스테이지 (Stage)

개요

스테이지는 한 차례의 엔지니어링 변경에 대한 연결 문서입니다. — 특정 스킬의 산출물을 대체하는 것이 아니라, 각 스킬이 무엇을 산출했는지, 산출물 간의 관계는 무엇인지, 그리고 이번 변경의 전체 스토리를 기록합니다.

스테이지는 네 가지 질문에 답합니다.

원래 무엇을 하려고 했는가? (MISSION + 사전 문서)
구현 작업이 어떻게 안전하게 위임되었는가? (Task Contract 순방향 인덱스)
실제로 무엇을 만들었는가? (사후 문서 + ADR)
왜 차이가 발생했는가? (사전 vs 사후 차이 + 학습 요약)

                          STAGE.md
                   (연결 계층 / 인덱스 + 서사)
                          │
    ┌────────┬────────┬────┴────┬────────────┬────────┬────────┐
    │        │             │    │            │        │        │
  MISSION   사전 문서     구현 계획  Task Contract  사후 문서   검증
  (목표)   (설계)      (plan+todo) (위임 경계)    (결과)    (증거)
                                                │
                                              ADR
                                      (필수, 각 스테이지 최소 1개)

사용 시기

스테이지 생성은 전적으로 사용자가 결정합니다. 사용자가 명시적으로 요청할 때만 생성되며, 자동 트리거 조건은 없습니다.

사용자는 일반적으로 다음과 같이 요청합니다.

"스테이지 생성" / "스테이지 시작"
"이번 작업을 위해 스테이지 생성"
"스테이지 봉인" / "스테이지 Seal"
/plan 출력 후 "스테이지 문서가 필요합니까?"라는 질문에 "예"라고 답변

일반적인 적용 시나리오 (사용자 참고용, 트리거 규칙 아님):

여러 작업에 걸쳐 하나의 논리적 전체를 이루는 변경
여러 모듈에 걸친 새로운 기능
내부 구조는 변경되지만 동작은 동일한 리팩토링
프로덕션 환경 버그의 전체 수정 체인
아키텍처 결정을 기록해야 하는 모든 변경

자동 트리거되지 않음:

단일 고립 작업 또는 기계적 변경은 자동 생성되지 않음
순수 문서 업데이트는 자동 생성되지 않음
Agent는 작업 수나 모듈 간 정도에 따라 스스로 판단하지 않음 — 반드시 사용자 확인 필요

delegated-task-contract가 소속 스테이지가 필요하더라도 스테이지 생성을 자동 트리거해서는 안 됩니다. 스테이지가 없는 경우 중단하고 사용자에게 명시적으로 결정을 요청해야 합니다. 디렉토리 소속, 단방향 인덱스, 상태 동기화 및 봉인 게이트는 통일적으로 Stage 및 Task Contract 연동 규칙을 따릅니다.

스테이지 유형

유형	동기	성공 기준	사전 vs 사후	문서 중심
feat	새 기능 추가	새 동작이 나타나고 명세에 부합	차이는 정상이며 반드시 기록	spec + api-contract + api-doc
opt	기존 동작 개선	지표가 목표 값에 도달	최적화 효과 비교 간략히 기록	성능 기준 + 최적화 결과
debug	잘못된 동작 수정	문제 재현되지 않음 + 회귀 테스트가 근본 원인 경로 커버	사전=사후 (수정이 목표)	현상 + 근본 원인 + 수정 전략 + 예방 조치
refactor	내부 구조 변경, 동작 유지	기존 모든 동작 유지, 회귀 테스트 전체 통과	사전=사후는 강제 요구사항	아키텍처 설계 + 구조 변경 설명

스테이지 생명주기

/plan 출력 후              구현 중                     전체 구현 완료 후          /ship 실행 시
     │                          │                            │                      │
     ▼                          ▼                            ▼                      ▼
   스켈레톤 생성            문서 및 Contract 인덱스 유지     봉인 STAGE.md           스테이지 존재 확인
  (MISSION +               (상태, 편차, 증거 요약)        (최종 상태 게이트,       (pre-launch
   사전 문서 경로,                                       사후 문서,             checklist
   구현 계획 링크)                                      ADR, 차이 분석,        차단 항목)
                                                        검증 결과, 학습 요약)

생성 (스켈레톤 단계)

/plan이 tasks/plan.md와 tasks/todo.md를 출력한 후, Agent가 사용자에게 스테이지 문서가 필요한지 묻습니다. 사용자가 확인하면:

