88 lines
5.1 KiB
Markdown
88 lines
5.1 KiB
Markdown
---
|
|
name: "review-discovery"
|
|
description: "Review and validate SDLC Discovery document for consistency, completeness, and readiness for approval"
|
|
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md"
|
|
agent: "agent"
|
|
---
|
|
SDLC Discovery 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
|
|
|
목표:
|
|
- 1_discovery.md 파일의 일관성 확인 (개념/용어/범위 중복 및 충돌)
|
|
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
|
- AI agent에게 할당된 플레이스홀더({{...}}) 중 판단/결정 가능한 항목 처리
|
|
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
|
- 최종 승인 가능 상태 판단
|
|
|
|
검토 절차:
|
|
|
|
1. 입력 해석
|
|
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 1_discovery.md 파일 위치를 확정한다.
|
|
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백한다.
|
|
|
|
2. 일관성 검토 (모든 섹션 대상)
|
|
- 용어: 같은 개념이 다른 이름으로 반복되는지 확인. 예: "사용자"와 "최종 사용자", "범위"와 "경계" 혼용.
|
|
- 개념 중복: 섹션 간 내용이 동일하거나 매우 유사한 부분 식별. 예: `# 1`의 해석과 `# 10` 요약의 중복.
|
|
- 범위 정합성: In Scope/Out of Scope가 명확히 구분되는지, 요구사항 목록과 맞는지 확인.
|
|
- 숫자 일관성: 리스크(R-1~3), 가정(A-1~3), 성공 기준(S-1~3) 등 번호가 누락 없이 연속인지 확인.
|
|
|
|
3. 표현 검토 (모든 텍스트)
|
|
- 문법: 문장 구조, 주술 호응, 시제 일관성 확인.
|
|
- 명확성: 주관적이거나 모호한 표현 식별. 예: "적절한", "대략적으로", "대체로".
|
|
- 작성 수준: 기술 문서 기준의 형식적 톤 유지. 비공식 표현이나 과도한 가정 제거.
|
|
- 오타: 한글 띄어쓰기, 숫자 오류, 링크 형식 검증.
|
|
|
|
4. 플레이스홀더 처리
|
|
- 모든 `{{...}}` 플레이스홀더를 나열하고, 각 항목의 의도를 파악한다.
|
|
- AI agent 할당 항목 식별:
|
|
- `{{ASSUMPTION_1_DECISION:...}}`, `{{TARGET_STATE_2_DECISION:...}}` 같은 `_DECISION` 형태
|
|
- `{{DECIDE_*}}`, `{{CONFIRM_*}}`, `{{DATA_*}}` 형태
|
|
- 각 항목에 대해 아래 중 하나를 판단한다.
|
|
- **채울 수 있음**: 문서 내 다른 섹션, 입력 요청, 저장소 구조를 바탕으로 합리적 내용 추론 가능 → 실제 내용으로 치환
|
|
- **판단 불가능**: 사용자/승인자의 정책 결정, 외부 데이터 확인, 승인 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화
|
|
- 처리 결과를 별도 목록으로 보고한다.
|
|
|
|
5. 섹션별 최소 검수 기준
|
|
- `# 0 문서 상태`: 메타데이터 완성도 확인 (예: CREATED_AT_KST는 현재 시각으로 채워졌는가)
|
|
- `# 2 요구사항 판정`: 판정이 신규/유사/중복 중 하나인가, 근거는 2줄 이상인가
|
|
- `# 3 문제점 요약`: 현재 상태와 기대 상태가 명확히 대비되는가
|
|
- `# 5 요구사항 목록`: FR/NFR 각각 최소 개수(FR 2개, NFR 1개) 이상인가, 범위 경계가 명시되었는가
|
|
- `# 6 리스크/가정/오픈질문`: 항목 수가 적절한가(2개 이상), 오픈 질문은 정말 결정 필요인가
|
|
- `# 8 확인 체크`: 체크 항목이 구체적이고 측정 가능한가
|
|
- `# 10 사용자 결정 필요`: 플레이스홀더가 실제 플레이스홀더 형식인가 (단순 문장 아닌가)
|
|
- `# 11 Freeze`: Handoff Decision과 Rationale이 채워졌는가
|
|
|
|
6. 최종 승인 판단
|
|
- **승인 가능 (Ready for Planning)**:
|
|
- 모든 일관성 오류가 해소되었는가
|
|
- 명확하지 않은 표현이 제거되었는가
|
|
- 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요)
|
|
- 모든 요구 섹션이 채워졌는가
|
|
- Freeze 플래그가 준비되었는가 (READY_FOR_PLANNING: true로 변경 가능한가)
|
|
- **조건부 (Pending Minor Changes)**:
|
|
- 일부 표현만 수정하면 가능
|
|
- 플레이스홀더 중 일부는 명확성을 위해 재작성 권장
|
|
- **보류 (Hold)**:
|
|
- 개념적 불일치, 범위 재정의, 승인자 선정 등 근본적 재검토 필요
|
|
|
|
응답 형식:
|
|
- **검토 결과 요약**
|
|
- 발견된 일관성 오류 (있으면 나열)
|
|
- 표현/문법 오류 (있으면 나열)
|
|
- 섹션별 완성도 점수 (예: 3/5 = 범위 경계 미명시)
|
|
|
|
- **플레이스홀더 처리 결과**
|
|
- 채워진 항목 (예: `{{TARGET_STATE_2_DECISION}}` → "GitHub 기반으로 운영"로 치환)
|
|
- 유지된 항목 (예: `{{DECIDE_ITEM_1}}` → 사용자 승인 필요로 유지)
|
|
|
|
- **수정 사항 목록** (적용된 변경)
|
|
|
|
- **최종 판단**
|
|
- 승인 가능 / 조건부 / 보류
|
|
- 근거 및 남은 작업 사항
|
|
|
|
중요 규칙:
|
|
- 도큐먼트 내용을 변경하는 경우 반드시 명확히 표기한다.
|
|
- AI agent 판단으로 치환한 항목은 합리적 근거를 함께 설명한다.
|
|
- 의도적으로 플레이스홀더를 유지한 이유도 명시한다.
|
|
- 승인 판단은 객관적 기준(섹션 완성도, 형식 준수, 범위 명확성)을 우선으로 한다.
|