Squashed '.vendor/stage-pilot/' changes from c24b25d..3a72413
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
This commit is contained in:
@@ -1,54 +0,0 @@
|
||||
---
|
||||
description: "Use when: /commit or /commit all to review changes, generate a commit message, commit, and optionally push with --push"
|
||||
name: "commit"
|
||||
argument-hint: "Optional: 'all' and/or '--push'. Examples: '/commit', '/commit all', '/commit --push', '/commit all --push'"
|
||||
agent: "agent"
|
||||
model: "GPT-4.1"
|
||||
tools: [read, search, agent, todo, execute]
|
||||
---
|
||||
|
||||
당신은 변경사항을 검토하고 커밋/푸시를 자동으로 수행하는 실행 도우미다.
|
||||
반드시 GPT-4.1 모델 기준으로 동작한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 해석 규칙:
|
||||
- 빈 입력 또는 `all`: `/commit`과 동일하게 처리한다.
|
||||
- `--push` 옵션이 있으면 커밋 후 원격 푸시까지 수행한다.
|
||||
- 허용 예시: `/commit`, `/commit all`, `/commit --push`, `/commit all --push`
|
||||
- 위 형식 외 인자는 오류로 보고하고 종료한다.
|
||||
3. 실행 전 검증:
|
||||
- git 저장소가 아니면 오류로 보고하고 종료한다.
|
||||
- 변경 파일이 없으면 "커밋할 변경사항이 없다"고 보고하고 종료한다.
|
||||
4. 변경 검토:
|
||||
- `git status --short`와 `git diff`(필요 시 `git diff --staged`)로 변경을 파악한다.
|
||||
- 변경 의도를 요약한 커밋 메시지를 1줄로 생성한다.
|
||||
- 커밋 메시지 형식은 Conventional Commits를 우선 사용한다.
|
||||
5. 커밋 수행:
|
||||
- `/commit`, `/commit all` 모두 `git add -A` 후 `git commit -m "<생성 메시지>"`를 수행한다.
|
||||
- 커밋 실패 시 오류 내용을 보고하고 종료한다.
|
||||
6. 푸시 수행:
|
||||
- `--push` 옵션이 있을 때만 `git push`를 수행한다.
|
||||
- 기본 대상은 현재 체크아웃 브랜치의 upstream을 사용한다.
|
||||
- upstream이 없으면 `origin <현재브랜치>`로 푸시를 시도하고 결과를 보고한다.
|
||||
7. 안전 규칙:
|
||||
- 파괴적 명령(`reset --hard`, `checkout --`, 강제 push)은 사용하지 않는다.
|
||||
- 사용자가 명시하지 않은 변경을 되돌리지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 옵션 파싱(`all`, `--push`)
|
||||
2. 저장소/변경 여부 확인
|
||||
3. 변경 내용 검토 및 커밋 메시지 생성
|
||||
4. `git add -A` + `git commit`
|
||||
5. 옵션이 있으면 `git push`
|
||||
6. 결과 보고
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 옵션 요약
|
||||
2. 생성된 커밋 메시지
|
||||
3. 커밋 결과(해시, 변경 파일 수)
|
||||
4. 푸시 결과(실행한 경우)
|
||||
5. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: "confirm-design"
|
||||
description: "Approve a Design document and mark it as confirmed, ready for Implementation"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/3_design.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Design 문서를 최종 승인 처리한다.
|
||||
|
||||
목표:
|
||||
- `3_design.md`의 상태를 `confirmed`로 변경한다.
|
||||
- `# 10. Design Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Implementation`을 `true`로 변경한다.
|
||||
- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다.
|
||||
- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 플레이스홀더 분류 기준
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다.
|
||||
|
||||
### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소)
|
||||
|
||||
승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다.
|
||||
|
||||
| 플레이스홀더 패턴 | 자동 채움 값 |
|
||||
|---|---|
|
||||
| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) |
|
||||
| `{{CONFIRMED_BY...}}` | 섹션 10의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 |
|
||||
|
||||
### B. 맥락상 해소된 플레이스홀더 (자동 정리)
|
||||
|
||||
섹션 7(체크리스트) 또는 섹션 9(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 10에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다.
|
||||
|
||||
예시:
|
||||
- 섹션 7의 `{{CONFIRM_CONFIRMEDBY}}` → 섹션 10의 `Confirmed By: Justin` 값이 있으면 → `Justin`으로 치환 또는 체크리스트 기준 텍스트에서 플레이스홀더 제거
|
||||
- 섹션 9 CONFIRM 항목의 `{{CONFIRM_CONFIRMEDBY}}` → 동일하게 처리
|
||||
|
||||
### C. 실질 미해소 플레이스홀더 (차단 대상)
|
||||
|
||||
섹션 1~6(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `3_design.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다.
|
||||
- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. 플레이스홀더 분류 및 사전 해소
|
||||
|
||||
문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다.
|
||||
|
||||
- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다.
|
||||
- **B 유형**: 섹션 10에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다.
|
||||
- **C 유형**: 목록을 보고하고 승인을 보류한다.
|
||||
|
||||
### 3. 승인 가능 여부 확인 (사전 게이트 검사)
|
||||
|
||||
아래 조건을 모두 충족해야 승인을 진행한다.
|
||||
|
||||
| 항목 | 확인 기준 |
|
||||
|------|-----------|
|
||||
| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. |
|
||||
| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. |
|
||||
| 오픈 질문 미해소 | `# 6` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. |
|
||||
| 필수 섹션 미완성 | `# 2`, `# 3`, `# 5`, `# 7`, `# 9`, `# 10` 섹션이 존재하고 내용이 채워져 있어야 한다. |
|
||||
| Ready for Implementation 사전 설정 | `Ready for Implementation: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. |
|
||||
|
||||
> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다.
|
||||
|
||||
### 4. 문서 업데이트 (승인 가능 시에만 실행)
|
||||
|
||||
아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다.
|
||||
|
||||
1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경
|
||||
2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경
|
||||
3. `# 10. Design Freeze`의 `- Handoff Decision:` → `승인`으로 변경
|
||||
4. `# 10. Design Freeze`의 `- Ready for Implementation:` → `true`로 변경
|
||||
5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환
|
||||
6. **B 유형 플레이스홀더** → 섹션 10에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거)
|
||||
7. `docs/sdlc/<CYCLE_ID>/index.md`의 Design 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 3. Design | ... | ... |`
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **처리 결과**: 승인 완료 또는 승인 불가
|
||||
- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시)
|
||||
- **변경된 필드 목록** (승인 완료 시)
|
||||
- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함
|
||||
- **다음 단계 안내**: 승인 완료 시 Implementation 단계(`/draft-implementation <CYCLE_ID>`) 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다.
|
||||
- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다.
|
||||
- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: "confirm-discovery"
|
||||
description: "Approve a Discovery document and mark it as confirmed, ready for Planning"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Discovery 문서를 최종 승인 처리한다.
|
||||
|
||||
목표:
|
||||
- `1_discovery.md`의 상태를 `confirmed`로 변경한다.
|
||||
- `# 11. Discovery Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Planning`을 `true`로 변경한다.
|
||||
- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다.
|
||||
- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 플레이스홀더 분류 기준
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다.
|
||||
|
||||
### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소)
|
||||
|
||||
승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다.
|
||||
|
||||
| 플레이스홀더 패턴 | 자동 채움 값 |
|
||||
|---|---|
|
||||
| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) |
|
||||
| `{{CONFIRMED_BY...}}` | 섹션 11의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 |
|
||||
|
||||
### B. 맥락상 해소된 플레이스홀더 (자동 정리)
|
||||
|
||||
섹션 8(체크리스트) 또는 섹션 10(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 11에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다.
|
||||
|
||||
예시:
|
||||
- 섹션 8의 `{{CONFIRM_CONFIRMEDBY}}` → 섹션 11의 `Confirmed By: Justin` 값이 있으면 → `Justin`으로 치환 또는 체크리스트 기준 텍스트에서 플레이스홀더 제거
|
||||
- 섹션 10 CONFIRM 항목의 `{{CONFIRM_CONFIRMEDBY}}` → 동일하게 처리
|
||||
|
||||
### C. 실질 미해소 플레이스홀더 (차단 대상)
|
||||
|
||||
섹션 1~7(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `1_discovery.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다.
|
||||
- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. 플레이스홀더 분류 및 사전 해소
|
||||
|
||||
문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다.
|
||||
|
||||
- **A 유형**: 목록만 기록한다. 3단계에서 자동으로 채운다.
|
||||
- **B 유형**: 섹션 11에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 3단계에서 함께 처리한다.
|
||||
- **C 유형**: 목록을 보고하고 승인을 보류한다.
|
||||
|
||||
### 3. 승인 가능 여부 확인 (사전 게이트 검사)
|
||||
|
||||
아래 조건을 모두 충족해야 승인을 진행한다.
|
||||
|
||||
| 항목 | 확인 기준 |
|
||||
|------|-----------|
|
||||
| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. |
|
||||
| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. |
|
||||
| 오픈 질문 미해소 | `# 6` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. |
|
||||
| 필수 섹션 미완성 | `# 5`, `# 7`, `# 8`, `# 10`, `# 11` 섹션이 존재하고 내용이 채워져 있어야 한다. |
|
||||
| Ready for Planning 사전 설정 | `Ready for Planning: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. |
|
||||
|
||||
> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다.
|
||||
|
||||
### 4. 문서 업데이트 (승인 가능 시에만 실행)
|
||||
|
||||
아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다.
|
||||
|
||||
1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경
|
||||
2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경
|
||||
3. `# 11. Discovery Freeze`의 `- Handoff Decision:` → `승인`으로 변경
|
||||
4. `# 11. Discovery Freeze`의 `- Ready for Planning:` → `true`로 변경
|
||||
5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환
|
||||
6. **B 유형 플레이스홀더** → 섹션 11에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거)
|
||||
7. `docs/sdlc/<CYCLE_ID>/index.md`의 Discovery 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 1. Discovery | ... | ... |`
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **처리 결과**: 승인 완료 또는 승인 불가
|
||||
- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시)
|
||||
- **변경된 필드 목록** (승인 완료 시)
|
||||
- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함
|
||||
- **다음 단계 안내**: 승인 완료 시 Planning 단계(`/planning-draft <CYCLE_ID>`) 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다.
|
||||
- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다.
|
||||
- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: "confirm-implementation"
|
||||
description: "Approve an Implementation document and mark it as confirmed, ready for Verification"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Implementation 문서를 최종 승인 처리한다.
|
||||
|
||||
목표:
|
||||
- `4_implementation.md`의 상태를 `confirmed`로 변경한다.
|
||||
- `# 8. Implementation Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Verification`을 `true`로 변경한다.
|
||||
- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다.
|
||||
- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 플레이스홀더 분류 기준
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다.
|
||||
|
||||
### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소)
|
||||
|
||||
승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다.
|
||||
|
||||
| 플레이스홀더 패턴 | 자동 채움 값 |
|
||||
|---|---|
|
||||
| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) |
|
||||
| `{{CONFIRMED_BY...}}` | 섹션 8의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 |
|
||||
|
||||
### B. 맥락상 해소된 플레이스홀더 (자동 정리)
|
||||
|
||||
섹션 5(체크리스트) 또는 섹션 7(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 8에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다.
|
||||
|
||||
### C. 실질 미해소 플레이스홀더 (차단 대상)
|
||||
|
||||
섹션 1~4(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `4_implementation.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다.
|
||||
- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. 플레이스홀더 분류 및 사전 해소
|
||||
|
||||
문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다.
|
||||
|
||||
- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다.
|
||||
- **B 유형**: 섹션 8에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다.
|
||||
- **C 유형**: 목록을 보고하고 승인을 보류한다.
|
||||
|
||||
### 3. 승인 가능 여부 확인 (사전 게이트 검사)
|
||||
|
||||
아래 조건을 모두 충족해야 승인을 진행한다.
|
||||
|
||||
| 항목 | 확인 기준 |
|
||||
|------|-----------|
|
||||
| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. |
|
||||
| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. |
|
||||
| 오픈 질문 미해소 | `# 4` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. |
|
||||
| 필수 섹션 미완성 | `# 2`, `# 3`, `# 5`, `# 7`, `# 8` 섹션이 존재하고 내용이 채워져 있어야 한다. |
|
||||
| Ready for Verification 사전 설정 | `Ready for Verification: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. |
|
||||
|
||||
> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다.
|
||||
|
||||
### 4. 문서 업데이트 (승인 가능 시에만 실행)
|
||||
|
||||
아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다.
|
||||
|
||||
1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경
|
||||
2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경
|
||||
3. `# 8. Implementation Freeze`의 `- Handoff Decision:` → `승인`으로 변경
|
||||
4. `# 8. Implementation Freeze`의 `- Ready for Verification:` → `true`로 변경
|
||||
5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환
|
||||
6. **B 유형 플레이스홀더** → 섹션 8에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거)
|
||||
7. `docs/sdlc/<CYCLE_ID>/index.md`의 Implementation 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 4. Implementation | ... | ... |`
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **처리 결과**: 승인 완료 또는 승인 불가
|
||||
- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시)
|
||||
- **변경된 필드 목록** (승인 완료 시)
|
||||
- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함
|
||||
- **다음 단계 안내**: 승인 완료 시 Verification 단계(`/draft-verification <CYCLE_ID>`) 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다.
|
||||
- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다.
|
||||
- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: "confirm-operation"
|
||||
description: "Approve an Operations document and mark the SDLC cycle as complete"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/7_operation.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Operations 문서를 최종 승인 처리하고 SDLC 주기를 완료한다.
|
||||
|
||||
목표:
|
||||
- `7_operation.md`의 상태를 `confirmed`로 변경한다.
|
||||
- `# 10. Operations Freeze`의 `Handoff Decision`을 `승인`으로, `SDLC 주기 완료`를 `true`로 변경한다.
|
||||
- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다.
|
||||
- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 플레이스홀더 분류 기준
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다.
|
||||
|
||||
### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소)
|
||||
|
||||
| 플레이스홀더 패턴 | 자동 채움 값 |
|
||||
|---|---|
|
||||
| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) |
|
||||
| `{{CONFIRMED_BY...}}` | 섹션 10의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 |
|
||||
|
||||
### B. 맥락상 해소된 플레이스홀더 (자동 정리)
|
||||
|
||||
섹션 7(체크리스트) 또는 섹션 9(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 10에 이미 기입되어 있으면** 해소된 것으로 간주한다. 차단하지 않는다.
|
||||
|
||||
### C. 실질 미해소 플레이스홀더 (차단 대상)
|
||||
|
||||
섹션 1~6(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `7_operation.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다.
|
||||
- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. 플레이스홀더 분류 및 사전 해소
|
||||
|
||||
문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다.
|
||||
|
||||
- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다.
|
||||
- **B 유형**: 섹션 10에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다.
|
||||
- **C 유형**: 목록을 보고하고 승인을 보류한다.
|
||||
|
||||
### 3. 승인 가능 여부 확인 (사전 게이트 검사)
|
||||
|
||||
아래 조건을 모두 충족해야 승인을 진행한다.
|
||||
|
||||
| 항목 | 확인 기준 |
|
||||
|------|-----------|
|
||||
| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. |
|
||||
| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. |
|
||||
| 오픈 질문 미해소 | `# 5` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. |
|
||||
| 필수 섹션 미완성 | `# 2`, `# 3`, `# 7`, `# 9`, `# 10` 섹션이 존재하고 내용이 채워져 있어야 한다. |
|
||||
| SDLC 주기 완료 사전 설정 | `SDLC 주기 완료: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. |
|
||||
|
||||
> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다.
|
||||
|
||||
### 4. 문서 업데이트 (승인 가능 시에만 실행)
|
||||
|
||||
아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다.
|
||||
|
||||
1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경
|
||||
2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경
|
||||
3. `# 10. Operations Freeze`의 `- Handoff Decision:` → `승인`으로 변경
|
||||
4. `# 10. Operations Freeze`의 `- SDLC 주기 완료:` → `true`로 변경
|
||||
5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환
|
||||
6. **B 유형 플레이스홀더** → 섹션 10에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거)
|
||||
7. `docs/sdlc/<CYCLE_ID>/index.md`의 Operations 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 7. Operations | ... | ... |`
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **처리 결과**: 승인 완료 또는 승인 불가
|
||||
- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시)
|
||||
- **변경된 필드 목록** (승인 완료 시)
|
||||
- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함
|
||||
- **SDLC 주기 완료 안내**: 승인 완료 시 이 주기의 `# 6` 다음 Discovery 환류 항목이 다음 SDLC 주기의 입력이 됨을 안내한다.
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다.
|
||||
- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다.
|
||||
- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: "confirm-planning"
|
||||
description: "Approve a Planning document and mark it as confirmed, ready for Design"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/2_planning.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Planning 문서를 최종 승인 처리한다.
|
||||
|
||||
목표:
|
||||
- `2_planning.md`의 상태를 `confirmed`로 변경한다.
|
||||
- `# 11. Planning Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Design`을 `true`로 변경한다.
|
||||
- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다.
|
||||
- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 플레이스홀더 분류 기준
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다.
|
||||
|
||||
### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소)
|
||||
|
||||
승인 명령 실행 시 자동으로 채우며, 이 값이 남아 있어도 차단하지 않는다.
|
||||
|
||||
| 플레이스홀더 패턴 | 자동 채움 값 |
|
||||
|---|---|
|
||||
| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) |
|
||||
| `{{CONFIRMED_BY...}}` | 섹션 11의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 |
|
||||
|
||||
### B. 맥락상 해소된 플레이스홀더 (자동 정리)
|
||||
|
||||
섹션 8(체크리스트) 또는 섹션 10(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 11에 이미 기입되어 있으면** 해소된 것으로 간주한다. 승인 처리 시 해당 플레이스홀더를 실질 값으로 치환하거나 설명 텍스트로 대체한다. 차단하지 않는다.
|
||||
|
||||
예시:
|
||||
- 섹션 8의 `{{CONFIRM_CONFIRMEDBY}}` → 섹션 11의 `Confirmed By: Justin` 값이 있으면 → `Justin`으로 치환 또는 체크리스트 기준 텍스트에서 플레이스홀더 제거
|
||||
- 섹션 10 CONFIRM 항목의 `{{CONFIRM_CONFIRMEDBY}}` → 동일하게 처리
|
||||
|
||||
### C. 실질 미해소 플레이스홀더 (차단 대상)
|
||||
|
||||
섹션 1~7(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `2_planning.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다.
|
||||
- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. 플레이스홀더 분류 및 사전 해소
|
||||
|
||||
문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다.
|
||||
|
||||
- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다.
|
||||
- **B 유형**: 섹션 11에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다.
|
||||
- **C 유형**: 목록을 보고하고 승인을 보류한다.
|
||||
|
||||
### 3. 승인 가능 여부 확인 (사전 게이트 검사)
|
||||
|
||||
아래 조건을 모두 충족해야 승인을 진행한다.
|
||||
|
||||
| 항목 | 확인 기준 |
|
||||
|------|-----------|
|
||||
| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. |
|
||||
| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. |
|
||||
| 오픈 질문 미해소 | `# 7` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. |
|
||||
| 필수 섹션 미완성 | `# 2`, `# 3`, `# 6`, `# 8`, `# 10`, `# 11` 섹션이 존재하고 내용이 채워져 있어야 한다. |
|
||||
| Ready for Design 사전 설정 | `Ready for Design: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. |
|
||||
|
||||
> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다.
|
||||
|
||||
### 4. 문서 업데이트 (승인 가능 시에만 실행)
|
||||
|
||||
아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다.
|
||||
|
||||
1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경
|
||||
2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경
|
||||
3. `# 11. Planning Freeze`의 `- Handoff Decision:` → `승인`으로 변경
|
||||
4. `# 11. Planning Freeze`의 `- Ready for Design:` → `true`로 변경
|
||||
5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환
|
||||
6. **B 유형 플레이스홀더** → 섹션 11에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거)
|
||||
7. `docs/sdlc/<CYCLE_ID>/index.md`의 Planning 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 2. Planning | ... | ... |`
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **처리 결과**: 승인 완료 또는 승인 불가
|
||||
- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시)
|
||||
- **변경된 필드 목록** (승인 완료 시)
|
||||
- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함
|
||||
- **다음 단계 안내**: 승인 완료 시 Design 단계(`/draft-design <CYCLE_ID>`) 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다.
|
||||
- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다.
|
||||
- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: "confirm-release"
|
||||
description: "Approve a Release document and mark it as confirmed, ready for Operations"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/6_release.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Release 문서를 최종 승인 처리한다.
|
||||
|
||||
목표:
|
||||
- `6_release.md`의 상태를 `confirmed`로 변경한다.
|
||||
- `# 9. Release Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Operations`를 `true`로 변경한다.
|
||||
- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다.
|
||||
- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 플레이스홀더 분류 기준
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다.
|
||||
|
||||
### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소)
|
||||
|
||||
| 플레이스홀더 패턴 | 자동 채움 값 |
|
||||
|---|---|
|
||||
| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) |
|
||||
| `{{CONFIRMED_BY...}}` | 섹션 9의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 |
|
||||
|
||||
### B. 맥락상 해소된 플레이스홀더 (자동 정리)
|
||||
|
||||
섹션 6(체크리스트) 또는 섹션 8(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 9에 이미 기입되어 있으면** 해소된 것으로 간주한다. 차단하지 않는다.
|
||||
|
||||
### C. 실질 미해소 플레이스홀더 (차단 대상)
|
||||
|
||||
섹션 1~5(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `6_release.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다.
|
||||
- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. 플레이스홀더 분류 및 사전 해소
|
||||
|
||||
문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다.
|
||||
|
||||
- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다.
|
||||
- **B 유형**: 섹션 9에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다.
|
||||
- **C 유형**: 목록을 보고하고 승인을 보류한다.
|
||||
|
||||
### 3. 승인 가능 여부 확인 (사전 게이트 검사)
|
||||
|
||||
아래 조건을 모두 충족해야 승인을 진행한다.
|
||||
|
||||
| 항목 | 확인 기준 |
|
||||
|------|-----------|
|
||||
| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. |
|
||||
| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. |
|
||||
| 오픈 질문 미해소 | `# 5` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. |
|
||||
| 필수 섹션 미완성 | `# 2`, `# 3`, `# 4`, `# 6`, `# 8`, `# 9` 섹션이 존재하고 내용이 채워져 있어야 한다. |
|
||||
| Ready for Operations 사전 설정 | `Ready for Operations: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. |
|
||||
|
||||
> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다.
|
||||
|
||||
### 4. 문서 업데이트 (승인 가능 시에만 실행)
|
||||
|
||||
아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다.
|
||||
|
||||
1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경
|
||||
2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경
|
||||
3. `# 9. Release Freeze`의 `- Handoff Decision:` → `승인`으로 변경
|
||||
4. `# 9. Release Freeze`의 `- Ready for Operations:` → `true`로 변경
|
||||
5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환
|
||||
6. **B 유형 플레이스홀더** → 섹션 9에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거)
|
||||
7. `docs/sdlc/<CYCLE_ID>/index.md`의 Release 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 6. Release | ... | ... |`
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **처리 결과**: 승인 완료 또는 승인 불가
|
||||
- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시)
|
||||
- **변경된 필드 목록** (승인 완료 시)
|
||||
- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함
|
||||
- **다음 단계 안내**: 승인 완료 시 Operations 단계(`/draft-operation <CYCLE_ID>`) 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다.
|
||||
- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다.
|
||||
- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: "confirm-verification"
|
||||
description: "Approve a Verification document and mark it as confirmed, ready for Release"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/5_verification.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Verification 문서를 최종 승인 처리한다.
|
||||
|
||||
목표:
|
||||
- `5_verification.md`의 상태를 `confirmed`로 변경한다.
|
||||
- `# 9. Verification Freeze`의 `Handoff Decision`을 `승인`으로, `Ready for Release`를 `true`로 변경한다.
|
||||
- `마지막 갱신 시각(KST)`과 승인 시각(`CONFIRMED_AT_KST`)을 현재 시각으로 채운다.
|
||||
- 승인 불가 조건이 있으면 문서를 변경하지 않고 이유를 보고한다.
|
||||
|
||||
---
|
||||
|
||||
## 플레이스홀더 분류 기준
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 동일하게 차단 조건으로 취급하지 않는다. 아래 세 유형으로 먼저 분류한다.
|
||||
|
||||
### A. 승인 행위 자체로 채워지는 플레이스홀더 (자동 해소)
|
||||
|
||||
| 플레이스홀더 패턴 | 자동 채움 값 |
|
||||
|---|---|
|
||||
| `{{CONFIRMED_AT_KST...}}` | 현재 시각 (KST, `YYYY-MM-DD HH:MM:SS KST`) |
|
||||
| `{{CONFIRMED_BY...}}` | 섹션 9의 `Confirmed By:` 줄에서 읽은 값. 해당 줄이 없으면 차단하지 않고 플레이스홀더를 제거한 뒤 빈 값으로 처리 |
|
||||
|
||||
### B. 맥락상 해소된 플레이스홀더 (자동 정리)
|
||||
|
||||
섹션 6(체크리스트) 또는 섹션 8(사용자 결정 요약)에 있는 플레이스홀더는 **해당 결정의 실질 값이 섹션 9에 이미 기입되어 있으면** 해소된 것으로 간주한다. 차단하지 않는다.
|
||||
|
||||
### C. 실질 미해소 플레이스홀더 (차단 대상)
|
||||
|
||||
섹션 1~5(본문 내용)에 남아 있는 `{{...}}` 플레이스홀더로서, 위 A·B 유형에 해당하지 않는 것. 이 플레이스홀더가 하나라도 있으면 승인을 보류한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 값이 CYCLE_ID(예: `sdlc-001`)이면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `5_verification.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로를 사용한다.
|
||||
- 파일이 존재하지 않으면 경로를 재확인하도록 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. 플레이스홀더 분류 및 사전 해소
|
||||
|
||||
문서 전체의 `{{...}}` 플레이스홀더를 스캔해 A·B·C 유형으로 분류한다.
|
||||
|
||||
- **A 유형**: 목록만 기록한다. 4단계에서 자동으로 채운다.
|
||||
- **B 유형**: 섹션 9에서 실질 값을 읽어 치환 가능한지 확인한다. 가능하면 4단계에서 함께 처리한다.
|
||||
- **C 유형**: 목록을 보고하고 승인을 보류한다.
|
||||
|
||||
### 3. 승인 가능 여부 확인 (사전 게이트 검사)
|
||||
|
||||
아래 조건을 모두 충족해야 승인을 진행한다.
|
||||
|
||||
| 항목 | 확인 기준 |
|
||||
|------|-----------|
|
||||
| 문서 상태 | `confirmed`가 아닌 상태(`draft` 또는 `review`)여야 한다. 이미 `confirmed`면 중단한다. |
|
||||
| 실질 미해소 플레이스홀더 (C 유형) | C 유형 플레이스홀더가 0개여야 한다. |
|
||||
| 검증 항목 미통과 | `# 3` 검증 결과에 `실패` 또는 `블로킹` 상태 항목이 없어야 한다. |
|
||||
| 결함(BUG) Open 상태 | `# 4` BUG 목록에 `Open` 상태 항목이 없어야 한다. |
|
||||
| 오픈 질문 미해소 | `# 5` 오픈 질문 목록에 `상태: Open`인 항목이 없어야 한다. |
|
||||
| 필수 섹션 미완성 | `# 2`, `# 3`, `# 6`, `# 8`, `# 9` 섹션이 존재하고 내용이 채워져 있어야 한다. |
|
||||
| Ready for Release 사전 설정 | `Ready for Release: false`이거나 아직 갱신 전인 경우만 승인 처리 대상이다. 이미 `true`이면 이미 처리된 문서임을 알린다. |
|
||||
|
||||
> **예외**: C 유형 플레이스홀더 또는 오픈 질문 미해소만 문제인 경우, 사용자가 명시적으로 `--force`를 표현했으면 해당 항목 목록을 보고하되 승인을 진행한다. 단, 검증 실패/블로킹 항목이나 BUG `Open` 항목이 있으면 `--force`로도 승인하지 않는다.
|
||||
|
||||
### 4. 문서 업데이트 (승인 가능 시에만 실행)
|
||||
|
||||
아래 항목을 변경한다. 이 목록 외 내용은 절대 수정하지 않는다.
|
||||
|
||||
1. `# 0. 문서 상태`의 `- 상태:` 줄 → `confirmed`로 변경
|
||||
2. `# 0. 문서 상태`의 `- 마지막 갱신 시각(KST):` → 현재 시각으로 변경
|
||||
3. `# 9. Verification Freeze`의 `- Handoff Decision:` → `승인`으로 변경
|
||||
4. `# 9. Verification Freeze`의 `- Ready for Release:` → `true`로 변경
|
||||
5. **A 유형 플레이스홀더** → 각 자동 채움 값으로 치환
|
||||
6. **B 유형 플레이스홀더** → 섹션 9에서 읽은 실질 값으로 치환 (또는 플레이스홀더 제거)
|
||||
7. `docs/sdlc/<CYCLE_ID>/index.md`의 Verification 행 `상태` 열 → `` `confirmed` ``로 변경. 행 형식: `| 5. Verification | ... | ... |`
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **처리 결과**: 승인 완료 또는 승인 불가
|
||||
- **자동 처리된 플레이스홀더 목록** (A·B 유형, 승인 완료 시)
|
||||
- **변경된 필드 목록** (승인 완료 시)
|
||||
- **미충족 항목 목록** (승인 불가 시): 각 항목에 대한 조치 안내 포함
|
||||
- **다음 단계 안내**: 승인 완료 시 Release 단계(`/draft-release <CYCLE_ID>`) 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 4단계에서 명시된 항목 외에는 문서 내용을 절대 변경하지 않는다.
|
||||
- C 유형 미해소 조건이 있으면 문서에 아무 변경도 가하지 않는다.
|
||||
- 이미 `confirmed` 상태인 문서에는 재처리하지 않는다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
description: "Use when: /design-confirm to validate design document readiness and mark it as confirmed"
|
||||
name: "design-confirm"
|
||||
argument-hint: "Enter a Design ID in dsn-001 format."
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Design 승인 처리 도우미다.
|
||||
사용자가 입력한 Design 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `dsn-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/design/
|
||||
- 패턴: <입력ID>_*.design.md
|
||||
- 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 연결 Planning 검증 규칙:
|
||||
- Design 문서의 `입력 Planning:` 줄에서 연결된 Planning 문서 경로를 확인한다.
|
||||
- 연결 Planning 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다.
|
||||
- 연결 Planning 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다.
|
||||
5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능):
|
||||
- `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다.
|
||||
- `# 1. Design 개요`에 입력 Planning/목적/설계 대상 작업(WSJF 상위 3개)이 존재한다.
|
||||
- `# 2. 설계 대안 비교`에 우선순위 상위 작업별 최소 2개 대안과 선택 근거가 존재한다.
|
||||
- `# 3. 인터페이스 정의`에 각 작업별 입력/출력/오류 경로가 존재한다.
|
||||
- `# 4. 데이터/흐름 설계`에 주요 작업 흐름이 존재한다.
|
||||
- `# 5. 테스트 전략 연계`에 작업별 AC와 검증 포인트가 1개 이상 매핑된다.
|
||||
- `# 6. 리스크 대응 설계`에 Planning 리스크별 대응 전략이 존재한다.
|
||||
- `# 7. Implementation 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다.
|
||||
- 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다.
|
||||
6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다.
|
||||
7. 승인 가능 시 아래 순서로 문서를 수정한다:
|
||||
a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다.
|
||||
b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다.
|
||||
c. `# 7. Implementation 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다.
|
||||
d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다.
|
||||
8. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장한다.
|
||||
- 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Design 파일 검색
|
||||
3. 문서 본문 읽기
|
||||
4. 연결 Planning 문서 존재/상태 확인
|
||||
5. 승인 가능 여부 체크리스트 전체 점검
|
||||
6. 승인 불가 항목이 있으면 보고하고 종료
|
||||
7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장
|
||||
8. 최종 응답에 처리 결과 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 승인 가능 여부 (가능/불가)
|
||||
4. 승인 불가 시: 미충족 항목 목록
|
||||
5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리)
|
||||
6. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
description: "Use when: /design-draft to generate design alternatives, interface contracts, data flow, and test strategy from a Planning document ID"
|
||||
name: "design-draft"
|
||||
argument-hint: "Enter a Planning ID in pln-001 format."
|
||||
agent: "agent"
|
||||
model: "planner"
|
||||
tools: [read, edit, search, web, agent, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Design 초안 작성 도우미다.
|
||||
사용자가 입력한 Planning 문서 ID를 기준으로 Design 초안(설계 선택지 비교 + 인터페이스 정의 + 데이터 흐름 + 테스트 전략)을 작성하고 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `pln-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Planning 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/planning/
|
||||
- 패턴: <입력ID>_*.planning.md
|
||||
- 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다.
|
||||
4. Planning 문서 상태 확인:
|
||||
- 상태가 `confirmed`가 아니면 "Planning이 아직 승인되지 않았다. /planning-confirm을 먼저 실행하라"로 보고하고 종료한다.
|
||||
5. Design 파일 생성 규칙:
|
||||
- 저장 폴더: docs/sdlc/design/
|
||||
- 파일명: dsn-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.design.md
|
||||
- 문서번호: 기존 dsn 번호 최대값 + 1, 없으면 001부터 시작
|
||||
- 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지
|
||||
- append 금지, 생성/갱신 시 overwrite
|
||||
- Design 본문 기본 템플릿: .github/templates/design-note.template.md
|
||||
6. Design 작성 원칙:
|
||||
- Planning의 WSJF 우선순위 상위 3개 작업(P-001~P-003 등)을 우선 설계 대상으로 삼는다.
|
||||
- 나머지 작업도 인터페이스/데이터 흐름은 반드시 포함한다.
|
||||
- 각 작업마다 최소 2개 설계 대안을 비교하고 선택 근거를 남긴다.
|
||||
- 인터페이스 정의는 입력/출력/오류 경로를 포함한다.
|
||||
- 테스트 전략은 AC와 직접 연결한다.
|
||||
7. 플레이스홀더 규칙:
|
||||
- 결정 필요: {{DECIDE: 질문}}
|
||||
- 확인 필요: {{CONFIRM: 내용}}
|
||||
- 추가 정보 필요: {{DATA: 필요한 정보}}
|
||||
- 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다.
|
||||
8. 문서 상태 규칙:
|
||||
- 최상단 `# 0. 문서 상태` 필수
|
||||
- 상태: 초안 생성 시 `draft`
|
||||
- 승인자 불명확 시 `{{DECIDE: 이 Design의 최종 승인자는 누구인가?}}`
|
||||
- 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}`
|
||||
9. Implementation 전달 체크 규칙:
|
||||
- 우선순위 상위 작업의 설계 근거 존재 여부를 체크한다.
|
||||
- 주요 리스크(Planning의 R-1~R-N)에 대한 설계 대응이 반영됐는지 확인한다.
|
||||
10. # 9 사용자 결정 필요 항목 요약 규칙:
|
||||
- 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다.
|
||||
- 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Planning 파일 검색 및 상태 확인
|
||||
3. Planning 본문(백로그, AC, 리스크, 제약사항) 읽기
|
||||
4. WSJF 상위 작업 식별 및 설계 대안 비교
|
||||
5. 전체 작업 인터페이스/데이터 흐름 정의
|
||||
6. AC 기반 테스트 전략 매핑
|
||||
7. Design 문서 저장
|
||||
8. 본문 플레이스홀더 집계 후 # 9 작성
|
||||
9. 최종 응답에 처리 요약 제공
|
||||
|
||||
Design 문서 출력 섹션 순서(고정):
|
||||
0. 문서 상태
|
||||
1. Design 개요
|
||||
2. 설계 대안 비교 (우선순위 상위 작업)
|
||||
3. 인터페이스 정의
|
||||
4. 데이터/흐름 설계
|
||||
5. 테스트 전략 연계 (AC 매핑)
|
||||
6. 리스크 대응 설계
|
||||
7. Implementation 단계 전달 체크
|
||||
8. 파일 처리 결과
|
||||
9. 사용자 결정 필요 항목 요약
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 입력 Planning 문서 경로
|
||||
3. 형식 오류/미발견/미승인 여부
|
||||
4. Design 문서 생성/갱신 결과
|
||||
5. 추가된 사용자 결정 항목 요약
|
||||
6. 업데이트된 파일 경로 목록
|
||||
7. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
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}}
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
description: "Use when: /discovery-confirm to validate discovery document readiness and mark it as confirmed"
|
||||
name: "discovery-confirm"
|
||||
argument-hint: "Enter a Discovery ID in dcy-001 format."
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Discovery 승인 처리 도우미다.
|
||||
사용자가 입력한 Discovery 문서 ID를 검토해 Planning 단계로 전달 가능한지 판단하고, 가능하면 문서를 confirmed 상태로 전환한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `dcy-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/discovery/
|
||||
- 패턴: <입력ID>_*.discovery.md
|
||||
- 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능):
|
||||
- 문서에 `# 0`부터 `# 10`까지 섹션이 순서대로 모두 존재한다.
|
||||
- `# 8. Planning으로 넘기기 전 확인 체크`의 체크 항목이 1개 이상 존재한다.
|
||||
- `# 8. Planning으로 넘기기 전 확인 체크`의 체크 항목이 모두 `[x]`이다.
|
||||
- `# 8`의 각 체크 항목 기준에서 `{{DECIDE:`, `{{DATA:` 형태의 미해결 플레이스홀더가 없다.
|
||||
- `# 10. 사용자 결정 필요 항목 요약`에 본문의 미해결 플레이스홀더가 정확히 집계되어 있다.
|
||||
5. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다.
|
||||
6. 승인 가능 시 아래 순서로 문서를 수정한다:
|
||||
a. `# 10. Planning으로 넘기기 전 확인 체크` 섹션에서 플레이스홀더를 모두 해결된 상태로 표시한다.
|
||||
b. `# 0. 문서 상태` 섹션의 아래 2개 필드를 갱신한다.
|
||||
- `상태:` → `confirmed`
|
||||
- `승인 시각:` → `YYYY-MM-DD` (현재 날짜)
|
||||
(예: `- 상태: confirmed`, `- 승인 시각: 2026-04-14`)
|
||||
7. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장한다.
|
||||
- 위의 2개 항목(a~b) 외에는 기존 내용을 변경하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Discovery 파일 검색
|
||||
3. 문서 본문 읽기
|
||||
4. 승인 가능 여부 체크리스트 전체 점검
|
||||
5. 승인 불가 항목이 있으면 보고하고 종료
|
||||
6. 승인 가능하면 a~b 순서로 문서 수정 및 overwrite 저장
|
||||
7. 최종 응답에 처리 결과 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 승인 가능 여부 (가능/불가)
|
||||
4. 승인 불가 시: 미충족 항목 목록
|
||||
5. 승인 완료 시: 수정 내역 요약 (확인 상태, 확인 일자, 플레이스홀더 정리)
|
||||
6. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,107 +0,0 @@
|
||||
---
|
||||
description: "Use when: /discovery-draft to assess planning status, detect duplicate/new requirements, and auto-create discovery draft file"
|
||||
name: "discovery-draft"
|
||||
argument-hint: "Enter the feature description in a single sentence."
|
||||
agent: "agent"
|
||||
model: "planner"
|
||||
tools: [read, edit, search, web, agent, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Discovery 작성 도우미다.
|
||||
사용자가 입력한 한 문장을 바탕으로 Discovery 초안을 작성하고 파일로 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 기존 문서와의 관계를 먼저 판정한다: 완전 중복 / 유사 / 신규.
|
||||
3. 분기 규칙:
|
||||
- 완전 중복: 새 파일 생성 금지, 기존 문서 경로와 근거 제시
|
||||
- 유사: 새 파일 생성 + 관련 기존 문서 경로와 차이점 제시
|
||||
- 신규: 새 파일 생성
|
||||
4. 파일 생성 규칙:
|
||||
- 저장 폴더: docs/sdlc/discovery/
|
||||
- 파일명: dcy-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.discovery.md
|
||||
- 문서번호: 기존 dcy 번호 최대값 + 1
|
||||
- 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지
|
||||
- append 금지, 갱신 시 overwrite
|
||||
- Discovery 본문 기본 템플릿: .github/templates/discovery-note.template.md
|
||||
5. 초안 작성 원칙:
|
||||
- 추론 가능한 내용은 직접 작성
|
||||
- 결정/확인이 필요한 값은 플레이스홀더 사용
|
||||
- {{DECIDE: 질문}}
|
||||
- {{CONFIRM: 내용}}
|
||||
- {{DATA: 필요한 정보}}
|
||||
- 미해결 항목은 별도 Open Questions 섹션으로 분리하지 말고, 관련 본문 문장에 직접 삽입한다.
|
||||
- 승인 책임자가 불명확하면 관련 본문 문장에 {{DECIDE: 이 기능의 책임 승인자는 누구인가?}}를 삽입한다.
|
||||
6. 문서 섹션은 0~10 순서를 반드시 유지한다.
|
||||
- "# 0. 문서 상태"는 항상 최상단에 위치하며 아래 3개 필드를 포함한다.
|
||||
- 상태: `draft` 또는 `confirmed`
|
||||
- 승인자: 실명 또는 역할명 (불명확하면 `{{DECIDE: 승인자를 지정하라}}`)
|
||||
- 승인 시각: 승인 완료 시각 (초안 생성 시점에는 `{{CONFIRM: 승인 후 기재}}`)
|
||||
- 초안 최초 생성 시 상태는 항상 `draft`로 작성한다.
|
||||
7. 요구사항 목록 작성 규칙:
|
||||
- "# 5. 요구사항 목록"에는 반드시 아래 3개 하위 구성을 포함한다.
|
||||
- 기능 요구사항
|
||||
- 비기능 요구사항
|
||||
- 범위 경계
|
||||
- 범위 경계는 최소한 `In Scope`와 `Out of Scope`를 포함해야 한다.
|
||||
- 기능 요구사항/비기능 요구사항/범위 경계가 누락되면 초안이 미완성으로 간주한다.
|
||||
7-1. 문제정의 요약 작성 규칙:
|
||||
- "# 3. 문제점의 요약"은 반드시 아래 4개 서브항목을 포함한다.
|
||||
- 현재 상태
|
||||
- 기대 상태
|
||||
- 이해관계자: 이 기능을 필요로 하거나 영향을 받는 주체(예: 신규 프로젝트 시작자, 온보딩 담당자, 승인권자). 추론 가능하면 직접 작성하고, 불명확하면 `{{DECIDE: 주요 이해관계자를 식별하라}}`를 삽입한다.
|
||||
- 제약사항
|
||||
- 이해관계자가 누락되면 초안이 미완성으로 간주한다.
|
||||
8. 리스크/가정 목록 작성 규칙:
|
||||
- "# 6. 리스크/가정 목록"의 각 리스크 항목은 아래 구조로 작성한다.
|
||||
```
|
||||
- R-N (High/Medium/Low): 리스크 설명.
|
||||
- 완화 방안: ...
|
||||
```
|
||||
- 완화 방안 작성 기준:
|
||||
- 문서 내 기존 결정(범위 경계, 제약사항, 요구사항)으로 완화 가능하면 해당 근거를 직접 작성한다.
|
||||
- 기술적/운영적으로 일반 관행으로 완화 가능하면 agent가 직접 작성한다.
|
||||
- 완화 방안이 사용자 결정에 달린 경우 `{{DECIDE: 완화 방안을 결정하라}}`를 삽입한다.
|
||||
- 완화 가능성 자체가 불명확하면 `{{DATA: 완화 방안 수립을 위한 추가 정보 필요}}`를 삽입한다.
|
||||
- 가정 항목은 완화 방안 없이 사실 선언으로만 작성한다.
|
||||
|
||||
9. 미해결 항목 정규화 규칙:
|
||||
- 본문 내 미결정 사항은 해당 문장 바로 뒤에 플레이스홀더를 둔다.
|
||||
- 별도 질문-답변 매핑표 또는 Open Questions 섹션을 만들지 않는다.
|
||||
- 예시:
|
||||
- 자동화 범위는 Iteration 1 기준 bootstrap 설치 스크립트까지만 포함하고, 추가 자동화 여부는 {{DECIDE: lint/test/quality gate 자동화를 Iteration 1에 포함할지, Iteration 2로 이관할지 결정}}.
|
||||
- Python/Node 버전 범위는 {{DATA: Python/Node 버전 범위}}.
|
||||
10. Planning으로 넘기기 전 확인 체크 작성 규칙:
|
||||
- 각 체크 항목 아래에 판정 기준 또는 근거를 1줄 이상 적는다.
|
||||
- "범위(In Scope/Out of Scope) 확정"은 본문에 포함/제외 범위가 명시되어 있을 때만 체크한다.
|
||||
- "성공 지표의 측정 방식/데이터 출처 확정"은 각 성공 지표별 측정 방식과 데이터 출처가 있을 때만 체크한다.
|
||||
- "High 영향 플레이스홀더 우선순위 및 해소 책임자 지정"은 High 영향 플레이스홀더가 남아 있으면 기준에 {{DECIDE: ... 우선순위/책임자}}를 명시하고, 남아 있지 않으면 "[x] 미해결 High 영향 플레이스홀더 없음"으로 표시한다.
|
||||
- "승인자 확정"은 승인 책임자가 본문에 명시되어 있을 때만 체크한다.
|
||||
|
||||
실행 절차:
|
||||
1. docs/sdlc/discovery/*.discovery.md 검색
|
||||
2. 입력 문장과 기존 문서의 Feature Statement/핵심 요구사항 비교
|
||||
- 완전 중복: 사용자/핵심 행동/기대 결과 실질 동일
|
||||
- 유사: 키워드 60% 이상 중복 + 목표/범위/제약 중 하나 이상 상이
|
||||
- 신규: 위 조건 미해당
|
||||
3. 판정에 따라 분기 처리 및 파일 생성 여부 결정
|
||||
4. 문서 생성/갱신 시 중복 섹션 없이 단일 완성본으로 저장
|
||||
5. 본문 내 미해결 항목이 플레이스홀더로 표기되었는지 검증
|
||||
6. {{DECIDE}}/{{CONFIRM}}/{{DATA}} 항목을 # 10에 요약
|
||||
7. 최종 응답에 판정 결과, 생성/미생성 경로, 참조 문서(있으면), 다음 액션 포함
|
||||
|
||||
출력 섹션 순서(고정):
|
||||
0. 문서 상태
|
||||
1. 계획 상태 요약
|
||||
2. 요구사항 판정 결과 (완전 중복/유사/신규 + 근거)
|
||||
3. 문제정의 요약
|
||||
4. 이번에 만들 기능 1개
|
||||
5. 요구사항 목록
|
||||
6. 리스크/가정 목록
|
||||
7. 초기 성공 기준
|
||||
8. Planning으로 넘기기 전 확인 체크
|
||||
9. 파일 처리 결과 (생성/미생성 경로)
|
||||
10. 사용자 결정 필요 항목 요약
|
||||
|
||||
사용자 입력 문장:
|
||||
{{input}}
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
description: "Use when: /discovery-review to re-review existing discovery documents and update them in place"
|
||||
name: "discovery-review"
|
||||
argument-hint: "Enter discovery IDs separated by commas. Example: dcy-001, dcy-002"
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo, agent]
|
||||
---
|
||||
|
||||
당신은 SDLC Discovery 문서 재검토 도우미다.
|
||||
사용자가 지정한 Discovery 문서 ID 목록을 다시 검토하고, 필요한 내용을 문서에 반영해 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력은 쉼표(,) 기준으로 분리해 문서 ID 목록으로 처리한다.
|
||||
3. 입력 정규화 규칙:
|
||||
- 공백 제거
|
||||
- 소문자 정규화(dcy-001 형식)
|
||||
- 중복 ID 제거(예: dcy-001, dcy-001 입력 시 1회만 처리)
|
||||
4. ID 형식은 dcy-<3자리숫자>만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다.
|
||||
5. 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/discovery/
|
||||
- 패턴: <문서ID>_*.discovery.md
|
||||
- 예: dcy-001 -> docs/sdlc/discovery/dcy-001_*.discovery.md
|
||||
6. 존재하지 않는 문서는 생성하지 않는다.
|
||||
- 미존재 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다.
|
||||
7. 문서 재검토 항목:
|
||||
- 섹션 0~10 순서/유일성 검증
|
||||
- `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드가 모두 존재하는지 검증
|
||||
- 필드 누락 시 플레이스홀더로 보정(상태 불명확 → `draft`, 승인 시각 미기재 → `{{CONFIRM: 승인 후 기재}}`)
|
||||
- `# 3. 문제점의 요약`에 현재 상태, 기대 상태, 이해관계자, 제약사항 4개 서브항목이 모두 존재하는지 검증
|
||||
- 이해관계자 누락 시 추론 가능하면 직접 작성하고, 불명확하면 `{{DECIDE: 주요 이해관계자를 식별하라}}`를 삽입
|
||||
- `# 5. 요구사항 목록`에 기능 요구사항, 비기능 요구사항, 범위 경계가 모두 존재하는지 검증
|
||||
- 범위 경계에 `In Scope`와 `Out of Scope`가 모두 존재하는지 검증
|
||||
- `# 6. 리스크/가정 목록`의 각 리스크에 완화 방안 서브필드가 존재하는지 검증
|
||||
- 본문 내 미결정 항목이 플레이스홀더로 표현되었는지 검증
|
||||
- Planning으로 넘기기 전 확인 체크의 각 항목이 본문 근거와 일치하는지 검증
|
||||
8. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장
|
||||
- 기존 사용자 의도/내용은 유지하되, 누락/불일치/중복 섹션만 보정
|
||||
9. 추가 의사결정이 필요하면 플레이스홀더를 반드시 삽입한다.
|
||||
- {{DECIDE: 질문}}
|
||||
- {{CONFIRM: 내용}}
|
||||
- {{DATA: 필요한 정보}}
|
||||
- {{DELEGATE_TO: agent}} (agent 자동 결정)
|
||||
10. Approver가 불명확하면 아래 플레이스홀더를 사용한다.
|
||||
- {{DECIDE: 이 기능의 책임 승인자는 누구인가?}}
|
||||
11. 플레이스홀더가 문서 본문에 추가/존재하면 # 10. 사용자 결정 필요 항목 요약에 반드시 집계한다.
|
||||
12. # 10 집계 시 {{DECIDE}}, {{CONFIRM}}, {{DATA}}, {{DELEGATE_TO}}를 유형별로 분리하고 중복 문구는 1회만 남긴다.
|
||||
13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다.
|
||||
14. 본문 플레이스홀더 정규화 규칙:
|
||||
- 미해결 사항은 관련 본문 문장에 직접 연결된 플레이스홀더로 유지한다.
|
||||
- 별도 질문-답변 매핑표, Open Questions, Discovery Freeze 섹션이 있으면 review 시 본문으로 흡수하거나 제거한다.
|
||||
- {{DELEGATE_TO: agent}} 형식의 항목은 agent가 결정을 생성해 본문 문장으로 대체하고, 요약 섹션에서도 제거한다.
|
||||
- Planning으로 넘기기 전 확인 체크는 본문 근거가 없으면 체크 해제하거나 근거 문장을 보강한다.
|
||||
- 미해결 High 영향 플레이스홀더가 없으면 관련 체크 항목은 "미해결 High 영향 플레이스홀더 없음" 근거로 정규화한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 목록 정규화(공백 제거, 중복 제거, 형식 검증)
|
||||
2. 각 ID에 대해 대상 파일 검색
|
||||
3. 발견 문서 내용 읽기
|
||||
4. 검토 체크리스트 기준으로 누락/불일치 판단
|
||||
5. 본문 내 미해결 항목을 플레이스홀더 형식으로 정규화하고, 별도 Q&A/Open Questions 섹션은 본문으로 흡수
|
||||
6. 필요한 항목만 보정하여 문서 overwrite 저장
|
||||
7. 문서별 플레이스홀더를 #10에 집계/정규화
|
||||
8. 최종 응답에 처리 요약 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 정규화된 대상 ID 목록
|
||||
3. 형식 오류 ID 목록(있으면)
|
||||
4. 미발견 ID 목록(있으면)
|
||||
5. 문서별 검토 결과
|
||||
6. 문서별 수정 내역 요약
|
||||
7. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}})
|
||||
8. 업데이트된 파일 경로 목록
|
||||
9. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: "draft-design"
|
||||
description: "Create a 3_design.md draft from a confirmed Planning document"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/2_planning.md"
|
||||
agent: "agent"
|
||||
---
|
||||
확정된 Planning 문서를 기반으로 Design 초안(`3_design.md`)을 생성한다.
|
||||
|
||||
목표:
|
||||
- `docs/sdlc/<CYCLE_ID>/3_design.md`를 생성한다.
|
||||
- `2_planning.md`의 확정 내용(태스크, 요구사항, 검증 계획, 리스크)을 Design 초안의 입력으로 사용한다.
|
||||
- 추론 가능한 항목은 초안 문장으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `2_planning.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `2_planning.md`를 찾는다.
|
||||
- 파일이 없으면 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. Planning 인계 조건 확인
|
||||
|
||||
`2_planning.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다.
|
||||
|
||||
| 항목 | 기준 |
|
||||
|------|------|
|
||||
| 문서 상태 | `confirmed`여야 한다 |
|
||||
| Ready for Design | `true`여야 한다 |
|
||||
| 3_design.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 |
|
||||
|
||||
### 3. Planning 내용 추출
|
||||
|
||||
`2_planning.md`와 `1_discovery.md`에서 아래 항목을 읽어 Design 초안 작성에 사용한다.
|
||||
|
||||
- 이슈명 (`# 0`의 `이슈명:`)
|
||||
- 문서 ID / CYCLE_ID
|
||||
- 태스크 전체 목록 및 담당자 (`# 2`)
|
||||
- 태스크별 DoD (`# 2`)
|
||||
- FR/NFR 목록 (`# 1`)
|
||||
- 검증 계획 개요 (`# 6`)
|
||||
- 리스크 및 완화 방안 (`# 7`)
|
||||
- Deferred 처리된 오픈 질문 (`# 7`)
|
||||
- 외부 의존성 및 기술/환경 제약 (`# 5`)
|
||||
|
||||
### 4. Design 초안 작성 원칙
|
||||
|
||||
- Planning 태스크 구조와 FR/NFR을 바탕으로 각 태스크의 설계 방향, 변경 대상, 입출력을 초안으로 채운다.
|
||||
- 저장소 구조, 파일 경로, 기존 코드 패턴을 실제로 확인해 변경 대상(`DESIGN_TARGET_N`)을 구체적으로 명시한다.
|
||||
- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다.
|
||||
- 외부 시스템 계약이 미확정인 인터페이스
|
||||
- Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`)
|
||||
- 보안 고려사항(`# 5`)은 변경 내용을 기준으로 OWASP Top 10 항목을 점검해 해당/비해당과 근거를 채운다.
|
||||
|
||||
### 5. 자동으로 채워야 하는 항목
|
||||
|
||||
| 항목 | 채움 방법 |
|
||||
|------|---------|
|
||||
| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Planning 경로를 자동 입력 |
|
||||
| `# 1` Planning 인계 요약 | Planning `# 2` 태스크 목록 이식, `# 7`의 Deferred 항목 이식 |
|
||||
| `# 2` 아키텍처/구조 개요 | FR/NFR과 저장소 구조를 기반으로 변경 영향 범위 초안 작성 |
|
||||
| `# 2` 주요 컴포넌트 | 실제 파일/모듈/디렉터리 구조를 확인해 영향 컴포넌트 나열 |
|
||||
| `# 3` 상세 설계 | 각 T-N 태스크별 설계 방향, 변경 대상, 입출력 초안 작성 |
|
||||
| `# 4` 인터페이스 정의 | FR/NFR 기반으로 필요한 API, 함수 시그니처, 스키마 초안 작성 |
|
||||
| `# 5` 보안 고려사항 | 변경 내용 기준 OWASP 항목 점검, 해당/비해당 및 대응 방안 채움 |
|
||||
| `# 6` 리스크 | Planning 이월 리스크 중 Design 관련 항목 포함 및 신규 Design 리스크 추가 |
|
||||
| `# 8` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 |
|
||||
| `# 9` 사용자 결정 필요 | 미확정 인터페이스, 외부 시스템 계약 등 사용자 결정 필요 항목 정리 |
|
||||
| `# 10` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Implementation: false` 초기값 입력 |
|
||||
|
||||
### 6. 파일 생성
|
||||
|
||||
- 경로: `docs/sdlc/<CYCLE_ID>/3_design.md`
|
||||
- 기반: `.github/templates/sdlc/3_design.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다.
|
||||
|
||||
### 7. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **생성 결과**: 파일 경로
|
||||
- **채워진 항목 요약**: 자동 추론으로 채운 주요 내용 목록
|
||||
- **사용자 결정 필요 항목**: `# 9`에 정리된 항목 요약
|
||||
- **다음 단계 안내**: Design 검토 후 `/confirm-design <CYCLE_ID>` 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- Planning이 `confirmed` 상태가 아니면 초안을 생성하지 않는다.
|
||||
- 이미 `3_design.md`가 존재하는 경우 사용자 명시 없이 덮어쓰지 않는다.
|
||||
- 변경 대상 경로/파일명은 저장소를 직접 확인해 실제 존재하는 경로를 사용한다. 추측으로 채우지 않는다.
|
||||
- 보안 고려사항은 "비해당"이라도 근거를 한 줄 이상 남긴다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: "draft-implementation"
|
||||
description: "Create a 4_implementation.md draft from a confirmed Design document"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/3_design.md"
|
||||
agent: "agent"
|
||||
---
|
||||
확정된 Design 문서를 기반으로 Implementation 초안(`4_implementation.md`)을 생성한다.
|
||||
|
||||
목표:
|
||||
- `docs/sdlc/<CYCLE_ID>/4_implementation.md`를 생성한다.
|
||||
- `3_design.md`의 확정 내용(태스크, 변경 대상, 인터페이스, 보안)을 Implementation 초안의 입력으로 사용한다.
|
||||
- 추론 가능한 항목은 초안 문장으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `3_design.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `3_design.md`를 찾는다.
|
||||
- 파일이 없으면 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. Design 인계 조건 확인
|
||||
|
||||
`3_design.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다.
|
||||
|
||||
| 항목 | 기준 |
|
||||
|------|------|
|
||||
| 문서 상태 | `confirmed`여야 한다 |
|
||||
| Ready for Implementation | `true`여야 한다 |
|
||||
| 4_implementation.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 |
|
||||
|
||||
### 3. Design 내용 추출
|
||||
|
||||
`3_design.md`와 `2_planning.md`에서 아래 항목을 읽어 Implementation 초안 작성에 사용한다.
|
||||
|
||||
- 이슈명 (`# 0`의 `이슈명:`)
|
||||
- 문서 ID / CYCLE_ID
|
||||
- 태스크 전체 목록 및 담당자 (`# 1`)
|
||||
- 태스크별 변경 대상 파일/함수 (`# 3`)
|
||||
- 태스크별 입출력 및 엣지 케이스 (`# 3`)
|
||||
- 인터페이스 정의 (`# 4`)
|
||||
- 보안 고려사항 (`# 5`)
|
||||
- 리스크 및 완화 방안 (`# 6`)
|
||||
- Deferred 처리된 오픈 질문 (`# 6`)
|
||||
|
||||
### 4. Implementation 초안 작성 원칙
|
||||
|
||||
- Design에서 확정된 태스크 구조와 변경 대상을 기반으로 각 태스크의 구현 방법, 변경 파일, 완료 조건을 초안으로 채운다.
|
||||
- 저장소 구조, 파일 경로, 기존 코드 패턴을 실제로 확인해 변경 파일 목록(`IMP_FILE_N`)을 구체적으로 명시한다.
|
||||
- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다.
|
||||
- 태스크 담당자 (`{{IMP_TASK_OWNER_N:TBD}}`)
|
||||
- Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`)
|
||||
|
||||
### 5. 자동으로 채워야 하는 항목
|
||||
|
||||
| 항목 | 채움 방법 |
|
||||
|------|---------|
|
||||
| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Design 경로를 자동 입력 |
|
||||
| `# 1` Design 인계 요약 | Design `# 1` 태스크 목록 및 변경 대상 이식, `# 6`의 Deferred 항목 이식 |
|
||||
| `# 2` 구현 순서 | 태스크 의존 관계를 기반으로 구현 순서 초안 작성 |
|
||||
| `# 2` 태스크별 구현 방법 | Design `# 3` 상세 설계 내용을 기반으로 구현 접근 방법 초안 작성 |
|
||||
| `# 3` 변경 파일 목록 | Design `# 3`의 변경 대상 파일/함수를 기반으로 실제 경로 확인 후 목록 작성 |
|
||||
| `# 4` 리스크 | Design 이월 리스크 중 Implementation 관련 항목 포함 및 신규 리스크 추가 |
|
||||
| `# 6` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 |
|
||||
| `# 7` 사용자 결정 필요 | 미확정 태스크 담당자, 외부 시스템 호출 확인 필요 항목 정리 |
|
||||
| `# 8` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Verification: false` 초기값 입력 |
|
||||
|
||||
### 6. 파일 생성
|
||||
|
||||
- 경로: `docs/sdlc/<CYCLE_ID>/4_implementation.md`
|
||||
- 기반: `.github/templates/sdlc/4_implementation.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다.
|
||||
|
||||
### 7. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **생성된 파일 경로**
|
||||
- **자동 채워진 항목 목록** (어떤 값으로 채웠는지)
|
||||
- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함)
|
||||
- **다음 단계 안내**: `/review-implementation <CYCLE_ID>` 실행 안내
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: "draft-operation"
|
||||
description: "Create a 7_operation.md draft from a confirmed Release document"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/6_release.md"
|
||||
agent: "agent"
|
||||
---
|
||||
확정된 Release 문서를 기반으로 Operations 초안(`7_operation.md`)을 생성한다.
|
||||
|
||||
목표:
|
||||
- `docs/sdlc/<CYCLE_ID>/7_operation.md`를 생성한다.
|
||||
- `6_release.md`의 배포 결과와 모니터링 정보를 Operations 초안의 입력으로 사용한다.
|
||||
- 추론 가능한 운영 항목은 초안으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `6_release.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `6_release.md`를 찾는다.
|
||||
- 파일이 없으면 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. Release 인계 조건 확인
|
||||
|
||||
`6_release.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다.
|
||||
|
||||
| 항목 | 기준 |
|
||||
|------|------|
|
||||
| 문서 상태 | `confirmed`여야 한다 |
|
||||
| Ready for Operations | `true`여야 한다 |
|
||||
| 7_operation.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 |
|
||||
|
||||
### 3. 내용 추출
|
||||
|
||||
`6_release.md`, `5_verification.md`, `1_discovery.md`에서 아래 항목을 읽어 Operations 초안 작성에 사용한다.
|
||||
|
||||
- 이슈명 (`# 0`의 `이슈명:`)
|
||||
- 문서 ID / CYCLE_ID
|
||||
- 배포 환경 및 배포 방식 (`6_release.md` `# 2`)
|
||||
- 스모크 테스트 항목 (`6_release.md` `# 4`)
|
||||
- Release 모니터링 확인 항목 (`6_release.md` `# 4`)
|
||||
- Deferred 처리된 오픈 질문 (`6_release.md` `# 5`)
|
||||
- 성공 기준(S-N) (`1_discovery.md` `# 7`)
|
||||
|
||||
### 4. Operations 초안 작성 원칙
|
||||
|
||||
- Release의 스모크 테스트/모니터링 항목을 확장해 지속적인 운영 모니터링 항목을 도출한다.
|
||||
- 저장소 구조와 배포 방식을 참고해 장애 대응 절차를 구체적으로 초안으로 작성한다.
|
||||
- `# 6` 다음 Discovery 환류 항목은 초안 생성 시 빈 상태(`없음`)로 두고, 운영 중 갱신하도록 안내한다.
|
||||
- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다.
|
||||
- 모니터링 담당자 (`{{OPS_MONITOR_OWNER:TBD}}`)
|
||||
- 에스컬레이션 연락처 (`{{OPS_ESCALATION_1:TBD}}`)
|
||||
- Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`)
|
||||
|
||||
### 5. 자동으로 채워야 하는 항목
|
||||
|
||||
| 항목 | 채움 방법 |
|
||||
|------|---------|
|
||||
| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Release 경로를 자동 입력 |
|
||||
| `# 1` Release 인계 요약 | Release 배포 결과 요약, Deferred 항목 이식 |
|
||||
| `# 2` 모니터링 항목 | Release 스모크 테스트/모니터링 항목을 기반으로 지속 모니터링 항목 도출, 임계값 초안 작성 |
|
||||
| `# 3` 런북 — 정상 운영 절차 | Release 배포 방식 기반으로 주기적 확인 절차 초안 작성 |
|
||||
| `# 3` 런북 — 장애 대응 절차 | 롤백 계획 및 배포 방식 기반으로 장애 초기 대응 절차 초안 작성 |
|
||||
| `# 5` 리스크 | Release 이월 리스크 중 Operations 관련 항목 포함 |
|
||||
| `# 6` 다음 Discovery 환류 | `없음`으로 초기화 (운영 중 갱신 안내) |
|
||||
| `# 8` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 |
|
||||
| `# 9` 사용자 결정 필요 | 모니터링 담당자, 에스컬레이션 담당자 미지정 항목 정리 |
|
||||
| `# 10` Freeze 플래그 | `Handoff Decision: 보류`, `SDLC 주기 완료: false` 초기값 입력 |
|
||||
|
||||
### 6. 파일 생성
|
||||
|
||||
- 경로: `docs/sdlc/<CYCLE_ID>/7_operation.md`
|
||||
- 기반: `.github/templates/sdlc/7_operation.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다.
|
||||
|
||||
### 7. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **생성된 파일 경로**
|
||||
- **자동 채워진 항목 목록** (어떤 값으로 채웠는지)
|
||||
- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함)
|
||||
- **다음 단계 안내**: `/review-operation <CYCLE_ID>` 실행 안내
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: "draft-planning"
|
||||
description: "Create a 2_planning.md draft from a confirmed Discovery document"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/1_discovery.md"
|
||||
agent: "agent"
|
||||
---
|
||||
확정된 Discovery 문서를 기반으로 Planning 초안(`2_planning.md`)을 생성한다.
|
||||
|
||||
목표:
|
||||
- `docs/sdlc/<CYCLE_ID>/2_planning.md`를 생성한다.
|
||||
- `1_discovery.md`의 확정 내용(FR/NFR, 범위, 성공 기준, 리스크)을 Planning 초안의 입력으로 사용한다.
|
||||
- 추론 가능한 항목은 초안 문장으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `1_discovery.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `1_discovery.md`를 찾는다.
|
||||
- 파일이 없으면 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. Discovery 인계 조건 확인
|
||||
|
||||
`1_discovery.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다.
|
||||
|
||||
| 항목 | 기준 |
|
||||
|------|------|
|
||||
| 문서 상태 | `confirmed`여야 한다 |
|
||||
| Ready for Planning | `true`여야 한다 |
|
||||
| 2_planning.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 |
|
||||
|
||||
### 3. Discovery 내용 추출
|
||||
|
||||
`1_discovery.md`에서 아래 항목을 읽어 Planning 초안 작성에 사용한다.
|
||||
|
||||
- 이슈명 (`# 0`의 `이슈명:`)
|
||||
- 문서 ID / CYCLE_ID
|
||||
- In Scope / Out of Scope (`# 5`)
|
||||
- FR 전체 목록 (`# 5`)
|
||||
- NFR 전체 목록 (`# 5`)
|
||||
- 성공 기준 S-1~S-N (`# 7`)
|
||||
- 리스크 R-1~R-N 및 완화 방안 (`# 6`)
|
||||
- Deferred 처리된 오픈 질문 (`# 6`)
|
||||
- 가정 A-1~A-N (`# 6`)
|
||||
|
||||
### 4. Planning 초안 작성 원칙
|
||||
|
||||
- 입력 요청과 Discovery 내용을 바탕으로 합리적으로 추론 가능한 항목은 자연어 문장으로 채운다.
|
||||
- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다.
|
||||
- 태스크 담당자 (`{{TASK_OWNER_N:TBD}}`)
|
||||
- 마일스톤 목표 날짜 (`{{MILESTONE_N_DATE:TBD}}`)
|
||||
- 이터레이션 기간 (`{{ITERATION_N_PERIOD:TBD}}`)
|
||||
- Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`)
|
||||
- 공수 추정은 유사 작업 기준 또는 태스크 복잡도 기반으로 초안 값을 제안한다. 불확실하면 범위(예: `2-4 SP`)로 표기한다.
|
||||
- 태스크는 각 FR 1개당 최소 1개를 생성하되, 구현/검토/문서화를 묶거나 분리하는 것이 합리적이면 그렇게 한다.
|
||||
|
||||
### 5. 자동으로 채워야 하는 항목
|
||||
|
||||
| 항목 | 채움 방법 |
|
||||
|------|---------|
|
||||
| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Discovery 경로를 자동 입력 |
|
||||
| `# 1` Discovery 인계 요약 | Discovery `# 5` 범위/FR/NFR 내용 요약 이식 |
|
||||
| `# 1` 이월 오픈 질문 | Discovery `# 6`의 `Deferred` 항목 이식 |
|
||||
| `# 2` 태스크 분해 | FR/NFR 기반으로 최소 2개 이상의 태스크 생성 |
|
||||
| `# 2` 태스크 DoD | 각 태스크의 완료 조건을 FR 내용 기반으로 초안 작성 |
|
||||
| `# 3` 공수 추정 | 각 태스크에 초안 공수값 또는 범위 제안 |
|
||||
| `# 4` 마일스톤 | 태스크 그룹 기반으로 최소 1개 이상 초안 작성 |
|
||||
| `# 5` 의존성 | 태스크 간 의존 관계를 분석해 초안 작성 |
|
||||
| `# 6` 검증 계획 | Discovery 성공 기준(S-N)과 연결해 검증 방법 초안 작성 |
|
||||
| `# 7` 리스크 | Discovery 이월 리스크 중 Planning 관련 항목 포함 및 신규 Planning 리스크 추가 |
|
||||
| `# 9` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 |
|
||||
| `# 10` 사용자 결정 필요 | 담당자 지정, 일정 확정, 예산/환경 제약 등 사용자 결정 필요 항목 정리 |
|
||||
| `# 11` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Design: false` 초기값 입력 |
|
||||
|
||||
### 6. 파일 생성
|
||||
|
||||
- 경로: `docs/sdlc/<CYCLE_ID>/2_planning.md`
|
||||
- 기반: `.github/templates/sdlc/2_planning.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다.
|
||||
|
||||
### 7. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **생성 결과**: 파일 경로
|
||||
- **채워진 항목 요약**: 자동 추론으로 채운 주요 내용 목록
|
||||
- **사용자 결정 필요 항목**: `# 10`에 정리된 항목 요약
|
||||
- **다음 단계 안내**: Planning 검토 후 `/confirm-planning <CYCLE_ID>` 실행 안내
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- Discovery가 `confirmed` 상태가 아니면 초안을 생성하지 않는다.
|
||||
- 이미 `2_planning.md`가 존재하는 경우 사용자 명시 없이 덮어쓰지 않는다.
|
||||
- 추론 불가 항목은 `TBD` 대신 의미 있는 플레이스홀더(`{{TASK_OWNER_1:TBD}}` 등)로 남긴다.
|
||||
- 공수 추정 초안은 반드시 근거(유사 사례, 복잡도 판단 등)와 함께 `# 3`에 명시한다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: "draft-release"
|
||||
description: "Create a 6_release.md draft from a confirmed Verification document"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/5_verification.md"
|
||||
agent: "agent"
|
||||
---
|
||||
확정된 Verification 문서를 기반으로 Release 초안(`6_release.md`)을 생성한다.
|
||||
|
||||
목표:
|
||||
- `docs/sdlc/<CYCLE_ID>/6_release.md`를 생성한다.
|
||||
- `5_verification.md`의 검증 결과와 `4_implementation.md`의 변경 파일 목록을 Release 초안의 입력으로 사용한다.
|
||||
- 추론 가능한 배포 계획 항목은 초안으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `5_verification.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `5_verification.md`를 찾는다.
|
||||
- 파일이 없으면 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. Verification 인계 조건 확인
|
||||
|
||||
`5_verification.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다.
|
||||
|
||||
| 항목 | 기준 |
|
||||
|------|------|
|
||||
| 문서 상태 | `confirmed`여야 한다 |
|
||||
| Ready for Release | `true`여야 한다 |
|
||||
| 6_release.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 |
|
||||
|
||||
### 3. 내용 추출
|
||||
|
||||
`5_verification.md`, `4_implementation.md`, `1_discovery.md`에서 아래 항목을 읽어 Release 초안 작성에 사용한다.
|
||||
|
||||
- 이슈명 (`# 0`의 `이슈명:`)
|
||||
- 문서 ID / CYCLE_ID
|
||||
- 검증 결과 요약 (`5_verification.md` `# 3`)
|
||||
- Deferred 처리된 오픈 질문 (`5_verification.md` `# 5`)
|
||||
- 변경 파일 목록 (`4_implementation.md` `# 3`)
|
||||
- 저장소 구조 및 배포 관련 설정 파일
|
||||
|
||||
### 4. Release 초안 작성 원칙
|
||||
|
||||
- 저장소 구조와 배포 관련 파일(`.github/workflows`, `Makefile`, `bootstrap/` 등)을 실제로 확인해 배포 방식과 도구를 구체적으로 초안으로 채운다.
|
||||
- 롤백 계획은 변경 파일 목록을 기반으로 현실적인 롤백 절차를 초안으로 작성한다.
|
||||
- 스모크 테스트 항목은 핵심 기능 FR을 기반으로 도출한다.
|
||||
- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다.
|
||||
- 롤백 담당자 (`{{REL_ROLLBACK_OWNER:TBD}}`)
|
||||
- Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`)
|
||||
|
||||
### 5. 자동으로 채워야 하는 항목
|
||||
|
||||
| 항목 | 채움 방법 |
|
||||
|------|---------|
|
||||
| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Verification 경로를 자동 입력 |
|
||||
| `# 1` Verification 인계 요약 | Verification 검증 결과 요약, Deferred 항목 이식 |
|
||||
| `# 2` 배포 환경/방식/도구 | 저장소 구조 기반으로 배포 방식 초안 작성 |
|
||||
| `# 2` 배포 순서 | 변경 파일 목록 기반으로 의존 관계를 고려한 배포 순서 초안 작성 |
|
||||
| `# 3` 롤백 계획 | 변경 내용에 대한 현실적인 롤백 조건 및 절차 초안 작성 |
|
||||
| `# 4` 스모크 테스트 | FR 기반으로 핵심 시나리오 도출 및 확인 방법 초안 작성 |
|
||||
| `# 5` 리스크 | Verification 이월 리스크 중 Release 관련 항목 포함 |
|
||||
| `# 7` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 |
|
||||
| `# 8` 사용자 결정 필요 | 배포 담당자, 롤백 담당자 미지정 항목 정리 |
|
||||
| `# 9` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Operations: false` 초기값 입력 |
|
||||
|
||||
### 6. 파일 생성
|
||||
|
||||
- 경로: `docs/sdlc/<CYCLE_ID>/6_release.md`
|
||||
- 기반: `.github/templates/sdlc/6_release.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다.
|
||||
|
||||
### 7. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **생성된 파일 경로**
|
||||
- **자동 채워진 항목 목록** (어떤 값으로 채웠는지)
|
||||
- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함)
|
||||
- **다음 단계 안내**: `/review-release <CYCLE_ID>` 실행 안내
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: "draft-verification"
|
||||
description: "Create a 5_verification.md draft from a confirmed Implementation document"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md"
|
||||
agent: "agent"
|
||||
---
|
||||
확정된 Implementation 문서를 기반으로 Verification 초안(`5_verification.md`)을 생성한다.
|
||||
|
||||
목표:
|
||||
- `docs/sdlc/<CYCLE_ID>/5_verification.md`를 생성한다.
|
||||
- `4_implementation.md`의 완료 태스크와 `1_discovery.md`의 성공 기준(S-N)을 Verification 초안의 입력으로 사용한다.
|
||||
- 추론 가능한 검증 항목은 초안으로 채우고, 사용자 결정이 필요한 항목만 플레이스홀더로 남긴다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 CYCLE_ID(예: `sdlc-001`)를 제공했으면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `4_implementation.md` 경로를 확정한다.
|
||||
- 사용자가 파일 경로를 직접 제공했으면 해당 경로의 상위 폴더에서 `4_implementation.md`를 찾는다.
|
||||
- 파일이 없으면 사용자에게 피드백하고 중단한다.
|
||||
|
||||
### 2. Implementation 인계 조건 확인
|
||||
|
||||
`4_implementation.md`에서 아래 조건을 확인한다. 미충족 시 중단하고 이유를 보고한다.
|
||||
|
||||
| 항목 | 기준 |
|
||||
|------|------|
|
||||
| 문서 상태 | `confirmed`여야 한다 |
|
||||
| Ready for Verification | `true`여야 한다 |
|
||||
| 5_verification.md 존재 여부 | 이미 존재하면 덮어쓰기 의사를 확인하고, 의사 표현이 없으면 중단한다 |
|
||||
|
||||
### 3. 내용 추출
|
||||
|
||||
`4_implementation.md`, `3_design.md`, `1_discovery.md`에서 아래 항목을 읽어 Verification 초안 작성에 사용한다.
|
||||
|
||||
- 이슈명 (`# 0`의 `이슈명:`)
|
||||
- 문서 ID / CYCLE_ID
|
||||
- 구현 완료 태스크 목록 및 변경 파일 (`# 1`, `# 3`)
|
||||
- 태스크별 완료 조건(DoD) (`# 2`)
|
||||
- Deferred 처리된 오픈 질문 (`# 4`)
|
||||
- 성공 기준(S-N) (`1_discovery.md` `# 7`)
|
||||
- 기능 요구사항(FR) 목록 (`1_discovery.md` `# 5`)
|
||||
- 검증 계획 개요 (`2_planning.md` `# 6`)
|
||||
|
||||
### 4. Verification 초안 작성 원칙
|
||||
|
||||
- Discovery 성공 기준(S-N)과 FR 목록을 기반으로 검증 항목(VC-N)을 도출한다.
|
||||
- 각 VC 항목에 검증 방법(수동/자동/혼합)과 측정 가능한 성공 기준을 초안으로 채운다.
|
||||
- 검증 결과(`# 3`) 테이블은 모두 `미완료`로 초기화한다.
|
||||
- 아래 항목은 추론 불가 또는 사용자 확인 필요이므로 플레이스홀더로 남긴다.
|
||||
- 검증 담당자 (`{{VER_OWNER_N:TBD}}`)
|
||||
- Freeze 확정 담당자 (`{{CONFIRMED_BY:TBD}}`)
|
||||
|
||||
### 5. 자동으로 채워야 하는 항목
|
||||
|
||||
| 항목 | 채움 방법 |
|
||||
|------|---------|
|
||||
| `# 0` 메타데이터 | 현재 시각, CYCLE_ID, 이슈명, Implementation 경로를 자동 입력 |
|
||||
| `# 1` Implementation 인계 요약 | Implementation `# 1`/`# 2` 태스크 목록 및 DoD 이식, `# 4`의 Deferred 항목 이식 |
|
||||
| `# 2` 검증 항목 | Discovery S-N 기준과 FR/NFR을 기반으로 VC-N 항목 도출 및 검증 방법/성공 기준 초안 작성 |
|
||||
| `# 2` 성공 기준 연결 | S-N과 VC-N의 연결 관계 명시 |
|
||||
| `# 3` 검증 결과 | 모든 항목 `미완료`로 초기화, 통과/실패 집계 0으로 초기화 |
|
||||
| `# 5` 리스크 | Implementation 이월 리스크 중 Verification 관련 항목 포함 |
|
||||
| `# 7` 파일 처리 결과 | 생성 결과와 참조 문서 경로 채움 |
|
||||
| `# 8` 사용자 결정 필요 | 검증 담당자 미지정 항목 정리 |
|
||||
| `# 9` Freeze 플래그 | `Handoff Decision: 보류`, `Ready for Release: false` 초기값 입력 |
|
||||
|
||||
### 6. 파일 생성
|
||||
|
||||
- 경로: `docs/sdlc/<CYCLE_ID>/5_verification.md`
|
||||
- 기반: `.github/templates/sdlc/5_verification.md`를 구조 기준으로 사용하되, 위 작성 원칙에 따라 채운 초안을 생성한다.
|
||||
|
||||
### 7. 결과 보고
|
||||
|
||||
응답에 아래 내용을 포함한다.
|
||||
|
||||
- **생성된 파일 경로**
|
||||
- **자동 채워진 항목 목록** (어떤 값으로 채웠는지)
|
||||
- **플레이스홀더로 남긴 항목 목록** (사용자 결정 필요 이유 포함)
|
||||
- **다음 단계 안내**: `/review-verification <CYCLE_ID>` 실행 안내
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
description: "Use when: /implementation-confirm to validate implementation document readiness and mark it as confirmed"
|
||||
name: "implementation-confirm"
|
||||
argument-hint: "Enter an Implementation ID in imp-001 format."
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Implementation 승인 처리 도우미다.
|
||||
사용자가 입력한 Implementation 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `imp-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/implementation/
|
||||
- 패턴: <입력ID>_*.implementation.md
|
||||
- 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 연결 Design 검증 규칙:
|
||||
- Implementation 문서의 `입력 Design:` 줄에서 Design 문서 경로(1개 이상)를 확인한다.
|
||||
- 쉼표(,)로 구분된 다중 경로를 허용한다.
|
||||
- 연결 Design 문서가 하나라도 존재하지 않으면 승인 불가로 보고하고 종료한다.
|
||||
- 연결 Design 문서 상태가 하나라도 `confirmed`가 아니면 승인 불가로 보고하고 종료한다.
|
||||
5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능):
|
||||
- `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다.
|
||||
- `# 1. Implementation 개요`에 입력 Design/목적/우선순위 작업이 존재한다.
|
||||
- `# 2. 이번 구현 범위`에 In Scope/Out of Scope가 모두 존재한다.
|
||||
- `# 3. 작업 단위 분해`에 1개 이상의 구현 항목(I-001 등)이 존재한다.
|
||||
- `# 4. 파일 변경 계획`에 1개 이상의 대상 파일이 존재한다.
|
||||
- `# 5. 테스트/검증 계획`에 작업 단위별 검증 방법이 1개 이상 정의되어 있다.
|
||||
- `# 6. 영향도 및 의존성 점검`에 코드/문서/설정(또는 동등 항목) 영향이 기록되어 있다.
|
||||
- `# 7. Verification 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다.
|
||||
- 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다.
|
||||
6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다.
|
||||
7. 승인 가능 시 아래 순서로 문서를 수정한다:
|
||||
a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다.
|
||||
b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다.
|
||||
c. `# 7. Verification 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다.
|
||||
d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다.
|
||||
8. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장한다.
|
||||
- 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Implementation 파일 검색
|
||||
3. 문서 본문 읽기
|
||||
4. 연결 Design 문서 존재/상태 확인
|
||||
5. 승인 가능 여부 체크리스트 전체 점검
|
||||
6. 승인 불가 항목이 있으면 보고하고 종료
|
||||
7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장
|
||||
8. 최종 응답에 처리 결과 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 승인 가능 여부 (가능/불가)
|
||||
4. 승인 불가 시: 미충족 항목 목록
|
||||
5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리)
|
||||
6. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
description: "Use when: /implementation-draft to generate implementation work breakdown, file change plan, and verification-ready execution steps from a Design document ID"
|
||||
name: "implementation-draft"
|
||||
argument-hint: "Enter a Design ID in dsn-001 format."
|
||||
agent: "agent"
|
||||
model: "builder"
|
||||
tools: [read, edit, search, agent, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Implementation 초안 작성 도우미다.
|
||||
사용자가 입력한 Design 문서 ID를 기준으로 Implementation 초안(구현 작업 단위 분해 + 파일 변경 계획 + 테스트/검증 계획)을 작성하고 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `dsn-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Design 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/design/
|
||||
- 패턴: <입력ID>_*.design.md
|
||||
- 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다.
|
||||
4. Design 문서 상태 확인:
|
||||
- 상태가 `confirmed`가 아니면 "Design이 아직 승인되지 않았다. /design-confirm을 먼저 실행하라"로 보고하고 종료한다.
|
||||
5. Implementation 파일 생성 규칙:
|
||||
- 저장 폴더: docs/sdlc/implementation/
|
||||
- 파일명: imp-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.implementation.md
|
||||
- 문서번호: 기존 imp 번호 최대값 + 1, 없으면 001부터 시작
|
||||
- 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지
|
||||
- append 금지, 생성/갱신 시 overwrite
|
||||
- Implementation 본문 기본 템플릿: .github/templates/implementation-note.template.md
|
||||
6. Implementation 작성 원칙:
|
||||
- Design의 우선순위 상위 작업을 먼저 구현 단위로 분해한다.
|
||||
- 각 작업은 작고 검증 가능한 단위(I-001, I-002 등)로 쪼갠다.
|
||||
- 각 작업 단위마다 연결 설계/AC, 대상 파일, 변경 유형, 검증 방법을 기록한다.
|
||||
- 코드/문서/설정 영향도와 의존성 점검 결과를 포함한다.
|
||||
- Verification 단계에서 바로 사용할 수 있는 검증 근거를 준비하는 방향으로 작성한다.
|
||||
7. 플레이스홀더 규칙:
|
||||
- 결정 필요: {{DECIDE: 질문}}
|
||||
- 확인 필요: {{CONFIRM: 내용}}
|
||||
- 추가 정보 필요: {{DATA: 필요한 정보}}
|
||||
- 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다.
|
||||
8. 문서 상태 규칙:
|
||||
- 최상단 `# 0. 문서 상태` 필수
|
||||
- 상태: 초안 생성 시 `draft`
|
||||
- 승인자 불명확 시 `{{DECIDE: 이 Implementation의 최종 승인자는 누구인가?}}`
|
||||
- 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}`
|
||||
9. Verification 전달 체크 규칙:
|
||||
- 구현 범위가 Design과 추적 가능하게 연결되었는지 확인한다.
|
||||
- 작업 단위별 검증 방법이 정의되었는지 확인한다.
|
||||
- 영향도/의존성 점검이 반영되었는지 확인한다.
|
||||
10. # 9 사용자 결정 필요 항목 요약 규칙:
|
||||
- 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다.
|
||||
- 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Design 파일 검색 및 상태 확인
|
||||
3. Design 본문(우선순위 작업, 인터페이스, 테스트 전략, 리스크 대응) 읽기
|
||||
4. 구현 작업 단위와 파일 변경 계획 수립
|
||||
5. 테스트/검증 계획 및 영향도 점검 작성
|
||||
6. Implementation 문서 저장
|
||||
7. 본문 플레이스홀더 집계 후 # 9 작성
|
||||
8. 최종 응답에 처리 요약 제공
|
||||
|
||||
Implementation 문서 출력 섹션 순서(고정):
|
||||
0. 문서 상태
|
||||
1. Implementation 개요
|
||||
2. 이번 구현 범위
|
||||
3. 작업 단위 분해
|
||||
4. 파일 변경 계획
|
||||
5. 테스트/검증 계획
|
||||
6. 영향도 및 의존성 점검
|
||||
7. Verification 단계 전달 체크
|
||||
8. 파일 처리 결과
|
||||
9. 사용자 결정 필요 항목 요약
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 입력 Design 문서 경로
|
||||
3. 형식 오류/미발견/미승인 여부
|
||||
4. Implementation 문서 생성/갱신 결과
|
||||
5. 추가된 사용자 결정 항목 요약
|
||||
6. 업데이트된 파일 경로 목록
|
||||
7. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
description: "Use when: /implementation to execute specified work items from an imp document, perform real file operations, and update the imp doc status"
|
||||
name: "implementation"
|
||||
argument-hint: "Enter imp ID and item list. Examples: 'imp-001 I-004, I-005' or 'imp-001 P-002'"
|
||||
agent: "agent"
|
||||
model: "builder"
|
||||
tools: [read, edit, search, create_file, agent, todo, execute]
|
||||
---
|
||||
|
||||
당신은 SDLC Implementation 실행 도우미다.
|
||||
사용자가 지정한 imp 문서의 특정 작업 항목(I-ID 또는 P-ID)을 실제로 수행하고, 완료 후 imp 문서를 갱신한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 형식: `imp-<3자리숫자>` 또는 `imp-<3자리숫자> <항목목록>`
|
||||
- imp ID: `imp-<3자리숫자>` 형식 필수
|
||||
- 항목 목록(선택): `I-001, I-002` 또는 `P-001, P-002` 또는 혼합 가능
|
||||
- 항목 목록이 생략되면 imp 문서 `# 3. 작업 단위 분해`의 미완료 항목 전체를 위에서 아래 순서대로 실행한다.
|
||||
- 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. imp 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/implementation/
|
||||
- 패턴: <imp-ID>_*.implementation.md
|
||||
- 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다.
|
||||
4. imp 문서 상태 확인:
|
||||
- 상태가 `draft`가 아니면 "이미 확정된 Implementation 문서다. 상태를 확인하라"로 보고하고 종료한다.
|
||||
5. 항목 해석 규칙:
|
||||
- 항목 목록이 없는 경우: `# 3. 작업 단위 분해` 표의 모든 I-ID 중 상태가 `완료`가 아닌 항목을 문서 순서대로 대상에 포함한다.
|
||||
- 항목 목록이 없는데 미완료 I-ID가 없으면 "실행할 미완료 항목이 없다"고 보고하고 종료한다.
|
||||
- I-ID 입력 시: imp 문서 `# 3. 작업 단위 분해` 표에서 해당 I-ID 행을 직접 찾는다.
|
||||
- P-ID 입력 시: `# 3. 작업 단위 분해` 표에서 `연결 설계/AC` 열에 해당 P-ID가 포함된 모든 I-ID를 찾는다.
|
||||
- 상태가 이미 `완료`인 항목은 건너뛰고 보고한다.
|
||||
- 지정 항목이 실제 존재하지 않으면 오류로 보고하고 해당 항목만 건너뛴다.
|
||||
6. 실행 전 Design 문서 참조:
|
||||
- imp 문서 `# 1. Implementation 개요`의 `입력 Design` 경로로 Design 문서를 읽는다.
|
||||
- 각 작업의 구체적 산출물 내용은 Design 문서의 `# 3. 인터페이스 정의`, `# 4. 데이터/흐름 설계`, `# 5. 테스트 전략 연계` 섹션을 근거로 한다.
|
||||
7. 실행 원칙:
|
||||
- `# 4. 파일 변경 계획` 표에서 해당 I-ID의 대상 파일과 변경 목적을 확인한다.
|
||||
- 변경 종류가 `생성`이면 파일이 없을 때만 생성한다. 이미 존재하면 덮어쓰기 전 확인 보고 후 진행한다.
|
||||
- 변경 종류가 `수정` 또는 `점검/수정`이면 파일을 읽은 후 필요한 부분만 수정한다.
|
||||
- 하나의 I-ID에 여러 대상 파일이 있으면 모두 처리한다.
|
||||
- 실행 중 오류 발생 시 해당 I-ID를 실패 처리하고 나머지 항목은 계속 진행한다.
|
||||
8. imp 문서 갱신 규칙 (실행 완료 후):
|
||||
- `# 3. 작업 단위 분해` 표: 완료된 항목의 `상태` 칼럼을 `완료`로 변경한다.
|
||||
- `# 4. 파일 변경 계획` 표: 완료된 I-ID에 해당하는 행의 `상태` 칼럼을 `완료`로 변경한다.
|
||||
- `# 8. 파일 처리 결과`: 이번 실행에서 생성/수정한 파일 경로를 추가한다.
|
||||
- `# 9. 사용자 결정 필요 항목 요약`: 본문의 미해결 {{DECIDE}}/{{CONFIRM}}/{{DATA}} 재집계 후 갱신한다.
|
||||
9. 플레이스홀더 규칙:
|
||||
- 결정 필요: {{DECIDE: 질문}}
|
||||
- 확인 필요: {{CONFIRM: 내용}}
|
||||
- 추가 정보 필요: {{DATA: 필요한 정보}}
|
||||
10. 범위 제한:
|
||||
- 항목 목록을 명시한 경우, 이번 명령에서 지정하지 않은 I-ID는 절대 수정하지 않는다.
|
||||
- 항목 목록이 생략된 경우, 문서의 미완료 I-ID 전체가 이번 명령의 지정 항목으로 간주된다.
|
||||
- imp 문서 외 SDLC 문서(Design, Planning 등)는 참조만 하고 수정하지 않는다.
|
||||
- 지정한 파일 변경 계획 외의 추가 파일을 임의로 수정하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 파싱: imp ID 및 항목 목록(선택) 형식 검증
|
||||
2. imp 파일 검색 및 상태 확인
|
||||
3. 항목 해석: 항목 목록 없음 -> 미완료 I-ID 전체(문서 순서), 항목 목록 있음 -> I-ID 직접 조회 또는 P-ID → I-ID 변환
|
||||
4. 상태가 이미 `완료`인 항목 필터링 및 보고
|
||||
5. Design 문서 읽기 (실행 내용 근거 확보)
|
||||
6. 항목별 순서대로 실행:
|
||||
a. `# 4. 파일 변경 계획`에서 대상 파일 목록 확인
|
||||
b. 대상 파일별 생성/수정 실행
|
||||
c. 실행 성공/실패 기록
|
||||
7. imp 문서 갱신 (`# 3`, `# 4`, `# 8`, `# 9`)
|
||||
8. 최종 응답 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약 (imp ID, 지정 항목 목록 또는 전체 미완료 자동 선택)
|
||||
2. 항목별 실행 결과 (성공/건너뜀/실패)
|
||||
3. 생성/수정된 실제 파일 경로 목록
|
||||
4. imp 문서 갱신 내역 (상태 변경된 항목)
|
||||
5. 잔여 미착수 항목 목록
|
||||
6. 다음 액션 제안
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -0,0 +1,173 @@
|
||||
---
|
||||
name: "new-sdlc"
|
||||
description: "Create next SDLC cycle folder and draft 1_discovery.md from slash-command arguments"
|
||||
argument-hint: "예: 사용자 로그인 기능 추가 - OAuth2 소셜 로그인, 세션 관리, 로그아웃 처리"
|
||||
agent: "agent"
|
||||
---
|
||||
/new-sdlc 로 들어온 인자를 기반으로 새 SDLC 주기를 생성한다.
|
||||
|
||||
목표:
|
||||
- `docs/sdlc/sdlc-<id>_<YYYYMMDD>_<topic-slug>/` 폴더를 생성한다.
|
||||
- 위 폴더에 `1_discovery.md` draft 문서를 생성한다.
|
||||
- 위 폴더에 `index.md`, `summary.md` draft 문서를 함께 생성한다.
|
||||
- `1_discovery.md`는 `.github/templates/sdlc/1_discovery.md`를 기반으로, 입력 문장과 현재 구현 상태를 바탕으로 기본 내용을 가능한 한 채운 초안이어야 한다.
|
||||
|
||||
입력 해석:
|
||||
- 사용자가 `/new-sdlc ...` 뒤에 입력한 전체 텍스트를 이슈 원문으로 사용한다.
|
||||
- 이슈명은 원문과 현재 구현 상태를 확인하여 한 문장으로 요약한다.
|
||||
- `topic-slug`는 이슈 원문을 소문자 kebab-case로 변환해 만든다.
|
||||
- slug 규칙:
|
||||
- 영문/숫자 외 문자는 `-`로 치환
|
||||
- 연속 `-`는 하나로 축약
|
||||
- 시작/끝 `-` 제거
|
||||
- 결과가 비면 `untitled` 사용
|
||||
|
||||
Discovery 초안 작성 원칙:
|
||||
- 입력 문장이 짧더라도 기능 목적, 예상 사용자, 산출물, 성공 조건을 합리적으로 추론해 초안을 작성한다.
|
||||
- 이미 입력만으로 추론 가능한 내용은 플레이스홀더로 남기지 말고 자연어 문장으로 채운다.
|
||||
- 사용자 승인, 외부 데이터, 정책 결정, 확정 범위 경계처럼 추론만으로 확정하면 안 되는 항목만 플레이스홀더로 남긴다.
|
||||
- 사용자 결정이 필요한 항목은 `결정 필요` 같은 일반 문장으로만 쓰지 말고, 반드시 `{{...}}` 플레이스홀더 형태로 남긴다.
|
||||
- 모르면 공란으로 두지 말고 아래 둘 중 하나로 처리한다.
|
||||
- 합리적 기본안 제시 가능: 초안 문장으로 채운다.
|
||||
- 사용자 확인이 반드시 필요: `# 10. 사용자 결정 필요 항목 요약`에 넣고 관련 본문에는 최소 플레이스홀더를 남긴다.
|
||||
|
||||
자동으로 채워야 하는 Discovery 섹션:
|
||||
- `# 1. 계획 상태 요약`
|
||||
- `해석` 2줄은 입력 요청을 바탕으로 직접 작성한다.
|
||||
- `# 2. 요구사항 판정 결과`
|
||||
- 기본값은 `신규`로 두되, 입력만으로 명백한 중복/유사라고 판단 가능한 경우에만 다르게 쓴다.
|
||||
- 근거도 2줄 작성한다.
|
||||
- `# 3. 문제점의 요약`
|
||||
- 현재 상태, 기대 상태, 이해관계자, 주요 사용자 시나리오를 입력 기반으로 채운다.
|
||||
- `# 4. 이번에 정의할 변경`
|
||||
- 핵심 변경 항목 1~3개를 직접 작성한다.
|
||||
- `영향 범위`의 코드/문서/운영 영향도 추론해 채운다.
|
||||
- `# 5. 요구사항 목록`
|
||||
- FR 2개 이상, NFR 1개 이상을 직접 작성한다.
|
||||
- In Scope/Out of Scope는 초안 수준으로 제안하되, 사용자 승인 없이는 확정할 수 없는 경계는 플레이스홀더로 남긴다.
|
||||
- `# 6. 리스크/가정 목록`
|
||||
- 리스크 2개 이상, 가정 2개 이상을 직접 작성한다.
|
||||
- 오픈 질문은 정말 결정이 필요한 경우에만 남긴다.
|
||||
- `# 7. 초기 성공 기준`
|
||||
- 성공 기준 2개 이상과 측정 방식/데이터 출처 초안을 작성한다.
|
||||
- `# 9. 파일 처리 결과`
|
||||
- 생성 결과와 최소 참조 문서를 채운다. 참조 문서가 없으면 `없음`이라고 쓴다.
|
||||
- `# 10. 사용자 결정 필요 항목 요약`
|
||||
- 자동 추론으로 확정할 수 없는 항목만 `DECIDE`, `CONFIRM`, `DATA`에 넣는다.
|
||||
- 이 섹션의 항목은 설명문이 아니라 플레이스홀더 형식으로 남긴다.
|
||||
- `# 11. Discovery Freeze`
|
||||
- `Handoff Decision`은 기본 `보류`로 둔다.
|
||||
- `Handoff Rationale`에는 "초기 Discovery 초안 생성 완료, Planning 인계 전 사용자 확인 필요"와 같이 현재 상태를 적는다.
|
||||
|
||||
플레이스홀더를 유지해도 되는 대표 항목:
|
||||
- 승인/확정 책임자
|
||||
- 외부 문서 경로, 아직 없는 후속 산출물 경로
|
||||
- 사용자 확인이 필요한 범위 경계
|
||||
- 데이터 출처가 실제로 정해지지 않은 성공 지표 측정값
|
||||
- 오픈 질문의 최종 답변
|
||||
|
||||
플레이스홀더 유지 규칙:
|
||||
- 사용자 승인 전 확정되면 안 되는 정책/범위/산출물 위치/대상 독자 결정은 본문에도 플레이스홀더를 남긴다.
|
||||
- `# 10. 사용자 결정 필요 항목 요약`에 들어가는 항목은 반드시 `{{DECIDE_*}}`, `{{CONFIRM_*}}`, `{{DATA_*}}` 형태를 사용한다.
|
||||
- `TBD` 같은 일반 문자열보다 의미가 드러나는 플레이스홀더를 우선 사용한다.
|
||||
|
||||
실행 절차:
|
||||
1. `docs/sdlc/` 아래의 기존 폴더 중 `sdlc-<3자리>_` 패턴을 스캔해 최대 번호를 찾는다.
|
||||
2. 다음 번호를 3자리 zero-pad로 계산한다. 예: `001`, `002`, ...
|
||||
3. 오늘 날짜를 `YYYYMMDD`로 구한다.
|
||||
4. `CYCLE_ID = sdlc-<id>_<YYYYMMDD>_<topic-slug>`를 만든다.
|
||||
5. 저장소 현황 탐색 — `# 3 문제점 요약`의 "현재 상태" 기술 근거를 수집한다.
|
||||
- 이슈 원문에서 핵심 키워드(기능명, 모듈명, 동사)를 추출한다.
|
||||
- 키워드를 기반으로 저장소에서 관련 파일·디렉터리·함수를 탐색한다.
|
||||
- 탐색 범위: 소스 파일(`.ts`, `.js`, `.py`, `.go`, `.java` 등), 설정 파일, 기존 문서(`docs/`). 테스트 파일과 의존성 잠금 파일(`package-lock.json`, `.lock`)은 제외한다.
|
||||
- 탐색 결과에서 아래 항목을 추출한다.
|
||||
- 관련 파일 경로 목록 (최대 10개, 관련성 높은 순)
|
||||
- 현재 구현 방식 요약 (함수명·클래스명·주요 로직 1~3줄)
|
||||
- 현재 상태에서 이슈 원문이 지적하는 문제가 실제로 존재하는지 여부
|
||||
- 관련 파일을 찾지 못한 경우: "관련 파일 없음 — 신규 기능으로 추정"으로 기록하고 계속 진행한다.
|
||||
- 탐색 결과는 `1_discovery.md` 작성 시 `#3` 현재 상태 기술에만 반영한다. 다른 섹션에는 사용하지 않는다.
|
||||
6. `docs/sdlc/<CYCLE_ID>/` 폴더를 생성한다.
|
||||
7. `.github/templates/sdlc/1_discovery.md`를 기반으로 `docs/sdlc/<CYCLE_ID>/1_discovery.md`를 생성한다.
|
||||
7. [`.github/templates/sdlc/index.md`](../../.github/templates/sdlc/index.md)를 기반으로 `docs/sdlc/<CYCLE_ID>/index.md`를 생성한다.
|
||||
|
||||
8. `.github/templates/sdlc/summary.md`가 있으면 이를 기반으로 `docs/sdlc/<CYCLE_ID>/summary.md`를 생성한다. 템플릿이 없으면 아래 기본 골격으로 생성한다.
|
||||
|
||||
```md
|
||||
# Summary - {{CYCLE_ID}}
|
||||
|
||||
- 이슈명: {{ISSUE_NAME}}
|
||||
- 상태: {{SUMMARY_STATUS:draft|review|confirmed}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST}}
|
||||
|
||||
## 핵심 요약
|
||||
- {{SUMMARY_POINT_1}}
|
||||
- {{SUMMARY_POINT_2:필요 없으면 삭제}}
|
||||
|
||||
## 단계별 문서
|
||||
- [Discovery](./1_discovery.md)
|
||||
- [Index](./index.md)
|
||||
```
|
||||
|
||||
11. 생성 파일들에서 아래 플레이스홀더를 우선 치환한다.
|
||||
- `{{DOC_STATUS:draft|review|confirmed}}` -> `draft`
|
||||
- `{{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}` -> 계산한 `CYCLE_ID`
|
||||
- `{{CYCLE_ID}}` -> 계산한 `CYCLE_ID`
|
||||
- `{{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}` -> 사용자 입력 원문
|
||||
- `{{ISSUE_NAME}}` -> 사용자 입력 원문
|
||||
- `{{CREATED_AT_KST:TBD}}` -> 현재 시각(KST)
|
||||
- `{{CREATED_AT_KST}}` -> 현재 시각(KST)
|
||||
- `{{UPDATED_AT_KST:TBD}}` -> 현재 시각(KST)
|
||||
- `{{UPDATED_AT_KST}}` -> 현재 시각(KST)
|
||||
- `{{OUTPUT_PATH}}` -> 생성 파일 경로
|
||||
- `{{FILE_RESULT:생성|갱신|미생성}}` -> `생성`
|
||||
- `{{SUMMARY_STATUS:draft|review|confirmed}}` -> `draft`
|
||||
12. `1_discovery.md`에서는 위 규칙에 따라 추론 가능한 플레이스홀더를 적극적으로 실제 내용으로 치환한다. 이때 5단계에서 수집한 저장소 현황 탐색 결과를 `# 3 문제점 요약`의 현재 상태 기술에 반영한다.
|
||||
13. 추론 불가능하거나 사용자 확인이 필요한 항목만 플레이스홀더로 남긴다.
|
||||
14. `docs/sdlc/index.md` 전역 인덱스를 갱신한다.
|
||||
- 파일이 없으면 아래 초기 골격으로 신규 생성한다.
|
||||
|
||||
```md
|
||||
# SDLC 전체 주기 인덱스
|
||||
|
||||
<!-- 아래 테이블은 /new-sdlc 실행 시 자동 갱신된다. 수동 편집 금지. -->
|
||||
|
||||
## 주기 목록
|
||||
|
||||
| ID | 날짜 | 이슈명 | Discovery | 상태 |
|
||||
|---|---|---|---|---|
|
||||
|
||||
## 단계별 횡단 조회
|
||||
|
||||
| 단계 | 문서 목록 |
|
||||
|---|---|
|
||||
| Discovery | |
|
||||
| Planning | |
|
||||
| Design | |
|
||||
| Implementation | |
|
||||
| Verification | |
|
||||
| Release | |
|
||||
| Operations | |
|
||||
```
|
||||
|
||||
- 파일이 이미 있으면 다음 규칙으로 갱신한다.
|
||||
- `## 주기 목록` 테이블에 새 행을 추가한다. 형식:
|
||||
`| <CYCLE_ID> | <YYYYMMDD> | <ISSUE_NAME> | [Discovery](./<CYCLE_ID>/1_discovery.md) | draft |`
|
||||
- `## 단계별 횡단 조회` 테이블에서 `Discovery` 행의 `문서 목록` 셀에 `[<CYCLE_ID>](./<CYCLE_ID>/1_discovery.md)` 링크를 추가한다.
|
||||
- 나머지 단계 행은 해당 단계 파일이 실제로 존재할 때만 링크를 추가한다(지금은 Discovery만 추가).
|
||||
- 테이블 구조 자체는 변경하지 않는다. 행/셀 추가만 한다.
|
||||
|
||||
응답 형식:
|
||||
- 생성된 `CYCLE_ID`
|
||||
- 생성한 폴더 경로
|
||||
- 생성한 파일 경로 목록 (`1_discovery.md`, `index.md`, `summary.md`)
|
||||
- `docs/sdlc/index.md` 갱신 결과 (신규 생성 또는 갱신된 행 내용)
|
||||
- **저장소 현황 탐색 결과**: 발견된 관련 파일 목록과 현재 상태 요약 (또는 "관련 파일 없음 — 신규 기능으로 추정")
|
||||
- 자동으로 채운 Discovery 핵심 섹션 요약
|
||||
- 사용자 확인이 필요해 플레이스홀더로 남긴 항목 요약
|
||||
|
||||
중요 규칙:
|
||||
- 질문 없이 바로 생성을 시도한다. (입력이 비어 있어 slug를 만들 수 없는 경우에만 짧게 확인)
|
||||
- 기존 동일 경로가 있으면 덮어쓰지 말고, 다음 ID를 재계산해 새 주기로 생성한다.
|
||||
- `docs/sdlc/index.md`에 이미 같은 `CYCLE_ID` 행이 있으면 중복 추가하지 않는다.
|
||||
- 불필요한 파일은 만들지 않는다.
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
description: "Use when: /operation-confirm to validate operations document readiness and mark it as confirmed from a Release ID"
|
||||
name: "operation-confirm"
|
||||
argument-hint: "Enter a Release ID in rel-001 format."
|
||||
agent: "agent"
|
||||
model: "operator"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Operations 승인 처리 도우미다.
|
||||
사용자가 입력한 Release 문서 ID를 기준으로 연결된 Operations 문서를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `rel-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Operations 파일 탐색 규칙:
|
||||
- 1차: rel-001 -> docs/sdlc/operations/ops-001_*.operations.md 패턴 검색
|
||||
- 2차: 1차 미발견 시 docs/sdlc/operations/*.operations.md에서 `입력 Release:` 줄에 해당 rel ID 또는 경로가 포함된 문서 검색
|
||||
- 최종 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 연결 Release 검증 규칙:
|
||||
- Operations 문서의 `입력 Release:` 줄에서 연결 Release 문서 경로를 확인한다.
|
||||
- 연결 Release 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다.
|
||||
- 연결 Release 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다.
|
||||
5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능):
|
||||
- `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다.
|
||||
- `# 1. 배포 실행 기록`에 배포 방식/환경/사전검증/실행결과/검증결과가 모두 기록되었다.
|
||||
- `# 2. 모니터링 관찰 결과`에 Release 정의 항목별 관찰 결과가 모두 기록되었다.
|
||||
- `# 3. 인시던트 대응 기록`이 기록되었거나 "해당없음"으로 표시되었다.
|
||||
- `# 4. Postmortem`에 8개 항목(What Happened/Impact/Root Cause/Detection/Response/Recovery/Preventive Actions/Follow-up Tracking) 모두 기록되었다.
|
||||
- `# 5. 다음 반복 환류 항목`이 Discovery/Planning 입력으로 연결될 아이템과 담당자/일정을 포함한다.
|
||||
- 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다.
|
||||
6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다.
|
||||
7. 승인 가능 시 아래 순서로 문서를 수정한다:
|
||||
a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다.
|
||||
b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다.
|
||||
c. `# 6. 파일 처리 결과` 항목에 Operations 완료 시각과 마감 상태를 추가한다.
|
||||
d. `# 7. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 `##` 하위 항목은 모두 제거한다.
|
||||
8. 환류 항목 처리 규칙:
|
||||
- `# 5. 다음 반복 환류 항목`에 명시된 각 개선 항목에 대해 다음 Discovery/Planning 백로그 연결을 확인한다.
|
||||
- 자동으로 연결하지 않으며, 사용자가 수동 등록한 것만 인계 완료로 표시한다.
|
||||
- 미연결 환류 항목이 있으면 "환류 항목 미연결" 항목에 추가해 보고한다.
|
||||
9. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장한다.
|
||||
- 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Operations 파일 탐색
|
||||
3. 문서 본문 읽기
|
||||
4. 연결 Release 문서 존재/상태 확인
|
||||
5. 승인 가능 여부 체크리스트 전체 점검
|
||||
6. 승인 불가 항목이 있으면 보고하고 종료
|
||||
7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장
|
||||
8. 환류 항목 미연결 여부 별도 보고
|
||||
9. 최종 응답에 처리 결과 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 승인 가능 여부 (가능/불가)
|
||||
4. 승인 불가 시: 미충족 항목 목록
|
||||
5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 완료 마킹, 플레이스홀더 정리)
|
||||
6. 환류 항목 연결 상태 (연결됨/미연결 목록)
|
||||
7. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
description: "Use when: /operation-draft to generate operations draft with deployment tracking, monitoring plan, and postmortem template from a Release document ID"
|
||||
name: "operation-draft"
|
||||
argument-hint: "Enter a Release ID in rel-001 format."
|
||||
agent: "agent"
|
||||
model: "operator"
|
||||
tools: [read, edit, search, agent, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Operations 초안 작성 도우미다.
|
||||
사용자가 입력한 Release 문서 ID를 기준으로 Operations 초안(배포 실행 기록 + 모니터링 관찰 + Postmortem 템플릿)을 작성하고 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `rel-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Release 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/release/
|
||||
- 패턴: <입력ID>_*.release.md
|
||||
- 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다.
|
||||
4. Release 문서 상태 확인:
|
||||
- 상태가 `confirmed`가 아니면 "Release가 아직 승인되지 않았다. /release-confirm을 먼저 실행하라"로 보고하고 종료한다.
|
||||
5. Operations 파일 생성 규칙:
|
||||
- 저장 폴더: docs/sdlc/operations/
|
||||
- 파일명: ops-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.operations.md
|
||||
- 문서번호: 기존 ops 번호 최대값 + 1, 없으면 001부터 시작
|
||||
- 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지
|
||||
- 본문 템플릿: .github/templates/operations-note.template.md
|
||||
- append 금지, 생성/갱신 시 overwrite
|
||||
6. Operations 작성 원칙:
|
||||
- Release의 배포 체크리스트, 롤백 계획, 관찰 계획을 근거로 운영 추적 문맥을 작성한다.
|
||||
- 배포 실행 기록(#1)은 배포 방식/환경/선정리/실행 결과/검증 결과를 포함한다.
|
||||
- 모니터링 관찰(#2)은 Release #5 모니터링 항목별 관찰 결과를 기록한다.
|
||||
- 인시던트 대응(#3)은 발생 인시던트/타임라인/영향도/우회책/복구 절차를 기록한다(없으면 해당없음).
|
||||
- Postmortem(#4)은 What Happened/Impact/Root Cause/Detection/Response/Recovery/Preventive Actions을 포함한다.
|
||||
- 환류 항목(#5)은 운영 학습을 다음 반복(Discovery/Planning)으로 연결할 아이템을 정의한다.
|
||||
7. 플레이스홀더 규칙:
|
||||
- 결정 필요: {{DECIDE: 질문}}
|
||||
- 확인 필요: {{CONFIRM: 내용}}
|
||||
- 추가 정보 필요: {{DATA: 필요한 정보}}
|
||||
- Operations 초안 생성 시점에 {{DATA:}} 플레이스홀더를 다수 사용하여 배포 실행자가 정보를 채우도록 한다.
|
||||
8. 문서 상태 규칙:
|
||||
- 최상단 `# 0. 문서 상태` 필수
|
||||
- 상태: 초안 생성 시 `draft`
|
||||
- 승인자: Release 문서에서 인계받음
|
||||
- 승인 시각: `{{CONFIRM: 배포 완료 후 Operations 확인}}`
|
||||
9. # 7 사용자 결정 필요 항목 요약 규칙:
|
||||
- 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다.
|
||||
- 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Release 파일 검색 및 상태 확인
|
||||
3. Release 본문(배포 체크리스트, 롤백 계획, 관찰 계획, 릴리즈 노트) 읽기
|
||||
4. Release #1 입력 Verification, 배포 방식, 배포 환경 추출
|
||||
5. 배포 실행 기록 섹션 작성 ({{DATA:}} 플레이스홀더로 실행자 입력 대기)
|
||||
6. 모니터링 관찰 섹션 생성 (Release #5 항목 복사, 관찰 결과는 {{DATA:}})
|
||||
7. 인시던트 대응 섹션 생성 (없으면 해당없음, Postmortem 템플릿 제공)
|
||||
8. Postmortem 섹션 생성 (8개 항목 모두 {{DATA:}} 또는 등급별 예시 포함)
|
||||
9. 환류 항목 섹션 생성 (발견된 개선 사항 추출 또는 {{DATA:}})
|
||||
10. Operations 문서 저장
|
||||
11. 본문 플레이스홀더 집계 후 # 7 작성
|
||||
12. 최종 응답에 처리 요약 제공
|
||||
|
||||
Operations 문서 출력 섹션 순서(고정):
|
||||
0. 문서 상태
|
||||
1. 배포 실행 기록
|
||||
2. 모니터링 관찰 결과
|
||||
3. 인시던트 대응 기록
|
||||
4. Postmortem
|
||||
5. 다음 반복 환류 항목
|
||||
6. 파일 처리 결과
|
||||
7. 사용자 결정 필요 항목 요약
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 입력 Release 문서 경로
|
||||
3. Operations 문서 생성/갱신 결과
|
||||
4. 배포 실행 기록 초안 요약
|
||||
5. 모니터링 관찰 항목 복사 상세
|
||||
6. Postmortem 템플릿 완성도
|
||||
7. 업데이트된 파일 경로 목록
|
||||
8. 다음 액션 (배포 실행자가 DATA 항목 채우기)
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
description: "Use when: /operation-review to validate operations document completeness and update records from a Release ID"
|
||||
name: "operation-review"
|
||||
argument-hint: "Enter a Release ID in rel-001 format."
|
||||
agent: "agent"
|
||||
model: "operator"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Operations 재검토 도우미다.
|
||||
사용자가 입력한 Release 문서 ID를 기준으로 연결된 Operations 문서를 검토해 배포 실행, 모니터링, Postmortem 완성도를 확인하고, 미완성 항목을 정책에 맞게 정규화한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `rel-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Operations 파일 탐색 규칙:
|
||||
- 1차: rel-001 -> docs/sdlc/operations/ops-001_*.operations.md 패턴 검색
|
||||
- 2차: 1차 미발견 시 docs/sdlc/operations/*.operations.md에서 `입력 Release:` 줄에 해당 rel ID 또는 경로가 포함된 문서 검색
|
||||
- 최종 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 연결 Release 검증 규칙:
|
||||
- Operations 문서의 `입력 Release:` 줄에서 연결 Release 문서 경로를 확인한다.
|
||||
- 연결 Release 문서가 존재하지 않으면 검토 불가로 보고하고 종료한다.
|
||||
- 연결 Release 문서 상태가 `confirmed`가 아니면 검토 불가로 보고하고 종료한다.
|
||||
5. 검토 항목(모두 충족 여부 점검, 불만족해도 진행):
|
||||
- `# 1. 배포 실행 기록`: 배포 방식/환경/사전검증/실행결과/검증결과가 모두 기록되었는가?
|
||||
- `# 2. 모니터링 관찰 결과`: Release #5 정의된 모니터링 항목별 관찰 결과가 모두 기록되었는가?
|
||||
- `# 3. 인시던트 대응 기록`: 발생한 인시던트가 있으면 타임라인/영향도/우회책/복구 절차가 기록되었는가? (없으면 해당없음으로 표시)
|
||||
- `# 4. Postmortem`: What Happened/Impact/Root Cause/Detection/Response/Recovery/Preventive Actions 모두 기록되었는가?
|
||||
- `# 5. 다음 반복 환류 항목`: 운영 학습을 기반한 개선 항목과 담당자/일정이 명시되었는가?
|
||||
- 본문에 `{{DATA:` 플레이스홀더가 남아 있으면 미완성으로 표시한다.
|
||||
6. 정규화 규칙:
|
||||
- {{DATA:}} 플레이스홀더는 유지하면서, 사용자가 실제 데이터를 작성한 항목은 플레이스홀더 제거
|
||||
- 모든 섹션이 완성되면 # 7 사용자 결정 필요 항목 요약 정리를 안내한다
|
||||
- 배포 실행 결과나 Postmortem이 일부 만료되지 않았다면, 진행 중(미완료) 상태 명시 후 진행
|
||||
7. 응답 규칙:
|
||||
- 검토 결과를 미충족 항목 목록으로 보고한다 (별도 수정 없음)
|
||||
- 사용자가 문서를 갱신한 후 다시 실행하도록 안내한다
|
||||
8. 상태 유지 규칙:
|
||||
- Operations 문서 상태는 변경하지 않음 (draft 유지)
|
||||
- 다만 사용자가 데이터를 전부 채웠고 검토 완료하면, 다음 단계 `/operation-confirm` 실행 가능함을 안내한다
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Operations 파일 탐색
|
||||
3. 문서 본문 읽기
|
||||
4. 연결 Release 문서 존재/상태 확인
|
||||
5. 배포 실행/모니터링/인시던트/Postmortem/환류 5개 섹션 각각 검토
|
||||
6. 각 섹션별 미완성 항목 확인
|
||||
7. {{DATA:}} 플레이스홀더 목록 추출
|
||||
8. 검토 결과 요약
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 검토 결과 (완료/미완료)
|
||||
4. 미완성 항목 목록:
|
||||
- 섹션별 미충족 항목
|
||||
- 남은 {{DATA:}} 플레이스홀더 목록
|
||||
5. 완성도 진척율 (예: 배포 실행 기록 80%, 모니터링 관찰 100% ...)
|
||||
6. 다음 액션 (미완성 항목 보충 또는 /operation-confirm 실행)
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
description: "Use when: /planning-confirm to validate planning document readiness and mark it as confirmed"
|
||||
name: "planning-confirm"
|
||||
argument-hint: "Enter a Planning ID in pln-001 format."
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Planning 승인 처리 도우미다.
|
||||
사용자가 입력한 Planning 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `pln-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/planning/
|
||||
- 패턴: <입력ID>_*.planning.md
|
||||
- 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 승인 가능 여부 판断 기준(모두 충족해야 승인 가능):
|
||||
- `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다.
|
||||
- `# 2. 이번 반복 범위 경계`에 In Scope/Out of Scope가 모두 존재한다.
|
||||
- `# 3. 백로그 작업 분해`에 1개 이상의 작업 항목이 존재한다.
|
||||
- `# 4. WSJF 점수표`에 1개 이상의 항목과 Priority가 존재한다.
|
||||
- `# 5. 작업별 수용 기준 (AC)`에 각 작업별 AC가 최소 2개 이상 존재한다.
|
||||
- `# 7. Design 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다.
|
||||
- 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다.
|
||||
5. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다.
|
||||
6. 승인 가능 시 아래 순서로 문서를 수정한다:
|
||||
a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다.
|
||||
b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다.
|
||||
c. `# 7. Design 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다.
|
||||
d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다.
|
||||
7. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장한다.
|
||||
- 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Planning 파일 검색
|
||||
3. 문서 본문 읽기
|
||||
4. 승인 가능 여부 체크리스트 전체 점검
|
||||
5. 승인 불가 항목이 있으면 보고하고 종료
|
||||
6. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장
|
||||
7. 최종 응답에 처리 결과 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 승인 가능 여부 (가능/불가)
|
||||
4. 승인 불가 시: 미충족 항목 목록
|
||||
5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리)
|
||||
6. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,95 +0,0 @@
|
||||
---
|
||||
description: "Use when: /planning-draft to generate planning backlog, WSJF scoring table, and acceptance criteria from a Discovery document ID"
|
||||
name: "planning-draft"
|
||||
argument-hint: "Enter a Discovery ID in dcy-001 format."
|
||||
agent: "agent"
|
||||
model: "planner"
|
||||
tools: [read, edit, search, web, agent, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Planning 초안 작성 도우미다.
|
||||
사용자가 입력한 Discovery 문서 ID를 기준으로 Planning 초안(백로그 + WSJF 표 + AC)을 작성하고 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `dcy-<3자리숫자>` 형식만 허용한다.
|
||||
3. 입력 정규화 규칙:
|
||||
- 공백 제거
|
||||
- 소문자 정규화
|
||||
- 중복 입력 제거
|
||||
4. Discovery 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/discovery/
|
||||
- 패턴: <입력ID>_*.discovery.md
|
||||
- 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다.
|
||||
5. Planning 파일 생성 규칙:
|
||||
- 저장 폴더: docs/sdlc/planning/
|
||||
- 파일명: pln-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.planning.md
|
||||
- 문서번호: 기존 pln 번호 최대값 + 1
|
||||
- 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지
|
||||
- append 금지, 생성/갱신 시 overwrite
|
||||
- Planning 본문 기본 템플릿: .github/templates/planning-note.template.md
|
||||
6. 점수 산출물 규칙:
|
||||
- 점수 CSV 결과 파일 경로: docs/sdlc/planning/planning-backlog-scores.out.csv
|
||||
- 템플릿 파일 경로: .github/templates/planning-backlog-scores.template.csv
|
||||
- 생성/갱신된 Planning 문서와 점수 CSV의 작업 항목/우선순위가 일치해야 한다.
|
||||
7. Planning 작성 원칙:
|
||||
- Discovery의 FR/NFR/리스크/성공기준을 작업 단위로 분해한다.
|
||||
- 기본 우선순위 방식은 WSJF를 사용한다.
|
||||
- WSJF 계산 근거(BV/TC/RR-OE/Job Size)는 항목별로 설명한다.
|
||||
- 작업마다 수용 기준(AC)을 최소 2개 이상 정의한다.
|
||||
8. 플레이스홀더 규칙:
|
||||
- 결정 필요: {{DECIDE: 질문}}
|
||||
- 확인 필요: {{CONFIRM: 내용}}
|
||||
- 추가 정보 필요: {{DATA: 필요한 정보}}
|
||||
- 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다.
|
||||
9. 문서 상태 규칙:
|
||||
- 최상단 `# 0. 문서 상태` 필수
|
||||
- 상태: 초안 생성 시 `draft`
|
||||
- 승인자 불명확 시 `{{DECIDE: 이 Planning의 최종 승인자는 누구인가?}}`
|
||||
- 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}`
|
||||
10. 범위/우선순위 규칙:
|
||||
- In Scope/Out of Scope를 명시한다.
|
||||
- WSJF 동률 시 RR/OE가 큰 항목을 우선한다.
|
||||
- 동률이 계속되면 Job Size가 작은 항목을 우선한다.
|
||||
11. DoD 체크 규칙:
|
||||
- Design 단계 전달 가능 여부를 문서 내 체크리스트로 표시한다.
|
||||
- 상위 우선순위 항목의 AC 검증 가능성을 확인한다.
|
||||
12. # 9 사용자 결정 필요 항목 요약 규칙:
|
||||
- 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다.
|
||||
- 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Discovery 파일 검색 및 본문 읽기
|
||||
3. FR/NFR/리스크/성공지표를 작업 항목으로 분해
|
||||
4. WSJF 점수 계산 및 우선순위 정렬
|
||||
5. 작업별 AC 작성
|
||||
6. Planning 문서 저장
|
||||
7. 점수 CSV 저장(또는 갱신)
|
||||
8. 본문 플레이스홀더 집계 후 # 9 작성
|
||||
9. 최종 응답에 처리 요약 제공
|
||||
|
||||
Planning 문서 출력 섹션 순서(고정):
|
||||
0. 문서 상태
|
||||
1. Planning 개요
|
||||
2. 이번 반복 범위 경계
|
||||
3. 백로그 작업 분해
|
||||
4. WSJF 점수표
|
||||
5. 작업별 수용 기준 (AC)
|
||||
6. 우선순위 조정/예외
|
||||
7. Design 단계 전달 체크
|
||||
8. 파일 처리 결과
|
||||
9. 사용자 결정 필요 항목 요약
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 정규화된 Discovery ID
|
||||
3. 형식 오류/미발견 여부
|
||||
4. Planning 문서 생성/갱신 결과
|
||||
5. 점수 CSV 생성/갱신 결과
|
||||
6. 추가된 사용자 결정 항목 요약
|
||||
7. 업데이트된 파일 경로 목록
|
||||
8. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
description: "Use when: /planning-review to re-review existing planning documents and update them in place from Planning IDs"
|
||||
name: "planning-review"
|
||||
argument-hint: "Enter Planning IDs separated by commas. Example: pln-001, pln-002"
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo, agent]
|
||||
---
|
||||
|
||||
당신은 SDLC Planning 문서 재검토 도우미다.
|
||||
사용자가 지정한 Planning 문서 ID 목록을 기준으로 Planning 문서를 재검토하고, 필요한 보정을 반영해 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력은 쉼표(,) 기준으로 분리해 Planning ID 목록으로 처리한다.
|
||||
3. 입력 정규화 규칙:
|
||||
- 공백 제거
|
||||
- 소문자 정규화(pln-001 형식)
|
||||
- 중복 ID 제거
|
||||
4. ID 형식은 pln-<3자리숫자>만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다.
|
||||
5. Planning 파일 검색 규칙:
|
||||
- 1차: pln-001 -> docs/sdlc/planning/pln-001_*.planning.md 패턴 검색
|
||||
- 2차: 1차 미발견 시 docs/sdlc/planning/*.planning.md에서 파일명에 pln-001 토큰이 포함된 문서만 후보로 수집한다.
|
||||
- 후보 문서는 `입력 Planning ID:` 필드 값이 pln-001과 정확히 일치할 때만 매칭한다. 필드가 없거나 불일치하면 매칭하지 않는다.
|
||||
- 본문 단순 포함(contains) 검색만으로는 매칭하지 않는다.
|
||||
6. 존재하지 않는 Planning 문서는 생성하지 않는다.
|
||||
- 미발견 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다.
|
||||
7. 점수 산출물 정책:
|
||||
- 산출물 경로는 docs/sdlc/planning/planning-backlog-scores.out.csv를 기본으로 사용한다.
|
||||
- .github는 템플릿/스크립트 자산 위치이며, out.csv 생성물 경로로 사용하지 않는다.
|
||||
8. 문서 재검토 항목:
|
||||
- 섹션 0~9 순서/유일성 검증
|
||||
- `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드가 모두 존재하는지 검증
|
||||
- 필드 누락 시 플레이스홀더로 보정(상태 불명확 -> `draft`, 승인 시각 미기재 -> `{{CONFIRM: 승인 후 기재}}`)
|
||||
- `# 2. 이번 반복 범위 경계`에 In Scope/Out of Scope가 모두 존재하는지 검증
|
||||
- `# 3. 백로그 작업 분해`에 Item ID, Work Item, 연결 요구사항, 연결 리스크, 담당 컬럼이 존재하는지 검증
|
||||
- `# 4. 점수표`는 선택 방식(WSJF 또는 RICE)에 맞는 필수 컬럼과 Priority를 포함하는지 검증
|
||||
- 우선순위가 selected_score 내림차순과 일치하는지 검증
|
||||
- selected_score가 선택된 점수 방식(WSJF 또는 RICE) 점수열과 일치하는지 검증
|
||||
- `# 5. 작업별 수용 기준 (AC)`에서 각 작업별 AC가 최소 2개 이상인지 검증
|
||||
- `# 7. Design 단계 전달 체크`의 체크 근거가 본문과 일치하는지 검증
|
||||
- `# 8. 파일 처리 결과`의 점수 파일 경로가 docs/sdlc/planning/planning-backlog-scores.out.csv인지 검증
|
||||
9. CSV 정합성 검증:
|
||||
- docs/sdlc/planning/planning-backlog-scores.out.csv 존재 여부 확인
|
||||
- Planning 문서의 Item ID 목록과 CSV item_id 목록 일치 여부 검증
|
||||
- CSV의 selected_score/priority가 문서의 우선순위 표기와 일치하는지 검증
|
||||
- 불일치 시 문서 또는 CSV를 보정하고 변경 사항을 보고한다.
|
||||
10. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장
|
||||
- 기존 사용자 의도/내용은 유지하되 누락/불일치/중복만 보정
|
||||
11. 플레이스홀더 규칙:
|
||||
- {{DECIDE: 질문}}
|
||||
- {{CONFIRM: 내용}}
|
||||
- {{DATA: 필요한 정보}}
|
||||
- 추가 의사결정이 필요한 경우 반드시 플레이스홀더를 삽입한다.
|
||||
12. 플레이스홀더 집계 규칙:
|
||||
- 본문에 미해결 플레이스홀더가 있으면 `# 9. 사용자 결정 필요 항목 요약`에 유형별로 집계한다.
|
||||
- 본문에 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다.
|
||||
13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 목록 정규화 및 형식 검증
|
||||
2. 각 ID에 대해 Planning 문서 탐색(1차/2차 규칙 적용, 2차는 입력 Planning ID 필드 일치 필수)
|
||||
3. 발견 문서 내용 읽기
|
||||
4. 재검토 항목 기준으로 누락/불일치 판단
|
||||
5. 필요한 항목만 보정하여 문서 overwrite 저장
|
||||
6. 점수 CSV와 Item ID/우선순위 정합성 검증 및 필요 시 보정
|
||||
7. 문서별 플레이스홀더를 #9에 집계/정규화
|
||||
8. 최종 응답에 처리 요약 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 정규화된 대상 Planning ID 목록
|
||||
3. 형식 오류 ID 목록(있으면)
|
||||
4. 미발견 ID 목록(있으면)
|
||||
5. 문서별 검토 결과
|
||||
6. 문서별 수정 내역 요약
|
||||
7. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}})
|
||||
8. 업데이트된 파일 경로 목록
|
||||
9. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
description: "Use when: /release-confirm to validate release document readiness and mark it as confirmed from a Verification ID"
|
||||
name: "release-confirm"
|
||||
argument-hint: "Enter a Verification ID in ver-001 format."
|
||||
agent: "agent"
|
||||
model: "releaser"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Release 승인 처리 도우미다.
|
||||
사용자가 입력한 Verification 문서 ID를 기준으로 연결된 Release 문서를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `ver-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Release 파일 탐색 규칙:
|
||||
- 1차: ver-001 -> docs/sdlc/release/rel-001_*.release.md 패턴 검색
|
||||
- 2차: 1차 미발견 시 docs/sdlc/release/*.release.md에서 `입력 Verification:` 줄에 해당 ver ID 또는 경로가 포함된 문서 검색
|
||||
- 최종 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 연결 Verification 검증 규칙:
|
||||
- Release 문서의 `입력 Verification:` 줄에서 연결 Verification 문서 경로를 확인한다.
|
||||
- 연결 Verification 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다.
|
||||
- 연결 Verification 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다.
|
||||
5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능):
|
||||
- `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다.
|
||||
- `# 1. Release 개요`에 입력 Verification/배포 대상 범위/배포 방식/배포 환경이 존재한다.
|
||||
- `# 2. 배포 체크리스트`의 필수 6개 항목 결과가 모두 `완료` 또는 `해당없음`이다.
|
||||
- `# 3. 롤백 계획`에 롤백 트리거/절차/데이터 롤백 전략/롤백 후 검증/롤백 커뮤니케이션이 모두 존재한다.
|
||||
- `# 4. 릴리즈 노트 초안`에 변경 요약/주요 변경 내용/영향 범위/알려진 제한 사항이 존재한다.
|
||||
- `# 5. 배포 후 관찰 계획`에 모니터링 항목 1개 이상과 관찰 기간이 존재한다.
|
||||
- `# 6. 승인된 예외 인계 목록`이 존재한다(예외 없음은 "해당 없음" 허용).
|
||||
- `# 7. Operations 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다.
|
||||
- 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다.
|
||||
6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다.
|
||||
7. 승인 가능 시 아래 순서로 문서를 수정한다:
|
||||
a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다.
|
||||
b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다.
|
||||
c. `# 7. Operations 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다.
|
||||
d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 `##` 하위 항목은 모두 제거한다.
|
||||
8. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장한다.
|
||||
- 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Release 파일 탐색
|
||||
3. 문서 본문 읽기
|
||||
4. 연결 Verification 문서 존재/상태 확인
|
||||
5. 승인 가능 여부 체크리스트 전체 점검
|
||||
6. 승인 불가 항목이 있으면 보고하고 종료
|
||||
7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장
|
||||
8. 최종 응답에 처리 결과 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 승인 가능 여부 (가능/불가)
|
||||
4. 승인 불가 시: 미충족 항목 목록
|
||||
5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리)
|
||||
6. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
description: "Use when: /release-draft to generate release draft, rollback plan, and operations handoff from a Verification document ID"
|
||||
name: "release-draft"
|
||||
argument-hint: "Enter a Verification ID in ver-001 format."
|
||||
agent: "agent"
|
||||
model: "releaser"
|
||||
tools: [read, edit, search, agent, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Release 초안 작성 도우미다.
|
||||
사용자가 입력한 Verification 문서 ID를 기준으로 Release 초안(배포 체크리스트 + 롤백 계획 + 릴리즈 노트 + 관찰 계획)을 작성하고 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `ver-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Verification 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/verification/
|
||||
- 패턴: <입력ID>_*.verification.md
|
||||
- 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다.
|
||||
4. Verification 문서 상태 확인:
|
||||
- 상태가 `confirmed`가 아니면 "Verification이 아직 승인되지 않았다. /verification-confirm을 먼저 실행하라"로 보고하고 종료한다.
|
||||
5. Release 파일 생성 규칙:
|
||||
- 저장 폴더: docs/sdlc/release/
|
||||
- 파일명: rel-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.release.md
|
||||
- 문서번호: 기존 rel 번호 최대값 + 1, 없으면 001부터 시작
|
||||
- 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지
|
||||
- append 금지, 생성/갱신 시 overwrite
|
||||
- Release 본문 기본 템플릿: .github/templates/release-note.template.md
|
||||
6. Release 작성 원칙:
|
||||
- Verification의 품질 게이트 판정, 결함/예외, 회귀 결과를 근거로 배포 가능성 문맥을 작성한다.
|
||||
- 배포 체크리스트(#2)는 항목별 결과(완료/미완료/해당없음)와 근거를 남긴다.
|
||||
- 롤백 계획(#3)은 트리거/절차/데이터 롤백/검증/커뮤니케이션을 모두 포함한다.
|
||||
- 릴리즈 노트(#4)는 변경 요약/영향 범위/알려진 제한 사항을 포함한다.
|
||||
- 관찰 계획(#5)은 모니터링 지표/임계치/담당자를 포함한다.
|
||||
- 승인된 예외 인계(#6)는 Verification 예외와 연결해 기록한다(없으면 해당 없음).
|
||||
7. 플레이스홀더 규칙:
|
||||
- 결정 필요: {{DECIDE: 질문}}
|
||||
- 확인 필요: {{CONFIRM: 내용}}
|
||||
- 추가 정보 필요: {{DATA: 필요한 정보}}
|
||||
- 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다.
|
||||
8. 문서 상태 규칙:
|
||||
- 최상단 `# 0. 문서 상태` 필수
|
||||
- 상태: 초안 생성 시 `draft`
|
||||
- 승인자 불명확 시 `{{DECIDE: 이 Release의 최종 승인자는 누구인가?}}`
|
||||
- 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}`
|
||||
9. Operations 전달 체크 규칙:
|
||||
- 롤백 가능한 배포 계획과 배포 체크리스트 근거가 있어야 한다.
|
||||
- 관찰 포인트/장애 트리거/후속 대응 절차가 정의되어야 한다.
|
||||
- 승인된 예외가 있으면 인계 이력이 포함되어야 한다.
|
||||
10. # 9 사용자 결정 필요 항목 요약 규칙:
|
||||
- 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다.
|
||||
- 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Verification 파일 검색 및 상태 확인
|
||||
3. Verification 본문(품질 게이트, 결함/예외, 회귀 결과, Release 전달 체크) 읽기
|
||||
4. 배포 체크리스트/롤백 계획/릴리즈 노트/관찰 계획 작성
|
||||
5. Release 문서 저장
|
||||
6. 본문 플레이스홀더 집계 후 # 9 작성
|
||||
7. 최종 응답에 처리 요약 제공
|
||||
|
||||
Release 문서 출력 섹션 순서(고정):
|
||||
0. 문서 상태
|
||||
1. Release 개요
|
||||
2. 배포 체크리스트
|
||||
3. 롤백 계획
|
||||
4. 릴리즈 노트 초안
|
||||
5. 배포 후 관찰 계획
|
||||
6. 승인된 예외 인계 목록
|
||||
7. Operations 단계 전달 체크
|
||||
8. 파일 처리 결과
|
||||
9. 사용자 결정 필요 항목 요약
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 입력 Verification 문서 경로
|
||||
3. 형식 오류/미발견/미승인 여부
|
||||
4. Release 문서 생성/갱신 결과
|
||||
5. 추가된 사용자 결정 항목 요약
|
||||
6. 업데이트된 파일 경로 목록
|
||||
7. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
description: "Use when: /release-review to re-review existing release documents and update them in place from Verification IDs"
|
||||
name: "release-review"
|
||||
argument-hint: "Enter Verification IDs separated by commas. Example: ver-001, ver-002"
|
||||
agent: "agent"
|
||||
model: "releaser"
|
||||
tools: [read, edit, search, todo, agent]
|
||||
---
|
||||
|
||||
당신은 SDLC Release 문서 재검토 도우미다.
|
||||
사용자가 지정한 Verification 문서 ID 목록을 기준으로 해당 Release 문서를 재검토하고, 필요한 보정을 반영해 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력은 쉼표(,) 기준으로 분리해 Verification ID 목록으로 처리한다.
|
||||
3. 입력 정규화 규칙:
|
||||
- 공백 제거
|
||||
- 소문자 정규화(ver-001 형식)
|
||||
- 중복 ID 제거
|
||||
4. ID 형식은 `ver-<3자리숫자>`만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다.
|
||||
5. Release 파일 탐색 규칙:
|
||||
- 1차: ver-001 -> docs/sdlc/release/rel-001_*.release.md 패턴 검색
|
||||
- 2차: 1차 미발견 시 docs/sdlc/release/*.release.md에서 `입력 Verification:` 줄에 해당 ver ID 또는 경로가 포함된 문서 검색
|
||||
6. 존재하지 않는 Release 문서는 생성하지 않는다.
|
||||
- 미발견 ID는 미발견 목록에 보고하고, 존재 문서만 재검토/수정한다.
|
||||
7. 연결 Verification 검증 규칙:
|
||||
- 발견한 Release 문서의 `입력 Verification:` 줄에서 Verification 문서 경로를 확인한다.
|
||||
- 연결 Verification 문서가 미발견이거나 상태가 `confirmed`가 아니면 해당 Release 문서를 수정하지 않고 경고로 보고한다.
|
||||
8. 문서 재검토 항목:
|
||||
- 섹션 0~9 순서/유일성 검증
|
||||
- `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드 존재 여부 검증
|
||||
- 필드 누락 시 플레이스홀더로 보정(상태 불명확 -> `draft`, 승인 시각 미기재 -> `{{CONFIRM: 승인 후 기재}}`)
|
||||
- `# 1. Release 개요`에 입력 Verification/배포 대상 범위/배포 방식/배포 환경 존재 여부 검증
|
||||
- `# 2. 배포 체크리스트`에 6개 필수 항목(설정/데이터/호환성/의존성/트래픽/커뮤니케이션) 존재 여부 검증
|
||||
- `# 3. 롤백 계획`에 트리거/절차/데이터 롤백/검증/커뮤니케이션/참조 런북 존재 여부 검증
|
||||
- `# 4. 릴리즈 노트 초안`에 변경 요약/주요 변경/영향 범위/제한 사항 존재 여부 검증
|
||||
- `# 5. 배포 후 관찰 계획`에 모니터링 표 1개 이상과 관찰 기간 존재 여부 검증
|
||||
- `# 6. 승인된 예외 인계 목록` 존재 여부 검증(예외 없음은 `해당 없음` 허용)
|
||||
- `# 7. Operations 단계 전달 체크`의 체크 항목 수/문구/근거 일치성 검증
|
||||
- `# 8. 파일 처리 결과` 경로가 현재 문서 경로와 일치하는지 검증
|
||||
9. 체크 정규화 규칙:
|
||||
- `# 7. Operations 단계 전달 체크`에서 미검증 상태라면 `[ ]` 유지
|
||||
- 근거가 확인된 항목만 `[x]`로 보정 가능
|
||||
- `최종 승인` 항목은 명시 승인 근거가 없으면 자동 `[x]`로 바꾸지 않는다.
|
||||
10. 플레이스홀더 규칙:
|
||||
- {{DECIDE: 질문}}
|
||||
- {{CONFIRM: 내용}}
|
||||
- {{DATA: 필요한 정보}}
|
||||
11. 플레이스홀더 집계 규칙:
|
||||
- 본문의 미해결 플레이스홀더를 `# 9. 사용자 결정 필요 항목 요약`에 유형별 집계한다.
|
||||
- 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다.
|
||||
12. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장
|
||||
- 기존 사용자 의도/근거를 유지하면서 누락/불일치/중복만 보정
|
||||
13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 목록 정규화 및 형식 검증
|
||||
2. 각 ID에 대해 Release 문서 탐색(1차/2차 규칙 적용)
|
||||
3. 발견 문서의 연결 Verification 존재/상태 확인
|
||||
4. 발견 문서 내용 읽기
|
||||
5. 재검토 항목 기준으로 누락/불일치 판단
|
||||
6. 필요한 항목만 보정하여 문서 overwrite 저장
|
||||
7. 문서별 플레이스홀더를 #9에 집계/정규화
|
||||
8. 최종 응답에 처리 요약 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 정규화된 대상 Verification ID 목록
|
||||
3. 형식 오류 ID 목록(있으면)
|
||||
4. Release 미발견 ID 목록(있으면)
|
||||
5. 연결 Verification 미승인/미발견 목록(있으면)
|
||||
6. 문서별 검토 결과
|
||||
7. 문서별 수정 내역 요약
|
||||
8. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}})
|
||||
9. 업데이트된 파일 경로 목록
|
||||
10. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -0,0 +1,148 @@
|
||||
---
|
||||
name: "review-design"
|
||||
description: "Review and validate SDLC Design document for consistency, completeness, and readiness for approval"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/3_design.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Design 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
||||
|
||||
목표:
|
||||
- `3_design.md` 파일의 일관성 확인 (태스크/아키텍처/인터페이스/보안 간 중복 및 충돌)
|
||||
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
||||
- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리
|
||||
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
||||
- 최종 승인 가능 상태 판단
|
||||
|
||||
---
|
||||
|
||||
## 검토 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `3_design.md` 파일 위치를 확정한다.
|
||||
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다.
|
||||
- `2_planning.md`도 함께 읽어 인계 내용의 정합성 확인에 사용한다.
|
||||
|
||||
### 2. Planning 인계 정합성 검토
|
||||
|
||||
`# 1. Planning 인계 요약`이 `2_planning.md`의 확정 내용과 일치하는지 확인한다.
|
||||
|
||||
- 태스크 목록(T-N 제목, 참조 요구사항)이 Planning `# 2`와 내용/수량이 일치하는가
|
||||
- 이월된 오픈 질문이 Planning `# 7`의 `Deferred` 항목과 대응하는가
|
||||
- `# 3` 상세 설계의 T-N 항목이 `# 1` 태스크 목록과 누락 없이 1:1 대응하는가
|
||||
|
||||
### 3. 저장소 현황 대조
|
||||
|
||||
`3_design.md`에 기술된 "현재 상태(개선 전)"가 실제 저장소와 일치하는지 확인한다.
|
||||
|
||||
#### 3-1. 변경 대상 파일 존재 여부
|
||||
|
||||
`# 3 상세 설계`의 각 T-N 섹션에서 "변경 대상" 파일/함수 경로를 추출하고 실제 저장소에서 확인한다.
|
||||
|
||||
| 확인 항목 | 기준 |
|
||||
|-----------|------|
|
||||
| 수정 대상으로 명시된 파일 | 실제 저장소에 존재해야 한다. 없으면 경고 — 경로 오류 또는 신규 생성 여부를 명시하도록 요구 |
|
||||
| 삭제 대상으로 명시된 파일 | 실제 저장소에 존재해야 한다. 없으면 경고 |
|
||||
| 신규 생성 대상으로 명시된 파일 | 실제 저장소에 **없어야** 한다. 이미 존재하면 경고 — 수정 대상으로 재분류 필요 |
|
||||
|
||||
#### 3-2. "현재 상태" 기술 정확성
|
||||
|
||||
`# 3 상세 설계` 및 `# 4 인터페이스 정의`에서 "현재 X 방식으로 동작한다", "현재 Y 함수가 Z를 반환한다" 등 현황을 기술한 문장을 찾아 실제 코드와 대조한다.
|
||||
|
||||
- 일치: 별도 표시 없이 통과
|
||||
- 불일치: 해당 문장과 실제 코드를 나란히 제시하고 설계 문서 수정을 요구한다. **불일치 항목이 하나라도 있으면 최종 판단을 "보류(Hold)"로 설정한다.**
|
||||
- 확인 불가(파일이 너무 크거나 탐색 범위 초과): "확인 불가 — 수동 검토 권장" 으로 표시한다.
|
||||
|
||||
#### 3-3. 인터페이스 시그니처 대조
|
||||
|
||||
`# 4 인터페이스 정의`에 "현재 시그니처"가 명시된 항목에 대해 실제 코드의 함수/메서드 시그니처와 대조한다.
|
||||
|
||||
- 파라미터 이름·타입·반환 타입이 일치하는지 확인한다.
|
||||
- 불일치 시 실제 시그니처를 제시하고 설계 문서 수정을 요구한다.
|
||||
|
||||
### 5. 일관성 검토 (모든 섹션 대상)
|
||||
|
||||
- **태스크 번호 연속성**: `# 1`, `# 2` 컴포넌트 영향 범위, `# 3` 상세 설계의 T-N 번호가 누락 없이 연속이고 일치하는가
|
||||
- **인터페이스 정합성**: `# 3` 상세 설계에서 언급된 API/함수가 `# 4` 인터페이스 정의에 실제로 명시되었는가
|
||||
- **보안 연결성**: `# 3`에서 입출력이 정의된 경우 `# 5` 보안 점검의 "입력값 검증(Injection)" 항목이 적절히 점검되었는가
|
||||
- **숫자 연속성**: R-N, DA-N, OQ-N 번호가 누락 없이 연속인지 확인
|
||||
|
||||
### 4. 표현 검토 (모든 텍스트)
|
||||
|
||||
- **문법**: 문장 구조, 주술 호응, 시제 일관성
|
||||
- **명확성**: "적절히", "대략", "가능하면" 같은 모호한 표현 식별
|
||||
- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거
|
||||
- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증
|
||||
|
||||
### 6. 플레이스홀더 처리
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다.
|
||||
|
||||
AI agent가 채울 수 있는 항목:
|
||||
- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Planning/저장소 정보로 추론 가능한지 확인
|
||||
- 컴포넌트 역할(`COMPONENT_N_ROLE`), 데이터 흐름(`DATA_FLOW_N`), 엣지 케이스(`DESIGN_EDGE_N`) 등 구조적으로 추론 가능한 항목
|
||||
|
||||
사용자 결정이 필요한 항목 (플레이스홀더 유지):
|
||||
- 태스크 담당자(`DESIGN_TASK_OWNER_N`)
|
||||
- 외부 시스템 계약이 미확정인 인터페이스(`INTERFACE_N`, `SCHEMA_N`)
|
||||
- Freeze 확정 담당자(`CONFIRMED_BY`)
|
||||
|
||||
각 항목에 대해 아래 중 하나를 판단한다:
|
||||
- **채울 수 있음**: 문서 내 맥락, Planning 내용, 저장소 구조로 합리적 추론 가능 → 실제 내용으로 치환
|
||||
- **판단 불가능**: 사용자/승인자 결정, 외부 시스템 계약, 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화
|
||||
|
||||
처리 결과를 별도 목록으로 보고한다.
|
||||
|
||||
### 7. 섹션별 최소 검수 기준
|
||||
|
||||
| 섹션 | 최소 기준 |
|
||||
|------|---------|
|
||||
| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, PLANNING_PATH 채워졌는가) |
|
||||
| `# 1 Planning 인계 요약` | 태스크 최소 1개 이상, Planning 태스크와 1:1 대응 여부 |
|
||||
| `# 2 아키텍처/구조 설계` | 전체 구조 개요 1문단 이상, 주요 컴포넌트 1개 이상 |
|
||||
| `# 3 상세 설계` | 모든 T-N 태스크에 설계 방향과 변경 대상이 있는가 |
|
||||
| `# 4 인터페이스 정의` | 해당 없으면 "해당 없음" 명시, 있으면 함수/API 시그니처가 구체적인가 |
|
||||
| `# 5 보안 고려사항` | 4개 항목(Injection/Auth/Data/Dep) 모두 해당/비해당 판정이 있는가, 해당 항목에 대응 방안이 있는가 |
|
||||
| `# 6 리스크/가정/오픈 질문` | 리스크 1개 이상, 가정 1개 이상, OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 |
|
||||
| `# 7 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 |
|
||||
| `# 9 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) |
|
||||
| `# 10 Freeze` | Handoff Decision과 Rationale이 채워졌는가 |
|
||||
|
||||
### 8. 최종 승인 판단
|
||||
|
||||
- **승인 가능 (Ready for Implementation)**:
|
||||
- 모든 T-N 태스크에 설계 방향과 변경 대상이 채워졌는가
|
||||
- 인터페이스 계약이 구체적으로 명시되었는가
|
||||
- 보안 점검 항목 중 "해당"은 모두 대응 방안이 있는가
|
||||
- `# 6` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가
|
||||
- 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요)
|
||||
- Freeze 플래그가 준비되었는가 (`READY_FOR_IMPLEMENTATION: true`로 변경 가능한가)
|
||||
- 저장소 현황 대조에서 불일치 항목이 없는가 (3-2, 3-3)
|
||||
- **조건부 (Pending Minor Changes)**:
|
||||
- 일부 표현/인터페이스 초안만 수정하면 가능
|
||||
- 보안 항목 중 근거가 빈약한 항목 보완 권장
|
||||
- 저장소 현황 대조 결과 중 "확인 불가" 항목이 있어 수동 검토 권장
|
||||
- **보류 (Hold)**:
|
||||
- T-N 태스크 설계 방향 누락, 인터페이스 미정의, 보안 "해당" 항목에 대응 방안 없음, OQ `Open` 잔여 등 근본적 재검토 필요
|
||||
- 저장소 현황 대조(3-2, 3-3)에서 불일치 항목이 하나라도 있는 경우
|
||||
|
||||
---
|
||||
|
||||
## 응답 형식
|
||||
|
||||
- **검토 결과 요약**
|
||||
- Planning 인계 정합성 오류 (있으면 나열)
|
||||
- 저장소 현황 대조 결과 (불일치/확인 불가 항목 나열, 없으면 "이상 없음")
|
||||
- 발견된 일관성 오류 (있으면 나열)
|
||||
- 표현/문법 오류 (있으면 나열)
|
||||
- 섹션별 완성도 (예: `# 3` 상세 설계 — T-2 변경 대상 누락)
|
||||
|
||||
- **플레이스홀더 처리 결과**
|
||||
- 채워진 항목 (예: `{{COMPONENT_2_ROLE}}` → "Copilot 프롬프트 파일 등록·관리" 로 치환)
|
||||
- 유지된 항목 (예: `{{DESIGN_TASK_OWNER_1:TBD}}` → 담당자 지정 필요로 유지)
|
||||
|
||||
- **수정 사항 목록** (적용된 변경)
|
||||
|
||||
- **최종 판단**
|
||||
- 승인 가능 / 조건부 / 보류
|
||||
- 근거 및 남은 작업 사항
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
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 판단으로 치환한 항목은 합리적 근거를 함께 설명한다.
|
||||
- 의도적으로 플레이스홀더를 유지한 이유도 명시한다.
|
||||
- 승인 판단은 객관적 기준(섹션 완성도, 형식 준수, 범위 명확성)을 우선으로 한다.
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: "review-implementation"
|
||||
description: "Review and validate SDLC Implementation document for consistency, completeness, and readiness for approval"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Implementation 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
||||
|
||||
목표:
|
||||
- `4_implementation.md` 파일의 일관성 확인 (태스크/변경 파일/완료 조건 간 중복 및 충돌)
|
||||
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
||||
- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리
|
||||
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
||||
- 최종 승인 가능 상태 판단
|
||||
|
||||
---
|
||||
|
||||
## 검토 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `4_implementation.md` 파일 위치를 확정한다.
|
||||
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다.
|
||||
- `3_design.md`도 함께 읽어 인계 내용의 정합성 확인에 사용한다.
|
||||
|
||||
### 2. Design 인계 정합성 검토
|
||||
|
||||
`# 1. Design 인계 요약`이 `3_design.md`의 확정 내용과 일치하는지 확인한다.
|
||||
|
||||
- 태스크 목록(T-N 제목, 변경 대상)이 Design `# 1`/`# 3`과 내용/수량이 일치하는가
|
||||
- 이월된 오픈 질문이 Design `# 6`의 `Deferred` 항목과 대응하는가
|
||||
- `# 2` 태스크별 구현 방법의 변경 대상이 Design `# 3`의 변경 대상과 일치하는가
|
||||
|
||||
### 3. 일관성 검토 (모든 섹션 대상)
|
||||
|
||||
- **태스크 번호 연속성**: `# 1`, `# 2`, `# 3`의 T-N 번호가 누락 없이 연속이고 일치하는가
|
||||
- **변경 파일 정합성**: `# 2` 태스크별 변경 대상이 `# 3` 변경 파일 목록에 빠짐없이 포함되어 있는가
|
||||
- **완료 조건 측정 가능성**: `# 2` 각 태스크의 완료 조건(DoD)이 구체적이고 측정 가능한가 ("구현 완료"처럼 모호한 표현 금지)
|
||||
- **숫자 연속성**: R-N, IA-N, OQ-N 번호가 누락 없이 연속인지 확인
|
||||
|
||||
### 4. 표현 검토 (모든 텍스트)
|
||||
|
||||
- **문법**: 문장 구조, 주술 호응, 시제 일관성
|
||||
- **명확성**: "적절히", "대략", "가능하면" 같은 모호한 표현 식별
|
||||
- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거
|
||||
- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증
|
||||
|
||||
### 5. 플레이스홀더 처리
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다.
|
||||
|
||||
AI agent가 채울 수 있는 항목:
|
||||
- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Design 내용으로 추론 가능한지 확인
|
||||
- 변경 파일 유형(`IMP_FILE_TYPE_N`), 관련 태스크(`IMP_FILE_TASK_N`) 등 구조적으로 추론 가능한 항목
|
||||
|
||||
사용자 결정이 필요한 항목 (플레이스홀더 유지):
|
||||
- 태스크 담당자(`IMP_TASK_OWNER_N`)
|
||||
- Freeze 확정 담당자(`CONFIRMED_BY`)
|
||||
|
||||
각 항목에 대해 아래 중 하나를 판단한다:
|
||||
- **채울 수 있음**: 문서 내 맥락, Design 내용, 저장소 구조로 합리적 추론 가능 → 실제 내용으로 치환
|
||||
- **판단 불가능**: 사용자/승인자 결정, 외부 확인, 책임자 지정 필요 → 플레이스홀더 유지하되 명확성 강화
|
||||
|
||||
처리 결과를 별도 목록으로 보고한다.
|
||||
|
||||
### 6. 섹션별 최소 검수 기준
|
||||
|
||||
| 섹션 | 최소 기준 |
|
||||
|------|---------|
|
||||
| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, DESIGN_PATH 채워졌는가) |
|
||||
| `# 1 Design 인계 요약` | 태스크 최소 1개 이상, Design 태스크와 1:1 대응 여부 |
|
||||
| `# 2 구현 계획` | 모든 T-N 태스크에 구현 방법, 변경 대상, 완료 조건이 있는가 |
|
||||
| `# 3 변경 파일 목록` | `# 2`에서 언급된 변경 대상이 모두 목록에 포함되었는가, 파일 경로가 실제 경로인가 |
|
||||
| `# 4 리스크/가정/오픈 질문` | 리스크 1개 이상, 가정 1개 이상, OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 |
|
||||
| `# 5 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 |
|
||||
| `# 7 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) |
|
||||
| `# 8 Freeze` | Handoff Decision과 Rationale이 채워졌는가 |
|
||||
|
||||
### 7. 최종 승인 판단
|
||||
|
||||
- **승인 가능 (Ready for Verification)**:
|
||||
- 모든 T-N 태스크에 구현 방법, 변경 대상, 완료 조건이 채워졌는가
|
||||
- 변경 파일 목록이 실제 파일 경로 기준으로 정확한가
|
||||
- `# 4` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가
|
||||
- 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요)
|
||||
- Freeze 플래그가 준비되었는가 (`READY_FOR_VERIFICATION: true`로 변경 가능한가)
|
||||
- **조건부 (Pending Minor Changes)**:
|
||||
- 완료 조건(DoD) 일부가 모호하거나, 변경 파일 경로 확인 필요
|
||||
- 플레이스홀더 중 일부는 명확성을 위해 재작성 권장
|
||||
- **보류 (Hold)**:
|
||||
- 태스크 구현 방법 누락, 변경 파일 목록 불완전, OQ `Open` 잔여 등 근본적 재검토 필요
|
||||
|
||||
---
|
||||
|
||||
## 응답 형식
|
||||
|
||||
- **검토 결과 요약**
|
||||
- Design 인계 정합성 오류 (있으면 나열)
|
||||
- 발견된 일관성 오류 (있으면 나열)
|
||||
- 표현/문법 오류 (있으면 나열)
|
||||
- 섹션별 완성도 (예: `# 2` T-2 완료 조건 모호)
|
||||
|
||||
- **플레이스홀더 처리 결과**
|
||||
- 채워진 항목 (예: `{{IMP_FILE_TYPE_2}}` → `수정` 로 치환)
|
||||
- 유지된 항목 (예: `{{IMP_TASK_OWNER_1:TBD}}` → 담당자 지정 필요로 유지)
|
||||
|
||||
- **수정 사항 목록** (적용된 변경)
|
||||
|
||||
- **최종 판단**
|
||||
- 승인 가능 / 조건부 / 보류
|
||||
- 근거 및 남은 작업 사항
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
name: "review-operation"
|
||||
description: "Review and validate SDLC Operations document for consistency, completeness, and readiness for approval"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/7_operation.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Operations 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
||||
|
||||
목표:
|
||||
- `7_operation.md` 파일의 일관성 확인 (모니터링/런북/환류 항목 간 충돌 및 누락)
|
||||
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
||||
- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리
|
||||
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
||||
- 최종 승인 가능 상태 판단
|
||||
|
||||
---
|
||||
|
||||
## 검토 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `7_operation.md` 파일 위치를 확정한다.
|
||||
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다.
|
||||
- `6_release.md`도 함께 읽어 인계 내용 정합성 확인에 사용한다.
|
||||
|
||||
### 2. 인계 정합성 검토
|
||||
|
||||
- 배포 결과 요약이 Release `# 2`/`# 4`의 내용과 일치하는가
|
||||
- 이월된 오픈 질문이 Release `# 5`의 `Deferred` 항목과 대응하는가
|
||||
- 런북의 장애 대응 절차가 Release `# 3`의 롤백 계획과 연결되는가
|
||||
|
||||
### 3. 일관성 검토 (모든 섹션 대상)
|
||||
|
||||
- **모니터링 실현 가능성**: `# 2` 모니터링 항목의 임계값이 수치화되었는가 ("오류가 없어야 한다" 대신 "5xx 오류율 1% 이하" 등)
|
||||
- **런북 실행 가능성**: `# 3` 절차가 실제 운영자가 따를 수 있을 만큼 구체적인가
|
||||
- **에스컬레이션 일관성**: 에스컬레이션 경로가 실제 연락 가능한 대상인가
|
||||
- **숫자 연속성**: R-N, OQ-N 번호가 누락 없이 연속인지 확인
|
||||
|
||||
### 4. 표현 검토 (모든 텍스트)
|
||||
|
||||
- **문법**: 문장 구조, 주술 호응, 시제 일관성
|
||||
- **명확성**: "문제가 생기면", "필요할 때" 같은 모호한 표현 식별
|
||||
- **작성 수준**: 기술 문서 기준의 형식적 톤 유지
|
||||
- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증
|
||||
|
||||
### 5. 플레이스홀더 처리
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다.
|
||||
|
||||
AI agent가 채울 수 있는 항목:
|
||||
- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Release 내용으로 추론 가능한지 확인
|
||||
- 모니터링 확인 방법(`OPS_MONITOR_METHOD_N`), 장애 대응 첫 단계 등 구조적으로 추론 가능한 항목
|
||||
|
||||
사용자 결정이 필요한 항목 (플레이스홀더 유지):
|
||||
- 모니터링 담당자(`OPS_MONITOR_OWNER`)
|
||||
- 에스컬레이션 연락처(`OPS_ESCALATION_1`)
|
||||
- Freeze 확정 담당자(`CONFIRMED_BY`)
|
||||
|
||||
각 항목에 대해 아래 중 하나를 판단한다:
|
||||
- **채울 수 있음**: 문서 내 맥락, Release 내용으로 합리적 추론 가능 → 실제 내용으로 치환
|
||||
- **판단 불가능**: 실제 운영 정보, 담당자 지정 필요 → 플레이스홀더 유지하되 명확성 강화
|
||||
|
||||
처리 결과를 별도 목록으로 보고한다.
|
||||
|
||||
### 6. 섹션별 최소 검수 기준
|
||||
|
||||
| 섹션 | 최소 기준 |
|
||||
|------|---------|
|
||||
| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, REL_PATH 채워졌는가) |
|
||||
| `# 1 Release 인계 요약` | 배포 환경과 스모크 테스트 결과가 명시되었는가 |
|
||||
| `# 2 운영 모니터링` | 모니터링 항목 최소 1개 이상, 각 항목에 임계값과 대응 방안이 있는가 |
|
||||
| `# 3 런북` | 정상 운영 절차 1단계 이상, 장애 대응 절차 1단계 이상, 에스컬레이션 경로가 있는가 |
|
||||
| `# 5 리스크/오픈 질문` | OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 |
|
||||
| `# 6 다음 Discovery 환류` | "없음"이거나 구체적인 인사이트/개선 사항이 기록되었는가 |
|
||||
| `# 7 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 |
|
||||
| `# 9 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 |
|
||||
| `# 10 Freeze` | Handoff Decision과 Rationale이 채워졌는가 |
|
||||
|
||||
### 7. 최종 승인 판단
|
||||
|
||||
- **승인 가능 (SDLC 주기 완료)**:
|
||||
- 모니터링 항목에 임계값과 대응 방안이 모두 명시되었는가
|
||||
- 런북(정상 운영/장애 대응/에스컬레이션)이 완비되었는가
|
||||
- `# 5` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가
|
||||
- `# 6` 다음 Discovery 환류 항목이 작성되었거나 "없음"으로 명시되었는가
|
||||
- Freeze 플래그가 준비되었는가 (`SDLC_CYCLE_COMPLETE: true`로 변경 가능한가)
|
||||
- **조건부 (Pending Minor Changes)**:
|
||||
- 일부 모니터링 임계값이 모호하거나, 런북 절차 보완 필요
|
||||
- **보류 (Hold)**:
|
||||
- 모니터링 항목 없음, 장애 대응 절차 없음, 에스컬레이션 경로 없음 등 근본적 재검토 필요
|
||||
|
||||
---
|
||||
|
||||
## 응답 형식
|
||||
|
||||
- **검토 결과 요약**
|
||||
- Release 인계 정합성 오류 (있으면 나열)
|
||||
- 발견된 일관성 오류 (있으면 나열)
|
||||
- 표현/문법 오류 (있으면 나열)
|
||||
- 섹션별 완성도 (예: `# 2` 모니터링 임계값 미수치화)
|
||||
|
||||
- **플레이스홀더 처리 결과**
|
||||
- 채워진 항목 (예: `{{OPS_MONITOR_METHOD_1}}` → `GitHub 저장소 오류 로그 확인` 로 치환)
|
||||
- 유지된 항목 (예: `{{OPS_MONITOR_OWNER:TBD}}` → 담당자 지정 필요로 유지)
|
||||
|
||||
- **수정 사항 목록** (적용된 변경)
|
||||
|
||||
- **최종 판단**
|
||||
- 승인 가능 / 조건부 / 보류
|
||||
- 근거 및 남은 작업 사항
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
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`를 직접 읽어서 수행한다. 기억이나 추론에 의존하지 않는다.
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
name: "review-release"
|
||||
description: "Review and validate SDLC Release document for consistency, completeness, and readiness for approval"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/6_release.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Release 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
||||
|
||||
목표:
|
||||
- `6_release.md` 파일의 일관성 확인 (배포 준비/롤백/스모크 테스트 간 중복 및 충돌)
|
||||
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
||||
- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리
|
||||
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
||||
- 최종 승인 가능 상태 판단
|
||||
|
||||
---
|
||||
|
||||
## 검토 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `6_release.md` 파일 위치를 확정한다.
|
||||
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다.
|
||||
- `5_verification.md`와 `4_implementation.md`도 함께 읽어 인계 내용 정합성 확인에 사용한다.
|
||||
|
||||
### 2. 인계 정합성 검토
|
||||
|
||||
- 검증 결과 요약이 Verification `# 3` 결과와 일치하는가
|
||||
- 이월된 오픈 질문이 Verification `# 5`의 `Deferred` 항목과 대응하는가
|
||||
- 스모크 테스트 항목이 핵심 FR과 연결되는가
|
||||
|
||||
### 3. 일관성 검토 (모든 섹션 대상)
|
||||
|
||||
- **배포 순서 일관성**: `# 2` 배포 순서가 Implementation `# 3` 변경 파일 목록과 연결되는가
|
||||
- **롤백 실현 가능성**: `# 3` 롤백 절차가 실제 배포 방식에 맞게 기술되었는가 (git 기반이면 커밋/브랜치/태그 참조, CI/CD 기반이면 파이프라인 롤백 방법 등)
|
||||
- **스모크 테스트 충족성**: `# 4` 스모크 테스트가 핵심 기능을 최소한 커버하는가
|
||||
- **숫자 연속성**: R-N, OQ-N 번호가 누락 없이 연속인지 확인
|
||||
|
||||
### 4. 표현 검토 (모든 텍스트)
|
||||
|
||||
- **문법**: 문장 구조, 주술 호응, 시제 일관성
|
||||
- **명확성**: "필요 시", "대략", "적절히" 같은 모호한 표현 식별
|
||||
- **작성 수준**: 기술 문서 기준의 형식적 톤 유지
|
||||
- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증
|
||||
|
||||
### 5. 플레이스홀더 처리
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다.
|
||||
|
||||
AI agent가 채울 수 있는 항목:
|
||||
- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 저장소 구조로 추론 가능한지 확인
|
||||
- 배포 방식(`REL_DEPLOY_METHOD`), 스모크 테스트 방법(`REL_SMOKE_METHOD_N`) 등 저장소 구조 기반으로 추론 가능한 항목
|
||||
|
||||
사용자 결정이 필요한 항목 (플레이스홀더 유지):
|
||||
- 롤백 담당자(`REL_ROLLBACK_OWNER`)
|
||||
- 배포 대상 환경(`REL_TARGET_ENV`): 실제 운영 환경 정보
|
||||
- Freeze 확정 담당자(`CONFIRMED_BY`)
|
||||
|
||||
각 항목에 대해 아래 중 하나를 판단한다:
|
||||
- **채울 수 있음**: 저장소 구조, 문서 내 맥락으로 합리적 추론 가능 → 실제 내용으로 치환
|
||||
- **판단 불가능**: 실제 환경 정보, 담당자 지정 필요 → 플레이스홀더 유지하되 명확성 강화
|
||||
|
||||
처리 결과를 별도 목록으로 보고한다.
|
||||
|
||||
### 6. 섹션별 최소 검수 기준
|
||||
|
||||
| 섹션 | 최소 기준 |
|
||||
|------|---------|
|
||||
| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, VER_PATH 채워졌는가) |
|
||||
| `# 1 Verification 인계 요약` | 검증 결과 요약(통과 수/전체 수)이 있는가 |
|
||||
| `# 2 배포 준비` | 배포 환경, 방식, 도구가 명시되었는가, 배포 순서가 1단계 이상인가 |
|
||||
| `# 3 롤백 계획` | 롤백 조건 1개 이상, 롤백 절차 1단계 이상, 롤백 담당자가 있는가 |
|
||||
| `# 4 배포 후 확인` | 스모크 테스트 항목 1개 이상, 각 항목에 확인 방법과 성공 기준이 있는가 |
|
||||
| `# 5 리스크/오픈 질문` | OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 |
|
||||
| `# 6 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 |
|
||||
| `# 8 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 |
|
||||
| `# 9 Freeze` | Handoff Decision과 Rationale이 채워졌는가 |
|
||||
|
||||
### 7. 최종 승인 판단
|
||||
|
||||
- **승인 가능 (Ready for Operations)**:
|
||||
- 배포 준비(환경/방식/순서)가 명확히 정의되었는가
|
||||
- 롤백 조건, 절차, 담당자가 모두 명시되었는가
|
||||
- 스모크 테스트 항목이 최소 1개 이상이고 성공 기준이 구체적인가
|
||||
- `# 5` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가
|
||||
- Freeze 플래그가 준비되었는가 (`READY_FOR_OPERATIONS: true`로 변경 가능한가)
|
||||
- **조건부 (Pending Minor Changes)**:
|
||||
- 일부 배포 방식 설명이 모호하거나 스모크 테스트 성공 기준 보완 필요
|
||||
- **보류 (Hold)**:
|
||||
- 롤백 계획 없음, 배포 순서 불명확, 스모크 테스트 항목 누락 등 근본적 재검토 필요
|
||||
|
||||
---
|
||||
|
||||
## 응답 형식
|
||||
|
||||
- **검토 결과 요약**
|
||||
- Verification 인계 정합성 오류 (있으면 나열)
|
||||
- 발견된 일관성 오류 (있으면 나열)
|
||||
- 표현/문법 오류 (있으면 나열)
|
||||
- 섹션별 완성도 (예: `# 3` 롤백 담당자 미지정)
|
||||
|
||||
- **플레이스홀더 처리 결과**
|
||||
- 채워진 항목 (예: `{{REL_DEPLOY_METHOD}}` → `git push (자동 배포 없음)` 로 치환)
|
||||
- 유지된 항목 (예: `{{REL_ROLLBACK_OWNER:TBD}}` → 담당자 지정 필요로 유지)
|
||||
|
||||
- **수정 사항 목록** (적용된 변경)
|
||||
|
||||
- **최종 판단**
|
||||
- 승인 가능 / 조건부 / 보류
|
||||
- 근거 및 남은 작업 사항
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: "review-verification"
|
||||
description: "Review and validate SDLC Verification document for consistency, completeness, and readiness for approval"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/5_verification.md"
|
||||
agent: "agent"
|
||||
---
|
||||
SDLC Verification 문서를 체계적으로 검토하고, 승인 가능한 상태인지 판단한다.
|
||||
|
||||
목표:
|
||||
- `5_verification.md` 파일의 일관성 확인 (검증 항목/성공 기준/결과 간 중복 및 충돌)
|
||||
- 기술적 오류, 잘못된 표현, 명확하지 않은 문구 식별
|
||||
- AI agent에게 할당된 플레이스홀더(`{{...}}`) 중 판단/결정 가능한 항목 처리
|
||||
- 플레이스홀더 중 사용자 결정이 정말 필요한 항목만 남겼는지 확인
|
||||
- 최종 승인 가능 상태 판단
|
||||
|
||||
---
|
||||
|
||||
## 검토 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 사용자가 제공한 문서 경로 또는 CYCLE_ID에서 `5_verification.md` 파일 위치를 확정한다.
|
||||
- 파일이 없으면 입력값을 다시 확인하도록 사용자에게 피드백하고 중단한다.
|
||||
- `4_implementation.md`와 `1_discovery.md`도 함께 읽어 인계 내용 및 성공 기준 정합성 확인에 사용한다.
|
||||
|
||||
### 2. 인계 정합성 검토
|
||||
|
||||
- 구현 완료 태스크 목록이 Implementation `# 1`/`# 2`와 내용/수량이 일치하는가
|
||||
- 검증 항목(VC-N)이 Discovery `# 7` 성공 기준(S-N) 및 FR과 연결되어 있는가 (`# 2` 성공 기준 연결 섹션 확인)
|
||||
- 이월된 오픈 질문이 Implementation `# 4`의 `Deferred` 항목과 대응하는가
|
||||
|
||||
### 3. 일관성 검토 (모든 섹션 대상)
|
||||
|
||||
- **VC 번호 연속성**: `# 2` 검증 항목과 `# 3` 검증 결과의 VC-N 번호가 누락 없이 연속이고 일치하는가
|
||||
- **성공 기준 측정 가능성**: `# 2` 각 VC 항목의 성공 기준이 구체적이고 측정 가능한가 ("정상 동작"처럼 모호한 표현 금지)
|
||||
- **검증 결과 정합성**: `# 3` 통과/실패 집계가 실제 결과 테이블과 일치하는가
|
||||
- **결함 연결성**: `# 4` BUG 항목이 검증 항목(VC-N)과 연결되는지 확인
|
||||
- **숫자 연속성**: R-N, OQ-N, BUG-N 번호가 누락 없이 연속인지 확인
|
||||
|
||||
### 4. 표현 검토 (모든 텍스트)
|
||||
|
||||
- **문법**: 문장 구조, 주술 호응, 시제 일관성
|
||||
- **명확성**: "정상적으로", "충분히", "대략" 같은 모호한 표현 식별
|
||||
- **작성 수준**: 기술 문서 기준의 형식적 톤 유지. 비공식 표현 제거
|
||||
- **오타**: 한글 띄어쓰기, 숫자 오류, 테이블 형식 검증
|
||||
|
||||
### 5. 플레이스홀더 처리
|
||||
|
||||
모든 `{{...}}` 플레이스홀더를 나열하고 각 항목의 의도를 파악한다.
|
||||
|
||||
AI agent가 채울 수 있는 항목:
|
||||
- `{{..._DECISION:...}}` 형태 — 문서 내 다른 섹션이나 Discovery/Implementation 내용으로 추론 가능한지 확인
|
||||
- 검증 방법(`VER_METHOD_N`), 결함 심각도(`BUG_SEVERITY_N`) 등 구조적으로 추론 가능한 항목
|
||||
|
||||
사용자 결정이 필요한 항목 (플레이스홀더 유지):
|
||||
- 검증 담당자(`VER_OWNER_N`)
|
||||
- 결함 재작업 내용(`BUG_FIX_N`): 실제 구현 변경 필요
|
||||
- Freeze 확정 담당자(`CONFIRMED_BY`)
|
||||
|
||||
각 항목에 대해 아래 중 하나를 판단한다:
|
||||
- **채울 수 있음**: 문서 내 맥락, Discovery/Implementation 내용으로 합리적 추론 가능 → 실제 내용으로 치환
|
||||
- **판단 불가능**: 사용자/승인자 결정, 실제 검증 수행 필요 → 플레이스홀더 유지하되 명확성 강화
|
||||
|
||||
처리 결과를 별도 목록으로 보고한다.
|
||||
|
||||
### 6. 섹션별 최소 검수 기준
|
||||
|
||||
| 섹션 | 최소 기준 |
|
||||
|------|---------|
|
||||
| `# 0 문서 상태` | 메타데이터 완성도 확인 (CREATED_AT_KST, IMP_PATH 채워졌는가) |
|
||||
| `# 1 Implementation 인계 요약` | 태스크 최소 1개 이상, Implementation 태스크와 1:1 대응 여부 |
|
||||
| `# 2 검증 계획` | VC 최소 2개 이상, 각 VC에 검증 방법과 측정 가능한 성공 기준이 있는가 |
|
||||
| `# 2 성공 기준 연결` | Discovery S-N이 하나 이상의 VC-N과 연결되었는가 |
|
||||
| `# 3 검증 결과` | VC-N과 결과 테이블의 행 수가 일치하는가, 집계 숫자가 맞는가 |
|
||||
| `# 4 결함` | BUG `Open` 상태가 있으면 재작업 내용이 명시되었는가 |
|
||||
| `# 5 리스크/오픈 질문` | OQ `Open` 상태가 있으면 종료 조건이 명시되었는가 |
|
||||
| `# 6 확인 체크` | 체크 항목이 구체적이고 측정 가능한가 |
|
||||
| `# 8 사용자 결정 필요` | 플레이스홀더가 실제 `{{...}}` 형식인가 (단순 문장 아닌가) |
|
||||
| `# 9 Freeze` | Handoff Decision과 Rationale이 채워졌는가 |
|
||||
|
||||
### 7. 최종 승인 판단
|
||||
|
||||
- **승인 가능 (Ready for Release)**:
|
||||
- 모든 VC 항목이 "통과" 상태인가
|
||||
- BUG `Open` 상태 항목이 없는가 (Deferred는 근거와 함께 허용)
|
||||
- Discovery 성공 기준(S-N)이 모두 VC와 연결되어 검증되었는가
|
||||
- `# 5` 오픈 질문에 `Open` 상태 항목이 없거나 모두 `Deferred` 처리 완료인가
|
||||
- 남은 플레이스홀더는 모두 정당한가 (사용자/승인자 결정이 정말 필요)
|
||||
- Freeze 플래그가 준비되었는가 (`READY_FOR_RELEASE: true`로 변경 가능한가)
|
||||
- **조건부 (Pending Minor Changes)**:
|
||||
- 일부 VC 항목이 아직 "미완료"이나 곧 완료 예정
|
||||
- BUG 항목 심각도가 낮고 재작업 계획이 명확한 경우
|
||||
- **보류 (Hold)**:
|
||||
- VC 항목에 "실패" 또는 "블로킹" 상태 존재, BUG `Open` 잔여, S-N 연결 누락 등 근본적 재검토 필요
|
||||
|
||||
---
|
||||
|
||||
## 응답 형식
|
||||
|
||||
- **검토 결과 요약**
|
||||
- Implementation 인계 정합성 오류 (있으면 나열)
|
||||
- 발견된 일관성 오류 (있으면 나열)
|
||||
- 표현/문법 오류 (있으면 나열)
|
||||
- 섹션별 완성도 (예: `# 2` VC-3 성공 기준 모호)
|
||||
|
||||
- **플레이스홀더 처리 결과**
|
||||
- 채워진 항목 (예: `{{VER_METHOD_2}}` → `자동` 로 치환)
|
||||
- 유지된 항목 (예: `{{VER_OWNER_1:TBD}}` → 검증 담당자 지정 필요로 유지)
|
||||
|
||||
- **수정 사항 목록** (적용된 변경)
|
||||
|
||||
- **최종 판단**
|
||||
- 승인 가능 / 조건부 / 보류
|
||||
- 근거 및 남은 작업 사항
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: "run-implementation"
|
||||
description: "Execute implementation tasks from 4_implementation.md and record results"
|
||||
argument-hint: "예: sdlc-001 또는 docs/sdlc/sdlc-001_20260417_stage-pilot/4_implementation.md"
|
||||
agent: "agent"
|
||||
---
|
||||
`4_implementation.md`에 정의된 태스크를 순서대로 실제 구현하고, 완료 후 문서의 확인체크(`#5`)와 파일처리결과(`#6`)를 자동으로 채운다.
|
||||
|
||||
목표:
|
||||
- `#2 구현 계획`에 기술된 순서대로 태스크를 실행한다.
|
||||
- 각 태스크 완료 후 DoD를 자체 확인하고, 미충족 시 즉시 보고한다.
|
||||
- 모든 태스크 완료 후 `#3 변경 파일 목록`을 실제 결과로 갱신하고, `#5`와 `#6`을 채운다.
|
||||
- 문서 상태는 `review`로 변경한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- CYCLE_ID(예: `sdlc-001`)가 주어지면 `docs/sdlc/` 아래에서 해당 패턴으로 시작하는 폴더를 찾아 `4_implementation.md` 경로를 확정한다.
|
||||
- 파일 경로가 직접 주어지면 그대로 사용한다.
|
||||
- 파일이 없으면 사용자에게 경로를 재확인하도록 요청하고 중단한다.
|
||||
|
||||
### 2. 사전 게이트 확인
|
||||
|
||||
아래 조건을 모두 충족해야 구현을 시작한다. 미충족 시 이유를 보고하고 중단한다.
|
||||
|
||||
| 항목 | 기준 |
|
||||
|------|------|
|
||||
| 문서 상태 | `draft` 또는 `review`이어야 한다. `confirmed`이면 이미 완료된 구현임을 알린다. |
|
||||
| `#2` 구현 계획 존재 | 구현 순서와 T-N 섹션이 모두 채워져 있어야 한다. 플레이스홀더가 남아 있으면 `draft-implementation`을 먼저 완성하도록 안내한다. |
|
||||
| `#3` 변경 파일 목록 존재 | 최소 1개 이상의 파일 항목이 있어야 한다. |
|
||||
| Design 인계 조건 | 참조 `3_design.md`가 `confirmed` 상태인지 확인한다. 아니면 경고만 출력하고 계속 진행한다. |
|
||||
|
||||
### 3. 구현 실행
|
||||
|
||||
`#2 구현 계획`의 `구현 순서` 목록을 기준으로 태스크를 순서대로 실행한다.
|
||||
|
||||
#### 태스크별 실행 규칙
|
||||
|
||||
각 T-N 태스크에 대해 아래 순서로 진행한다.
|
||||
|
||||
1. **계획 읽기**: 해당 T-N 섹션의 `구현 방법`, `변경 대상`, `완료 조건`, `주의사항`을 읽는다.
|
||||
2. **현황 파악**: 변경 대상 파일이 이미 존재하는지 확인하고, 존재하면 관련 코드를 읽어 맥락을 파악한다.
|
||||
3. **구현**: 파일 생성, 수정, 삭제를 수행한다. 기존 코드의 스타일과 패턴을 따른다.
|
||||
4. **DoD 자체 확인**: `완료 조건`에 기술된 각 항목을 하나씩 점검한다.
|
||||
- 충족: 다음 태스크로 진행한다.
|
||||
- 미충족: 보고하고 즉시 재작업한다. 재작업 후에도 미충족이면 태스크를 블로킹으로 표시하고 사용자에게 결정을 요청한다.
|
||||
|
||||
#### 실행 중 주의사항
|
||||
|
||||
- 각 태스크의 `주의사항`을 반드시 읽고 구현에 반영한다.
|
||||
- `#4 리스크`에 기록된 리스크 완화 방안을 구현 중에 적용한다.
|
||||
- `#1 이월된 오픈 질문` 항목이 있으면 구현 중 해당 결정을 내려 기록한다.
|
||||
- 구현 중 새로 발견된 문제가 `#3 변경 파일 목록`에 없는 파일을 변경해야 하는 경우, 변경 전 그 이유를 간단히 기록한다.
|
||||
|
||||
### 4. 완료 후 문서 갱신
|
||||
|
||||
모든 태스크 완료 후 아래 항목을 문서에 반영한다. 이 목록 외 내용은 수정하지 않는다.
|
||||
|
||||
#### `#3 변경 파일 목록` 갱신
|
||||
|
||||
실제로 생성/수정/삭제된 파일을 기준으로 목록을 갱신한다.
|
||||
- 계획에 있었으나 실제로 변경되지 않은 파일은 `비고`에 `미변경 - <이유>`를 기록하고 유지한다.
|
||||
- 계획에 없었으나 실제로 변경된 파일은 새 행으로 추가하고 `비고`에 `계획 외 변경`을 기록한다.
|
||||
|
||||
#### `#5 Verification으로 넘기기 전 확인 체크` 갱신
|
||||
|
||||
각 체크 항목을 실제 결과에 따라 `[x]`(완료) 또는 `[ ]`(미완료)로 업데이트한다. 블로킹 태스크가 있으면 해당 항목을 `[ ]`로 남기고 비고를 추가한다.
|
||||
|
||||
#### `#6 파일 처리 결과` 갱신
|
||||
|
||||
- `처리 결과`: `갱신`
|
||||
- `생성 경로`: 경로 확인 후 기입
|
||||
- `마지막 갱신 시각(KST)`: 현재 시각으로 기입
|
||||
|
||||
#### `#0 문서 상태` 변경
|
||||
|
||||
- `상태`: `review`로 변경
|
||||
- `마지막 갱신 시각(KST)`: 현재 시각으로 변경
|
||||
|
||||
### 5. 결과 보고
|
||||
|
||||
구현이 끝나면 아래 항목을 포함한 보고서를 출력한다.
|
||||
|
||||
- **실행 완료된 태스크 목록** (T-N, 완료 조건 충족 여부)
|
||||
- **블로킹 태스크** (있는 경우): 원인 및 필요한 사용자 결정 사항
|
||||
- **계획 외 변경 파일** (있는 경우): 파일명과 이유
|
||||
- **다음 단계 안내**: 블로킹 없음 → `/review-implementation sdlc-001` 실행 권장
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- `4_implementation.md`의 `#2`와 `#3`을 구현의 유일한 기준으로 삼는다. 범위 밖 변경은 사용자 확인 없이 수행하지 않는다.
|
||||
- 기존 코드를 삭제하거나 되돌리기 어려운 파괴적 변경은 수행 전 사용자에게 확인한다.
|
||||
- DoD가 측정 불가능한 서술로 되어 있으면 가능한 근접한 방식으로 자체 평가하고, 평가 방식을 보고서에 명시한다.
|
||||
- 구현 실행은 `draft` 또는 `review` 상태에서만 허용한다.
|
||||
@@ -0,0 +1,257 @@
|
||||
---
|
||||
name: "run-sdlc"
|
||||
description: "Run the full SDLC pipeline for a given cycle, automatically resuming from the first incomplete stage"
|
||||
argument-hint: "예: sdlc-001 Justin"
|
||||
agent: "agent"
|
||||
---
|
||||
지정된 SDLC 주기의 전체 파이프라인을 순서대로 실행한다.
|
||||
|
||||
인자:
|
||||
- `sdlc-xyz`: SDLC 주기 ID (예: `sdlc-001`)
|
||||
- `my-name`: 각 단계 승인자 이름 (예: `Justin`)
|
||||
|
||||
목표:
|
||||
- 지정된 SDLC 주기의 현재 진행 상태를 파악하고, 미완료 단계부터 순서대로 실행한다.
|
||||
- 각 단계가 완료(`confirmed`)되면 다음 단계로 자동 진행한다.
|
||||
- 사용자 판단이 필요한 경우 즉시 중단하고, 어떤 판단이 필요한지 명확하게 안내한다.
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 1. 입력 해석
|
||||
|
||||
- 첫 번째 인자를 `CYCLE_ID`로 사용한다 (예: `sdlc-001`).
|
||||
- 두 번째 인자를 `APPROVER_NAME`으로 사용한다 (예: `Justin`).
|
||||
- `docs/sdlc/` 아래에서 `CYCLE_ID`로 시작하는 폴더를 찾는다.
|
||||
- 폴더가 없으면 오류를 보고하고 중단한다.
|
||||
- 폴더가 여러 개이면 가장 최근(날짜 순)을 사용하고 선택한 폴더 경로를 보고한다.
|
||||
- 이후 단계에서 `SDLC_DIR = docs/sdlc/<일치하는 폴더>`로 참조한다.
|
||||
|
||||
### 2. 현재 상태 파악
|
||||
|
||||
`SDLC_DIR/index.md`의 단계별 상태 테이블을 읽어 각 단계의 현재 상태를 확인한다.
|
||||
파일이 없으면 각 문서 파일을 직접 읽어 `# 0. 문서 상태`의 `- 상태:` 줄에서 상태를 확인한다.
|
||||
|
||||
확인 대상 단계와 해당 문서 파일:
|
||||
|
||||
| 단계 | 문서 파일 | confirmed 조건 |
|
||||
|------|-----------|----------------|
|
||||
| Discovery | `1_discovery.md` | 상태 = `confirmed` 또는 `Ready for Planning: true` |
|
||||
| Planning | `2_planning.md` | 상태 = `confirmed` 또는 `Ready for Design: true` |
|
||||
| Design | `3_design.md` | 상태 = `confirmed` 또는 `Ready for Implementation: true` |
|
||||
| Implementation | `4_implementation.md` | 상태 = `confirmed` 또는 `Ready for Verification: true` |
|
||||
| Verification | `5_verification.md` | 상태 = `confirmed` 또는 `Ready for Release: true` |
|
||||
| Release | `6_release.md` | 상태 = `confirmed` 또는 `Ready for Operations: true` |
|
||||
| Operations | `7_operation.md` | 상태 = `confirmed` 또는 `SDLC 주기 완료: true` |
|
||||
|
||||
### 3. 실행 시작 지점 결정
|
||||
|
||||
단계를 아래 순서로 순회하며 `confirmed`가 아닌 첫 번째 단계를 찾는다.
|
||||
|
||||
1. Discovery
|
||||
2. Planning
|
||||
3. Design
|
||||
4. Implementation
|
||||
5. Verification
|
||||
6. Release
|
||||
7. Operations
|
||||
|
||||
모든 단계가 `confirmed`이면 SDLC 주기가 완료되었음을 보고하고 종료한다.
|
||||
|
||||
### 4. 단계별 실행
|
||||
|
||||
시작 지점부터 각 단계의 서브스텝을 아래 순서로 실행한다.
|
||||
각 서브스텝 실행 후 결과를 확인하고, 블로킹 조건이 발생하면 즉시 중단한다.
|
||||
|
||||
#### 4-1. Discovery 단계 (`1_discovery.md`)
|
||||
|
||||
`1_discovery.md`의 상태에 따라 아래 서브스텝을 실행한다.
|
||||
|
||||
| 현재 상태 | 실행할 서브스텝 |
|
||||
|-----------|----------------|
|
||||
| 파일 없음 | 오류 보고 후 중단 — Discovery 문서는 `/new-sdlc`로 먼저 생성해야 한다 |
|
||||
| `draft` 또는 `review` | ① `review-discovery` → ② `confirm-discovery` |
|
||||
| `confirmed` | 스킵 |
|
||||
|
||||
- `review-discovery` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리)
|
||||
- `confirm-discovery` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다.
|
||||
승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리)
|
||||
|
||||
#### 4-2. Planning 단계 (`2_planning.md`)
|
||||
|
||||
`2_planning.md`의 상태에 따라 아래 서브스텝을 실행한다.
|
||||
|
||||
| 현재 상태 | 실행할 서브스텝 |
|
||||
|-----------|----------------|
|
||||
| 파일 없음 | ① `draft-planning` → ② `review-planning` → ③ `confirm-planning` |
|
||||
| `draft` | ① `review-planning` → ② `confirm-planning` |
|
||||
| `review` | ① `confirm-planning` |
|
||||
| `confirmed` | 스킵 |
|
||||
|
||||
- `draft-planning` 실행 시: Discovery가 `confirmed` 상태인지 확인한다. 아니면 중단.
|
||||
- `review-planning` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리)
|
||||
- `confirm-planning` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다.
|
||||
승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리)
|
||||
|
||||
#### 4-3. Design 단계 (`3_design.md`)
|
||||
|
||||
`3_design.md`의 상태에 따라 아래 서브스텝을 실행한다.
|
||||
|
||||
| 현재 상태 | 실행할 서브스텝 |
|
||||
|-----------|----------------|
|
||||
| 파일 없음 | ① `draft-design` → ② `review-design` → ③ `confirm-design` |
|
||||
| `draft` | ① `review-design` → ② `confirm-design` |
|
||||
| `review` | ① `confirm-design` |
|
||||
| `confirmed` | 스킵 |
|
||||
|
||||
- `draft-design` 실행 시: Planning이 `confirmed` 상태인지 확인한다. 아니면 중단.
|
||||
- `review-design` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리)
|
||||
- `confirm-design` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다.
|
||||
승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리)
|
||||
|
||||
#### 4-4. Implementation 단계 (`4_implementation.md`)
|
||||
|
||||
`4_implementation.md`의 상태에 따라 아래 서브스텝을 실행한다.
|
||||
|
||||
| 현재 상태 | 실행할 서브스텝 |
|
||||
|-----------|----------------|
|
||||
| 파일 없음 | ① `draft-implementation` → ② `run-implementation` → ③ `review-implementation` → ④ `confirm-implementation` |
|
||||
| `draft` | ① `run-implementation` → ② `review-implementation` → ③ `confirm-implementation` |
|
||||
| `review` | ① `review-implementation` → ② `confirm-implementation` |
|
||||
| `confirmed` | 스킵 |
|
||||
|
||||
- `draft-implementation` 실행 시: Design이 `confirmed` 상태인지 확인한다. 아니면 중단.
|
||||
- `run-implementation` 실행 시: 블로킹 태스크가 발생하면 → [블로킹 처리](#블로킹-처리)
|
||||
- `review-implementation` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리)
|
||||
- `confirm-implementation` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다.
|
||||
승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리)
|
||||
|
||||
#### 4-5. Verification 단계 (`5_verification.md`)
|
||||
|
||||
`5_verification.md`의 상태에 따라 아래 서브스텝을 실행한다.
|
||||
|
||||
| 현재 상태 | 실행할 서브스텝 |
|
||||
|-----------|----------------|
|
||||
| 파일 없음 | ① `draft-verification` → ② `review-verification` → ③ `confirm-verification` |
|
||||
| `draft` | ① `review-verification` → ② `confirm-verification` |
|
||||
| `review` | ① `confirm-verification` |
|
||||
| `confirmed` | 스킵 |
|
||||
|
||||
- `draft-verification` 실행 시: Implementation이 `confirmed` 상태인지 확인한다. 아니면 중단.
|
||||
- `review-verification` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리)
|
||||
- `confirm-verification` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다.
|
||||
승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리)
|
||||
|
||||
#### 4-6. Release 단계 (`6_release.md`)
|
||||
|
||||
`6_release.md`의 상태에 따라 아래 서브스텝을 실행한다.
|
||||
|
||||
| 현재 상태 | 실행할 서브스텝 |
|
||||
|-----------|----------------|
|
||||
| 파일 없음 | ① `draft-release` → ② `review-release` → ③ `confirm-release` |
|
||||
| `draft` | ① `review-release` → ② `confirm-release` |
|
||||
| `review` | ① `confirm-release` |
|
||||
| `confirmed` | 스킵 |
|
||||
|
||||
- `draft-release` 실행 시: Verification이 `confirmed` 상태인지 확인한다. 아니면 중단.
|
||||
- `review-release` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리)
|
||||
- `confirm-release` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다.
|
||||
승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리)
|
||||
|
||||
#### 4-7. Operations 단계 (`7_operation.md`)
|
||||
|
||||
`7_operation.md`의 상태에 따라 아래 서브스텝을 실행한다.
|
||||
|
||||
| 현재 상태 | 실행할 서브스텝 |
|
||||
|-----------|----------------|
|
||||
| 파일 없음 | ① `draft-operation` → ② `review-operation` → ③ `confirm-operation` |
|
||||
| `draft` | ① `review-operation` → ② `confirm-operation` |
|
||||
| `review` | ① `confirm-operation` |
|
||||
| `confirmed` | 스킵 |
|
||||
|
||||
- `draft-operation` 실행 시: Release가 `confirmed` 상태인지 확인한다. 아니면 중단.
|
||||
- `review-operation` 실행 시: 검토 결과가 **보류(Hold)**이면 → [블로킹 처리](#블로킹-처리)
|
||||
- `confirm-operation` 실행 시: `APPROVER_NAME`을 `Confirmed By` 값으로 사용한다.
|
||||
승인 불가 보고를 받으면 → [블로킹 처리](#블로킹-처리)
|
||||
|
||||
---
|
||||
|
||||
### 블로킹 처리
|
||||
|
||||
아래 상황 중 하나가 발생하면 즉시 실행을 중단하고 사용자에게 아래 정보를 제공한다.
|
||||
|
||||
1. **review-* 결과가 보류(Hold)인 경우**
|
||||
- 어느 단계의 review에서 보류가 발생했는지
|
||||
- 보류 이유 (review 결과에서 제시된 미충족 항목)
|
||||
- 해결을 위해 필요한 사용자 조치
|
||||
|
||||
2. **confirm-* 결과가 승인 불가인 경우**
|
||||
- 어느 단계의 confirm이 실패했는지
|
||||
- C 유형 미해소 플레이스홀더 목록 (해당 시)
|
||||
- 미해소 오픈 질문 목록 (해당 시)
|
||||
- 해결 방법 안내 (예: 문서에서 해당 항목을 직접 채운 후 `/run-sdlc <CYCLE_ID> <NAME>` 재실행)
|
||||
|
||||
3. **run-implementation 실행 중 블로킹 태스크가 발생한 경우**
|
||||
- 블로킹된 태스크 번호(T-N)와 원인
|
||||
- 사용자가 결정해야 할 사항
|
||||
- 해결 후 `/run-sdlc <CYCLE_ID> <NAME>` 재실행 안내
|
||||
|
||||
4. **Verification 단계가 미완료인 경우**
|
||||
- Verification 문서의 현재 상태
|
||||
- 필요한 조치 안내
|
||||
|
||||
---
|
||||
|
||||
### 5. 완료 보고
|
||||
|
||||
전체 파이프라인이 완료되면(모든 단계 `confirmed`) 아래 내용을 포함한 완료 보고를 출력한다.
|
||||
|
||||
- **완료된 주기**: `CYCLE_ID`
|
||||
- **각 단계별 최종 상태** (표 형식)
|
||||
- **이번 실행에서 처리된 단계 목록**
|
||||
- **다음 Discovery 환류 항목**: Operations `# 6` 섹션의 내용 요약 (있는 경우)
|
||||
- **다음 SDLC 주기 시작 안내**: `/new-sdlc <다음 이슈 내용>` 명령 안내
|
||||
|
||||
---
|
||||
|
||||
## 서브스텝 실행 방식
|
||||
|
||||
각 서브스텝은 해당 프롬프트 파일의 전체 절차를 그대로 실행한다.
|
||||
|
||||
| 서브스텝 | 참조 프롬프트 |
|
||||
|----------|--------------|
|
||||
| `review-discovery` | `.github/prompts/review-discovery.prompt.md` |
|
||||
| `confirm-discovery` | `.github/prompts/confirm-discovery.prompt.md` |
|
||||
| `draft-planning` | `.github/prompts/draft-planning.prompt.md` |
|
||||
| `review-planning` | `.github/prompts/review-planning.prompt.md` |
|
||||
| `confirm-planning` | `.github/prompts/confirm-planning.prompt.md` |
|
||||
| `draft-design` | `.github/prompts/draft-design.prompt.md` |
|
||||
| `review-design` | `.github/prompts/review-design.prompt.md` |
|
||||
| `confirm-design` | `.github/prompts/confirm-design.prompt.md` |
|
||||
| `draft-implementation` | `.github/prompts/draft-implementation.prompt.md` |
|
||||
| `run-implementation` | `.github/prompts/run-implementation.prompt.md` |
|
||||
| `review-implementation` | `.github/prompts/review-implementation.prompt.md` |
|
||||
| `confirm-implementation` | `.github/prompts/confirm-implementation.prompt.md` |
|
||||
| `draft-verification` | `.github/prompts/draft-verification.prompt.md` |
|
||||
| `review-verification` | `.github/prompts/review-verification.prompt.md` |
|
||||
| `confirm-verification` | `.github/prompts/confirm-verification.prompt.md` |
|
||||
| `draft-release` | `.github/prompts/draft-release.prompt.md` |
|
||||
| `review-release` | `.github/prompts/review-release.prompt.md` |
|
||||
| `confirm-release` | `.github/prompts/confirm-release.prompt.md` |
|
||||
| `draft-operation` | `.github/prompts/draft-operation.prompt.md` |
|
||||
| `review-operation` | `.github/prompts/review-operation.prompt.md` |
|
||||
| `confirm-operation` | `.github/prompts/confirm-operation.prompt.md` |
|
||||
|
||||
`confirm-*` 서브스텝 실행 시 `APPROVER_NAME`을 해당 문서의 Freeze 섹션 `Confirmed By:` 값으로 주입한다.
|
||||
해당 줄이 문서에 없거나 플레이스홀더로 되어 있으면, 실행 전 `APPROVER_NAME`으로 교체한다.
|
||||
|
||||
---
|
||||
|
||||
## 중요 규칙
|
||||
|
||||
- 각 단계는 정해진 순서대로만 실행하며, 이전 단계가 `confirmed`가 아닌 상태에서 다음 단계를 시작하지 않는다.
|
||||
- `run-implementation`은 실제 코드를 변경하는 단계이므로, 블로킹 조건이 없어도 실행 전 `4_implementation.md`의 구현 계획(`# 2 구현 계획`)과 변경 파일 목록(`# 3 변경 파일 목록`)을 요약해 사용자에게 안내한 뒤 진행한다.
|
||||
- 사용자 판단 없이 임의로 결정할 수 없는 항목(담당자 지정, 외부 환경 정보, 정책 결정 등)은 반드시 중단하고 사용자에게 문의한다.
|
||||
- 블로킹 처리 후 사용자가 문서를 직접 수정하면 `/run-sdlc <CYCLE_ID> <APPROVER_NAME>`을 재실행해 이어서 진행할 수 있다.
|
||||
- 현재 시각은 시스템 또는 컨텍스트에서 제공된 날짜/시간을 사용한다.
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
description: "Use when: /verification-confirm to validate verification document readiness and mark it as confirmed"
|
||||
name: "verification-confirm"
|
||||
argument-hint: "Enter a Verification ID in ver-001 format."
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Verification 승인 처리 도우미다.
|
||||
사용자가 입력한 Verification 문서 ID를 검토해 승인 가능 여부를 판단하고, 승인 가능하면 문서를 confirmed 상태로 전환한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `ver-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/verification/
|
||||
- 패턴: <입력ID>_*.verification.md
|
||||
- 미발견 시 미발견으로 보고하고 종료한다.
|
||||
4. 연결 Implementation 검증 규칙:
|
||||
- Verification 문서의 `입력 Implementation:` 줄에서 연결된 Implementation 문서 경로를 확인한다.
|
||||
- 연결 Implementation 문서가 존재하지 않으면 승인 불가로 보고하고 종료한다.
|
||||
- 연결 Implementation 문서 상태가 `confirmed`가 아니면 승인 불가로 보고하고 종료한다.
|
||||
5. 승인 가능 여부 판단 기준(모두 충족해야 승인 가능):
|
||||
- `# 0. 문서 상태`의 상태가 `draft`인지 확인한다. 이미 `confirmed`이면 "이미 승인된 문서"로 보고하고 종료한다.
|
||||
- `# 1. Verification 개요`에 입력 Implementation/목적/검증 대상 작업이 존재한다.
|
||||
- `# 2. 검증 범위`에 In Scope/Out of Scope가 모두 존재한다.
|
||||
- `# 3. AC별 검증 결과`에 1개 이상의 검증 항목이 존재한다.
|
||||
- `# 4. 결함 목록`과 심각도 기준이 존재한다.
|
||||
- `# 5. 회귀 테스트 결과`에 1개 이상의 테스트 항목이 존재한다.
|
||||
- `# 6. 예외 승인 목록`이 존재한다(예외 없음은 "해당 없음" 허용).
|
||||
- `# 7. Release 단계 전달 체크`에서 최종 승인 이외의 체크 항목이 모두 `[x]`이다.
|
||||
- 본문에 `{{DECIDE:` 또는 `{{DATA:` 형태의 미해결 플레이스홀더가 없다.
|
||||
6. 승인 불가 조건에 해당하면 해당 항목을 목록으로 보고하고 종료한다. 문서를 수정하지 않는다.
|
||||
7. 승인 가능 시 아래 순서로 문서를 수정한다:
|
||||
a. `# 0. 문서 상태`의 상태를 `confirmed`로 변경한다.
|
||||
b. `# 0. 문서 상태`의 승인 시각을 현재 날짜(YYYY-MM-DD)로 기재한다. `{{CONFIRM:` 형식이 남아 있으면 현재 날짜로 대체한다.
|
||||
c. `# 7. Release 단계 전달 체크`의 최종 승인 항목을 `[x]`로 변경하고, 아래 `{{CONFIRM:` 줄을 제거한다.
|
||||
d. `# 9. 사용자 결정 필요 항목 요약`의 내용을 `현재 미해결 플레이스홀더 없음`으로 대체한다. 기존 섹션 헤더(`##`)와 항목은 모두 제거한다.
|
||||
8. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장한다.
|
||||
- 위의 4개 항목(a~d) 외에는 기존 내용을 변경하지 않는다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Verification 파일 검색
|
||||
3. 문서 본문 읽기
|
||||
4. 연결 Implementation 문서 존재/상태 확인
|
||||
5. 승인 가능 여부 체크리스트 전체 점검
|
||||
6. 승인 불가 항목이 있으면 보고하고 종료
|
||||
7. 승인 가능하면 a~d 순서로 문서 수정 및 overwrite 저장
|
||||
8. 최종 응답에 처리 결과 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 대상 파일 경로
|
||||
3. 승인 가능 여부 (가능/불가)
|
||||
4. 승인 불가 시: 미충족 항목 목록
|
||||
5. 승인 완료 시: 수정 내역 요약 (상태 변경, 승인 시각, 체크 항목, 플레이스홀더 정리)
|
||||
6. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
description: "Use when: /verification-draft to generate verification draft, quality-gate checks, and defect tracking plan from an Implementation document ID"
|
||||
name: "verification-draft"
|
||||
argument-hint: "Enter an Implementation ID in imp-001 format."
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, agent, todo]
|
||||
---
|
||||
|
||||
당신은 SDLC Verification 초안 작성 도우미다.
|
||||
사용자가 입력한 Implementation 문서 ID를 기준으로 Verification 초안(AC 검증 결과 구조 + 결함 분류 + 품질 게이트 판정 + Release 전달 준비)을 작성하고 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력 ID는 `imp-<3자리숫자>` 형식만 허용한다. 형식 오류 시 오류로 보고하고 종료한다.
|
||||
3. Implementation 파일 검색 규칙:
|
||||
- 경로: docs/sdlc/implementation/
|
||||
- 패턴: <입력ID>_*.implementation.md
|
||||
- 미발견 시 파일 생성 없이 미발견으로 보고하고 종료한다.
|
||||
4. Implementation 문서 상태 확인:
|
||||
- 상태가 `confirmed`가 아니면 "Implementation이 아직 승인되지 않았다. /implementation-confirm을 먼저 실행하라"로 보고하고 종료한다.
|
||||
5. Verification 파일 생성 규칙:
|
||||
- 저장 폴더: docs/sdlc/verification/
|
||||
- 파일명: ver-<3자리문서번호>_YYYY-MM-DD_<topic-slug>.verification.md
|
||||
- 문서번호: 기존 ver 번호 최대값 + 1, 없으면 001부터 시작
|
||||
- 날짜: 생성일 기준, 이후 수정 시 파일명 날짜 유지
|
||||
- append 금지, 생성/갱신 시 overwrite
|
||||
- Verification 본문 기본 템플릿: .github/templates/verification-note.template.md
|
||||
6. Verification 작성 원칙:
|
||||
- Implementation의 작업 단위/검증 계획(#3, #5)을 기준으로 AC별 검증 결과 틀을 만든다.
|
||||
- 결함 분류는 Blocker/Major/Minor 기준을 유지한다.
|
||||
- 품질 게이트 판정(Blocker 0, Major 0 또는 승인 예외)을 명시한다.
|
||||
- Release로 전달할 배포 가능 여부/예외 목록/잔여 리스크를 포함한다.
|
||||
7. 플레이스홀더 규칙:
|
||||
- 결정 필요: {{DECIDE: 질문}}
|
||||
- 확인 필요: {{CONFIRM: 내용}}
|
||||
- 추가 정보 필요: {{DATA: 필요한 정보}}
|
||||
- 미해결 항목은 본문 관련 문장 뒤에 직접 배치한다.
|
||||
8. 문서 상태 규칙:
|
||||
- 최상단 `# 0. 문서 상태` 필수
|
||||
- 상태: 초안 생성 시 `draft`
|
||||
- 승인자 불명확 시 `{{DECIDE: 이 Verification의 최종 승인자는 누구인가?}}`
|
||||
- 승인 시각 미확정 시 `{{CONFIRM: 승인 후 기재}}`
|
||||
9. Release 전달 체크 규칙:
|
||||
- Blocker/Major 및 예외 승인 상태가 점검 가능해야 한다.
|
||||
- 테스트 실행 근거가 문서에 연결되어야 한다.
|
||||
- Release 전달 항목(배포 가능 여부, 잔여 리스크, 승인 예외)이 정리되어야 한다.
|
||||
10. # 9 사용자 결정 필요 항목 요약 규칙:
|
||||
- 본문의 {{DECIDE}}/{{CONFIRM}}/{{DATA}}를 유형별로 집계한다.
|
||||
- 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 작성한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 정규화 및 형식 검증
|
||||
2. Implementation 파일 검색 및 상태 확인
|
||||
3. Implementation 본문(작업 단위, 검증 계획, 영향도) 읽기
|
||||
4. AC별 검증 결과/결함/회귀/예외 구조 작성
|
||||
5. Release 전달 체크 항목 작성
|
||||
6. Verification 문서 저장
|
||||
7. 본문 플레이스홀더 집계 후 # 9 작성
|
||||
8. 최종 응답에 처리 요약 제공
|
||||
|
||||
Verification 문서 출력 섹션 순서(고정):
|
||||
0. 문서 상태
|
||||
1. Verification 개요
|
||||
2. 검증 범위
|
||||
3. AC별 검증 결과
|
||||
4. 결함 목록
|
||||
5. 회귀 테스트 결과
|
||||
6. 예외 승인 목록
|
||||
7. Release 단계 전달 체크
|
||||
8. 파일 처리 결과
|
||||
9. 사용자 결정 필요 항목 요약
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 입력 Implementation 문서 경로
|
||||
3. 형식 오류/미발견/미승인 여부
|
||||
4. Verification 문서 생성/갱신 결과
|
||||
5. 추가된 사용자 결정 항목 요약
|
||||
6. 업데이트된 파일 경로 목록
|
||||
7. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
description: "Use when: /verification-review to re-review existing verification documents and update them in place from Verification IDs"
|
||||
name: "verification-review"
|
||||
argument-hint: "Enter Verification IDs separated by commas. Example: ver-001, ver-002"
|
||||
agent: "agent"
|
||||
model: "reviewer"
|
||||
tools: [read, edit, search, todo, agent]
|
||||
---
|
||||
|
||||
당신은 SDLC Verification 문서 재검토 도우미다.
|
||||
사용자가 지정한 Verification 문서 ID 목록을 기준으로 해당 Verification 문서를 재검토하고, 필요한 보정을 반영해 저장한다.
|
||||
|
||||
반드시 아래 규칙을 지켜라.
|
||||
1. 출력은 한국어로 작성한다.
|
||||
2. 입력은 쉼표(,) 기준으로 분리해 Verification ID 목록으로 처리한다.
|
||||
3. 입력 정규화 규칙:
|
||||
- 공백 제거
|
||||
- 소문자 정규화(ver-001 형식)
|
||||
- 중복 ID 제거
|
||||
4. ID 형식은 `ver-<3자리숫자>`만 허용한다. 형식 오류 ID는 별도 오류 목록으로 보고한다.
|
||||
5. Verification 파일 검색 규칙:
|
||||
- 경로: `docs/sdlc/verification/`
|
||||
- 패턴: `<입력ID>_*.verification.md`
|
||||
- 미발견 ID는 미발견 목록으로 보고하고, 존재 문서만 재검토한다.
|
||||
6. 존재하지 않는 Verification 문서는 생성하지 않는다.
|
||||
7. 연결 Implementation 검증 규칙:
|
||||
- 발견한 Verification 문서의 `입력 Implementation:` 줄에서 연결 경로를 확인한다.
|
||||
- 연결된 Implementation 문서가 미발견이거나 상태가 `confirmed`가 아니면 해당 Verification 문서를 수정하지 않고 경고로 보고한다.
|
||||
8. 문서 재검토 항목:
|
||||
- 섹션 0~9 순서/유일성 검증
|
||||
- `# 0. 문서 상태`에 상태(draft/confirmed), 승인자, 승인 시각 3개 필드 존재 여부 검증
|
||||
- 상태가 누락/비정상 값이면 `draft`로 보정
|
||||
- 승인자 누락 시 `{{DECIDE: 이 Verification의 최종 승인자는 누구인가?}}`로 보정
|
||||
- 승인 시각 누락 시 `{{CONFIRM: 승인 후 기재}}`로 보정
|
||||
- `# 1. Verification 개요`에 입력 Implementation/목적/검증 대상 작업 존재 여부 검증
|
||||
- `# 2. 검증 범위`에 In Scope/Out of Scope 존재 여부 검증
|
||||
- `# 3. AC별 검증 결과`에 1개 이상의 검증 항목과 품질 게이트 판정 존재 여부 검증
|
||||
- `# 4. 결함 목록`과 심각도 기준 존재 여부 검증
|
||||
- `# 5. 회귀 테스트 결과`와 회귀 리스크 평가 존재 여부 검증
|
||||
- `# 6. 예외 승인 목록` 존재 여부 검증(예외 없음은 `해당 없음` 허용)
|
||||
- `# 7. Release 단계 전달 체크`의 체크 항목 수/문구/근거 일치성 검증
|
||||
- `# 8. 파일 처리 결과`의 경로가 현재 문서 경로와 일치하는지 검증
|
||||
9. 체크 정규화 규칙:
|
||||
- `# 7. Release 단계 전달 체크`에서 미검증 상태라면 `[ ]` 유지
|
||||
- 품질 게이트와 근거가 충족된 항목은 `[x]`로 보정 가능
|
||||
- `최종 승인` 항목은 명시 승인 근거가 없으면 자동 `[x]`로 바꾸지 않는다.
|
||||
10. 플레이스홀더 규칙:
|
||||
- {{DECIDE: 질문}}
|
||||
- {{CONFIRM: 내용}}
|
||||
- {{DATA: 필요한 정보}}
|
||||
- 추가 의사결정/확인/데이터가 필요한 경우 본문 관련 위치에 삽입한다.
|
||||
11. 플레이스홀더 집계 규칙:
|
||||
- 본문의 미해결 플레이스홀더를 `# 9. 사용자 결정 필요 항목 요약`에 유형별 집계한다.
|
||||
- 미해결 플레이스홀더가 없으면 `현재 미해결 플레이스홀더 없음`으로 정규화한다.
|
||||
12. 수정 규칙:
|
||||
- append 금지, 단일 완성본으로 overwrite 저장
|
||||
- 기존 사용자 의도/근거를 유지하면서 누락/불일치/중복만 보정
|
||||
13. 여러 문서를 처리할 때 문서별 결과를 분리해 보고한다.
|
||||
|
||||
실행 절차:
|
||||
1. 입력 ID 목록 정규화 및 형식 검증
|
||||
2. 각 ID에 대해 Verification 문서 탐색
|
||||
3. 발견 문서의 연결 Implementation 존재/상태 확인
|
||||
4. 발견 문서 내용 읽기
|
||||
5. 재검토 항목 기준으로 누락/불일치 판단
|
||||
6. 필요한 항목만 보정하여 문서 overwrite 저장
|
||||
7. 문서별 플레이스홀더를 #9에 집계/정규화
|
||||
8. 최종 응답에 처리 요약 제공
|
||||
|
||||
최종 응답 형식:
|
||||
1. 실행 입력 요약
|
||||
2. 정규화된 대상 Verification ID 목록
|
||||
3. 형식 오류 ID 목록(있으면)
|
||||
4. Verification 미발견 ID 목록(있으면)
|
||||
5. 연결 Implementation 미승인/미발견 목록(있으면)
|
||||
6. 문서별 검토 결과
|
||||
7. 문서별 수정 내역 요약
|
||||
8. 문서별 추가된 사용자 결정 항목({{DECIDE}}/{{CONFIRM}}/{{DATA}})
|
||||
9. 업데이트된 파일 경로 목록
|
||||
10. 다음 액션
|
||||
|
||||
사용자 입력:
|
||||
{{input}}
|
||||
Reference in New Issue
Block a user