stages/<stage-id>/ 디렉토리 생성 (stage-id는 kebab-case의 짧은 제목)
STAGE.md 스켈레톤 생성, 미리 채움:
- 유형 (feat | opt | debug | refactor)
- 상태를 draft로 설정
- 의사 결정자
- MISSION (spec에서 추출)
- 사전 문서 경로 (TODO로 표시)
- 구현 계획 링크 (tasks/plan.md 및 tasks/todo.md 입력)
- Task Contracts 순방향 인덱스 테이블 (초기에는 비어 있음)
- 사후 문서 (TODO로 표시 — 구현 완료 후 작성)
- ADR (TODO로 표시 — 각 스테이지 최소 1개, 구현 완료 후 작성)
- 검증 결과 (TODO로 표시)
stages/INDEX.md에 한 줄 추가

채우기 (구축 단계)

구현 중:

일반 작업 완료 시 STAGE.md를 수정할 필요 없음. 단, Contract가 처음 기록될 때, 상태가 변경되거나 deviation/evidence가 반환될 때는 반드시 동기화해야 함
사전 문서(spec, api-contract)가 산출되면 해당 링크를 업데이트하고 TODO 표시 제거
Contract는 STAGE.md에서만 순방향 인덱싱함. Contract에 Stage 필드나 역방향 링크를 추가하지 마세요.
none이 아닌 Contract deviation은 "사전 vs 사후 차이" 테이블에 동기화하고, 봉인 시 기억에 의존해 나중에 작성하지 마세요.

봉인 (완료 후)

모든 작업이 완료되고 검증이 통과되면 Agent가 사용자에게 봉인을 알립니다. 사용자가 확인하면:

task-contract/와 인덱스 테이블을 대조하여 누락, 끊어진 링크 또는 상태 변이가 없는지 확인
모든 Contract 본문 상태가 COMPLETED 또는 CANCELLED인지 확인. DRAFT, READY 또는 BLOCKED_BY_ARCHITECTURE 상태인 Contract가 하나라도 있으면 봉인이 차단됨
사후 문서 링크 채움 (api-doc, ADR)
사전 vs 사후 차이 테이블 작성 ("사전 문서 업데이트 여부" 열 포함), Contract가 보고한 의미 있는 편차 포함
검증 결과 작성 및 Contract의 Required Evidence 링크
학습 요약 정리 ("다음에는 이렇게"와 "다음에는 이렇게 하지 말 것")
상태를 done으로 변경
stages/INDEX.md의 해당 행 상태 업데이트

확인 (출시 전)

/ship의 pre-launch checklist에 포함:

"□ 주요 변경에 해당하는 스테이지 문서가 있습니까?" — 이번 작업에서 스테이지가 생성된 경우 이는 차단 항목

스테이지 템플릿

다음은 stages/<stage-id>/STAGE.md의 표준 템플릿입니다:

# 스테이지: [짧은 제목]

**유형**: feat | opt | debug | refactor
**날짜**: YYYY-MM-DD — YYYY-MM-DD
**상태**: draft | in-progress | done | abandoned | superseded | split
**의사 결정자**: @username

---

## MISSION (이번 목표)

<!-- feat / opt / refactor는 표준 MISSION 사용 -->

- **목표**: [이번에 달성할 것을 한 문장으로 설명]
- **사용자**: [누가 혜택을 볼 것인가]
- **성공 기준**: [완료되었는지 어떻게 알 수 있는가 — 구체적이고 검증 가능한 조건]
- **제약 사항**: [바인딩 제한 — 기술, 리소스, 시간]
- **하지 않음**: [명시적으로 제외된 내용 및 이유]

<!-- debug 유형은 다음 구조로 대체: -->
<!--
- **현상**: [사용자가 무엇을 했고, 무엇을 보았으며, 무엇을 보아야 했는지]
- **영향**: [영향 범위, 지속 시간, 데이터 무결성 위험]
- **근본 원인 가설**: [초기 판단 — 구현 완료 후 확인된 근본 원인으로 업데이트]
- **수정 전략**: [지혈 방안 + 근본 원인 수정 + 예방 조치]
- **성공 기준**: [문제가 재현되지 않음, 회귀 테스트가 근본 원인 경로 커버, 유사 문제에 정적 검사 있음]
-->

→ 자세한 내용은 [MISSION.md](./MISSION.md) 참조

---

## 사전 문서 (계획한 방법)

