[DEPLOY] 1차 main 브랜치 프로덕션 배포

.agents/skills/api-integration-workflow/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: api-integration-workflow
+description: Use this when adding API helpers, request/response types, TanStack Query hooks, query keys, or cache behavior.
+---
+
+# API Integration Workflow
+
+## Purpose
+
+Implement predictable API boundaries and React Query usage for Roominus Admin.
+
+## Read First
+
+- `AGENTS.md`
+- `.agents/skills/project-conventions-workflow/SKILL.md` for file naming and commit conventions when relevant
+- Existing API/client/query patterns in `src/features` and `src/shared`
+- Endpoint docs or backend contract supplied by the user
+
+## Required Inputs
+
+- HTTP method and path
+- Request params, search params, or body
+- Response shape
+- Expected error shape, if known
+- Usage site or page
+
+If the API contract is unclear and cannot be inferred from local code, ask before inventing fields.
+
+## Rules
+
+- Keep request/response types close to the API boundary.
+- Include every response-changing input in the query key.
+- Prefer domain-local API helpers first. Promote to `src/shared` only when multiple real users exist.
+- Do not add optimistic updates, retries, or broad invalidation unless the UX needs them.
+- Surface errors explicitly enough for the page to render useful states.
+- Keep mapping/normalization near the boundary when it protects the UI from backend shape changes.
+
+## Implementation Flow
+
+1. Find existing `axios` and `@tanstack/react-query` usage.
+2. Add or reuse a typed API helper.
+3. Add query keys before hooks when caching is involved.
+4. Add query or mutation hooks with narrow inputs and readable return values.
+5. Wire the hook into the page or component without mixing transport details into UI.
+6. Verify lint/build according to change risk.
+
+## Done Criteria
+
+- Types describe the API boundary.
+- Query keys include response-changing inputs.
+- Cache invalidation or update behavior is intentional.
+- Errors are not silently swallowed.
+- Verification is run or the skipped check is explained.

.agents/skills/api-integration-workflow/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: 'API Integration Workflow'
+  short_description: 'Add API helpers and React Query hooks.'
+  default_prompt: '$api-integration-workflow로 API 연동과 query key/cache 동작까지 구현해줘.'
+policy:
+  allow_implicit_invocation: true

.agents/skills/app-structure-evolution-workflow/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: app-structure-evolution-workflow
+description: Use this when deciding whether Roominus Admin should evolve from route-local pages into a domain-oriented Next.js App Router structure, especially when referencing the DONGCHIMI client folder structure, adding multiple related admin pages, creating route groups, or moving code between src/app, src/features, src/domains, and src/shared.
+---
+
+# App Structure Evolution Workflow
+
+## Purpose
+
+Guide structural decisions for Roominus Admin as it grows. Use DONGCHIMI client as a reference pattern, but adapt it conservatively to this repo's current size, stack, and admin product needs.
+
+## Read First
+
+- `AGENTS.md`
+- Nearby files in `src/app`, `src/features`, `src/shared`, and `src/assets`
+- When the user explicitly provides a reference project path, inspect only the relevant route, domain or feature, and shared folders from that path.
+
+## Current Baseline
+
+- Keep `src/app` as the routing layer.
+- Keep small route-only UI close to the route while the app is still shallow.
+- Use `src/shared` only for code reused by more than one page or clearly app-wide primitives.
+- Use `src/features` for domain-specific code only when a feature has enough substance to justify the folder.
+- Do not introduce Vanilla Extract, a monorepo package, generators, or DONGCHIMI-only infrastructure unless the user explicitly asks and the repo has the need.
+
+## Reference Pattern From DONGCHIMI
+
+DONGCHIMI client uses this dependency direction:
+
+```text
+app -> domains -> shared
+```
+
+Its main idea is:
+
+- `src/app`: Next route entries, route groups, layouts, metadata, providers, route handlers.
+- `src/domains/{domain}`: real page composition, domain APIs, hooks, models, query keys.
+- `src/shared`: app-wide API clients, reusable UI, auth helpers, constants, query setup, hooks, utilities.
+
+Treat this as a growth target, not an immediate migration plan.
+
+Use the current repository's `src/app`, `src/features`, and `src/shared` as the default inputs for structure decisions. Compare with DONGCHIMI or any other reference project only when the user provides that reference path for the current task.
+
+## When To Stay Route-Local
+
+Keep code inside `src/app/{route}` or a nearby route-local component when:
+
+- The page is one screen with little logic.
+- Components are not reused elsewhere.
+- There is no domain API, query key, mutation, or shared model yet.
+- Moving files would create ceremony without reducing complexity.
+
+Example:
+
+```text
+src/app/login/page.tsx
+```
+
+## When To Introduce A Domain Folder
+
+Introduce a domain folder when at least two of these are true:
+
+- A route has several sections, components, hooks, or utilities.
+- Multiple pages share one business domain.
+- API helpers, query hooks, request/response models, or query keys appear.
+- Page logic is becoming hard to scan inside `src/app`.
+- A route group or admin shell separates auth pages from authenticated pages.
+
+Prefer this shape:
+
+```text
+src/app/(auth)/login/page.tsx
+src/features/auth/login/LoginPage.tsx
+src/features/auth/login/components/
+src/features/auth/login/sections/
+```
+
+If this repo later standardizes on `src/domains`, update `AGENTS.md` and this skill first, then migrate intentionally.
+
+## App Router Rules
+
+- Keep route files thin: parse `params` and `searchParams`, connect layouts, then render page composition.
+- Keep pages and layouts as Server Components by default.
+- Put `'use client'` only in the smallest component that needs state, events, browser APIs, effects, providers, or TanStack Query hooks.
+- Use route groups only when they clarify layout or access boundaries, such as `(auth)` and `(admin)`.
+- Put route constants in `src/shared/constants/routes.ts` once paths are referenced in multiple places.
+
+## API And State Placement
+
+- Keep request/response types near the API boundary.
+- Put shared API helpers under `src/shared/api` only when more than one feature needs them.
+- Put feature-specific API helpers and hooks under `src/features/{domain}` when they are not broadly reusable.
+- Include response-changing inputs in React Query keys.
+- Keep transport and mutation logic out of presentational components.
+
+## Migration Flow
+
+1. Identify the route or feature that is becoming large.
+2. List the code that is route-only, feature/domain-level, and shared.
+3. Move only the code whose new owner is clear.
+4. Keep the route entry thin and Server Component compatible.
+5. Update imports without renaming public routes unless requested.
+6. Run the lightest useful verification: use `git diff --check` for docs-only or agent-only changes, `pnpm lint` for applicable code changes, and `pnpm build` for route, layout, or boundary changes.
+
+## Done Criteria
+
+- `src/app` remains focused on routing and Next conventions.
+- New folders have a clear owner and are not speculative.
+- Shared code is actually shared or obviously app-wide.
+- Server/Client boundaries are still minimal.
+- The result is easier to navigate than the previous structure.

