draft: Reorganize documentation and update prompts

This commit is contained in:
2026-04-13 23:26:54 +09:00
parent 0fcde8b89b
commit e89690b1dd
7 changed files with 128 additions and 283 deletions
@@ -0,0 +1,44 @@
---
description: "Use when: move Approved, Implemented, or Deprecated requirements back to Proposed (or Re-review) with decision checkpoints, conflict candidates, and fallback REQ discovery"
name: "Reopen Requirement Status"
argument-hint: "(선택) REQ-XXX, REQ-XXX; 변경 의도와 범위 설명"
agent: "agent"
model: "GPT-5 (copilot)"
---
다음 입력을 기준으로 지정된 requirement를 재검토 상태로 되돌리는 변경안을 만든다.
입력:
${input}
입력 해석 규칙:
- 입력 형식은 기본적으로 `REQ-XXX, REQ-XXX; 이렇게 이렇게 변경할거야.` 를 따른다.
- `;` 앞은 대상 REQ ID 목록, 뒤는 변경 의도/배경으로 해석한다.
- 구분자는 쉼표/공백을 모두 허용하되, 최종적으로 중복 없는 REQ ID 목록으로 정규화한다.
- 입력에 REQ ID가 없으면 전체 입력을 변경 의도/배경으로 간주한다.
작업 규칙:
- 기준 문서는 `docs/SRS/index.md`, 해당 REQ 파일, [SRS instructions](../../.github/instructions/srs.instructions.md), [Reopen requirement discovery instructions](../../.github/instructions/reopen-requirement-discovery.instructions.md) 다.
- 대상 REQ ID가 명시되지 않으면 `docs/SRS/index.md` Requirement Register와 REQ 파일 제목/Intent/Requirement/Impacted Area를 기반으로 관련 후보를 탐색한다.
- 후보 탐색, 점수화, 신뢰도, 동점 처리, 도메인 키워드 정규화는 [Reopen requirement discovery instructions](../../.github/instructions/reopen-requirement-discovery.instructions.md)를 그대로 따른다.
- REQ 미지정 시 후보는 최대 5개까지 제시하고, 신뢰도(High/Medium/Low)와 근거(키워드/영향 영역)를 함께 제시한다.
- REQ 미지정 시 확정 전에는 상태 변경안을 단정하지 말고, `Immediate Questions`에서 최종 대상 REQ 확인 질문을 먼저 제시한다.
- 사용자가 후보 중 선택하면 선택된 REQ 기준으로 상태 되돌림 변경안을 완성한다.
- 대상 REQ의 현재 상태가 `Approved`, `Implemented`, `Deprecated` 중 하나인지 확인한다.
- 상태 되돌림의 목표 상태는 기본 `Proposed`로 제안한다.
- 팀이 `재검토 상태`를 별도로 운용하면 목표 상태를 `Re-review`(또는 팀 표기)로 제안할 수 있다. 단, 최종 상태값은 사용자 결정 항목으로 분리한다.
- 각 REQ마다 왜 되돌려야 하는지(계약 변경, acceptance criteria 변경, 리스크 발견, 구현 불일치 등) 근거를 1-2줄로 요약한다.
- 변경 전/후 영향으로 충돌 가능성이 있는 REQ 후보를 `docs/SRS/index.md` Requirement Register 기준으로 제시한다.
- 충돌 후보는 다음 기준으로 찾는다: 동일 기능 영역, 동일 인터페이스/API/CLI/데이터 스키마, 같은 모듈/문서 영향 범위, 기존 acceptance criteria 중복/상충.
- 사용자가 결정해야 할 항목을 별도 섹션으로 분리한다.
- 결정 누락 시 즉시 물어야 할 질문을 먼저 제시한다.
- 실제 문서 변경을 수행하는 대신, 바로 적용 가능한 수정안(상태, Change Log, impacted area 재검토 포인트)을 제시한다.
출력 형식:
1. Reopen Decision
2. Immediate Questions (없으면 `없음`)
3. Detected REQ Candidates (REQ 미지정인 경우 필수, 지정된 경우 생략 가능)
4. User Decisions Required
5. Suggested Status Changes (REQ별: `from -> to`)
6. Conflict Candidate REQs (REQ별 후보 ID와 충돌 이유)
7. Suggested REQ Edits (Status, Intent/Requirement/Acceptance Criteria 영향, Change Log 초안)
8. Next Action
@@ -0,0 +1,34 @@
---
description: "Use when: verify one or more REQ IDs are Approved and create or update the matching docs/technical specifications"
name: "Sync Technical Specs"
argument-hint: "Enter REQ IDs, e.g. REQ-011, REQ-007, REQ-012"
agent: "agent"
model: "GPT-5 (copilot)"
---
다음 입력으로 지정된 requirement ID 목록에 대해, 승인 상태를 확인하고 해당하는 `docs/technical/` 문서를 실제로 갱신한다.
입력:
${input}
작업 규칙:
- 입력에서 `REQ-XXX` 목록을 추출한다. 쉼표 또는 공백으로 구분된 여러 ID를 지원한다.
- 먼저 `docs/SRS/index.md`의 `Requirement Register`와 각 REQ 파일의 `Status`를 함께 확인한다.
- 두 곳 모두 `Approved`인 requirement만 기술명세 업데이트 대상으로 포함한다.
- 하나라도 `Approved`가 아니거나 파일을 찾지 못하면 해당 REQ는 blocker로 보고하고, 그 REQ에 대한 technical doc은 수정하지 않는다.
- `docs/technical/index.md`와 각 technical doc 상단의 `Related REQ`를 기준으로 기존 연결 문서를 찾는다.
- 연결 문서가 있으면 현재 승인된 requirement에 맞게 내용을 실제로 업데이트한다.
- 연결 문서가 없으면 `docs/technical/` 아래에 새 문서를 생성하고 `docs/technical/index.md`에 항목을 추가한다.
- 기술 문서는 SRS를 source of truth로 따르며, 외부 계약이나 acceptance criteria를 재정의하지 않는다. 대신 구현 상세(모듈 책임, 파일 위치, 설정/환경값, 런타임 흐름, validation notes, open implementation points)를 정리한다.
- 문서 상단에는 반드시 `- Related REQ: ...`를 유지하거나 추가한다.
- `REQ-011`, `REQ-007`, `REQ-012`는 다음 문서를 우선 후보로 사용한다:
- `REQ-011` → `docs/technical/project-structure-baseline.md`
- `REQ-007` → `docs/technical/python-runtime-and-packaging.md`
- `REQ-012` → `docs/technical/settings-and-env-loading.md`
- `docs/technical/index.md`의 문서 목록과 연관 REQ 표도 문서 생성/연결 변경 사항에 맞게 함께 갱신한다.
- 실제 파일 변경을 수행한 뒤, 변경된 파일과 각 REQ의 승인 확인 결과를 요약한다.
출력 형식:
1. Approval Check
2. Technical Spec Updates
3. Files Changed
4. Remaining Blockers or Notes