| 문서 | 출처 스킬 | 설명 |
|------|---------|------|
| [spec/xxx.md](./spec/xxx.md) | spec-driven-dev | 기능 명세 |
| [design/api-contract.md](./design/api-contract.md) | api-and-interface | API 계약 |
| [design/xxx.md](./design/xxx.md) | — | [추가 설명] |

> 구현 시작 전에 채웁니다. 이번에 특정 유형의 문서가 관련되지 않은 경우 해당 행을 삭제합니다.

---

## 구현 계획

| 문서 | 출처 스킬 | 설명 |
|------|---------|------|
| [tasks/plan.md](./tasks/plan.md) | planning-and-task | 기술 계획 |
| [tasks/todo.md](./tasks/todo.md) | planning-and-task | 원자적 작업 목록 |

---

## Task Contracts (위임 실행 경계)

> `delegated-task-contract` 게이트가 필요한 쓰기 가능 위임만 인덱싱합니다. Contract 본문, 상태 및 Required Evidence는 해당 파일을 기준으로 합니다. 이 테이블은 순방향 링크와 요약만 저장하며, Contract에 스테이지 역방향 링크를 작성하지 않습니다.

| Task | Contract | 상태 | Deviation / Evidence |
|------|----------|------|----------------------|
| [Task ID] | [Task ID](./task-contract/TASK-XXX.md) | DRAFT \| READY \| BLOCKED_BY_ARCHITECTURE \| COMPLETED \| CANCELLED | [차단, 편차, 증거 또는 취소 사유; 없으면 `—` 작성] |

> 아직 Contract가 없으면 테이블 헤더를 유지하고 예제 행을 삭제합니다. Contract가 처음 기록될 때와 상태, 편차 또는 증거가 변경될 때마다 이 테이블을 동기화합니다.

---

## 사후 문서 (실제로 만든 모습)

> 구현 완료 후 이 섹션을 채웁니다.

| 문서 | 출처 스킬 | 설명 |
|------|---------|------|
| [docs/api/xxx.md](./docs/api/xxx.md) | documentation-and-adrs | 실제 API 문서 |
| [docs/adr/XXX-title.md](./docs/adr/XXX-title.md) | documentation-and-adrs | 아키텍처 결정 기록 (필수, 각 스테이지 최소 1개) |

### ADR (필수)

각 스테이지 **반드시** 최소 1개의 ADR을 산출해야 합니다. ADR은 핵심 아키텍처 결정과 그 맥락을 기록합니다.

| ADR | 결정 내용 | 대안 |
|-----|---------|---------|
| [ADR-XXX](./docs/adr/XXX.md) | [결정을 한 문장으로 설명] | [거부된 방안 및 이유] |

**ADR 내용 요구사항:**
- "왜 A를 선택하고 B를 선택하지 않았는지" 기록
- 고려되었으나 거부된 대안과 거부 이유를 나열
- 결정의 제약 조건과 결과 설명
- 결정이 기존 ADR과 관련된 경우 명시적으로 참조

**스테이지 유형별 ADR 중심:**

| 스테이지 유형 | ADR 일반적인 내용 |
|-----------|-------------|
| **feat** | 왜 이 아키텍처/프레임워크/프로토콜을 선택했는지; 데이터 모델 설계 트레이드오프 |
| **opt** | 왜 이 최적화 전략을 선택했는지; 왜 다른 방안(예: 캐싱 vs 인덱스 최적화)을 선택하지 않았는지 |
| **debug** | 근본 원인이 왜 발생했는지; 왜 이 수정 방안을 선택했는지; 예방 조치 설계 |
| **refactor** | 왜 이 새로운 구조를 선택했는지; 왜 특정 경계 조건을 통일하지 않았는지; 이전 구조와 새로운 구조 비교 |

---

## 사전 vs 사후 차이

> 구현 완료 후 작성합니다. 계획과 실제 간의 모든 의미 있는 편차를 기록합니다.

Contract의 `Required Evidence`가 `none`이 아닌 deviation을 보고하는 경우, 해당 Contract를 검수하는 동시에 편차를 이 테이블에 동기화합니다. Contract에만 흔적을 남기지 마세요.

| 차이 | 사전 (계획) | 사후 (결과) | 이유 | 사전 문서 업데이트 여부 |
|------|------------|------------|------|-------------------|
| [간략 설명] | [계획한 방법] | [실제 방법] | [편차 이유] | 예 / 아니요 |