.agents/skills/app-structure-evolution-workflow/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: 'App Structure Evolution Workflow'
+  short_description: 'Evolve Roominus Admin structure using DONGCHIMI as a reference.'
+  default_prompt: '$app-structure-evolution-workflow로 Roominus Admin의 Next.js 폴더 구조를 점검하고 성장 방향을 제안해줘.'
+policy:
+  allow_implicit_invocation: true

.agents/skills/form-flow-workflow/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: form-flow-workflow
+description: Use this when implementing form validation, submit flows, mutations, and loading/error/success states.
+---
+
+# Form Flow Workflow
+
+## Purpose
+
+Implement predictable form behavior for Roominus Admin screens, including validation, submit state, server errors, and success handling.
+
+Use this with `api-integration-workflow` when a form submits to an API or uses a React Query mutation.
+
+## Read First
+
+- `AGENTS.md`
+- `.agents/skills/page-feature-workflow/SKILL.md` for route ownership
+- `.agents/skills/api-integration-workflow/SKILL.md` when submit calls an API
+- Existing forms or input patterns in `src/app`, `src/features`, and `src/shared`
+
+## Required Inputs
+
+- Fields and input types
+- Validation rules and user-facing error messages
+- Submit behavior
+- Loading, disabled, failure, and success behavior
+- API request and error shape when server-backed
+
+If validation or submit behavior is unclear and cannot be inferred from nearby code, ask before inventing business rules.
+
+## Rules
+
+- Keep field state, validation, submit orchestration, and transport concerns separated enough to read.
+- Do not hide server errors silently.
+- Disable submit only for intentional conditions such as invalid input, unchanged state, or in-flight submission.
+- Keep validation messages close to the relevant field when possible.
+- Ensure labels, focus-visible states, keyboard submission, and error association are usable.
+- Keep API payload mapping near the API boundary when it protects UI code.
+
+## Implementation Flow
+
+1. Decide whether the form belongs in the page, a route-local component, a feature component, or shared UI.
+2. Map each field to its source of truth, validation rule, and displayed error.
+3. Separate client validation from server error handling.
+4. Add mutation or submit logic with explicit loading and failure states.
+5. Handle success intentionally: refetch, invalidate, navigate, close dialog, or show feedback.
+6. Check keyboard flow, disabled behavior, and layout stability.
+7. Run targeted verification.
+
+## Done Criteria
+
+- Validation matches the requested behavior.
+- Submit state and disabled state are intentional.
+- Server errors are visible or otherwise handled deliberately.
+- Loading, failure, and success states are consistent.
+- Accessibility basics are covered for labels, focus, and error text.
+- Verification is run or the skipped check is explained.

