Files
trex-core/.github/skills/run-sdlc/SKILL.md
T
genichinandClaude Opus 4.8 2bb2db1a72 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

105 lines
6.8 KiB
Markdown

---
name: run-sdlc
description: "Use when: orchestrating the next SDLC action from the current 3-phase state, running /run-sdlc with a Discovery, REQ, Batch, or Release ID, resuming from the first incomplete unit in docs/discovery, docs/srs, docs/batches, or docs/releases, or routing a no-history repository to bootstrap-baseline before the first real Discovery."
version: 0.7.0
author: Justin Ko
license: private
argument-hint: "예: dcy-001, bat-001, rel-001, req-001 req-002"
user-invocable: true
metadata:
hermes:
tags: [stage-pilot, orchestration, workflow, execution, sdlc]
related_skills: [bootstrap-baseline, new-discovery, draft-req, draft-batch, run-batch-delivery, draft-release]
---
# Purpose
This skill inspects the current state of Discovery, REQ, Batch, and Release documents and routes work to the next skill-only step in the 3-phase SDLC model.
`docs/project-structure.md`와 `docs/runtime-flows.md`는 별도 governance unit는 아니지만, 이 skill은 다음 단계를 추천할 때 해당 baseline 문서의 존재 여부와 갱신 필요 여부를 함께 확인한다.
# Inputs
- `DISCOVERY_ID`
- `REQ-ID` 목록
- `BAT-ID`
- `REL-ID`
- 관련 문서 경로
- `docs/project-structure.md` (존재하는 경우)
- `docs/runtime-flows.md` (존재하는 경우)
# Core Rules
- 이 skill은 `docs/discovery/`, `docs/srs/`, `docs/batches/`, `docs/releases/`만 active 경로로 사용한다.
- `docs/project-structure.md`와 `docs/runtime-flows.md`는 active routing 대상은 아니지만, 모든 단계에서 참고할 cross-cutting baseline 문서로 취급한다.
- prompt 기반 stage command는 사용하지 않는다.
- `review-*` 단계는 별도 명령으로 두지 않고 대응 `confirm-*` 절차에 흡수된 상태를 전제로 한다.
- 사람 선택이 필요한 경계에서는 자동으로 넘기지 않고 중단한다. 대표적으로 `suggest-batch-reqs` 결과에서 어떤 후보를 채택할지 결정하는 단계가 그렇다.
- 단, 정확히 1개의 `Approved` REQ가 국소적이고 저위험 변경으로 판단되면 `minor-change` fast path로 `draft-batch`를 바로 제안할 수 있다. 이 경로의 batch profile은 `batch-lite`다.
- active unit가 아직 없고 baseline 문서 또는 active index가 비어 있으면, 첫 real Discovery 전에 `bootstrap-baseline`을 우선 추천한다.
# Execution Procedure
## 1. 입력 해석
- 입력이 `dcy-`로 시작하면 Discovery를 기준으로 현재 상태를 확인한다.
- 입력이 `req-` 목록이면 REQ 상태를 읽고 batch 생성 또는 추천 단계로 보낸다.
- 입력이 `bat-`로 시작하면 batch delivery 상태를 확인한다.
- 입력이 `rel-`로 시작하면 release 상태를 확인한다.
- 입력이 없으면 현재 저장소에서 첫 incomplete step을 판정한다.
- 어떤 입력이든 가능하면 `docs/project-structure.md`와 `docs/runtime-flows.md` 존재 여부를 함께 확인한다.
## 1.5 bootstrap baseline routing
- active unit가 없고 `docs/project-structure.md`, `docs/runtime-flows.md`, active index 중 일부라도 비어 있으면 `bootstrap-baseline`을 다음 skill로 제안한다.
- 이 경우 Discovery를 자동 생성하지 않는다.
- baseline 초기화가 끝난 뒤 `new-discovery`를 다음 real Discovery entrypoint로 안내한다.
## 2. Discovery 기준 routing
- Discovery가 아직 `confirmed`가 아니면 `confirm-discovery`를 우선 실행한다.
- Discovery는 confirmed지만 연결된 REQ가 없으면 `draft-req`를 다음 단계로 사용한다.
- `Approved` REQ는 있으나 batch가 없으면 `suggest-batch-reqs`를 실행해 후보를 제시하고, 사용자가 후보를 선택한 뒤 `draft-batch`로 이어 가도록 멈춘다.
- batch가 이미 생성되었고 delivery chain을 한 번에 이어서 진행하려면 `run-batch-delivery`를 직접 entrypoint로 사용할 수 있다.
- baseline 문서 갭이 있으면 상태 요약에 `docs/project-structure.md`와 `docs/runtime-flows.md` 갱신 필요 여부를 함께 기록한다.
## 3. REQ 기준 routing
- `Proposed` REQ면 `confirm-req`를 다음 단계로 사용한다.
- 기존 REQ의 `Requirement`, `Acceptance Criteria`, 구현 전제가 바뀌어 Change Log 기반 변경 관리가 필요하면 `change-req`를 다음 단계로 사용한다.
- `Approved` REQ가 `release-candidate` 또는 `released` batch의 verification evidence와 연결돼 있으면 `confirm-req-implemented`를 다음 단계로 사용한다.
- 단일 `Approved` REQ이고 구조/인터페이스/런타임 영향이 없는 소규모 변경이면 `draft-batch`를 `minor-change -> batch-lite` 경로로 바로 제안한다.
- Approved REQ 묶음이 2개 이상이거나 사람 선택이 필요한 경우 `suggest-batch-reqs` 또는 `draft-batch`로 이어진다.
- baseline 문서 갱신이 REQ에 포함돼 있으면 상태 요약에 이를 반영한다.
## 4. Batch 기준 routing
- `planning.md`가 비어 있거나 draft 수준이면 `draft-batch-planning`
- batch profile이 `standard`이거나 `batch-lite`라도 planning의 `Design Gate`가 `yes`면 `draft-batch-design`
- batch profile이 `batch-lite`이고 `Design Gate`가 `no`면 design 없이 `run-batch-implementation`
- 구현 로그와 코드 변경이 아직 없으면 `run-batch-implementation`
- verification 문서가 없거나 불완전하면 `draft-batch-verification`
- verification evidence가 있지만 release-candidate가 아니면 `confirm-batch-verification`
- batch가 `release-candidate` 또는 `released`이고 포함 REQ 중 `Approved` 상태가 남아 있으면 `confirm-req-implemented`
- batch가 `release-candidate`이고 포함 REQ 구현 상태 동기화까지 끝났으면 `draft-release`
- batch design 또는 verification에 structure/flow 영향이 보이면 baseline 문서 갱신 필요 여부를 상태 요약에 포함한다.
## 5. Release 기준 routing
- release 문서가 draft면 profile(`docs-only` | `tooling` | `app-service`)에 맞는 근거가 채워졌는지 확인한 뒤 `confirm-release`
- `feedback-captured` release에 follow-up 입력이 있으면 `suggest-next-discovery` 또는 `change-req`를 다음 단계 후보로 제안한다.
- release가 confirmed 이후 운영 관찰이 남아 있지 않으면 `capture-release-feedback`
# Output Expectations
- 입력으로 해석한 단위 종류
- 현재 상태 요약
- baseline 문서 상태 (`present` | `missing` | `update-likely-required` | `bootstrap-required`)
- 바로 실행할 다음 skill 1개 또는 추천 후보 목록
- 자동으로 진행하지 않고 멈춘 이유가 있으면 그 사유
# Validation
- 다음 단계가 현재 문서 상태와 모순되지 않는지 확인한다.
- 제안한 다음 skill이 실제 `.stage-pilot/skills/` 아래 존재하는지 확인한다.
- baseline 문서가 필요한 상황에서 상태 요약 또는 추천 사유에 그 정보가 누락되지 않았는지 확인한다.