**"사전 문서 업데이트 여부" 열 설명:**
- **예**: 해당 편차가 올바른 설계 방향으로 인정되어, spec 또는 api-contract를 사후와 일치하도록 수정함
- **아니요**: 해당 편차가 임시 절충 또는 타협으로, 사전 문서는 원본을 유지하여 향후 스테이지가 참조할 수 있도록 함
- "아니요"로 표시된 모든 차이 행은 다음 백로그(backlog)의 후보 입력입니다.

---

## 검증 결과

| 검사 항목 | 상태 | 증거 |
|--------|------|------|
| [인수 기준 1] | ✅ / ❌ | [테스트 보고서, 성능 데이터, 스크린샷 등] |
| [인수 기준 2] | ✅ / ❌ | [증거] |
| 회귀 없음 | ✅ / ❌ | CI 실행 링크 |

→ 자세한 내용은 [VERIFY.md](./VERIFY.md) 참조

---

## 학습 요약

> 봉인 시 작성합니다. 두 문장을 넘지 않습니다.

- **다음에는 이렇게**: [이번에 잘한 점 — 다른 스테이지에서 재사용할 가치가 있음]
- **다음에는 이렇게 하지 말 것**: [이번에 잘못한 점 — 피해야 할 사항, 경계 또는 개선해야 할 사항]

---

## 연관

- **이전 스테이지**: [STAGE-XXX](../stage-XXX/STAGE.md) (또는 "없음")
- **다음 계획**: [간략 설명, 또는 "없음"]

증분 (봉인 후 추가)

스테이지가 봉인(상태가 done으로 변경)된 후, 작은 문제를 수정해야 하지만 새로운 스테이지를 구성하지 않는 경우 STAGE.md 끝에 증분 섹션을 추가할 수 있습니다:

---

## 증분 1 (2026-07-28)

- **변경**: [무엇을 수정했는지 간략히 설명]
- **이유**: [봉인 후에도 왜 이 수정이 필요한지]
- **영향 범위**: [영향을 받은 파일/모듈]

증분 추가 시:

스테이지 상태는 done을 유지하고 in-progress로 되돌리지 않음
증분 항목은 시간 순서대로 추가
수정에 새로운 ADR 결정이 포함된 경우 사후 문서의 ADR 테이블에 추가하고 [증분 1]로 표시
증분이 누적 3개 이상인 경우, 증분을 계속 추가할지 아니면 새 스테이지를 생성할지 고려

INDEX.md

stages/INDEX.md는 모든 스테이지의 탐색 진입점입니다. 각 스테이지 생성 및 봉인 시 유지 관리합니다.

# 스테이지 인덱스

| ID | 제목 | 유형 | 상태 | 관련 모듈 | 날짜 |
|----|------|------|------|---------|------|
| 001 | raft-election-optimization | opt | done | consensus, rpc | 2026-07-15 — 2026-07-17 |
| 002 | wal-checksum-verification | feat | done | storage, wal | 2026-07-18 — 2026-07-20 |
| 003 | replica-sync-refactor | refactor | done | replication, net | 2026-07-22 — 2026-07-23 |
| 004 | multi-az-placement | feat | abandoned | placement, scheduler | 2026-07-23 |

유지 관리 규칙:

스테이지 생성 시 한 줄 추가, 상태는 draft
스테이지 봉인 시 상태를 done으로 업데이트
스테이지 상태가 abandoned, superseded 또는 split으로 변경될 때 동기화하여 업데이트
관련 모듈은 영향을 받는 최상위 모듈/디렉토리를 나열하여 모듈별 검색을 용이하게 함

상태 모델

상태	의미	사용 시기
`draft`	스켈레톤이 생성되었고 구현이 아직 시작되지 않음	스테이지 생성 후
`in-progress`	구현 중	구현 기간 (선택적 사용)
`done`	계획대로 완료, 봉인됨	모든 작업 완료, 검증 통과, 학습 요약 작성됨
`abandoned`	중도 포기	방향 오류, 요구사항 취소, 더 높은 우선순위로 인해 중단
`superseded`	다른 스테이지로 대체됨	스테이지-B의 범위가 스테이지-A를 흡수
`split`	여러 개의 더 작은 스테이지로 분할됨	스테이지가 너무 커서 독립적인 하위 스테이지로 분할

abandoned 처리:

MISSION 섹션 업데이트: "포기 이유" 단락 추가
ADR 테이블에 최소 1개 유지: "왜 계속하지 않는지" 기록
학습 요약은 정상적으로 작성 — 포기의 교훈은 성공보다 더 가치 있는 경우가 많음
포기된 스테이지에서 이미 완료된 코드/문서의 롤백 여부는 의사 결정자가 결정하고 ADR에 기록
연관 섹션의 "다음 계획"을 "없음 (포기됨)"으로 변경