.agents/skills/form-flow-workflow/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: 'Form Flow Workflow'
+  short_description: 'Implement validation and submit state for forms.'
+  default_prompt: '$form-flow-workflow로 Roominus Admin 폼 흐름을 구현해줘.'
+policy:
+  allow_implicit_invocation: true

.agents/skills/frontend-fundamentals-review/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: frontend-fundamentals-review
+description: Use this when reviewing frontend diffs for readability, predictability, cohesion, coupling, and logic composition.
+---
+
+# Frontend Fundamentals Review
+
+## Purpose
+
+Review frontend changes for maintainability risks beyond formatter, lint, and build results.
+
+Use this for non-trivial React, page, component, hook, or API wiring changes. Skip it for docs-only or formatting-only edits.
+
+## Read First
+
+- `AGENTS.md`
+- The current diff or requested files
+- Nearby components, hooks, API helpers, and usage sites
+- Relevant workflow skills for the changed area, such as `page-feature-workflow`, `shared-component-workflow`, `form-flow-workflow`, or `api-integration-workflow`
+
+## Review Criteria
+
+- Readability: names, control flow, component shape, and JSX structure are easy to scan.
+- Predictability: props, state, effects, keys, memoization, and return values behave as callers expect.
+- Cohesion: responsibilities stay close to the code that owns them.
+- Coupling: route, copy, API, analytics, and styling details do not leak into generic code.
+- Logic composition: extracted helpers or hooks have a real responsibility and stable usage sites.
+
+## Common Checks
+
+- Avoid render-time side effects.
+- Avoid copying props into state without a clear synchronization rule.
+- Avoid conditional hook calls, unstable list keys, and unnecessary `useMemo` or `useCallback`.
+- Keep presentational components free of transport details.
+- Keep route-only behavior out of shared components.
+- Do not extract a hook only because a component is long.
+- Prefer pure helpers for mapping, formatting, grouping, and validation that do not need React state.
+
+## Output Shape
+
+When reviewing, lead with findings:
+
+```markdown
+Findings:
+
+- [Severity] `path/to/file.tsx:line` - Issue.
+  Fix: Suggested change.
+
+Open questions:
+
+- Question, if any.
+
+Residual risk:
+
+- Anything not checked.
+```
+
+If no issues are found, say that clearly and mention any remaining verification gap.
+
+## Done Criteria
+
+- Findings are tied to files and lines when possible.
+- Suggestions are actionable and scoped.
+- Taste-only preferences are separated from correctness or maintainability risks.
+- Lint/build results are not treated as a substitute for review judgment.

.agents/skills/frontend-fundamentals-review/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: 'Frontend Fundamentals Review'
+  short_description: 'Review frontend diffs for maintainability risks.'
+  default_prompt: '$frontend-fundamentals-review로 현재 프론트엔드 변경사항을 리뷰해줘.'
+policy:
+  allow_implicit_invocation: true

.agents/skills/frontend-quality-verification/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: frontend-quality-verification
+description: Use this after Roominus Admin frontend changes to choose and run the smallest useful verification commands.
+---
+
+# Frontend Quality Verification
+
+## Purpose
+
+Pick checks that match the actual change. Keep verification light, but do enough to prove the work.
+
+## Read First
+
+- `package.json`
+- Changed files from `git status --short` or `git diff --name-only`
+
+## Verification Ladder
+
+| Change Type                                                            | Checks              |
+| ---------------------------------------------------------------------- | ------------------- |
+| Docs or agent files only                                               | `git diff --check`  |
+| Formatting-sensitive docs or code                                      | `pnpm format:check` |
+| TypeScript, React, or shared UI changes                                | `pnpm lint`         |
+| Next route, config, build, or Server/Client Component boundary changes | `pnpm build`        |
+
+Use `npm run ...` only if pnpm is not available in the environment.
+
+## Rules
+
+- Do not claim a check passed unless it was run successfully.
+- If a check fails, separate failures caused by the current change from pre-existing failures when possible.
+- If a check cannot run because dependencies or environment are missing, report that plainly.
+- For UI changes, mention any manual browser check that still matters.
+
+## Output Shape
+
+```markdown
+Verification:
+
+- `command`: pass/fail/not run
+- Notes:
+```

.agents/skills/frontend-quality-verification/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: 'Frontend Quality Verification'
+  short_description: 'Choose and run the right frontend checks.'
+  default_prompt: '$frontend-quality-verification으로 이번 변경에 맞는 검증을 해줘.'
+policy:
+  allow_implicit_invocation: true