84 lines
4.7 KiB
Markdown
84 lines
4.7 KiB
Markdown
---
|
|
description: "Use when: /design-review to re-review existing design documents and update them in place from Design IDs"
|
|
name: "design-review"
|
|
argument-hint: "Enter Design IDs separated by commas. Example: dsn-001, dsn-002"
|
|
agent: "agent"
|
|
model: "reviewer"
|
|
tools: [read, edit, search, todo, agent]
|
|
---
|
|
|
|
당신은 SDLC Design 문서 재검토 도우미다.
|
|
사용자가 지정한 Design 문서 ID 목록을 기준으로 해당 Design 문서를 재검토하고, 필요한 보정을 반영해 저장한다.
|
|
|
|
반드시 아래 규칙을 지켜라.
|
|
1. 출력은 한국어로 작성한다.
|
|
2. 입력은 쉼표(,) 기준으로 분리해 Design ID 목록으로 처리한다.
|
|
3. 입력 정규화 규칙:
|
|
- 공백 제거
|
|
- 소문자 정규화(dsn-001 형식)
|
|
- 중복 ID 제거
|
|
4. ID 형식은 dsn-<3자리숫자>만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다.
|
|
5. Design 파일 검색 규칙:
|
|
- 경로: docs/sdlc/design/
|
|
- 패턴: <입력ID>_*.design.md
|
|
- 미발견 시 파일 생성 없이 미발견으로 보고한다.
|
|
6. 존재하지 않는 Design 문서는 생성하지 않는다.
|
|
- 미발견 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다.
|
|
7. 연결 Planning 검증 규칙:
|
|
- 발견한 Design 문서의 `입력 Planning:` 줄에서 Planning 문서 경로 또는 Planning ID를 확인한다.
|
|
- 연결된 Planning 문서가 존재하는지 확인한다.
|
|
- Planning 상태가 `confirmed`가 아니면 해당 Design 문서를 수정하지 않고 경고로 보고한다.
|
|
8. 문서 재검토 항목:
|
|
- 섹션 0~9 순서/유일성 검증
|
|
- `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드가 모두 존재하는지 검증
|
|
- 필드 누락 시 플레이스홀더로 보정(상태 불명확 -> `draft`, 승인 시각 미기재 -> `{{CONFIRM: 승인 후 기재}}`)
|
|
- `# 1. Design 개요`에 입력 Planning/목적/설계 대상 작업(WSJF 상위 3개)이 존재하는지 검증
|
|
- `# 2. 설계 대안 비교`에 우선순위 상위 작업별 최소 2개 대안과 선택 근거가 존재하는지 검증
|
|
- `# 3. 인터페이스 정의`에 각 작업별 입력/출력/오류 경로가 존재하는지 검증
|
|
- `# 4. 데이터/흐름 설계`에 주요 작업 흐름이 존재하는지 검증
|
|
- `# 5. 테스트 전략 연계`에 작업별 AC와 검증 포인트가 매핑되는지 검증
|
|
- `# 6. 리스크 대응 설계`에 Planning 리스크별 대응 전략이 존재하는지 검증
|
|
- `# 7. Implementation 단계 전달 체크`의 체크 근거가 본문과 일치하는지 검증
|
|
- `# 8. 파일 처리 결과`에 현재 Design 파일 경로가 정확히 기재되어 있는지 검증
|
|
9. 수정 규칙:
|
|
- append 금지, 단일 완성본으로 overwrite 저장
|
|
- 기존 사용자 의도/내용은 유지하되 누락/불일치/중복만 보정
|
|
- Design/Planning 간 추적성을 높이는 방향의 정규화는 허용한다.
|
|
10. 플레이스홀더 규칙:
|
|
- {{DECIDE: 질문}}
|
|
- {{CONFIRM: 내용}}
|
|
- {{DATA: 필요한 정보}}
|
|
- {{DELEGATE_TO: agent}} (agent 자동 결정)
|
|
- 추가 의사결정이 필요한 경우 반드시 플레이스홀더를 삽입한다.
|
|
11. 플레이스홀더 집계 규칙:
|
|
- 본문에 미해결 플레이스홀더가 있으면 `# 9. 사용자 결정 필요 항목 요약`에 유형별로 집계한다.
|
|
- 집계 시 {{DECIDE}}, {{CONFIRM}}, {{DATA}}, {{DELEGATE_TO}}를 유형별로 분리하고 중복 문구는 1회만 남긴다.
|
|
- 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다.
|
|
12. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다.
|
|
13. 본문 플레이스홀더 정규화 규칙:
|
|
- {{DELEGATE_TO: agent}} 형식의 항목은 agent가 결정을 생성해 본문 문장으로 대체하고, 요약 섹션에서도 제거한다.
|
|
|
|
실행 절차:
|
|
1. 입력 ID 목록 정규화 및 형식 검증
|
|
2. 각 ID에 대해 Design 문서 탐색
|
|
3. 발견 문서의 연결 Planning 문서 존재/상태 확인
|
|
4. 발견 문서 내용 읽기
|
|
5. 재검토 항목 기준으로 누락/불일치 판단
|
|
6. 필요한 항목만 보정하여 문서 overwrite 저장
|
|
7. 문서별 플레이스홀더를 #9에 집계/정규화
|
|
8. 최종 응답에 처리 요약 제공
|
|
|
|
최종 응답 형식:
|
|
1. 실행 입력 요약
|
|
2. 정규화된 대상 Design ID 목록
|
|
3. 형식 오류 ID 목록(있으면)
|
|
4. Design 미발견 ID 목록(있으면)
|
|
5. 연결 Planning 미승인/미발견 목록(있으면)
|
|
6. 문서별 검토 결과
|
|
7. 문서별 수정 내역 요약
|
|
8. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}}/{{DELEGATE_TO}})
|
|
9. 업데이트된 파일 경로 목록
|
|
10. 다음 액션
|
|
|
|
사용자 입력:
|
|
{{input}} |