Squashed '.vendor/myagent-kit/' content from commit 96defc9

git-subtree-dir: .vendor/myagent-kit git-subtree-split: 96defc92f92d617a80f7b0f54e998ce4c25f631b
2026-04-13 23:25:23 +09:00
commit acd1bab8f2
19 changed files with 1058 additions and 0 deletions
@@ -0,0 +1,26 @@
+---
+description: "Use when: decide whether a Proposed requirement is ready to move to Approved and generate the required status-change edits"
+name: "Approve Requirement"
+argument-hint: "Paste a Proposed REQ file or select requirement text"
+agent: "agent"
+model: "GPT-5 (copilot)"
+---
+다음 requirement 문서가 `Proposed`에서 `Approved`로 전환 가능한지 검토한다.
+
+입력:
+${input}
+
+검토 규칙:
+- 기준 문서는 [SRS index](../../docs/SRS/index.md) 의 `Status Transition Evidence`와 해당 requirement 문서 구조다.
+- `Status`, `Type`, `Priority`, `Owner`, `Intent`, `Requirement`, `Acceptance Criteria`, `Impacted Area`, `Change Log` 존재 여부를 검토한다.
+- Type이 SRS index의 분류 도표에 정의된 타입 중 정확하게 하나로 지정되었는지 확인한다.
+- `Acceptance Criteria`가 구현 기준으로 충분히 구체적인지 판단한다.
+- 중요한 assumption 또는 open question이 남아 있으면 승인 blocker로 본다.
+- 승인 가능하면 status 변경과 Change Log 추가 초안을 함께 제안한다.
+- 승인 불가하면 blocker를 우선순위 순으로 정리한다.
+
+출력 형식:
+1. Approval Decision: `Approved-ready` 또는 `Not ready`
+2. Blockers
+3. Suggested Edits
+4. Approval Change Log Draft
@@ -0,0 +1,32 @@
+---
+description: "Use when: complete a partial SRS requirement draft into a full REQ file with acceptance criteria and impacted area"
+name: "Complete Requirement Draft"
+argument-hint: "Paste a partial requirement draft or describe the feature"
+agent: "agent"
+model: "GPT-5 (copilot)"
+---
+다음 입력을 기반으로 SRS requirement 초안을 완성한다.
+
+입력:
+${input}
+
+작업 규칙:
+- SRS 기준 문서는 [SRS index](../../docs/SRS/index.md) 와 관련 [REQ template](../../docs/SRS/REQ-template.md) 를 따른다.
+- 입력에 `REQ-XXX` 형식의 명시적 ID가 없으면, [SRS index](../../docs/SRS/index.md)의 `Next Requirement ID`를 우선 읽어 그 값을 사용한다. `Next Requirement ID`가 없거나 신뢰할 수 없으면 `Requirement Register`와 기존 REQ 파일들 기준의 최고 번호에 1을 더한 값을 사용한다.
+- 사용자가 이미 특정 REQ ID를 명시했으면 그 ID를 유지하고 임의로 바꾸지 않는다.
+- requirement의 유형을 인식하고 `Type` 필드를 정확하게 지정한다. 분류는 [SRS index](../../docs/SRS/index.md)의 "Requirement 작성 규칙" 또는 [SRS instructions](../../.github/instructions/srs.instructions.md)의 "분류 의사결정 규칙"을 따른다.
+- 최종 `Type`과 `REQ ID`를 이용해 추천 파일 경로를 함께 제시한다. 형식은 `docs/SRS/<Type>/REQ-XXX_<slug>.md`를 사용한다.
+- `<slug>`는 requirement 제목을 기반으로 소문자 kebab-case 영문으로 생성한다. 공백은 `-`로 치환하고, 영문/숫자/`-`만 남긴다.
+- 제목이 한글이거나 slug 생성이 불명확하면 의미를 유지하는 짧은 영문 slug를 보수적으로 제안한다.
+- 사용자가 제공한 의도와 핵심 동작을 보존한다.
+- 빠진 항목은 보수적으로 보완하되, 추정이 필요한 내용은 `Notes`에 assumption으로 분리한다.
+- `Acceptance Criteria`는 반드시 test 가능하게 작성한다.
+- `Impacted Area`는 Docs, Modules, Tests로 구분한다.
+- 새로 할당한 ID를 문서 제목 `# REQ-XXX: ...`에 반영한다.
+- 결과는 REQ 파일에 바로 붙여넣을 수 있는 Markdown 형식으로만 출력한다.
+- 코드 구현 계획은 포함하지 않는다.
+
+출력 형식:
+1. `Recommended File Path: docs/SRS/<Type>/REQ-XXX_<slug>.md` 한 줄
+2. 실제 할당된 ID가 반영된 `# REQ-XXX: ...` 형식의 전체 문서 본문
+3. `## Change Log` 아래에 초안 생성용 `CHG-YYYYMMDD-01` 항목 1개 포함
@@ -0,0 +1,42 @@
+---
+description: "Use when: create an implementation plan and GitHub issue draft from an Approved requirement"
+name: "Create Implementation Issue"
+argument-hint: "Paste an Approved REQ file"
+agent: "agent"
+model: "GPT-5 (copilot)"
+---
+다음 `Approved` requirement 문서를 기반으로 implementation issue 초안을 생성한다.
+
+입력:
+${input}
+
+작업 규칙:
+- 기준 문서는 [SRS index](../../docs/SRS/index.md) 와 해당 REQ 문서다.
+- 출력 언어는 기본적으로 한국어로 작성한다.
+- section 제목, 설명, 작업 지시문은 한국어를 우선 사용하되, 중요한 technical term는 영어를 유지하거나 한국어 뒤 괄호로 병기한다. 예: `AI Agent Work`, `Human Verification Checklist`, `Acceptance Criteria`, `Open Questions`, `Risk`, `Definition of Done`.
+- 코드 식별자, 파일 경로, 명령어, API 이름, 테스트 이름, UI 라벨 등 구현 대상과 직접 연결되는 literal은 영어 원문을 유지한다.
+- requirement의 `Acceptance Criteria`를 구현 task로 분해한다.
+- task는 구현 단위로 나누고, 각 task를 `AI Agent가 완료 가능한 작업`과 `Human이 수행해야 하는 작업`으로 구분한다.
+- test task를 반드시 포함한다.
+- 각 acceptance criteria 또는 task에 대해 다음을 판단한다:
+	- AI Agent가 코드 변경과 자동 검증까지 완료할 수 있는가
+	- Human이 직접 확인해야 하는 수동 검증이 남는가
+- Human이 직접 확인해야 하는 항목이 있으면 `Human Verification Checklist`에 구체적인 확인 절차와 기대 결과를 작성한다.
+- AI Agent가 자체적으로 테스트를 완료할 수 있어 Human 확인이 불필요하면 `Human Verification Checklist`에 `No manual verification required.`를 명시하고 그 근거를 `AI Validation Summary`에 적는다.
+- `Impacted Area`를 기반으로 module/docs/test 변경 범위를 제시한다.
+- 미해결 가정이나 리스크가 있으면 issue 본문에 `Open Questions`와 `Risks`로 명시한다.
+- 출력은 GitHub issue에 바로 붙여 넣을 수 있는 Markdown 형식으로만 작성한다.
+
+출력 형식:
+1. Issue Title
+2. 배경 (Context)
+3. 범위 (Scope)
+4. AI Agent 작업 (AI Agent Work) 체크리스트
+5. 사람 작업 (Human Work) 체크리스트
+6. Acceptance Criteria Mapping (REQ 기준)
+7. AI 검증 요약 (AI Validation Summary)
+8. 사람 확인 체크리스트 (Human Verification Checklist)
+9. 열린 질문 (Open Questions)
+10. 리스크 (Risks)
+11. 완료 조건 (Definition of Done)
+12. GitHub Issue Create Command (`gh issue create`) 예시
@@ -0,0 +1,38 @@
+---
+description: "Use when: evaluate whether a new feature or change request needs a new SRS requirement, an update to an existing one, a technical spec update only, or owner decision — before starting requirement drafting"
+name: "Decide Requirement Scope"
+argument-hint: "Describe the feature or change request: include feature description, issue body, and/or PR/diff summary"
+agent: "agent"
+model: "GPT-5 (copilot)"
+---
+다음 입력을 기반으로, 이 변경이 SRS 대상인지 아닌지를 판정한다.
+
+입력:
+${input}
+
+판정 규칙:
+- 기준 문서는 [requirement-scope-decision instructions](../../.github/instructions/requirement-scope-decision.instructions.md) 와 [SRS index](../../docs/SRS/index.md) 의 Requirement Register다.
+- 다음 4가지 결과 중 하나를 반드시 반환한다.
+  1. `New SRS requirement needed`
+  2. `Update existing SRS requirement`
+  3. `Technical spec only`
+  4. `Needs owner decision`
+- 판정 기준을 순서대로 적용한다.
+  - 사용자/외부 시스템이 관찰하는 계약(API, CLI, UI, Event, Data schema, Config, Deployment, Integration)이 바뀌는가? → YES면 SRS
+  - 측정 가능한 Non-Functional requirement(성능, 보안, 가용성 등)가 추가/변경되는가? → YES면 SRS
+  - Acceptance Criteria 및 명시적 승인 게이트가 필요한가? → YES면 SRS
+  - 위 기준에 모두 해당하지 않으면서 내부 리팩터링·라이브러리 교체·코드 구조 변경·구현 최적화인가? → Technical spec only
+  - 위 기준만으로 분류가 확정되지 않거나 운영 책임/리스크가 불명확한가? → Needs owner decision
+- SRS 대상으로 판정되면, 신규 기능/계약인지 기존 REQ 범위 내 변경인지를 구분한다.
+  - 기존 REQ에 해당하는 경우 [SRS index](../../docs/SRS/index.md) 의 Requirement Register에서 후보 REQ ID를 찾아 제시한다.
+- Technical spec only로 판정되면, 불필요한 REQ 생성을 명시적으로 피하도록 안내한다.
+- 결과에는 항상 `Why`와 `Next Action`을 포함한다.
+- `Open Questions`가 없으면 `없음`으로 명시한다.
+
+출력 형식:
+1. **Decision**: `New SRS requirement needed` / `Update existing SRS requirement` / `Technical spec only` / `Needs owner decision` 중 하나
+2. **Why**: 판정 근거 — 어떤 기준에 해당하는지 구체적으로 설명
+3. **Recommended Type**: (SRS 대상인 경우만) Interface / Data / Deployment / Configuration 등 해당 requirement type
+4. **Existing REQ candidates**: (Update 가능성이 있는 경우만) 관련 REQ ID와 제목 목록. 해당 없으면 생략
+5. **Next Action**: 판정 결과에 따른 다음 단계 안내
+6. **Open Questions**: 추가 확인이 필요한 사항. 없으면 `없음`
@@ -0,0 +1,25 @@
+---
+description: "Use when: decide whether an Approved requirement is ready to move to Implemented and generate the required status-change edits"
+name: "Mark Requirement Implemented"
+argument-hint: "Paste an Approved REQ file and implementation evidence"
+agent: "agent"
+model: "GPT-5 (copilot)"
+---
+다음 requirement 문서와 implementation evidence를 검토해 `Approved`에서 `Implemented`로 전환 가능한지 판단한다.
+
+입력:
+${input}
+
+검토 규칙:
+- 기준 문서는 [SRS index](../../docs/SRS/index.md) 의 `Status Transition Evidence`와 해당 requirement 문서 구조다.
+- requirement의 `Acceptance Criteria`가 implementation evidence, tests, 또는 manual verification으로 충족되었는지 확인한다.
+- 충족되지 않은 acceptance criteria가 있으면 구현 완료로 판정하지 않는다.
+- 구현 완료 가능하면 status 변경, 잔여 리스크, Change Log 추가 초안을 함께 제안한다.
+- 구현 완료 불가하면 미충족 기준과 필요한 검증 항목을 정리한다.
+
+출력 형식:
+1. Implementation Decision: `Implemented-ready` 또는 `Not ready`
+2. Unverified Criteria
+3. Suggested Edits
+4. Implementation Change Log Draft
+5. Residual Risk
@@ -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,28 @@
+---
+description: "Use when: update docs/SRS/index.md Requirement Register or Recent Change Log Summary after adding or editing REQ files"
+name: "Sync SRS Index"
+argument-hint: "Paste changed REQ files or describe what changed in SRS"
+agent: "agent"
+model: "GPT-5 (copilot)"
+---
+다음 입력을 기준으로 `docs/SRS/index.md`를 갱신하기 위한 제안을 만든다.
+
+입력:
+${input}
+
+작업 규칙:
+- 기준 문서는 [SRS index](../../docs/SRS/index.md) 이다.
+- 새 requirement가 추가되었거나 Register가 바뀌면 `Requirement Register`의 최고 번호를 기준으로 다음 번호를 계산해 `Next Requirement ID`도 함께 갱신한다.
+- 새 requirement가 추가되었으면 `Requirement Register`에 들어갈 행을 만든다.
+- 기존 requirement가 수정되었으면 `Recent Change Log Summary`에 들어갈 요약 항목을 만든다.
+- 기존 구조를 바꾸지 말고, 필요한 행과 요약만 제안한다.
+- `Next Requirement ID`는 `Requirement Register`에 있는 가장 큰 REQ 번호보다 정확히 1 큰 값이어야 한다.
+- `Recent Change Log Summary`는 최신 변경을 위에 두고, 짧은 요약 1줄로 작성한다.
+- `Recent Change Log Summary`는 최신 5건만 유지하도록 제안한다. 5건을 초과하면 제거 또는 대체해야 할 가장 오래된 항목도 함께 설명한다.
+- 출력은 사람이 `docs/SRS/index.md`에 바로 반영할 수 있는 Markdown 조각으로만 작성한다.
+
+출력 형식:
+1. `Next Requirement ID`에 반영할 Markdown bullet
+2. `Requirement Register`에 추가 또는 수정할 Markdown table row
+3. `Recent Change Log Summary`에 추가할 Markdown section
+4. 필요한 경우 only, index에서 제거 또는 갱신해야 할 기존 항목 설명
@@ -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
@@ -0,0 +1,24 @@
+---
+description: "Use when: review an SRS requirement for ambiguity, missing acceptance criteria, missing impacted area, and change-log gaps"
+name: "Validate Requirement Quality"
+argument-hint: "Paste a REQ file or select requirement text"
+agent: "agent"
+model: "GPT-5 (copilot)"
+---
+다음 requirement 문서를 검토한다.
+
+입력:
+${input}
+
+검토 규칙:
+- 기준은 [SRS index](../../docs/SRS/index.md) 와 관련 requirement 문서 구조를 따른다.
+- 다음 항목을 우선 검토한다: 모호한 표현, test 불가능한 문장, 누락된 acceptance criteria, 누락된 impacted area, 상태/유형/우선순위/owner 누락, Type이 의사결정 규칙에 따라 정확하게 지정되었는지, Change Log 누락 또는 불일치.
+  - Type 분류 규칙: 사용자 조작 방식 → Interface, 데이터 저장/구조 → Data, 오류 처리 → Exception & Error Handling, 그 외 → Non-Functional
+- 중요한 문제부터 우선순위 순으로 정리한다.
+- 문제가 없으면 `No critical findings.` 로 시작한다.
+- requirement 본문을 직접 다시 작성하지 말고, 수정 제안 위주로 답한다.
+
+출력 형식:
+1. Findings
+2. Open Questions
+3. Suggested Edits