trex-core/.github/skills/change-req/SKILL.md

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

name	description	version	author	license	argument-hint	user-invocable	metadata
change-req	Use when: updating an existing requirement after approval or implementation, running /change-req with a REQ ID or file path, recording a change-request entry before overwriting a REQ, analyzing impacted batches/releases, or deciding whether an Implemented REQ must be downgraded and reverified.	0.8.1	Justin Ko	private	예: req-001 또는 docs/srs/Documentation/req-001_minor-docs.md	true	hermes tags related_skills stage-pilot requirements change-management documentation sdlc draft-req confirm-req draft-batch

Purpose

This skill applies a controlled change to an existing REQ by recording a new change-request entry before editing the requirement body, analyzing downstream delivery impact, and updating status/index state when the prior implementation is no longer valid.

When to use

• /change-req req-001처럼 기존 REQ의 Requirement, Acceptance Criteria, Impacted Area를 수정해야 할 때
• 운영 피드백이나 release feedback에서 기존 REQ 수정 필요가 확인됐을 때
• Implemented 또는 Approved REQ가 더 이상 현재 구현/검증 증거와 맞지 않는지 판단해야 할 때
• docs/srs/index.md의 REQ 상태와 실제 변경 영향 범위를 다시 동기화해야 할 때

Inputs

• 선택 입력
  • REQ-ID prefix
  • REQ 파일 경로
• 변경 요청 근거
  • 사용자 요청
  • release feedback
  • batch verification 또는 implementation 결과
• 대상 REQ 문서
• docs/srs/index.md
• 관련 docs/batches/index.md
• 관련 docs/releases/index.md
• 영향이 의심되는 batch/release 문서들

Core Rules

1. 입력 해석

• prefix 입력이면 docs/srs/**/req-001_*.md 형식으로 찾는다.
• 동일 prefix에 여러 문서가 매칭되면 임의 선택하지 않는다.
• REQ가 Deprecated면 기본적으로 새 변경 요청 대상으로 삼지 않는다. 복구가 필요하면 근거를 먼저 명시한다.

2. 변경 요청 기록 규칙

• 기존 Requirement, Acceptance Criteria, Impacted Area를 덮어쓰기 전에 새 Change Log 항목을 추가한다.
• 새 변경 항목 ID는 CHG-YYYYMMDD-NN 형식을 사용하고 같은 날짜 내에서 순차 증가시킨다.
• 새 항목에는 최소한 아래를 모두 기록한다.
  • Change Summary
  • Intent
  • Acceptance Criteria Delta
  • Impacted Area Delta
  • Delivery Trace Delta
  • Revalidation Impact
  • Validation Plan
• 과거 Change Log 항목은 삭제하거나 덮어쓰지 않는다.

3. 상태 영향 규칙

• 변경이 기존 구현 또는 verification evidence를 무효화하지 않으면 현재 상태를 유지할 수 있다.
• Implemented REQ의 기존 구현/검증 근거가 깨지면 상태를 Approved로 되돌린다.
• 변경이 승인 전제 자체를 다시 검토하게 만들면 상태를 Proposed로 되돌릴 수 있다.
• 상태를 되돌릴 때는 이유를 Revalidation Impact와 Change Log에 함께 남긴다.
• 상태가 바뀌면 docs/srs/index.md의 Register와 Recent Change Log Summary도 함께 갱신한다.

4. 영향 분석 규칙

• 관련 batch가 있으면 어떤 batch planning/design/verification이 다시 검토되어야 하는지 기록한다.
• 관련 release가 있으면 release 문서를 직접 덮어쓰지 말고 영향 범위와 후속 action을 REQ의 Change Log에 남긴다.
• 사람 판단이 필요한 범위 재정의, 우선순위 변경, 정책 변경은 임의 확정하지 않는다.

Execution Procedure

1. 입력에서 대상 REQ 경로를 확정한다.
2. REQ 현재 상태와 최근 Change Log를 읽는다.
3. docs/batches/index.md, docs/releases/index.md, 관련 batch/release 문서를 읽어 현재 delivery trace를 요약한다.
4. 변경 요청 근거를 기존 구현/검증 상태와 비교한다.
5. 새 Change Log 항목을 먼저 추가하고 delta, trace, revalidation impact를 채운다.
6. 그 다음 REQ 본문(Requirement, Acceptance Criteria, Impacted Area, Notes)을 필요한 만큼 수정한다.
7. 상태 유지 또는 상태 되돌림 필요 여부를 결정해 REQ 본문과 docs/srs/index.md를 갱신한다.
8. Recent Change Log Summary에 최신 변경 항목을 반영한다.

Output Expectations

• 대상 REQ 경로
• 새 Change Log 항목 ID
• 변경 요약
• 영향 받는 batch/release 목록
• 재검증 필요 여부
• 상태 유지 또는 상태 되돌림 결과
• docs/srs/index.md 갱신 결과

Common Pitfalls

1. 활성 batch 안에서 계약/필드 순서 같은 외부 계약을 바꾸면서 REQ만 수정하고 delivery 산출물과 baseline 문서를 같이 재정렬하지 않는 실수
   • 예: persistence flat slot 순서, CTSP read/write 슬롯 순서, revision migration 시 기본값 채움 순서 변경.
   • 이런 변경은 change-req 후에 source Discovery, 연결된 Approved REQ들, 현재 batch의 planning/design/implementation/verification, 그리고 CTSP_PROTOCOL/CONFIGURATION/runtime-flows 같은 기준 문서를 같은 변경 묶음으로 갱신해야 한다.
   • verification evidence가 다시 필요해질 수 있으므로, 검증 전에는 batch를 release-candidate로 올리거나 REQ를 Implemented로 확정하지 않는다.

Validation

• Change Log 새 항목이 REQ 본문 수정보다 앞선 시간순 근거로 남았는지 확인한다.
• Acceptance Criteria Delta, Delivery Trace Delta, Revalidation Impact가 모두 채워졌는지 확인한다.
• 상태 되돌림이 필요한 경우 REQ 문서와 docs/srs/index.md 상태가 함께 바뀌었는지 확인한다.
• 관련 batch/release 영향이 Change Log에 누락되지 않았는지 확인한다.