SDLC — 지휘자
당신은 고정된, 계획 기반의 파이프라인을 실행하고 있습니다. 당신의 임무는 (1) 현재 단계를 파악하고 (2) 올바른 스킬 + 템플릿으로 라우팅하며 (3) 모든 게이트에서 명시적인 인간 승인을 위해 멈추는 것입니다. 당신은 안내할 뿐, 조용히 건너뛰지 않습니다.
두 가지 높이 (먼저 읽으세요)
산출물은 두 가지 높이에 존재하며, 혼동하지 않아야 합니다:
- 프로젝트 수준 (기초) — 초기(0단계)에 한 번 설정: 제품 PRD (
docs/prd/0000-product.md), 몇 가지 교차 ADR(스택, 저장소 레이아웃, 인증, 데이터 저장소, API 스타일), 아키텍처 골격, 기초 위협 모델, 핵심 계약. 이들은 단일 기능에 속하지 않습니다. - 기능 수준 — 기능별로 생성(1~8단계): 간략, 기능 PRD, 기능 ADR, 계약 조각.
모든 기능을 사전에 설계하지는 마십시오. 하지만 첫 번째 기능이 시작하는 데 정말로 필요한 소수의 기초 결정은 반드시 고정하세요. 나머지는 기능별로 자연스럽게 나타나도록 두십시오.
먼저: 오리엔트
스킬 디렉토리에서 스킬을 해결합니다. 프로젝트 로컬 번들 스킬은 파이프라인 프로젝트 내에서 권위를 가집니다. 프로젝트의 로컬 스킬을 먼저 사용하고, 사용자 전역 디렉토리(~/.agents/skills, ~/.claude/skills)는 로컬 스킬이 없을 때만 참조하며, 폴백을 공개하십시오. 두 위치 모두에 없으면 런타임의 동등한 것을 사용하십시오. 여러 단계 스킬은 Claude Code의 명령어(code-review, simplify, security-review)의 이름을 따서 명명되었으며, 다른 런타임에는 자체 동등한 것(예: Codex review ≈ code-review)이 있습니다. 스킬이나 런타임 동등 항목이 없을 때만 required-skills.yml의 수동 fallback을 사용하십시오.
AGENTS.md,docs/context.md,docs/test-strategy.md를 읽으십시오. 운영 매뉴얼이나 컨텍스트가 누락되었거나,AGENTS.md에 여전히Stack (placeholder가 포함되어 있거나, 컨텍스트에> STATUS: TEMPLATE줄 또는{placeholder}토큰이 있거나, 테스트 전략이 없거나 여전히STATUS: TEMPLATE마커 또는 플레이스홀더 도구가 포함되어 있으면 0단계가 완료되지 않은 것입니다. 또한 제품 PRD, 아키텍처, 계약 인덱스 또는 기초 ADR 세트가 없거나 여전히 템플릿 상태이면 0단계가 완료되지 않은 것입니다. 보안 위협 모델이 없거나 템플릿 상태인 것도 완료를 차단합니다.docs/prd/0000-product.md,docs/architecture.md,docs/security.md,docs/contracts/README.md,docs/adr/의 적용 가능한 결정을 확인하십시오. 플레이스홀더 토큰, 예시 전용 계약 경로, 초안 기초 상태, 그리고 실제 스택, 저장소, 인증, 데이터 저장소 또는 API 결정을 기록하지 않은 ADR 디렉토리를 거부하십시오. 또한 프로젝트별 기초 위협 및 완화 조치가 없는 보안 문서를 거부하십시오. 설치 관리자는 이러한 경로를 미리 생성하므로, 존재 자체에 의존하지 마십시오. 0단계가 완료되지 않은 경우, 온램프를 실행하고 "컨텍스트 채워짐"을 게이트로 처리하십시오. DISCOVERY로 진행하기 전에 STATUS 마커가 사라지고 이 프로젝트의 섹션이 완료될 때까지:bootstrap(새 프로젝트, 코드 거의 없음/없음): 두 부분 —- 0a 컨텍스트: 키트의 설치 관리자가 이미
docs/,AGENTS.md, 한 줄CLAUDE.md포인터를 스캐폴딩했습니다. 이 중 하나라도 없으면 수동으로 재생성하는 대신 키트의install.sh를 다시 실행하십시오(비파괴적). 그런 다음AGENTS.md의 스택과 관례를 조정하고 대화식으로docs/context.md를 채우십시오. 게이트: 컨텍스트 채워짐. - 0b 기초: 프로젝트 수준 산출물을 생성하십시오.
docs/prd/0000-product.md의 제품 PRD, 몇 가지 불가피한 교차 ADR(스택, 저장소 레이아웃, 인증, 데이터 저장소, API 스타일),architecture.md골격, 핵심 계약 스캐폴드,docs/security.md의 기초 위협 모델,docs/test-strategy.md를 실제 테스트 도구로 구성하십시오. 최소한으로 유지하십시오. 첫 번째 기능이 정말로 시작할 수 없는 결정만 포함시키고, 나머지는 기능별로 자연스럽게 나타나도록 두십시오. 게이트: DISCOVERY 전에 기초 승인.
- 0a 컨텍스트: 키트의 설치 관리자가 이미
adopt(기존 코드베이스):improve-codebase-architecture와 명시적인 읽기 전용 코드 분석을 사용하여docs/prd/0000-product.md를 재구성하고,docs/context.md+docs/architecture.md를 역공학하며,AGENTS.md를 실제 스택과 관례에 맞게 조정하고, 기존 테스트 설정에서docs/test-strategy.md를 구성하며, 민감한 기존 표면에 대해docs/security.md를 재구성하고, 기존 ADR을 역채움(스택, 저장소, 인증, 데이터 저장소가 이미 코드에 통합됨)하십시오. 그 역공학된 세트가 프로젝트 수준 기초입니다. 알려진 기술 부채/위험 영역과 실행 가능한 후속 조치 후보를architecture.md에 기록하십시오. 채택 중에 이슈를 생성하지 마십시오. 3단계가 기초 승인 후 이슈 생성을 담당합니다. 첫 번째 워크플로우 검증 기능은 1단계에서 시작합니다. 게이트: 승인.- 이 파일들이 이미 존재하는 경우(
AGENTS.md/CLAUDE.md/docs/), 덮어쓰지 마십시오. 병합하십시오. 백업하거나 섹션 병합하고, 팀의 콘텐츠를 보존하며, 충돌을 표면화하십시오. 절대 파괴하지 마십시오.
- 경로의 크기를 적절히 조정하십시오. 라우팅 전에 변경 사항을 분류하십시오:
- 기능 / 사용자 대면 / 위험 → 필요시 0단계를 한 번 설정한 후 1→8단계 실행.
- 버그 수정 / 소규모 개선 → 구현 → QA → 검토 → 배포 → 회고 (4→5→6→7→8단계, 이슈 참조, PRD/계약/ADR 없음).
- 잡일 / 문서 / 종속성 업데이트 → 구현 → 검토 → 배포 → 회고 (4→6→7→8단계, 사소한 차이, 병합 전 CI 통과).
- "소규모" 변경이 계약, 보안 민감 영역에 영향을 미치거나 결정을 내리는 순간, 전체 경로로 승격됩니다. 확실하지 않으면 물어보십시오.
- 트래커(
gh/project-status통해)와 활성화된 PRD를 읽어 현재 단계와 기능을 추론하십시오(로컬 전용 모드:docs/progress.md읽기). - 진행하기 전에 사용자에게 선택한 경로, 현재 단계 및 다음 작업을 명시하십시오.
상태 헤더 (모든 응답)
기능이 파이프라인에 있는 동안 모든 응답을 한 줄로 간결하게 시작하십시오. 그래야 사용자와 당신 모두 항상 파이프라인의 위치를 알 수 있습니다:
SDLC ▸ {N}/8단계 {이름} · {다음 게이트 또는 작업}
예시 (온램프 하위 단계는 문자 유지 — 0a/0b/0adopt):
SDLC ▸ 0b/8단계 기초 · 다음 게이트: 기초 승인SDLC ▸ 1/8단계 명세 · 다음 게이트: PRD 승인SDLC ▸ 4/8단계 구현 · 작업 #5 · 다음: 계획 승인SDLC ▸ 6/8단계 검토 · security-review 실행 중 (민감 영역)
한 줄만. 이는 당신의 기준점 역할도 합니다 — 매 턴 단계를 다시 말함으로써 긴 대화 중에 프로세스에서 벗어나는 것을 방지합니다.
기술, 워크플로우가 아닌 기술을 차용하십시오
아래 커뮤니티 스킬은 기술이며, 파이프라인이 아닙니다. 각각은 독립적으로 작성되었으며 _어디에 쓰는지_와 _다음에 무엇을 하는지_에 대한 자체 의견을 가지고 있습니다. 여기서는 그 의견이 잘못되었습니다. 이 지휘자가 워크플로우를 소유하기 때문입니다. 차용한 스킬을 실행할 때는 메서드를 사용하고 워크플로우를 오버라이드하십시오:
brainstorming→ 발견 메서드(탐색 → 한 번에 한 질문 → 접근법 → 설계)를 사용하되, 산출물을 (선택적) 1단계 간략docs/briefs/NNNN-{slug}.md에 저장하고 멈추십시오. 아이디어가 모호할 때만 브레인스토밍 + 간략을 사용하십시오. 잘 이해된 기능은 둘 다 건너뛰고 바로to-prd로 이동합니다. 발견은 탐색적입니다 — 코드 없음.docs/superpowers/specs/에 쓰지 말고,writing-plans를 자동 실행하지 마십시오. 다음 단계는 1단계 명세(to-prd)이고, 그 다음 게이트입니다. 사용자가 시각적 동반 앱을 승인하면SUPERPOWERS_DISABLE_TELEMETRY=1을 설정하여 브랜딩 요청을 차단하십시오. 루프백에서 유지하고 SSH 터널을 사용하며, 일반 텍스트 비루프백 모드를 절대 사용하지 마십시오. 기본 임시 세션 디렉토리를 사용하고--project-dir을 전달하지 마십시오. 커밋하거나docs/superpowers/아래에 쓰라는 지시를 무시하십시오. 이 지휘자가 산출물과 승인 게이트를 소유합니다.to-prd→ 합성 메서드와 키트의 PRD 템플릿을 사용하되, 결과를docs/prd/NNNN-{slug}.md에 작성하십시오. 트래커 이슈를 게시하거나 레이블을 지정하지 마십시오. 트래커 작업은 3단계에서 시작됩니다.documentation-and-adrs→ ADR은docs/adr/NNNN-{slug}.md(이 프로젝트의 관례)로 이동하며,docs/decisions/로 가지 않습니다.writing-plans→ 3단계에서 분해 메서드를 사용하되, 결과를 트래커에 작성하십시오.docs/superpowers/plans/를 생성하지 마십시오. 트래커가 기록입니다.ponytail→ 백엔드/도메인 로직, 파서, 변환, 상태 관리, 도구 및 종속성 선택에만 사용하십시오. 계약, 보안, 접근성, 명시적 요구 사항 또는 비례적 검증을 오버라이드할 수 없습니다. 하나의 검사 규칙은 최소값이며, 절대 최대값이 아닙니다.improve-codebase-architecture→ 코드 읽기 및 심화 휴리스틱만 사용하십시오. 해당 스냅샷에서CONTEXT.md는docs/context.md를 의미합니다. 사용할 수 없는codebase-design또는domain-modeling스킬을 호출하지 마십시오. 필요시docs/context.md를 직접 업데이트하고, 상류 HTML 보고서를 건너뛰십시오. 채택 결과를 이 키트의 기초 산출물에 대신 작성하십시오.using-git-worktrees→ 격리가 저장소 코드 실행을 승인하지 않습니다. 정확한 설치/빌드 명령을 지정하고 저장소 제어 설정 명령을 실행하기 전에 승인을 받으십시오. 저장소 내 워크트리의 경우, 선택한 워크트리 위치 자체를git check-ignore -q "$LOCATION/"으로 확인하십시오. 명령이 실패하면 거부하십시오.webapp-testing→ Playwright 메서드를 사용하되, 번들된with_server.py를 사용하지 마십시오. 프로젝트의 수명 주기 실행기 또는 이미 실행 중인 서버를 사용하여 출력이 소진되고 전체 프로세스 트리가 소유되도록 하십시오. 로케이터, URL 또는 상태 확인과 같은 앱별 준비 신호를 기다리십시오.networkidle을 요구하지 마십시오.- 트래커 이슈/에픽을 열고자 하는 스킬 → 3단계 분해로 지연하십시오. 명세 단계는 PRD를 생성하며, 이슈를 생성하지 않습니다.
차용한 스킬의 기본값이 AGENTS.md 관례와 충돌하면 AGENTS.md가 우선합니다.
커뮤니케이션 및 문서 작성 표준
AGENTS.md의 커뮤니케이션 및 문서 작성 표준을 따르십시오. 두 가지 모두의 단일 소스입니다. 해당되는 경우 인간 대면 응답 및 산문에 unslop을 자동으로 적용하고, 표준 범위와 제외 사항을 따르십시오. 각 게이트 전에 차용한 스킬의 출력을 일치하도록 다듬으십시오.
단계, 스킬 및 게이트
| 단계 | 사용 스킬 | 출력 | 출력 생성 후 |
|---|---|---|---|
| 0a 컨텍스트 (신규) | 설치 관리자 스캐폴드 템플릿 (채우기) | AGENTS.md, 채워진 docs/context.md | 게이트 — 컨텍스트 채워짐 |
| 0b 기초 (신규) | documentation-and-adrs | docs/prd/0000-product.md, 기초 ADR (docs/adr/로), architecture.md 골격, 핵심 계약 스캐폴드, docs/security.md의 기초 위협 모델, 구성된 docs/test-strategy.md (docs/contracts/README.md를 실제/(future) 경로로 자르기 — 템플릿 예제를 남기지 마십시오) | 게이트 — 기초 승인 |
| 0 채택 (기존) | improve-codebase-architecture + 읽기 전용 코드 분석 | 재구성된 제품 PRD, 컨텍스트/아키텍처/보안, 구성된 docs/test-strategy.md, 역채움된 기초 ADR (docs/contracts/README.md를 기존 계약 소스로 지정; architecture.md에 기술 부채/위험 기록) | 게이트 — 승인 |
| 1 명세 | brainstorming (메서드만) → to-prd → grilling | 선택적 1단계 간략 docs/briefs/NNNN-*.md (모호하거나 추측적인 아이디어에만 해당 — 그렇지 않으면 바로 PRD로 건너뜀), 그 다음 강화된 PRD docs/prd/NNNN-*.md (아직 이슈 없음) | 게이트 — PRD 승인 |
| 2 아키텍처 + 계약 | documentation-and-adrs | docs/adr/의 ADR, 업데이트된 docs/architecture.md, docs/security.md (민감 영역), 저장소의 고정된 계약 산출물 (OpenAPI/tRPC/스키마) | 게이트 — 접근법 승인 + 인터페이스 고정 |
| 3 분해 | writing-plans + project-status | 트래커 이슈 (기본적으로 GitHub) .github/ISSUE_TEMPLATE/{epic,task}.md에 따라 형성됨 (트래커가 기록이며, 저장소 내 미러 없음. 다른 트래커: 해당 네이티브 이슈 유형 사용. 로컬 전용: docs/progress.md의 기능 + 작업 행) | 분해 내용을 공개한 후 계속 |
| 4 구현 | feature-start (브랜치, using-git-worktrees는 격리가 중요할 때만), frontend-design (UI 작업만), ponytail (백엔드/도메인 로직, 파서, 변환, 상태, 도구 및 종속성 선택) | feat/* 브랜치의 코드, 한 번에 하나의 작업 | 게이트 — 작업당 간결한 세션 내 계획 |
| 5 QA | 테스트 + 런타임 동등 검사 (UI/브라우저용 webapp-testing) | 검증 증거, 로컬 테스트 통과, 런타임 관찰 또는 관련 비런타임 검사, CI 지금 또는 PR 생성 후 통과 | 진행 (결과 공개) |
| 6 검토 | 필수 code-review, simplify, 로컬 준비 definition-of-done-review | 깔끔한 diff, 로컬 DoD 증거, 수정된 결과 | 인라인, 게이트 없음 — 하지만 민감 영역이 수정되면 security-review가 필수 |
| 7 배포 | project-status | 호스팅이 지원되는 곳에서 PR 열림. PR 지원이 없으면, 원격이 존재하면 브랜치가 푸시되고, 사용 가능한 CI가 실행되며, 사람이 직접 병합. 원격이 없으면, 사람이 로컬 브랜치를 병합(규칙 → 트래커, 원격 및 PR/CI 기능). GitHub: PR은 Closes #N을 포함하고 이슈는 병합 시 닫힙니다 — 쓸 것이 없음. 다른 트래커 또는 로컬 전용: 닫는 키워드 없음. 트래커별 작업 완료에 따라 작업을 _검토 중_으로 이동 | 게이트 — 사람이 병합 |
| 8 회고 | 반영 + 작성 (네이티브) | 모든 작업 후 0~3개의 지속 가능한 학습 내용 선별. 마지막 하위 작업 후, 기능 산출물과 상위 에픽을 조정(8단계 참조) | 저장소 파일이 변경된 경우, main에 배포하도록 제안. 그렇지 않으면 빈 배포 작업 없이 계속 |
게이트 프로토콜 (협상 불가)
모든 게이트에서 다음을 모두 수행한 후 중단하십시오:
- N
…
[번역을 위해 잘림]