superseded 처리:

MISSION 섹션 업데이트: "어느 스테이지에 의해 대체되었는지 및 이유" 단락 추가
연관 섹션에 "대체됨: STAGE-XXX" 추가
상태를 superseded로 변경
대체된 스테이지에 증분을 추가하지 않음 — 모든 후속 작업은 이를 대체하는 스테이지로 이전

split 처리:

MISSION 섹션 업데이트: "어떤 하위 스테이지로 분할되었는지 및 이유" 단락 추가
연관 섹션에 "분할됨: STAGE-XXX, STAGE-YYY" 추가
상태를 split으로 변경
원래 스테이지에 증분을 추가하지 않음 — 모든 작업은 하위 스테이지로 이전

디렉토리 구조

stages/
  INDEX.md                      ← 인덱스, 각 스테이지당 한 행
  001-raft-election-optimization/
    STAGE.md                    ← 스테이지 연결 문서
    MISSION.md                  ← 상세 목표 설명 (선택 사항, 복잡한 프로젝트 권장)
    spec/                       ← 사전: 기능 명세
    design/                     ← 사전: 프로토콜 계약, 데이터 레이아웃
    tasks/
      plan.md                   ← 구현 계획
      todo.md                   ← 작업 목록
    task-contract/              ← 위임 실행 경계, tasks/spec과 동일 레벨
      TASK-001.md
      TASK-002.md
    docs/
      protocol/                 ← 사후: 프로토콜 문서, RPC 인터페이스
      adr/                      ← 사후: 아키텍처 결정 기록 (필수)
    verify/                     ← 검증 증거
      fault-injection-report.md
      consistency-check.txt
      perf-before-after.json
  002-wal-checksum/
    ...
    ...

Task Contract의 소속 경로를 제외하고 디렉토리 구조는 권장 패러다임입니다. 핵심 제약 조건은: STAGE.md가 반드시 존재해야 함, 각 스테이지는 최소 1개의 ADR을 포함해야 함. Task Contract가 존재하는 경우, 해당 스테이지의 task-contract/ 아래에 위치해야 하며 STAGE.md에서 순방향 인덱싱해야 합니다.

다른 스킬과의 상호작용

스킬	상호작용 방식
spec-driven-development	스테이지의 MISSION은 spec의 Objective에서 추출
planning-and-task-breakdown	`/plan` 출력 후 Agent가 스테이지 스켈레톤 생성 여부 묻기
delegated-task-contract	Contract를 현재 스테이지의 `task-contract/`에 저장; `STAGE.md`가 그 상태, 편차 및 증거를 단방향 인덱싱, Contract는 스테이지를 역방향 인덱싱하지 않음
api-and-interface-design	사전 문서의 프로토콜 계약(gRPC/protobuf)과 사후 문서의 인터페이스 문서 모두 스테이지에 링크
failure-injection-testing	내결함성 및 장애 복구와 관련된 경우 장애 주입 계획 및 카오스 실험 보고서를 스테이지 사후 문서에 링크
consistency-and-durability-verification	스토리지 또는 상태 복제와 관련된 경우 일관성/내구성 검증 보고서를 스테이지 검증 결과에 링크
에이전트 네이티브 구현 흐름	모든 작업 완료 및 검증 후 Agent가 스테이지 봉인 알림
documentation-and-adrs	ADR은 스테이지의 필수 산출물; 각 스테이지 최소 1개
shipping-and-launch	`/ship`이 스테이지 존재 여부 확인 (이번에 생성된 경우 차단)

일반적인 합리화 변명

