Files
portfolio-hub/.github/prompts/run-implementation.prompt.md
T
genichin 3a1afaac46 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
2026-04-23 04:31:42 +00:00

100 lines
5.2 KiB
Markdown

---
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` 상태에서만 허용한다.