diff --git a/.claude/commands/commit.md b/.claude/commands/commit.md new file mode 100644 index 0000000..842d954 --- /dev/null +++ b/.claude/commands/commit.md @@ -0,0 +1,48 @@ +# /commit — Commit + +Git 커밋 규칙에 따라 커밋 메시지를 생성하고 커밋한다. + +## Steps + +1. 현재 브랜치 이름을 확인한다. + + ``` + git branch --show-current + ``` + +2. 브랜치 이름에서 이슈 번호를 추출한다. + - 규칙: `/` 이후 첫 번째 숫자 + - 예: `feat/42-addSearchFilter` → `42` + +3. `gh issue view <번호> --json title,body,labels` 로 이슈를 조회해 맥락을 파악한다. + +4. `git diff --staged` 또는 `git diff HEAD` 로 변경 내용을 확인한다. + - 변경 내용을 기반으로 커밋 메시지를 한국어로 작성한다. + - 사용자에게 확인을 구하지 않는다. + +5. 커밋 메시지 포맷: + + ``` + : 변경 내용 요약 (한국어) (#이슈번호) + ``` + + 예: `feat : 검색 필터 API 연동 (#42)` + +6. 스테이징 및 커밋 실행: + + ``` + git add -A + git commit -m " : 변경 내용 요약 (#이슈번호)" + ``` + +7. 완료 후 출력: + ``` + ✅ 커밋 완료: : 변경 내용 요약 (#이슈번호) + ``` + +## Notes + +- `git push` 는 명시적으로 요청받았을 때만 실행한다. +- `commit all` 명령 시 이 플로우를 즉시 실행한다. +- /verify 를 통과하지 않은 상태에서 커밋 요청 시 + "/verify 를 먼저 실행하세요." 를 출력하고 중단한다. diff --git a/.claude/commands/green.md b/.claude/commands/green.md new file mode 100644 index 0000000..2e9e7eb --- /dev/null +++ b/.claude/commands/green.md @@ -0,0 +1,40 @@ +# /green — Green Phase + +실패 중인 테스트를 통과시키는 최소한의 구현 코드를 작성한다. + +## Rules + +- **과도한 추상화 금지**: 지금 당장 필요한 것만 구현한다. 미래를 위한 설계는 /refactor 단계에서 한다. +- **컴포넌트**: 함수형 컴포넌트 + hooks only. 클래스 컴포넌트 금지. +- **서버 상태**: `useQuery` / `useMutation` 만 사용. 컴포넌트 내 axios 직접 호출 금지. +- **타입**: `any` 사용 금지. 명시적 interface 또는 generic 사용. +- **에러/로딩 처리**: skeleton 및 error boundary 상태를 항상 처리한다. + +## Steps + +1. 실패 중인 테스트 목록을 확인한다 (`pnpm vitest run {파일경로}`). +2. 테스트를 통과시키는 구현 코드를 작성한다. +3. `pnpm vitest run {파일경로}` 를 재실행해 모든 테스트가 통과하는지 확인한다. +4. 통과 후 아래 형식으로 출력한다. + +--- + +## ✅ Green Phase 완료 + +**통과한 테스트**: N개 +**작성/수정한 파일**: + +- `경로/파일명` — (한 줄 설명) + +## 🎓 **Mentor note**: (이번 구현에서 적용한 패턴 또는 주니어가 놓치기 쉬운 포인트) + +5. 아래 다음 단계 안내를 출력한다. + +### 👉 다음 단계 + +| 명령어 | 설명 | +| ----------- | ----------------------------- | +| `/refactor` | 코드 품질 개선 (동작 변경 X, 생략 가능) | +| `/verify` | 품질에 문제 없으면 바로 검증 (필수) | + +> `/refactor` 는 생략 가능. `/verify` → `/commit` 은 항상 실행. diff --git a/.claude/commands/pr.md b/.claude/commands/pr.md new file mode 100644 index 0000000..2dd05ec --- /dev/null +++ b/.claude/commands/pr.md @@ -0,0 +1,83 @@ +# /pr — Pull Request + +현재 브랜치의 PR을 생성하고 Qodo AI 코드 리뷰를 요청한다. + +## Steps + +1. 현재 브랜치 이름을 확인한다. + + ``` + git branch --show-current + ``` + +2. 브랜치 이름에서 작업 유형과 이슈 번호를 추출한다. + - 규칙: `/-` + - 예: `feat/42-addSearchFilter` → type=`feat`, issue=`42` + +3. `gh issue view <번호> --json title,body,labels` 로 이슈 정보를 조회한다. + +4. `git log develop..HEAD --oneline` 과 `git diff develop...HEAD` 로 변경 내용을 파악한다. + +5. `.github/pull_request_template.md` 양식에 맞춰 PR 본문을 작성한다. + + ```markdown + ## 📌 PR 제목 + + ### [Type] : 작업 내용 요약 + + ## 📌 변경 사항 + + - 변경 1 + - 변경 2 + + ## 💬 추가 참고 사항 + + - 관련 이슈: #<번호> + ``` + + - PR 제목: `[Type] : 작업 내용 요약 (#이슈번호)` (한국어) + - Type은 브랜치의 작업 유형을 대문자로 (feat → Feat, fix → Fix 등) + - 변경 사항은 커밋 내역과 diff를 기반으로 bullet 정리 + +6. PR을 생성한다. + + ``` + gh pr create --base develop --title "" --body "" + ``` + + 생성된 PR 번호를 추출한다. + +7. Qodo AI 코드 리뷰를 위해 댓글을 순서대로 작성한다. + + ``` + gh pr comment --body "/describe" + gh pr comment --body "/review" + gh pr comment --body "/improve" + ``` + +8. 완료 후 아래 형식으로 출력한다. + +--- + +## 📋 PR 생성 완료 + +**PR**: # — +**Base**: `develop` ← `<현재 브랜치>` +**이슈**: #<이슈번호> + +### 🤖 Qodo AI 리뷰 요청 + +- [x] `/describe` — PR 설명 자동 생성 +- [x] `/review` — 코드 리뷰 +- [x] `/improve` — 개선 제안 + +**PR 링크**: + +--- + +## Notes + +- PR의 base 브랜치는 `develop` 이다. +- 이슈 번호를 추출할 수 없는 경우 이슈 연결 없이 PR을 생성한다. +- PR 생성 실패 시 에러 메시지를 출력하고 중단한다. +- Qodo AI 댓글 실패 시 경고를 출력하되 PR 생성 자체는 성공으로 처리한다. diff --git a/.claude/commands/red.md b/.claude/commands/red.md new file mode 100644 index 0000000..cd015e3 --- /dev/null +++ b/.claude/commands/red.md @@ -0,0 +1,41 @@ +# /red — Red Phase + +현재 작업 범위에 대해 실패하는 테스트를 먼저 작성한다. 구현 코드는 작성하지 않는다. + +## Rules + +- 테스트 파일 위치: 구현 파일과 동일 경로에 `*.test.ts(x)` 생성 +- 테스트 러너: Vitest (`import { describe, it, expect } from 'vitest'`) +- 아직 존재하지 않는 함수/컴포넌트를 import해도 된다. + 테스트가 컴파일 에러 또는 실패 상태여야 정상이다. +- 테스트 설명은 한국어로 작성한다. (`it('빈 배열이면 빈 문자열을 반환한다')`) +- `any` 타입 사용 금지. 테스트에도 명시적 타입을 사용한다. + +## Test Coverage + +아래 케이스를 커버하는 테스트를 작성한다. + +1. **Happy path**: 정상 입력 → 예상 출력 +2. **Edge case**: 빈 값, null, undefined, 경계값 +3. **Error case**: 에러 발생 시 동작 (throw, error state 등) + +## Steps + +1. /spsc 에서 정의한 완료 기준을 기반으로 테스트 케이스 목록을 먼저 나열한다. +2. 테스트 코드를 작성한다. +3. `pnpm vitest run {파일경로}` 를 실행해 테스트가 실패하는지 확인한다. +4. 실패 확인 후 아래를 출력한다. + +--- + +## 🔴 Red Phase 완료 + +**작성한 테스트 케이스**: + +- [ ] (케이스 목록) + +### 👉 다음 단계 + +| 명령어 | 설명 | +| --------- | ------------------------ | +| `/green` | 테스트를 통과시키는 구현 | diff --git a/.claude/commands/refactor.md b/.claude/commands/refactor.md new file mode 100644 index 0000000..4f52203 --- /dev/null +++ b/.claude/commands/refactor.md @@ -0,0 +1,58 @@ +# /refactor — Refactor Phase + +테스트를 통과한 코드의 품질을 개선한다. 동작은 변경하지 않는다. + +## Checklist + +아래 기준으로 코드를 검토하고, 문제가 있으면 수정한다. + +### 구조 + +- [ ] SRP: 하나의 함수/컴포넌트가 너무 많은 일을 하지 않는가? + → 로직이 많으면 custom hook으로 분리 +- [ ] DRY: 중복 코드가 있는가? + → 공통 유틸 또는 shared 컴포넌트로 추출 +- [ ] 컴포넌트가 100줄을 넘는가? + → 하위 컴포넌트로 분리 검토 + +### 타입 + +- [ ] `any` 타입이 있는가? → 제거 +- [ ] 리터럴 유니온 타입으로 좁힐 수 있는 `string`/`number`가 있는가? +- [ ] Props interface가 명시적으로 정의되어 있는가? + +### 성능 + +- [ ] `useMemo`/`useCallback`이 증명 없이 남용되고 있지 않은가? +- [ ] 불필요한 리렌더링을 유발하는 구조가 있는가? + +### 네이밍 + +- [ ] 함수/변수명이 역할을 명확히 설명하는가? +- [ ] 이벤트 핸들러는 `handle` 접두어를 사용하는가? (`handleSubmit`, `handleChange`) +- [ ] boolean은 `is`/`has`/`can` 접두어를 사용하는가? + +## Steps + +1. 위 체크리스트를 순서대로 검토한다. +2. 문제가 있는 항목만 수정한다 (diff 중심으로 출력). +3. 수정 후 `pnpm vitest run {파일경로}` 를 실행해 테스트가 여전히 통과하는지 확인한다. +4. 아래 형식으로 출력한다. + +--- + +## 🔧 Refactor 완료 + +**개선한 항목**: + +- (체크리스트 항목 + 간단한 이유) + +**변경 없는 항목**: (개선이 필요 없었던 항목) + +## 🎓 **Mentor note**: (이번 리팩토링의 핵심 포인트) + +### 👉 다음 단계 + +| 명령어 | 설명 | +| --------- | ------------------ | +| `/verify` | 머지 전 전체 검증 | diff --git a/.claude/commands/spsc.md b/.claude/commands/spsc.md new file mode 100644 index 0000000..936b63b --- /dev/null +++ b/.claude/commands/spsc.md @@ -0,0 +1,53 @@ +# /spsc — Spec & Scope + +주어진 GitHub Issue 번호를 기반으로 작업 범위를 정의한다. + +## Steps + +1. `gh issue view <번호> --json title,body,labels,assignees,milestone` 로 이슈 상세를 조회한다. + - 체크리스트(task list)가 있으면 하위 작업 목록도 함께 확인한다. + +2. 아래 형식으로 작업 범위를 출력한다. + +--- + +## 📋 Spec & Scope — #{ISSUE-NUMBER} + +**이슈 제목**: (원문) +**작업 유형**: Feature | Bugfix | Refactor | Chore + +### 구현 범위 + +- (구체적인 작업 항목 bullet) + +### 변경 예상 파일 + +- `src/features/.../` — (이유) +- `src/shared/.../` — (이유) + +### 범위 외 (이번 작업에서 하지 않는 것) + +- (명시적으로 제외할 항목) + +### 완료 기준 + +- [ ] (체크리스트 형태) + +--- + +3. 출력 후 "이 범위로 진행할까요?" 라고 확인을 구한다. + - 승인 시 작업 브랜치를 생성한다. + - 브랜치 형식: `/-` + - type 매핑: Feature → `feat`, Bugfix → `fix`, Refactor → `refactor`, Chore → `chore` + - 예: `feat/42-addSearchFilter` + - develop 브랜치에서 분기한다. + - 이후 아래 다음 단계 안내를 출력한다. + +### 👉 다음 단계 + +| 명령어 | 설명 | +| --------- | ---------------------------- | +| `/red` | 실패 테스트 먼저 작성 (TDD) | +| `/green` | 바로 구현 시작 | + +> `/red` ~ `/refactor` 사이클은 생략 가능. `/verify` → `/commit` 은 필수. diff --git a/.claude/commands/start.md b/.claude/commands/start.md new file mode 100644 index 0000000..14826fa --- /dev/null +++ b/.claude/commands/start.md @@ -0,0 +1,76 @@ +# /start — Start Task + +작업 설명을 받아 GitHub Issue를 생성하고, 해당 브랜치로 체크아웃한다. + +## Input + +`$ARGUMENTS` — 작업 설명 (자연어) + +예: `/start 검색 결과에 페이지네이션 추가` + +## Steps + +1. `$ARGUMENTS` 를 분석해 아래 항목을 결정한다. + - **작업 유형**: `feat` | `fix` | `hotfix` | `chore` | `refactor` | `doc` + - **이슈 제목**: 한국어, 간결하게 + - **이슈 본문**: 구현할 내용을 bullet으로 정리 + - **라벨**: 작업 유형에 맞는 라벨 (없으면 생략) + +2. GitHub Issue를 생성한다. + + ``` + gh issue create --title "<이슈 제목>" --body "<이슈 본문>" + ``` + + 생성된 이슈 번호를 추출한다. + +3. develop 브랜치를 최신으로 갱신한다. + + ``` + git checkout develop + git pull origin develop + ``` + +4. 작업 브랜치를 생성하고 체크아웃한다. + - 브랜치 형식: `/-` + - camelCaseName은 이슈 제목에서 핵심 키워드를 추출해 작성한다. + + ``` + git checkout -b /- + ``` + +5. 완료 후 아래 형식으로 출력한다. + +--- + +## 🚀 작업 시작 + +**이슈**: #<번호> — <제목> +**브랜치**: `/-` +**유형**: <작업 유형> + +### 👉 다음 단계 + +| 명령어 | 설명 | +| --------- | ------------------------ | +| `/spsc` | 작업 범위 정의 (권장) | +| `/red` | 테스트 먼저 작성 | +| `/green` | 바로 구현 시작 | + +### 🔄 워크플로우 사이클 + +``` +일반: /start → /spsc → /red → /green → /refactor → /verify → /commit +단축: /start → /spsc → /green → /verify → /commit +``` + +- `/red` ~ `/refactor` 사이클은 상황에 따라 생략 가능하다. +- `/verify` 와 `/commit` 은 항상 실행한다. +- 긴급 핫픽스: `/spsc` → `/green` → `/verify` → `/commit` 단축 사이클 허용. + +--- + +## Notes + +- `$ARGUMENTS` 가 비어 있으면 "작업 내용을 입력해주세요." 를 출력하고 중단한다. +- 이슈 생성 실패 시 에러 메시지를 출력하고 중단한다. diff --git a/.claude/commands/verify.md b/.claude/commands/verify.md new file mode 100644 index 0000000..5aab262 --- /dev/null +++ b/.claude/commands/verify.md @@ -0,0 +1,59 @@ +# /verify — Verify Phase + +머지 전 전체 품질을 검증한다. 실패 시 자동으로 수정하고 재실행한다. + +## Steps + +아래 커맨드를 순서대로 실행한다. +각 단계가 실패하면 즉시 수정하고 재실행한다. +사용자에게 확인을 구하지 않고 자동으로 처리한다. + +1. **Type check** + + ``` + pnpm build + ``` + + 실패 시: TypeScript 에러를 수정한다. + +2. **Lint** + + ``` + pnpm lint + ``` + + 실패 시: ESLint 에러를 수정한다. `eslint-disable` 주석으로 우회하지 않는다. + +3. **Format** + + ``` + pnpm format + ``` + +4. **Unit test** + + ``` + pnpm test + ``` + + 실패 시: 실패한 테스트를 분석하고 구현 코드를 수정한다. + 테스트를 삭제하거나 skip 처리하지 않는다. + +5. 모든 단계 통과 후 아래 형식으로 출력한다. + +--- + +## ✅ Verify 완료 + +| 단계 | 결과 | +| ---------- | ----------- | +| Type check | ✅ | +| Lint | ✅ | +| Format | ✅ | +| Test | ✅ N개 통과 | + +### 👉 다음 단계 + +| 명령어 | 설명 | +| --------- | ------------- | +| `/commit` | 커밋 실행 | diff --git a/.claude/settings.json b/.claude/settings.json new file mode 100644 index 0000000..0ef714b --- /dev/null +++ b/.claude/settings.json @@ -0,0 +1,16 @@ +{ + "hooks": { + "SessionStart": [ + { + "hooks": [ + { + "type": "command", + "command": "git fetch --prune 2>&1 && git branch -vv | awk '/: gone]/{print $1}' | xargs -r git branch -D 2>&1 || true", + "timeout": 30, + "statusMessage": "원격 삭제된 브랜치 정리 중..." + } + ] + } + ] + } +} diff --git a/.claude/skills/find-skills/SKILL.md b/.claude/skills/find-skills/SKILL.md new file mode 100644 index 0000000..f92bce2 --- /dev/null +++ b/.claude/skills/find-skills/SKILL.md @@ -0,0 +1,143 @@ +--- +name: find-skills +description: Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill. +--- + +# Find Skills + +This skill helps you discover and install skills from the open agent skills ecosystem. + +## When to Use This Skill + +Use this skill when the user: + +- Asks "how do I do X" where X might be a common task with an existing skill +- Says "find a skill for X" or "is there a skill for X" +- Asks "can you do X" where X is a specialized capability +- Expresses interest in extending agent capabilities +- Wants to search for tools, templates, or workflows +- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.) + +## What is the Skills CLI? + +The Skills CLI (`npx skills`) is the package manager for the open agent skills ecosystem. Skills are modular packages that extend agent capabilities with specialized knowledge, workflows, and tools. + +**Key commands:** + +- `npx skills find [query]` - Search for skills interactively or by keyword +- `npx skills add ` - Install a skill from GitHub or other sources +- `npx skills check` - Check for skill updates +- `npx skills update` - Update all installed skills + +**Browse skills at:** https://skills.sh/ + +## How to Help Users Find Skills + +### Step 1: Understand What They Need + +When a user asks for help with something, identify: + +1. The domain (e.g., React, testing, design, deployment) +2. The specific task (e.g., writing tests, creating animations, reviewing PRs) +3. Whether this is a common enough task that a skill likely exists + +### Step 2: Check the Leaderboard First + +Before running a CLI search, check the [skills.sh leaderboard](https://skills.sh/) to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options. + +For example, top skills for web development include: + +- `vercel-labs/agent-skills` — React, Next.js, web design (100K+ installs each) +- `anthropics/skills` — Frontend design, document processing (100K+ installs) + +### Step 3: Search for Skills + +If the leaderboard doesn't cover the user's need, run the find command: + +```bash +npx skills find [query] +``` + +For example: + +- User asks "how do I make my React app faster?" → `npx skills find react performance` +- User asks "can you help me with PR reviews?" → `npx skills find pr review` +- User asks "I need to create a changelog" → `npx skills find changelog` + +### Step 4: Verify Quality Before Recommending + +**Do not recommend a skill based solely on search results.** Always verify: + +1. **Install count** — Prefer skills with 1K+ installs. Be cautious with anything under 100. +2. **Source reputation** — Official sources (`vercel-labs`, `anthropics`, `microsoft`) are more trustworthy than unknown authors. +3. **GitHub stars** — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism. + +### Step 5: Present Options to the User + +When you find relevant skills, present them to the user with: + +1. The skill name and what it does +2. The install count and source +3. The install command they can run +4. A link to learn more at skills.sh + +Example response: + +``` +I found a skill that might help! The "react-best-practices" skill provides +React and Next.js performance optimization guidelines from Vercel Engineering. +(185K installs) + +To install it: +npx skills add vercel-labs/agent-skills@react-best-practices + +Learn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices +``` + +### Step 6: Offer to Install + +If the user wants to proceed, you can install the skill for them: + +```bash +npx skills add -g -y +``` + +The `-g` flag installs globally (user-level) and `-y` skips confirmation prompts. + +## Common Skill Categories + +When searching, consider these common categories: + +| Category | Example Queries | +| --------------- | ---------------------------------------- | +| Web Development | react, nextjs, typescript, css, tailwind | +| Testing | testing, jest, playwright, e2e | +| DevOps | deploy, docker, kubernetes, ci-cd | +| Documentation | docs, readme, changelog, api-docs | +| Code Quality | review, lint, refactor, best-practices | +| Design | ui, ux, design-system, accessibility | +| Productivity | workflow, automation, git | + +## Tips for Effective Searches + +1. **Use specific keywords**: "react testing" is better than just "testing" +2. **Try alternative terms**: If "deploy" doesn't work, try "deployment" or "ci-cd" +3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills` + +## When No Skills Are Found + +If no relevant skills exist: + +1. Acknowledge that no existing skill was found +2. Offer to help with the task directly using your general capabilities +3. Suggest the user could create their own skill with `npx skills init` + +Example: + +``` +I searched for skills related to "xyz" but didn't find any matches. +I can still help you with this task directly! Would you like me to proceed? + +If this is something you do often, you could create your own skill: +npx skills init my-xyz-skill +``` diff --git a/.gitignore b/.gitignore index 02f5a07..a4dd6ba 100644 --- a/.gitignore +++ b/.gitignore @@ -46,7 +46,6 @@ yarn-error.log* .gitmessage.txt # Claude Code local settings (contains secrets) -.claude/* temp/ .vscode \ No newline at end of file diff --git a/.gitmessage.txt b/.gitmessage.txt deleted file mode 100644 index 1d65fac..0000000 --- a/.gitmessage.txt +++ /dev/null @@ -1,23 +0,0 @@ -################ -# <타입>: <제목> 의 형식으로 제목을 아래 공백줄에 작성 -# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지 -# 예) feat : 로그인 기능 추가 - -################ -# 본문(구체적인 내용)을 아랫줄에 작성 -# 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내) - -################ -# 꼬릿말(footer)을 아랫줄에 작성 (현재 커밋과 관련된 이슈 번호 추가 등) -# 예) Close #7 - -################ -# feat : 새로운 기능 추가 -# fix : 버그 수정 -# docs : 문서 수정 -# style : 코드 의미에 영향을 주지 않는 변경사항 -# refactor : 코드 리팩토링 -# test : 테스트 코드 추가 -# chore : 빌드 부분 혹은 패키지 매니저 수정사항 -# init : 초기 세팅 작업 -################ \ No newline at end of file diff --git a/CLAUDE.md b/CLAUDE.md index 4cc0f88..ad72a5a 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -58,37 +58,60 @@ See [apps/web/CLAUDE.md](apps/web/CLAUDE.md) for full detail. Key points: - **Tailwind CSS v4** + **shadcn/ui** in `src/components/ui/` (do not modify directly) - Path alias `@/` → `src/` -## Git Workflows +## Workflow Commands -### "branch 정리해줘" +`.claude/commands/` 에 정의된 슬래시 커맨드로 작업을 진행한다. -원격에서 merge 후 삭제된 브랜치를 로컬에서도 동기화한다. +### 전체 플로우 -```bash -# 1. 원격 삭제된 브랜치 참조 정리 -git fetch --prune +``` +/start → /spsc → /red → /green → /refactor → /verify → /commit +``` -# 2. 원격에 없는 로컬 브랜치 목록 확인 -git branch -vv | grep ': gone]' +| 커맨드 | 설명 | 필수 여부 | +| ----------- | --------------------------------------- | --------- | +| `/start` | GitHub Issue 생성 + 작업 브랜치 체크아웃 | 권장 | +| `/spsc` | 이슈 기반 작업 범위 정의 | 권장 | +| `/red` | 실패 테스트 먼저 작성 (TDD) | 생략 가능 | +| `/green` | 구현 코드 작성 | 필수 | +| `/refactor` | 코드 품질 개선 (동작 변경 X) | 생략 가능 | +| `/verify` | build, lint, format, test 전체 검증 | **필수** | +| `/commit` | 커밋 메시지 생성 및 커밋 | **필수** | -# 3. 삭제 대상 브랜치 제거 (main, develop, 현재 브랜치 제외) -git branch -vv | grep ': gone]' | awk '{print $1}' | xargs -r git branch -d -``` +### 단축 사이클 -- `-d` 플래그 사용 (merge되지 않은 브랜치는 삭제 안 됨, 안전) -- 삭제 전 목록을 사용자에게 보여주고 확인 후 진행 +- 긴급 핫픽스: `/start` → `/spsc` → `/green` → `/verify` → `/commit` +- `/red` ~ `/refactor` 는 상황에 따라 생략 가능하나, `/verify` → `/commit` 은 항상 실행한다. ## Git Conventions -Branch format: `/` — flow: `feat/*` → `develop` → `main` - -Commit format: ` : ` (space before and after colon) +Branch format: `/-` — flow: `feat/*` → `develop` → `main` Types: `feat`, `fix`, `hotfix`, `chore`, `refactor`, `doc` +Branch examples: +``` +feat/42-addSearchFilter +fix/57-songCardCss +chore/61-versionBump +``` + +Commit format: ` : (#issue-number)` (space before and after colon) + Examples: ``` -feat : MarqueeText 자동 스크롤 텍스트 적용 -fix : SongCard css 수정 -chore : 버전 2.3.0 +feat : MarqueeText 자동 스크롤 텍스트 적용 (#42) +fix : SongCard css 수정 (#57) +chore : 버전 2.3.0 (#61) ``` + +## Self-Maintenance + +이 파일(CLAUDE.md)은 프로젝트의 규칙과 구조가 변경될 때 함께 업데이트한다. +별도 요청 없이도 아래 항목에 해당하는 변경이 발생하면 자동으로 반영한다. + +- 커맨드(`.claude/commands/`) 추가·수정·삭제 시 → **Workflow Commands** 섹션 반영 +- 브랜치·커밋 규칙 변경 시 → **Git Conventions** 섹션 반영 +- 패키지 추가·삭제·구조 변경 시 → **Monorepo Structure** 섹션 반영 +- 기술 스택·아키텍처 변경 시 → **Web App Architecture** 섹션 반영 +- 빌드·린트·포맷 명령어 변경 시 → **Commands** 섹션 반영