3a72413 Merge pull request #5 from genichin/copilot/add-verification-steps-sdlc-prompt d362b6b feat: add verification stage to run-sdlc pipeline 9b52ae1 Initial plan 893d465 Merge pull request #3 from genichin/copilot/add-sdlc-prompt-feature 57b3941 feat: add /run-sdlc prompt for automated SDLC pipeline execution 27396ab Initial plan 6979011 Clarify draft creation for new SDLC prompts 1c5557b fix(bootstrap): sdlc 디렉토리 구조 단순화 및 summary 템플릿 추가 af343e5 docs(prompt): SDLC 프롬프트 저장소 현황 탐색 및 대조 절차 강화 cc55e06 chore: Release/Operations 프로세스 템플릿 및 프롬프트 추가 및 README 최신화 386695b commit 4533017 draft 82b7690 draft-design 0503411 draft 9984db0 confirm-discovery, draft-planning, review-planning 명령 추가 cba64f0 add confirm-discovery prompt 9391537 draft 58f2de8 feat: execute implementation during run-sdlc flow 693e3f6 feat: auto-create downstream drafts in run-sdlc 404bc63 docs: translate SDLC orchestration prompts to English 9018e8f feat: add SDLC scaffold and sequential run commands d60e21c docs: clarify when to create a new discovery 0629eee feat: add operation issue triage prompt cdc8d87 feat: make update.sh auto-overwrite by default with --no-overwrite option ead06c2 chore: add execute tool to all prompt files git-subtree-dir: .vendor/stage-pilot git-subtree-split: 3a72413acd2edd95053631f900d3c99c1caef359
128 lines
6.3 KiB
Markdown
128 lines
6.3 KiB
Markdown
---
|
|
name: "review-planning"
|
|
description: "Review and validate SDLC Planning document for consistency, completeness, and readiness for approval"
|
|
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/2_planning.md"
|
|
agent: "agent"
|
|
---
|
|
SDLC Planning 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
|
|
|
목표:
|
|
- `2_planning.md` 파일의 일관성 확인 (태스크/요구사항/범위 간 중복 및 충돌)
|
|
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
|
- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리
|
|
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
|
- 최종 승인 가능 상태 판단
|
|
|
|
---
|
|
|
|
## 검토 절차
|
|
|
|
### 1. 입력 해석
|
|
|
|
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `2_planning.md` 파일 위치를 확정한다.
|
|
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다.
|
|
- `1_discovery.md`도 함께 읽어 인계 내용의 정합성 확인에 사용한다.
|
|
|
|
### 2. Discovery 인계 정합성 검토
|
|
|
|
`# 1. Discovery 인계 요약`이 `1_discovery.md`의 확정 내용과 일치하는지 확인한다.
|
|
|
|
- FR/NFR 목록이 Discovery `# 5`와 내용/수량이 일치하는가
|
|
- In Scope / Out of Scope 경계가 Discovery와 충돌하지 않는가
|
|
- 이월된 오픈 질문이 Discovery `# 6`의 `Deferred` 항목과 대응하는가
|
|
|
|
### 3. 일관성 검토 (모든 섹션 대상)
|
|
|
|
- **용어**: 태스크 제목, 요구사항 ID(FR-N, T-N, M-N), 담당자 표기가 섹션 간 일치하는가
|
|
- **태스크 참조**: `# 2` 태스크 분해 테이블의 T-N 번호가 `# 3` 공수 추정, `# 4` 일정 계획, `# 5` 의존성과 연속·일치하는가
|
|
- **성공 기준 연결**: `# 6` 검증 계획의 기준(S-N)이 Discovery `# 7`과 대응하는가
|
|
- **숫자 연속성**: T-N, M-N, OQ-N, R-N 번호가 누락 없이 연속인지 확인
|
|
|
|
### 4. 표현 검토 (모든 텍스트)
|
|
|
|
- **문법**: 문장 구조, 주술 호응, 시제 일관성
|
|
- **명확성**: "적절히", "대략", "가능하면" 같은 모호한 표현 식별
|
|
- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거
|
|
- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증
|
|
|
|
### 5. 플레이스홀더 처리
|
|
|
|
모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다.
|
|
|
|
AI agent가 채울 수 있는 항목:
|
|
- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Discovery 내용으로 추론 가능한지 확인
|
|
- 태스크 유형(`TASK_TYPE_N`), 참조 요구사항(`TASK_REF_N`), 의존 관계(`TASK_DEP_N`) 등 구조적으로 추론 가능한 항목
|
|
|
|
사용자 결정이 필요한 항목 (플레이스홀더 유지):
|
|
- 태스크 담당자(`TASK_OWNER_N`)
|
|
- 마일스톤 목표 날짜(`MILESTONE_N_DATE`)
|
|
- 이터레이션 기간(`ITERATION_N_PERIOD`)
|
|
- 검증 담당자(`VERIFY_OWNER_N`)
|
|
- Freeze 확정 담당자(`CONFIRMED_BY`)
|
|
|
|
각 항목에 대해 아래 중 하나를 판단한다:
|
|
- **채울 수 있음**: 문서 내 맥락, Discovery 내용, 저장소 구조로 합리적 추론 가능 → 실제 내용으로 치환
|
|
- **판단 불가능**: 사용자/승인자 결정, 외부 데이터, 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화
|
|
|
|
처리 결과를 별도 목록으로 보고한다.
|
|
|
|
### 6. 섹션별 최소 검수 기준
|
|
|
|
| 섹션 | 최소 기준 |
|
|
|------|---------|
|
|
| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, DISCOVERY_PATH 채워졌는가) |
|
|
| `# 1 Discovery 인계 요약` | FR 2개 이상, NFR 1개 이상, In/Out Scope 명시 여부 |
|
|
| `# 2 작업 분해` | 태스크 최소 2개 이상, 각 태스크에 DoD가 있는가 |
|
|
| `# 3 공수 추정` | 모든 태스크에 추정 공수와 단위가 있는가, 총 공수와 신뢰도가 명시되었는가 |
|
|
| `# 4 일정 계획` | 마일스톤 최소 1개 이상, 이터레이션 단위가 정의되었는가 |
|
|
| `# 5 의존성 및 제약` | 태스크 간 의존성이 `# 2`와 일치하는가 |
|
|
| `# 6 검증 계획` | Discovery 성공 기준(S-N)과 연결된 검증 방법 초안이 있는가 |
|
|
| `# 7 리스크/가정/오픈 질문` | 항목이 적절한가(리스크 1개 이상, 가정 1개 이상), 오픈 질문은 정말 결정 필요인가 |
|
|
| `# 8 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 |
|
|
| `# 10 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) |
|
|
| `# 11 Freeze` | Handoff Decision과 Rationale이 채워졌는가 |
|
|
|
|
### 7. 최종 승인 판단
|
|
|
|
- **승인 가능 (Ready for Design)**:
|
|
- 모든 일관성 오류가 해소되었는가
|
|
- 명확하지 않은 표현이 제거되었는가
|
|
- 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요)
|
|
- 모든 요구 섹션이 채워졌는가
|
|
- Freeze 플래그가 준비되었는가 (`READY_FOR_DESIGN: true`로 변경 가능한가)
|
|
- **조건부 (Pending Minor Changes)**:
|
|
- 일부 표현/수치만 수정하면 가능
|
|
- 플레이스홀더 중 일부는 명확성을 위해 재작성 권장
|
|
- **보류 (Hold)**:
|
|
- 태스크-요구사항 연결 누락, 공수 추정 근거 부재, 범위 재정의 등 근본적 재검토 필요
|
|
|
|
---
|
|
|
|
## 응답 형식
|
|
|
|
- **검토 결과 요약**
|
|
- Discovery 인계 정합성 오류 (있으면 나열)
|
|
- 발견된 일관성 오류 (있으면 나열)
|
|
- 표현/문법 오류 (있으면 나열)
|
|
- 섹션별 완성도 (예: `# 3` 공수 추정 — T-2 추정값 누락)
|
|
|
|
- **플레이스홀더 처리 결과**
|
|
- 채워진 항목 (예: `{{TASK_DEP_2}}` → `T-1` 로 치환)
|
|
- 유지된 항목 (예: `{{TASK_OWNER_1:TBD}}` → 담당자 지정 필요로 유지)
|
|
|
|
- **수정 사항 목록** (적용된 변경)
|
|
|
|
- **최종 판단**
|
|
- 승인 가능 / 조건부 / 보류
|
|
- 근거 및 남은 작업 사항
|
|
|
|
---
|
|
|
|
## 중요 규칙
|
|
|
|
- 문서 내용을 변경하는 경우 반드시 명확히 표기한다.
|
|
- AI agent 판단으로 치환한 항목은 합리적 근거를 함께 설명한다.
|
|
- 의도적으로 플레이스홀더를 유지한 이유도 명시한다.
|
|
- 승인 판단은 객관적 기준(섹션 완성도, 형식 준수, Discovery 정합성)을 우선으로 한다.
|
|
- Discovery와의 정합성 확인은 `1_discovery.md`를 직접 읽어서 수행한다. 기억이나 추론에 의존하지 않는다.
|