Add SDLC governance scaffolding and Claude/GitHub skills

Add CLAUDE.md governance instructions, .claude command definitions, and .github skill/instruction set for the Agile iterative SDLC flow. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-03 08:56:54 +00:00
parent a9f99f90fd
commit 2bb2db1a72
49 changed files with 3519 additions and 0 deletions
@@ -0,0 +1,162 @@
+---
+name: run-batch-delivery
+description: "Use when: orchestrating the full delivery chain for an existing batch, running /run-batch-delivery with a BAT ID, resuming an in-progress batch from the first incomplete delivery stage, or chaining planning, design, implementation, verification drafting, verification approval, and REQ implementation sync for one selected batch."
+version: 0.7.0
+author: Justin Ko
+license: private
+argument-hint: "예: bat-002 또는 docs/batches/bat-002_20260522_visioncfg-32-contract-migration"
+user-invocable: true
+metadata:
+  hermes:
+    tags: [stage-pilot, batch, delivery, orchestration, execution, sdlc]
+    related_skills: [draft-batch-planning, draft-batch-design, run-batch-implementation, draft-batch-verification, confirm-batch-verification, confirm-req-implemented, draft-release]
+---
+
+# Purpose
+
+This skill orchestrates the Delivery phase for one already-created batch by chaining the batch-level skills in order until the batch reaches `release-candidate` and its included REQs are synchronized to `Implemented` where evidence exists.
+
+이 skill은 새 batch를 만들지 않는다. 이미 존재하는 `docs/batches/<BAT_ID>/`를 기준으로 현재 delivery 진행 상태를 읽고, 아래 6단계를 순서대로 이어 붙이는 orchestration entrypoint다.
+
+1. `draft-batch-planning`
+2. `draft-batch-design`
+3. `run-batch-implementation`
+4. `draft-batch-verification`
+5. `confirm-batch-verification`
+6. `confirm-req-implemented`
+
+# When to use
+
+- `/run-batch-delivery bat-002`처럼 특정 batch를 delivery phase 끝까지 밀고 싶을 때
+- 이미 `draft-batch`까지 끝난 batch를 planning/design/implementation/verification/REQ 상태 동기화까지 이어서 처리할 때
+- 기존 batch가 어느 delivery 단계에서 멈췄는지 확인하고, 첫 incomplete stage부터 재개하고 싶을 때
+- 사람이 REQ 묶음을 이미 선택했고 batch도 생성했으므로, 이제 batch 내부 delivery chain만 집중 실행해야 할 때
+
+## Do not use when
+
+- 아직 batch가 생성되지 않았고 포함 REQ 집합 선택도 끝나지 않았을 때 (`suggest-batch-reqs`, `draft-batch`가 더 적절함)
+- 단순히 batch의 planning만 채우거나 design만 보강하려는 단일 단계 작업일 때 (해당 개별 skill이 더 적절함)
+- verification 승인 이후 release 문서까지 자동으로 이어 가고 싶을 때 (`draft-release`는 별도 단계로 남겨 둔다)
+- batch가 아니라 저장소 전체의 다음 SDLC 단계를 판단하려는 상황일 때 (`run-sdlc`가 더 적절함)
+
+# Inputs
+
+- `BAT-ID` prefix 또는 batch 경로
+- `docs/batches/<BAT_ID>/index.md`
+- `docs/batches/<BAT_ID>/planning.md`
+- `docs/batches/<BAT_ID>/design.md` (존재하는 경우)
+- `docs/batches/<BAT_ID>/implementation.md` (존재하는 경우)
+- `docs/batches/<BAT_ID>/verification.md` (존재하는 경우)
+- 포함된 REQ 문서들
+- `docs/batches/index.md`
+- `docs/srs/index.md`
+
+# Core Rules
+
+## 1. 배치 단위 orchestration
+
+- 이 skill은 정확히 하나의 batch를 대상으로 한다.
+- 입력 batch가 유일하게 확정되지 않으면 진행하지 않는다.
+- batch 밖의 다른 REQ나 다른 batch를 임의로 끌어오지 않는다.
+
+## 2. 6단계 delivery chain 유지
+
+- 기본 chain은 아래 순서를 따른다.
+  1. `draft-batch-planning`
+  2. `draft-batch-design`
+  3. `run-batch-implementation`
+  4. `draft-batch-verification`
+  5. `confirm-batch-verification`
+  6. `confirm-req-implemented`
+- 앞 단계 결과가 다음 단계 입력 전제를 만족하지 않으면 그 지점에서 멈추고 blocker를 보고한다.
+- `confirm-batch-verification`과 `confirm-req-implemented`는 승인 게이트이므로 evidence 부족 상태를 억지로 통과시키지 않는다.
+
+## 3. design 생략 규칙
+
+- batch profile이 `batch-lite`이고 planning의 `Design Gate`가 `no`이며 구조/인터페이스/런타임 영향이 실제로 없을 때만 `draft-batch-design`을 생략할 수 있다.
+- 그 외에는 design 단계를 delivery chain에 포함한다.
+- 생략 여부는 planning 문서와 batch index 근거로 설명되어야 한다.
+
+## 4. 중복 실행보다 불완전 단계 우선
+
+- 이미 충분히 채워진 단계는 다시 덮어쓰는 것이 목적이 아니다.
+- 각 단계는 먼저 현재 batch 문서를 읽고, 실제로 비어 있거나 draft 수준인 stage부터 시작한다.
+- 다만 앞 단계 산출물이 뒤 단계 전제를 만족하지 못하면 필요한 범위 내에서 보강할 수 있다.
+
+## 5. 사람 결정과 승인 게이트 존중
+
+- verification evidence가 부족하거나 blocker가 있으면 `confirm-batch-verification`에서 멈춘다.
+- REQ acceptance criteria와 evidence 연결이 불충분하면 `confirm-req-implemented`에서 멈춘다.
+- release 문서 생성과 release 승인까지 자동으로 넘기지 않는다. 이 skill의 종료점은 delivery phase 완료 직전 또는 완료 직후 상태 보고다.
+
+## 6. child skill 규칙 상속
+
+- 이 skill은 하위 skill들을 대체하지 않는다.
+- 각 단계에서는 해당 skill의 prerequisite, validation, blocker 규칙을 그대로 따른다.
+- 특히 baseline 문서(`docs/project-structure.md`, `docs/runtime-flows.md`) 영향 여부는 design/verification 단계 child skill 규칙을 따라 점검한다.
+
+# Execution Procedure
+
+1. 입력에서 `BAT-ID` 또는 batch 경로를 유일하게 확정한다.
+2. batch `index.md`, `planning.md`, `design.md`, `implementation.md`, `verification.md`, 포함 REQ, `docs/batches/index.md`, `docs/srs/index.md`를 읽어 현재 delivery 상태를 요약한다.
+3. 아래 기준으로 첫 incomplete stage를 판정한다.
+   - `planning.md`가 비어 있거나 draft 수준이면 `draft-batch-planning`
+   - design이 필요하지만 `design.md`가 비어 있거나 부족하면 `draft-batch-design`
+   - 구현 로그/변경/검증 기록이 부족하면 `run-batch-implementation`
+   - verification mapping/evidence 초안이 부족하면 `draft-batch-verification`
+   - verification evidence는 있으나 batch가 아직 `release-candidate`가 아니면 `confirm-batch-verification`
+   - batch가 `release-candidate` 또는 `released`인데 포함 REQ 중 `Approved`가 남아 있으면 `confirm-req-implemented`
+4. 첫 incomplete stage부터 시작해, blocker가 생길 때까지 다음 stage로 순차 진행한다.
+5. `draft-batch-planning`이 실행되면 범위, dependency, milestone, Design Gate가 채워졌는지 확인한다.
+6. `draft-batch-design`이 필요하면 architecture summary, changed areas, key decisions, architecture impact가 채워졌는지 확인한다.
+7. `run-batch-implementation` 후에는 구현 변경, execution log, validation, remaining risks가 기록됐는지 확인한다.
+8. `draft-batch-verification` 후에는 REQ acceptance criteria와 evidence mapping, blocking issues, baseline 동기화 evidence가 필요한 경우 그 항목이 채워졌는지 확인한다.
+9. `confirm-batch-verification` 성공 시 batch가 `release-candidate`로 전환됐는지 확인한다. 실패 시 blocker를 보고하고 멈춘다.
+10. `confirm-req-implemented`를 실행해 포함 REQ 중 evidence가 충분한 항목만 `Implemented`로 동기화한다. 부족한 항목은 blocker와 함께 남긴다.
+11. delivery chain 종료 후 결과를 아래 중 하나로 보고한다.
+    - `Stopped at <stage>` + blocker
+    - `Delivery chain complete through REQ sync`
+12. delivery chain이 성공적으로 끝났으면 다음 단계로 `draft-release`를 추천하되, 자동 실행하지는 않는다.
+
+# Output Expectations
+
+- 대상 batch 경로
+- 시작 시점 batch 상태 요약
+- 실제로 실행한 stage 목록
+- 생략한 stage와 생략 근거 (`batch-lite` design 생략 등)
+- 각 stage 결과 요약
+- 중단 지점과 blocker 또는 완료 결과
+- batch 최종 상태 (`draft` | `in-delivery` | `release-candidate` 등)
+- 포함 REQ 중 `Implemented` 전환 성공 목록 / 보류 목록
+- 다음 권장 단계 (`draft-release` 또는 blocker 해소)
+
+# Common Pitfalls
+
+1. `draft-batch` 전 batch를 바로 delivery chain에 넣는 실수
+   - 이 skill은 이미 생성된 batch가 전제다. REQ 묶음 선택이나 batch 생성은 먼저 끝나 있어야 한다.
+
+2. `draft-batch-verification`을 건너뛰고 바로 `confirm-batch-verification`으로 가는 실수
+   - verification 초안과 evidence mapping이 먼저 있어야 approval gate를 제대로 통과시킬 수 있다.
+
+3. `batch-lite`라는 이유만으로 design을 자동 생략하는 실수
+   - planning의 `Design Gate`가 `no`여야 하고 실제 구조 영향도 없어야 한다.
+
+4. verification blocker가 있는데도 REQ를 `Implemented`로 올리는 실수
+   - `confirm-req-implemented`는 batch verification evidence를 근거로 해야 하므로 blocker가 남아 있으면 보류해야 한다.
+
+5. child skill이 이미 만든 문서를 읽지 않고 매번 처음부터 다시 쓰는 실수
+   - 현재 batch 문서를 먼저 읽고, 첫 incomplete stage부터 이어 가야 한다.
+
+6. release까지 자동으로 계속 진행하는 실수
+   - 이 skill의 역할은 delivery chain orchestration이다. release 문서 생성/승인은 별도 stage다.
+
+# Verification Checklist
+
+- [ ] 대상 batch가 유일하게 확정되었다.
+- [ ] batch 생성 단계가 이미 완료된 상태다.
+- [ ] planning -> design -> implementation -> verification drafting -> verification approval -> REQ sync 순서가 유지되었다.
+- [ ] `batch-lite` design 생략은 `Design Gate`와 실제 영향 근거로 설명된다.
+- [ ] `confirm-batch-verification`은 blocker 없는 evidence 상태에서만 통과했다.
+- [ ] `confirm-req-implemented`는 evidence가 연결된 REQ만 전환했다.
+- [ ] stage별 실행 결과와 중단/완료 상태가 보고되었다.
+- [ ] release 단계는 자동으로 진행하지 않고 별도 추천으로 남겼다.