Menu
Use when the user asks to handle or work on a GitHub issue end-to-end — phrases like "이슈
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
production 배포 릴리즈를 진행한다. 최신 develop → 버전 입력 → develop 커밋/푸시 → master PR → skill 이 직접 npm test + E2E 통과 확인 → merge commit → master 머지커밋에 태그 push → tag push 가 prod CD 트리거. 사용자 발화 "릴리즈해", "/release", "release v1.2.3" 등으로 시작.
Use when the user asks to add, remove, or modify test data injected by the dev-only 🧪 button — triggers on phrases like "테스트 데이터 추가", "시드 데이터 수정", "test data seeder", "주입되는 데이터", or any request touching `src/dev/testDataSeeder.ts`, `src/components/dev/TestDataSeederButton.tsx`, or the dev-env data injection flow
| name | work-issue |
| description | Use when the user asks to handle or work on a GitHub issue end-to-end — phrases like "이슈 |
GitHub 이슈를 받아 프로젝트 CLAUDE.md의 "서브에이전트 기반 병렬 작업 플로우" 순서로 끝까지 처리하는 엔트리포인트.
Core principle: 프로젝트 CLAUDE.md가 진짜 규약이다. 이 스킬은 그 규약을 끝까지 발동시키는 트리거다. CLAUDE.md에 없는 부분만 이 스킬이 보강한다.
digraph work_issue {
rankdir=TB;
node [shape=box];
read_claude [label="0. 프로젝트 CLAUDE.md\n재확인 (브랜치/커밋/TDD 규약)"];
read_issue [label="1. 이슈 본문 + 코멘트 + 디자인 레퍼런스 읽기\n(gh issue view <N> --comments)"];
plan [label="2. 계획 수립\n(brainstorming → writing-plans)"];
conflict [label="3. 파일 충돌 맵 + 모델 배정\n(S: haiku, M: sonnet, L/XL: opus)"];
verify [label="4. 태스크 분해 검증\n(부분 ↔ 전체 양방향 대조)"];
verify_ok [label="분해 일치?" shape=diamond];
confirm [label="사용자 확인" shape=diamond];
worktree [label="5. 워크트리 + 이슈 브랜치\n(using-git-worktrees)"];
implement [label="6. 병렬 서브에이전트 실행\n(subagent-driven-development + TDD)"];
pr [label="7. push + PR 생성"];
review [label="8. 리뷰 사이클\n(요구사항 + 디자인 대조 + 코드 품질)"];
resolved [label="모든 지적 해소?" shape=diamond];
merge [label="9. rebase merge\n(approve + push 완료 후)"];
sync [label="10. 베이스 브랜치 pull\n+ 워크트리 정리"];
read_claude -> read_issue -> plan -> conflict -> verify -> verify_ok;
verify_ok -> conflict [label="재분해"];
verify_ok -> confirm [label="통과"];
confirm -> plan [label="수정"];
confirm -> worktree [label="승인"];
worktree -> implement -> pr -> review -> resolved;
resolved -> implement [label="no (반영 → push)"];
resolved -> merge [label="yes (approve)"];
merge -> sync;
}
프로젝트 루트의 CLAUDE.md (+ 상위 글로벌 ~/.claude/CLAUDE.md) 읽어 규약 추출:
이후 모든 단계에서 여기서 추출한 규약을 기준으로 한다. CLAUDE.md 규약이 이 스킬의 기본 기술과 상충하면 CLAUDE.md가 이긴다.
gh issue view <N> --comments
다음을 전부 파악:
디자인 이미지가 있으면 다운로드해서 직접 본다 (예: curl -sL <url> -o /tmp/<name>.png 후 Read 툴로 열람). 이미지에서 읽을 수 있는 요소:
추출한 요구사항 + 디자인 요소를 항목 체크리스트로 정리해둔다 — 4단계 분해 검증과 8단계 리뷰에서 대조한다.
superpowers:brainstorming — 스코프/접근 합의superpowers:writing-plans — TDD 플랜 문서화계획 문서 위치는 프로젝트 관례(예: docs/superpowers/specs/, docs/superpowers/plans/)를 따른다. 중요 결정은 이슈 코멘트로도 기록한다.
디자인 레퍼런스가 있으면 계획에 "디자인 대조 항목" 섹션을 포함한다 (레이아웃 구조, 필수 시각 요소, 인터랙션 패턴).
각 서브태스크에 대해 표로 정리:
| Task | 주요 수정 파일 | 충돌 그룹 | 복잡도 | 모델 |
|---|---|---|---|---|
| 1 | ... | A (독립) | M | sonnet |
| 2 | ... | B (독립) | S | haiku |
| 3 | ... | A+B (공유) | L | opus |
사용자에게 보여주기 전에 4단계 분해 검증을 통과시킨다.
사용자 승인 전에 자체 리뷰로 태스크 분해가 계획을 정확히 투영하는지 대조한다. 두 방향 모두 통과해야 승인 단계로 넘어간다.
a. 부분 → 전체 (Faithfulness): 각 태스크가 계획의 해당 부분을 충실히 반영하는가
b. 전체 → 부분 (Completeness): 태스크들을 합치면 계획/요구사항 전체가 커버되는가
대조 표 예시:
| 요구사항/계획 항목 | 담당 태스크 | 비고 |
|---|---|---|
| 요구사항 A-1 | Task 1 | |
| 요구사항 A-2 | Task 2, 3 | 공유 파일 — 순차 |
| 디자인 항목 D1 | Task 1 | |
| 디자인 항목 D2 | — | 🚨 누락 → 3단계로 돌아가 재분해 |
| 에러 처리 A-3 | Task 4 |
게이트 규칙:
superpowers:using-git-worktrees 호출. 베이스는 최신 베이스 브랜치. 브랜치명은 CLAUDE.md 규약.
git fetch origin
git worktree add <경로> -b <브랜치명> origin/<base-branch>
cd <경로>
# 프로젝트 setup (npm install, pip install, 등)
# .env.local 등 gitignore된 필수 파일 복사
# 베이스라인 테스트 실행
superpowers:subagent-driven-development로 독립 태스크 병렬 실행. 각 에이전트는:
superpowers:test-driven-development 엄수: 테스트 작성 → 실패 확인 → 구현 → 통과 → 커밋#N feat(scope): ...)공유 그룹(같은 파일 수정)은 순차. 병렬 안전성은 충돌 맵 기준.
모든 태스크 완료 + 로컬 전체 테스트 + (UI 변경 시) E2E 통과 후:
git push -u origin <브랜치명>
gh pr create --base <base-branch> --title "<이슈번호> 제목" --body "..."
PR body에 포함:
closes #<N> (자동 close)지적사항이 모두 해소될 때까지 반복:
a. 리뷰 에이전트 — 3중 대조
이슈 요구사항 대조
gh issue view <N>로 본문 + 코멘트 재확인디자인 대조 (디자인 레퍼런스가 이슈에 있는 경우 필수)
코드 품질 대조
인라인 코멘트로 해당 라인에 직접 지적 (한 PR 코멘트에 몰아쓰기 금지).
b. 구현 에이전트
c. 재리뷰
반드시 approve + push 완료 상태에서 실행. 머지 후 push 금지.
gh pr merge <N> --rebase --delete-branch
cd <메인 체크아웃>
git checkout <base-branch>
git pull --rebase origin <base-branch>
git worktree remove <워크트리 경로>
다음 태스크는 최신 base-branch 기반으로 새 워크트리/브랜치부터 시작.
| 증상 / 생각 | 실제 의미 |
|---|---|
| "CLAUDE.md 규약이 명시 안 된 부분은 내 판단으로" | 0단계에서 놓친 섹션이 있다. 다시 읽어라 |
| "이슈 본문만 봐도 요구사항은 알 수 있다" | 코멘트에 결정·피드백이 있다. --comments 필수 |
| "디자인 이미지는 대충 보면 감온다" | 다운로드해서 직접 열람. 항목 체크리스트 없이는 리뷰 대조 불가 |
| "디자인 대조는 구현 완료 후에 한 번 보면 된다" | 8단계 리뷰에서 재리뷰마다 통과해야 한다. "나중에"는 approve 게이트를 틀리는 것 |
| "시안에 명시 안 된 세부는 내가 판단" | 추측 금지. 애매하면 사용자에게 반문 |
| "파일 충돌 맵은 생략해도 감으로 병렬 가능" | 3단계 건너뛰면 병렬 중 머지 충돌 폭발 |
| "태스크 쪼갰으면 바로 사용자 승인 요청" | 4단계 분해 검증 누락. 부분→전체 / 전체→부분 대조 표 없이는 요구사항 구멍이 보이지 않는다 |
| "요구사항 체크리스트 항목 대부분 커버됐으니 됐다" | "대부분"은 커버리지가 아니다. 1단계 체크리스트의 모든 항목이 어느 태스크에 매핑됐는지 명시적으로 대조 |
| "태스크 지시에 계획 요점만 축약해 전달" | 축약 과정에서 제약·테스트 요구사항이 손실된다. 계획 해당 섹션을 태스크 지시에 원문에 가깝게 전달 |
| "순차가 안전하니 전부 순차로" | 충돌 맵 → 독립 그룹은 병렬. 전부 순차는 무의미 |
| "리뷰 한 번이면 충분" | 8단계는 루프. approve까지 간 적 없으면 반복 중 |
| "머지 후에 리뷰 반영" | 금지. 9단계는 approve + push 완료 후에만 |
| "개별 테스트만 돌려도 OK" | 각 커밋이 단독 빌드/테스트 통과 원칙 위배 |
| "테스트는 구현 후에 몰아서" | TDD 위배. 테스트 먼저 → 실패 확인 → 구현 |
| "merge commit이 더 이력 명확" | CLAUDE.md가 rebase merge 명시했다면 위배 |
superpowers:brainstorming — 스코프/접근 합의superpowers:writing-plans — 구현 계획 문서superpowers:using-git-worktrees — 워크트리 생성superpowers:subagent-driven-development — 병렬 실행superpowers:test-driven-development — TDD 사이클superpowers:verification-before-completion — 완료 주장 전 증거 확보superpowers:requesting-code-review — 리뷰 요청superpowers:finishing-a-development-branch — 머지 결정사용자 발화 예시:
/work-issue 58이슈 #58 처리해줘이 이슈 처리해줘 https://github.com/owner/repo/issues/58#58 작업 시작이슈 번호를 추출한 뒤 0단계부터 순차 진행. 사용자가 중간 단계만 원한다고 하면 해당 지점부터 시작하되, 이전 단계의 결과물(계획 문서, 워크트리 등)이 존재하는지 확인.