스킬: /plan — 구현 계획 관리자
세션의 활성 구현 계획(<prefix>-implementation_plan-<suffix>.md)을 관리합니다. 이 스킬은 계획의 뼈대, 상태 값, 링크 블록 및 검토(--review)를 소유합니다. 계획을 쓰거나 읽는 다른 모든 명령(/implement-feature, /problem, /refine, /pr-fix-pipeline, /proceed)은 여기에 정의된 내용을 사용합니다.
모듈
경로는 이 스킬의 실제 폴더를 기준으로 합니다. 스킬의 기본 디렉토리에서 realpath를 한 번 실행하고(심볼릭 링크일 수 있음), 거기서 각 경로를 확인하세요. 모듈을 읽을 수 없으면 중단하고 경로를 보고하세요. 모듈 없이 계속 진행하지 마십시오.
1단계 전에 다음을 읽으십시오:
../_modules/core.md../_modules/artifact-protocol.md: 아티팩트 디렉토리(artifact-protocol)에<prefix>-implementation_plan-<suffix>.md를 씁니다.../_modules/project-profile.md: 검토(Case D)를 위한 기본 프로필(명령 프로필 없음)입니다. 레퍼런스별 레이어, 계약 접점, 형제 체인 및 선택적 계획-검토 확인 항목 필드를 읽습니다.
주문형 참조(references/):
references/review.md— 다섯 가지 검토 핵심 요소(Case D 3단계)와--review(Case D) 및 자체 검토(Case B 4단계)를 위한 보고서 템플릿입니다.
1. 계획 계약
상태 값
계획의 두 번째 줄에는 **Status:** <값>이 있으며, 다음 중 하나입니다:
| 값 | 의미 | 설정하는 곳 |
|---|---|---|
Draft | 작성 중입니다. 검토 준비되지 않음 | 작성자(초안 작성 중) |
Awaiting User Review | 완료되어 게이트에서 대기 중 | 작성자(제시 시) |
Approved | 사용자가 게이트를 열었습니다. 구현 실행 중 | core › /proceed 게이트 |
Completed | 범위 내 모든 단계가 완료되고 검증됨 | core › /proceed 게이트 |
값 뒤에 짧은 설명이 따를 수 있습니다(Approved — phase 2 of 3 done). 읽는 쪽에서는 앞부분의 값만 일치시킵니다.
뼈대
<!-- artifact-owner: … --> <!-- artifact-protocol › Claim -->
# 구현 계획: <제목>
**Status:** Awaiting User Review
**Suffix:** `<접미사>`
**Inputs:** <조사 / 검토 / 티켓 링크, 또는 "없음">
**Review:** <_Case D_ 통합 후 판정> · <n>건 발견 사항 통합됨 <!-- Case B 4단계 -->
## 1. 컨텍스트 및 목표
## 2. 결정 사항 <!-- 표: 결정 · 이유 -->
## 3. 제안된 변경 사항 <!-- 단계별 또는 저장소별: [NEW|MODIFY|DELETE] <경로> — 무엇을, 왜 -->
## 4. 검증 계획 <!-- 정확한 명령어 및 수동 단계 -->
## 5. 위험 요소 <!-- 표: 위험 · 완화 방안 -->
## 6. 작업 체크리스트 <!-- 라이브 체크리스트: [ ] / [/] / [x] -->
## 7. 미해결 질문 <!-- 해결되지 않은 질문; 항상 마지막, 있다면; 각각 권장 사항 포함 -->
명령어는 필요한 섹션을 추가할 수 있습니다(/implement-feature는 사용자 검토 필요, 사각지대 통과 및 _저장소 간 순서_를 추가합니다). 위의 7개 섹션을 이 순서로 유지하여 /plan, /plan --review 및 /proceed가 찾을 수 있도록 합니다. 미해결 질문(해결되지 않은 질문)은 항상 마지막 섹션입니다. 추가된 섹션은 그 앞에 옵니다.
스타일
사용자 규칙(~/.claude/CLAUDE.md › Plan Mode)이 적용됩니다: 매우 간결하게, 문법은 희생. Steps, 이어서 Unresolved questions(각각 권장 사항 포함, 없으면 생략)으로 끝냅니다.
모든 계획 작성자는 이를 전체 파일 및 계획을 제시하는 채팅 응답에 적용합니다:
- 단편, 산문 금지: 문단 없음, 완전한 문장 설명 없음.
- 한 줄에 하나의 아이디어; 긴 것은 하위 불릿으로 나눕니다.
- 결정 사항 및 _위험 요소_는 표로.
- 모든 미해결 질문에는 Rec:(권장 답변)을 포함합니다.
- 미해결 질문 이후에는 아무것도 없음. 해결되지 않은 질문이 없으면 "없음"이라고 표시하거나 생략합니다.
링크 블록
계획을 제시하는 모든 채팅 응답은 artifact-protocol › Chat link block(작성 후 grep -n '^#\{1,3\} ' <파일>의 실제 줄 번호)으로 시작하며 Context & Goal, Proposed Changes, Verification Plan 및 Open Questions를 연결하고, 그 뒤에 **Status:** <값>이 옵니다. 명령어는 각 섹션 링크 뒤에 한 줄 요약을 추가할 수 있습니다(/plan --review는 그렇게 합니다).
2. 핵심 동작
인수에서 케이스를 선택합니다. 첫 번째 일치가 우선합니다:
| 인수 | 케이스 |
|---|---|
--review 포함 | D: 계획 검토 |
preview로 시작 | C: 미리보기 |
| 없음 | A: 기본 |
| 그 외 | B: 초안 또는 업데이트 |
Case A: 기본 명령어 (/plan 인수 또는 메시지 없음)
- 계획 찾기: 아티팩트 디렉토리(
artifact-protocol)에서<prefix>-implementation_plan-*.md를 스캔하고artifact-protocol› Claim › _Readers & family selection_에 따라 계열을 선택합니다(다음에/plan <접미사>로 프롬프트를 건너뛸 수 있다고 사용자에게 알립니다). 없으면 그렇다고 말하고 사용자의 다음 프롬프트에서 만들겠다고 제안합니다. - 링크 블록 렌더링 (§1 링크 블록)을 선택한 계획의 현재
Status와 함께 표시합니다. 어떤 것도 편집하거나 백그라운드 명령을 실행하지 마십시오.
Case B: 지시사항이 있는 명령어 (/plan <지시사항>)
- 컨텍스트 접미사 확인 (
artifact-protocol› 규칙 2에 따라). - 계획 수립, 코드 변경 없이:
- 먼저 기존 조사가 있는지 확인합니다.
<prefix>-investigation-<접미사>.md가 아티팩트 디렉토리(artifact-protocol)에 존재하고 이 주제를 다루면, 그 위에 구축합니다: Plan Seed, Options & Trade-offs 및 Confidence Ledger. 이미 문서화된 연구를 다시 수행하지 마십시오. 계획이 의존하는 ❓ Unknown은 해결하십시오. - 그렇지 않으면 관련 코드를 읽기 전용으로 조사합니다. 주제가 크거나 미지수가 상당하면 먼저
/investigate를 실행합니다. - 프로젝트 자체 규칙(작업 공간 규칙집, 프로젝트 범위 참조 및 프로필(
core› Precedence))에 맞게 설계합니다.
- 먼저 기존 조사가 있는지 확인합니다.
- 계획 쓰기 (§1 뼈대 형식으로, 아티팩트 디렉토리(
artifact-protocol)에):- 새 계획: 세션 전용 경로에 초안을 작성한 후 Claim(
artifact-protocol› 규칙 4)으로 게시합니다. 기본 이름이 이미 사용 중이면 Claim이…-2.md를 씁니다. 그것이 출력한 경로를 사용하고 채팅에 알립니다. - 기존 계획: 소유자 마커가 이 세션을 명명하거나, 사용자가 해당 파일을 지정하고 업데이트를 요청한 경우에만 업데이트합니다(
artifact-protocol› 규칙 3). 그렇지 않으면 _Claim_을 통해 새 개정판을 작성하고, Inputs에 대체하는 계획을 연결합니다. - 완료되면
Status를Awaiting User Review로 설정합니다. Antigravity에서<appDataDir>/brain/<conversation-id>/내에 미러된 아티팩트 복사본을 쓸 때는ArtifactMetadata에UserFacing = true와RequestFeedback = true를 설정합니다(아티팩트 디렉토리 파일에는ArtifactMetadata를 생략합니다).
- 새 계획: 세션 전용 경로에 초안을 작성한 후 Claim(
- 제시 전 자체 검토:
references/review.md를 읽고 Case D 2-3단계를 방금 작성한 계획에 대해 기본 컨텍스트에서 실행합니다. 핵심 요소와 심각도 수준을 사용합니다. 보고서나 게이트를 출력하지 마십시오: 이것은 초안 작성의 일부이며, 사용자는 통합된 계획을 검토합니다.-
제시하기 전에 모든 발견 사항을 계획에 통합합니다:
발견 사항 통합 위치 🔴 / 🟡, 확인됨 ( path:line다시 열림)Proposed Changes, Task Checklist, 및 수정 없이는 실패하는 Verification Plan 확인 항목 🔴 / 🟡, 사용자 결정 필요 Open Questions, Rec: 포함 🟢 한 줄이면 적용, 아니면 삭제 기각된 발견 사항 Risks, 이유와 함께 한 행 추가 -
수정 사항과 모순되는 부분(이전 단계, 테스트, 결정 행)이 없는지 계획을 한 번 다시 읽고 수정합니다.
-
검토는 한 번 실행합니다. 통합된 계획이 받을 판정으로 Review: 헤더 라인을 채웁니다.
-
모든 새 계획과 Proposed Changes 또는 _Verification Plan_을 변경하는 모든 업데이트에서 실행합니다. 체크리스트만 체크하거나
Status만 변경하는 업데이트에서는 건너뜁니다.
-
- 계획 제시: 링크 블록(§1 링크 블록), 검토 판정 및 설계를 변경시킨 발견 사항(각각 한 불릿씩), 핵심 결정 사항을 단편 불릿으로, 마지막으로 각각 Rec:(_§1 스타일_이 이 채팅 텍스트에도 적용됨: 문단 없음, 완전한 문장 없음)와 함께 미해결 질문을 순서대로 표시합니다. 코드 변경 전에 사용자가 게이트를 열 때까지 기다립니다(
core›/proceed게이트).
Case C: 미리보기 명령어 (/plan preview [대상])
호스트의 계획 미리보기 패널에 기존 계획을 표시하여(가능하면 ExitPlanMode 사용) 사용자가 대화식으로 읽고, 댓글을 달고, 승인할 수 있게 합니다.
- 계획 확인: 인수(경로 또는 접미사), 세션의 활성 계획 파일 또는 아티팩트 디렉토리의 최신 계획 계열을 사용합니다(Case A).
- 호스트 기능 확인: 호스트에
ExitPlanMode가 없으면(Antigravity IDE 등), 계획의 링크 블록(Case A)을 출력하고 호스트가 마크다운 링크를 통해 계획을 직접 렌더링한다고 설명합니다. - 계획 모드 진입 및 복사:
EnterPlanMode를 호출하고, 시스템 메시지에서 호스트 계획 파일 경로를 읽은 후 소스 계획을 그 안으로 복사합니다(앞부분의<!-- artifact-owner: … -->주석은 생략). - 미리보기 열기:
ExitPlanMode를 호출합니다. - 결정 처리:
- 승인: 사용자가 구현을 승인했습니다(
core›/proceed게이트). 실행을 시작합니다. - 계속 계획 / 피드백: 계획 모드를 유지하고, 피드백을 Case B에 전달하여 계획을 업데이트한 후 미리보기를 다시 엽니다.
- 닫힘 / 오류: 상태를 보고하고 파일 링크를 제공합니다.
- 승인: 사용자가 구현을 승인했습니다(
Case D: 검토 명령어 (/plan --review [대상])
코드 작성 전, 구현 계획, 아키텍처 제안 또는 변경 설계에 대한 엄격하고 읽기 전용 감사입니다. /proceed(core › /proceed 게이트)까지 읽기 전용입니다:
- 파일을 편집하거나, 수정 명령(마이그레이션, 커밋, 스캐폴딩)을 실행하거나, 계획이 완벽하더라도 구현을 시작하지 마십시오.
--review하의 모든 응답(후속 질문 포함)은 링크 블록으로 시작합니다: 사용자는 종종 계획 탭을 닫고 채팅에서 다시 엽니다.
잘못된 도구:
| 상황 | 대신 사용 |
|---|---|
| 계획이 아닌 코드 diff, 브랜치 또는 PR | /code-review |
| PR에 대한 리뷰어 댓글 및 투표 | /pr-feedback-review |
| 계획이 존재하기 전의 연구 | /investigate |
| 설계의 숨겨진 가정 및 실패 모드 | /what-am-I-missing |
references/review.md를 읽고 Case D 1-4단계를 실행한 후(1단계: 계획 찾기; 2단계: 프로젝트 규칙 읽기; Case D 3단계: 다섯 가지 핵심 요소 + 프로필 Plan-review checks 평가; 4단계: 링크 블록 및 검토 보고서 렌더링), core › _/proceed 게이트_에서 대기합니다.