feat: 던전 시스템과 레벨업 로직 추가

Fantasy-server/.agents/skills/commit/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: commit
 description: Creates Git commits by splitting changes into logical units. Use for staging files and writing commit messages.
-allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*)
+allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*), Bash(git branch:*), Bash(git switch:*)
 ---
 
 Create Git commits following the project's commit conventions.
 
 ## Argument
 
-`$ARGUMENTS` — optional GitHub issue number (e.g. `/commit 42`)
+`$ARGUMENTS` - optional GitHub issue number (e.g. `/commit 42`)
 
 - If provided, add `#42` as the commit body (blank line after subject, then the reference).
 - If omitted, commit without any issue reference.
@@ -28,23 +28,23 @@ With issue number:
 ```
 
 **Types**:
-- `feat` — new feature added
-- `fix` — bug fix, missing config, or missing DI registration
-- `update` — modification to existing code
-- `chore` — tooling, CI/CD, dependency updates, config changes unrelated to app logic
+- `feat` - new feature added
+- `fix` - bug fix, missing config, or missing DI registration
+- `update` - modification to existing code
+- `chore` - tooling, CI/CD, dependency updates, config changes unrelated to app logic
 
 **Description rules**:
 - Written in **Korean**
-- Short and imperative (단문)
+- Short and imperative
 - No trailing punctuation (`.`, `!` etc.)
-- Avoid noun-ending style — prefer verb style
+- Avoid noun-ending style; prefer verb style
 
 **Examples**:
 ```
 feat: 로그인 로직 추가
 ```
 ```
-fix: 세션 DI 누락 수정
+fix: 인증 DI 누락 수정
 
 #12
 ```
@@ -54,18 +54,35 @@ See `.claude/skills/commit/examples/type-guide.md` for a boundary-rule table and
 **Do NOT**:
 - Add Claude as co-author
 - Write descriptions in English
+- Commit directly on `develop`
+
+## Branch Rule
+
+Always check the current branch before staging or committing.
+
+- If the current branch is **not** `develop`, proceed with the normal commit flow.
+- If the current branch **is** `develop`:
+  - Review the changes first with `git status` and `git diff`
+  - Infer the dominant logical unit and create a new working branch before any `git add` or `git commit`
+  - Use a short branch name based on the work, such as `feat/player-resource-seed`, `fix/player-stage-config`, or `update/player-domain-cleanup`
+  - Run `git switch -c <branch-name>`
+  - Confirm the branch changed successfully, then continue the commit flow on that new branch
+
+Do not keep working on `develop` after detecting staged or unstaged changes there.
 
 ## Steps
 
-1. Check all changes with `git status` and `git diff`
-2. Categorize changes into logical units:
-   - New feature addition → `feat`
-   - Bug / missing registration fix → `fix`
-   - Modification to existing code → `update`
-3. Group files by each logical unit
-4. For each group:
+1. Check the current branch with `git branch --show-current`
+2. Check all changes with `git status` and `git diff`
+3. If the current branch is `develop`, create and switch to a new branch that matches the dominant logical unit before staging anything
+4. Categorize changes into logical units:
+   - New feature addition - `feat`
+   - Bug / missing registration fix - `fix`
+   - Modification to existing code - `update`
+5. Group files by each logical unit
+6. For each group:
    - Stage only the relevant files with `git add <files>`
    - Write a concise commit message following the format above
    - If `$ARGUMENTS` is provided: `git commit -m "{subject}" -m "#{issue}"`
    - If `$ARGUMENTS` is omitted: `git commit -m "{subject}"`
-5. Verify results with `git log --oneline -n {number of commits made}`
+7. Verify results with `git log --oneline -n {number of commits made}`

Fantasy-server/.agents/skills/write-pr/SKILL.md

@@ -129,16 +129,19 @@ rm PR_BODY.md
 
 - Follow the PR Title Convention below
 
-**Step 3. Write PR body**
+**Step 3. Ask the user which title to use**
 
-- Follow the PR Body Template below
-- Save to `PR_BODY.md`
+Use AskUserQuestion and present exactly these choices before proceeding:
+- `1`: first generated title
+- `2`: second generated title
+- `3`: third generated title
+- Wait for the user's answer before continuing to the next step
+- Use the selected numbered option to determine the final PR title
 
-**Step 4. Ask the user**
+**Step 4. Write PR body**
 
-Use AskUserQuestion with a `choices` array:
-- Options: the 3 generated titles plus `직접 입력` as the last option
-- If the user selects `직접 입력`, ask a follow-up AskUserQuestion for the custom title
+- Follow the PR Body Template below
+- Save to `PR_BODY.md`
 
 **Step 5. Select labels**
 
@@ -147,7 +150,7 @@ Use AskUserQuestion with a `choices` array:
 
 **Step 6. Create PR to `{Base Branch}`**
 
-- Use the selected title, or the custom title if the user chose `직접 입력`
+- Use the title selected by the user from options `1` / `2` / `3`
 
 ```bash
 ./scripts/create-pr.sh "{chosen title}" PR_BODY.md "{label1,label2}"