합리화 변명	현실
"이번 변경이 너무 작아서 스테이지가 필요 없어요"	변경이 스테이지가 필요 없을 정도로 작다면 ADR도 필요 없을 수 있습니다. 하지만 사용자가 이미 스테이지 생성을 결정했습니다 — 사용자의 판단을 신뢰하세요.
"요구사항이 너무 간단해서 사전과 사후에 차이가 없을 거예요"	차이는 어디에나 있습니다 — 가장 간단한 변경조차도 구현 중 계획에서 벗어날 수 있습니다. 스테이지의 핵심 가치는 바로 이러한 차이를 기록하는 데 있습니다.
"일단 코드를 작성하고, 스테이지는 나중에 채울게요"	봉인 전 스테이지는 살아있는 디렉토리이며 한 번에 다 채울 필요가 없습니다. 하지만 사후에 작성한다는 것은 차이 분석이 기억에 의존한다는 것을 의미합니다 — 기억은 신뢰할 수 없습니다.
"이건 ADR이 필요 없어요"	모든 스테이지에는 기록할 가치가 있는 결정이 최소한 하나는 있습니다 — 심지어 "현재 제약 조건이 더 복잡한 방안을 허용하지 않기 때문에 가장 간단한 구현 방식을 선택했습니다"라도.
"이미 `abandoned`인데 학습 요약이 무슨 의미가 있나요?"	포기의 교훈은 성공보다 더 가치 있는 경우가 많습니다. "왜 포기했는지"를 기록하는 것은 "왜 성공했는지"를 기록하는 것만큼 중요합니다.
"차이 테이블에 '아니요'라고 표시하면 충분하고 설명은 필요 없어요"	차이 테이블의 각 행은 미래 결정의 입력값입니다. '아니요'로 표시된 행은 다음 담당자에게 "여기에 기술 부채가 있으며 의도적으로 남겨졌습니다"라고 알려줍니다.
"INDEX.md는 나중에 채우면 돼요"	INDEX.md의 가치는 스테이지 수가 증가함에 따라 커집니다 — 첫 번째 스테이지에서는 필요성을 느끼지 못하지만, 열 번째가 되면 필수품이 됩니다. 처음부터 유지 관리하세요.

레드 플래그 경고

STAGE.md가 생성되었지만 MISSION이 비어 있음 — 스켈레톤의 가치는 MISSION에 있으며, 목표 없는 스테이지는 단지 자리 표시자일 뿐임
사후 문서에 API 문서는 있지만 해당 ADR이 없음 — "각 스테이지 최소 1개 ADR" 규칙 위반
차이 테이블이 비어 있지만 사용자가 구현 중 편차에 대해 언급한 경우 — 차이가 포착되지 않음
학습 요약이 "없음" 또는 "모든 것이 순조로웠음" — 모든 스테이지에는 교훈이 있으며, 찾지 못했다는 것은 충분히 깊이 반성하지 않았다는 의미
abandoned 스테이지에 "포기 이유"가 없음 — 가장 가치 있는 정보를 잃어버림
INDEX.md의 특정 행이 오랫동안 draft 상태 — 구현을 진행하거나 abandoned로 표시하고, 스켈레톤을 썩게 두지 마세요
증분 섹션이 누적 3개 이상이지만 새 스테이지 분할을 고려하지 않음 — 이번 범위 판단에 오류가 있었음을 의미, 계속 추가하기보다 반성해야 함
의사 결정자 필드가 비어 있음 — 다중 협업 시 결정 추적 체인이 끊어질 수 있음
task-contract/에 STAGE.md에서 인덱싱되지 않은 파일이 있거나, 인덱스 링크가 존재하지 않는 Contract를 가리키는 경우
Contract 상태, deviation 또는 evidence가 변경되었지만 스테이지 테이블에 이전 요약이 그대로 남아 있는 경우
Contract가 STAGE.md를 역방향 링크하여 소속 관계가 양방향으로 유지되는 경우
DRAFT, READY 또는 BLOCKED_BY_ARCHITECTURE Contract가 아직 존재하는데 스테이지를 done으로 표시한 경우

검증

스테이지 스켈레톤 생성 후:

stages/<stage-id>/STAGE.md 존재
스테이지 유형 (feat | opt | debug | refactor) 작성됨
상태가 draft
의사 결정자 작성됨
MISSION 작성됨 (유형에 따라 표준 형식 또는 debug 형식)
구현 계획 링크가 tasks/plan.md 및 tasks/todo.md를 가리킴
"Task Contracts (위임 실행 경계)" 섹션 및 빈 순방향 인덱스 테이블 생성됨
stages/INDEX.md에 해당 행 추가됨

스테이지 봉인 후:

13eholder/zflow

zflow란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서

스테이지 (Stage)

개요

사용 시기

스테이지 유형

스테이지 생명주기

생성 (스켈레톤 단계)

채우기 (구축 단계)

봉인 (완료 후)

확인 (출시 전)

스테이지 템플릿

증분 (봉인 후 추가)

INDEX.md

상태 모델

디렉토리 구조

다른 스킬과의 상호작용

일반적인 합리화 변명

레드 플래그 경고

검증

관련 스킬

steipete/gemini

steipete/gh-issues

steipete/skill-creator

steipete/clawhub

steipete/coding-agent

steipete/mcporter