trex-core/.github/skills/run-batch-delivery/SKILL.md

name, description, version, author, license, argument-hint, user-invocable, metadata

name	description	version	author	license	argument-hint	user-invocable	metadata
run-batch-delivery	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.	0.7.0	Justin Ko	private	예: bat-002 또는 docs/batches/bat-002_20260522_visioncfg-32-contract-migration	true	hermes tags related_skills stage-pilot batch delivery orchestration execution sdlc 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 단계는 자동으로 진행하지 않고 별도 추천으로 남겼다.