Fantasy-server/.claude/skills/commit/SKILL.md

@@ -1,71 +1,88 @@
----
-name: commit
-description: Creates Git commits by splitting changes into logical units. Use for staging files and writing commit messages.
-allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*)
----
-
-Create Git commits following the project's commit conventions.
-
-## Argument
-
-`$ARGUMENTS` — optional GitHub issue number (e.g. `/commit 42`)
-
-- If provided, add `#42` as the commit body (blank line after subject, then the reference).
-- If omitted, commit without any issue reference.
-
-## Commit Message Format
-
-Subject line only (no issue):
-```
-{type}: {Korean description}
-```
-
-With issue number:
-```
-{type}: {Korean description}
-
-#{issue}
-```
-
-**Types**:
-- `feat` — new feature added
-- `fix` — bug fix, missing config, or missing DI registration
-- `update` — modification to existing code
-- `chore` — tooling, CI/CD, dependency updates, config changes unrelated to app logic
-
-**Description rules**:
-- Written in **Korean**
-- Short and imperative (단문)
-- No trailing punctuation (`.`, `!` etc.)
-- Avoid noun-ending style — prefer verb style
-
-**Examples**:
-```
-feat: 로그인 로직 추가
-```
-```
-fix: 세션 DI 누락 수정
-
-#12
-```
-
-See `.claude/skills/commit/examples/type-guide.md` for a boundary-rule table and real scenarios from this project.
-
-**Do NOT**:
-- Add Claude as co-author
-- Write descriptions in English
-
-## Steps
-
-1. Check all changes with `git status` and `git diff`
-2. Categorize changes into logical units:
-   - New feature addition → `feat`
-   - Bug / missing registration fix → `fix`
-   - Modification to existing code → `update`
-3. Group files by each logical unit
-4. For each group:
-   - Stage only the relevant files with `git add <files>`
-   - Write a concise commit message following the format above
-   - If `$ARGUMENTS` is provided: `git commit -m "{subject}" -m "#{issue}"`
-   - If `$ARGUMENTS` is omitted: `git commit -m "{subject}"`
-5. Verify results with `git log --oneline -n {number of commits made}`
+---
+name: commit
+description: Creates Git commits by splitting changes into logical units. Use for staging files and writing commit messages.
+allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*), Bash(git branch:*), Bash(git switch:*)
+---
+
+Create Git commits following the project's commit conventions.
+
+## Argument
+
+`$ARGUMENTS` - optional GitHub issue number (e.g. `/commit 42`)
+
+- If provided, add `#42` as the commit body (blank line after subject, then the reference).
+- If omitted, commit without any issue reference.
+
+## Commit Message Format
+
+Subject line only (no issue):
+```
+{type}: {Korean description}
+```
+
+With issue number:
+```
+{type}: {Korean description}
+
+#{issue}
+```
+
+**Types**:
+- `feat` - new feature added
+- `fix` - bug fix, missing config, or missing DI registration
+- `update` - modification to existing code
+- `chore` - tooling, CI/CD, dependency updates, config changes unrelated to app logic
+
+**Description rules**:
+- Written in **Korean**
+- Short and imperative
+- No trailing punctuation (`.`, `!` etc.)
+- Avoid noun-ending style; prefer verb style
+
+**Examples**:
+```
+feat: 로그인 로직 추가
+```
+```
+fix: 인증 DI 누락 수정
+
+#12
+```
+
+See `.claude/skills/commit/examples/type-guide.md` for a boundary-rule table and real scenarios from this project.
+
+**Do NOT**:
+- Add Claude as co-author
+- Write descriptions in English
+- Commit directly on `develop`
+
+## Branch Rule
+
+Always check the current branch before staging or committing.
+
+- If the current branch is **not** `develop`, proceed with the normal commit flow.
+- If the current branch **is** `develop`:
+  - Review the changes first with `git status` and `git diff`
+  - Infer the dominant logical unit and create a new working branch before any `git add` or `git commit`
+  - Use a short branch name based on the work, such as `feat/player-resource-seed`, `fix/player-stage-config`, or `update/player-domain-cleanup`
+  - Run `git switch -c <branch-name>`
+  - Confirm the branch changed successfully, then continue the commit flow on that new branch
+
+Do not keep working on `develop` after detecting staged or unstaged changes there.
+
+## Steps
+
+1. Check the current branch with `git branch --show-current`
+2. Check all changes with `git status` and `git diff`
+3. If the current branch is `develop`, create and switch to a new branch that matches the dominant logical unit before staging anything
+4. Categorize changes into logical units:
+   - New feature addition - `feat`
+   - Bug / missing registration fix - `fix`
+   - Modification to existing code - `update`
+5. Group files by each logical unit
+6. For each group:
+   - Stage only the relevant files with `git add <files>`
+   - Write a concise commit message following the format above
+   - If `$ARGUMENTS` is provided: `git commit -m "{subject}" -m "#{issue}"`
+   - If `$ARGUMENTS` is omitted: `git commit -m "{subject}"`
+7. Verify results with `git log --oneline -n {number of commits made}`

