菜单
확정된 artifacts/<feature>/plan.md의 Task를 TDD로 하나씩 구현하고 Task당 한 커밋을 만든다. 사용자가 "이제 구현 시작", "플랜 실행" 같은 신호를 보낼 때 트리거한다. plan.md 없이 바로 구현하는 경우에는 쓰지 않는다. "/execute-plan", "플랜 실행", "구현 시작"으로도 호출한다.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
여러 feature에 쌓인 `artifacts/*/learnings.md`를 정리한다 — 중복 병합, 충돌 해소, 낡은 항목 폐기, hypothesis 확정. 승격은 하지 않는다. learnings.md가 여러 feature에 쌓였을 때 트리거하고, 단일 feature 진행 중에는 쓰지 않는다. "/compound", "회고", "메모리 정리"로도 호출한다.
spec.md를 기반으로 구현 계획(artifacts/<feature>/plan.md)을 작성한다. 여러 파일에 걸치거나 시나리오가 서로 의존하는 product feature에 쓴다. 한 세션에 끝나는 작업·meta-tooling·명백한 변경은 내장 plan 모드로 한다. "/draft-plan", "draft plan", "계획 작성", "구현 계획"으로도 호출한다.
날것의 아이디어를 실행 가능한 one-pager(artifacts/<feature>/idea.md)로 다듬는 옵션 모듈. 아이디어가 막연하거나 MVP 범위·추진 방향을 정해야 할 때("이거 괜찮을까?", "뭘 먼저 만들지?") 트리거한다. 요구사항이 이미 구체적이면 건너뛰고 /write-spec으로 간다. "/idea-refine", "아이디어 정리", "ideate"로도 호출한다.
spec.md를 기반으로 HTML 와이어프레임을 생성하는 옵션 모듈. 레이아웃 구조가 바뀌는 UI feature(새 화면, 새 레이아웃, 화면 간 흐름)에 사용한다. 서버·데이터 전용 변경이나 레이아웃이 그대로인 변경에는 쓰지 않는다. "/sketch-wireframe", "wireframe", "와이어프레임", "레이아웃 확인"으로도 호출한다.
새 feature의 외부 관찰 가능한 동작(WHAT)을 사용자와 대화하며 spec.md로 확정한다. 요구사항이 모호하거나 여러 화면·경로에 걸친 다단계 feature를 정의하려는 신호가 보이면 트리거한다. 버그 수정, 한 줄 변경, 이미 구체적인 요구에는 쓰지 않는다. "/write-spec", "스펙 작성", "기능 정의"로도 호출한다.
| name | execute-plan |
| description | 확정된 artifacts/<feature>/plan.md의 Task를 TDD로 하나씩 구현하고 Task당 한 커밋을 만든다. 사용자가 "이제 구현 시작", "플랜 실행" 같은 신호를 보낼 때 트리거한다. plan.md 없이 바로 구현하는 경우에는 쓰지 않는다. "/execute-plan", "플랜 실행", "구현 시작"으로도 호출한다. |
| argument-hint | feature name |
plan.md의 Task를 메인 컨텍스트에서 한 번에 하나씩 직접 구현한다. 구현은 직접 하고, 독립 검증은 내장 /code-review 스킬에 위임한다. 판단은 전부 직접 내리고 artifacts/<feature>/learnings.md에 기록해 다음 feature를 더 쉽게 만든다. Compound Engineering 정신이다.
완료의 기준은 실행 증거다. spec.md의 판정 기준 체크박스는 테스트 통과 또는 End-to-end 확인으로만 켠다.
| 입력 | 출력 |
|---|---|
artifacts/<feature>/plan.md, spec.md, wireframe.html(있으면) | 코드 + 커밋, artifacts/<feature>/learnings.md |
$ARGUMENTS에서 feature 이름을 추출한다.
artifacts/<feature>/plan.md: 없으면 "/draft-plan을 먼저 실행하세요." 출력 후 중단artifacts/<feature>/spec.md: 없으면 "/write-spec을 먼저 실행하세요." 출력 후 중단. 커버리지 검사와 판정 기준 체크가 이 파일 경로에 의존한다artifacts/<feature>/wireframe.html: 있으면 참조references/learnings-template.md 읽기 (learnings.md 기록 형식 확인)artifacts/*/learnings.md의 triggers: 라인을 grep하고, 걸린 항목만 읽는다. status: verified는 지시문을 따르고, hypothesis는 참고만 한다.plan.md의 Task 목록을 분석한다.
plan.md와 다르게 순서를 결정한 경우에만 그 근거를 learnings.md에 기록한다.
Step 2의 순서대로 Task를 한 번에 하나씩 구현한다. 각 Task에 대해:
CLAUDE.md → Testing 규율을 따른다. 테스트 이름에 담당 ID를 [S1-1] 형식으로 인용한다.bun run typecheck와 영향받은 테스트를 실행한다 (풀빌드는 체크포인트에서만 돈다)plan의 체크포인트에 도달하면 체크포인트 항목을 실행한다 (테스트 + 빌드 + scripts/spec-coverage.sh <feature> --tests + slice 동작 확인). 마지막 체크포인트는 spec.md의 End-to-end 검증 절차를 실제로 실행하는 것이다. 절차가 통과해야 feature가 완료다.
컨텍스트가 길어졌으면 체크포인트 통과 후 /clear하고 /execute-plan <feature>로 재개해도 안전하다. plan.md의 완료 표시와 spec.md 체크박스가 진행 상태를 들고 있다.
빌드·테스트가 실패하면 근본 원인을 찾기 전에 에러 메시지 문자열로 artifacts/*/learnings.md를 grep한다 — 과거에 같은 함정을 밟았다면 verified 지시문이 우회 없이 해결해 준다. 없으면 우회하지 않고 근본 원인을 찾는다. 빌드 skip, 테스트 disable, 에러 swallow는 기술 부채를 가리는 단기 우회일 뿐이다.
상황에 따라 Task 재정렬·병합, spec 범위 밖 피드백 기각, 접근 전환, 사용자 escalation을 직접 결정한다. 다음 같은 판단은 기록할 가치가 있다:
판단은 learnings.md에 기록한다. 형식은 references/learnings-template.md에 있다.
모든 Task 구현이 끝나면:
/code-review 스킬을 실행한다: feature 브랜치의 전체 diff를 대상으로 한다 (마지막 커밋만 보지 않는다). 정확성 버그와 함께 중복·재사용·단순화 정리도 보고된다./security-review도 실행한다.보고된 findings를 분류해 처리한다. 기준: 지금 안 고치면 다음에 얼마의 비용이 드는가
판정을 learnings.md에 기록한다.
모든 Task가 완료되면 사용자에게 요약을 제시한다:
bun run build와 테스트, 커버리지 검사 결과사용자에게 spec.md 대비 feature를 검증해 달라고 요청한다. 피드백이 있으면 직접 수정하고 재검증한다. 판단을 learnings.md에 기록한다.
Compound Engineering 정신: 이번 feature가 다음 feature를 더 쉽게 만들도록 학습을 누적한다. 항상 실행한다. 발견이 없으면 "발견 없음"도 기록한다.
다음 3질문에 답해 사용자에게 제시한다:
이어서 이번 feature의 learnings.md 항목을 최종 정리한다. learnings는 다음 feature가 검색으로 소비하는 메모리이므로, 여기가 기록 품질을 지키는 마지막 관문이다:
verified, 원인이 불확실하면 hypothesis/compound의 병합·확정 근거가 된다)사용자에게 결과를 보고한다:
이번 feature는 완료다. learnings가 여러 feature에 쌓이면 다음 단계는 /compound로 메모리를 정리(병합·폐기·확정)하는 것이다.