Fantasy-server/.claude/skills/plan-deep-dive/SKILL.md

@@ -1,8 +1,32 @@
----
+---
 name: plan-deep-dive
 description: Conduct an in-depth structured interview with the user to uncover non-obvious requirements, tradeoffs, and constraints, then produce a detailed implementation spec file.
-argument-hint: [instructions]
-allowed-tools: AskUserQuestion, Write
+argument-hint: [feature description or task goal]
+allowed-tools: AskUserQuestion, Write, Bash(mkdir:*)
 ---
 
-Follow the user instructions and interview me in detail using the AskUserQuestionTool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious. be very in-depth and continue interviewing me continually until it's complete. then, write the spec to a file. <instructions>$ARGUMENTS</instructions>
+Use `$ARGUMENTS` as the primary description of the feature or task. Start the interview based on it and expand into detailed requirements.
+
+If `$ARGUMENTS` is provided, treat it as the initial feature idea and begin the interview immediately without asking for clarification of the topic itself.
+
+Interview me in detail using the AskUserQuestionTool about anything non-obvious: technical implementation, UI & UX, concerns, tradeoffs, constraints, edge cases, etc. Be very in-depth and continue interviewing me continually until it's complete.
+
+Once the interview is complete and you have enough information to write the spec:
+
+1. Derive a concise `feature-name` in kebab-case based on the full interview context. Do not rely solely on `$ARGUMENTS` — use it only as an initial hint. Examples: `dungeon-system`, `auth-refresh`, `player-inventory`.
+
+2. Create the plans directory if it doesn't exist:
+   ```bash
+   mkdir -p .claude/plans
+   ```
+
+3. Write the full spec to `.claude/plans/{feature-name}-plan.md`. Use structured markdown with headings (`#`, `##`, `###`), lists, and tables where appropriate.
+
+4. Copy the same content verbatim to `.claude/current_plan.md` (overwrite — do not summarize). This file always reflects the most recently created plan.
+
+5. Tell the user:
+   - The plan was saved to `.claude/plans/{feature-name}-plan.md`
+   - `.claude/current_plan.md` was updated
+   - They can run `/review-plan` to send this plan to Codex for review
+
+<task>$ARGUMENTS</task>