agent-project-sdlc 0.1.0

package/assets/skills/dev_sprint/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: dev_sprint
+description: Use during SPRINTING to execute one task from plan.yaml, respecting the active plan contract.
+---
+
+# Dev Sprint Skill
+
+## 目的
+
+按当前任务游标执行一个开发任务，控制修改范围，补充测试，记录 gate 证据，并沉淀真实实现文档。
+
+## 角色提示词
+
+你是资深开发者，目标是在当前 task 合同内完成最小、正确、可验证的实现。你需要把 PRD、技术方案、allowed_paths、required_gates 和 acceptance_criteria 当作执行边界，而不是把开发阶段变成重新规划阶段。
+
+开始编码前，先确认当前 open task 是否完整，修改范围是否覆盖必要文件，验收标准是否能被测试或 gate 验证。如果发现任务边界、产品行为或技术方案不清晰，要停下来说明 blocker、给出可能解释和推荐下一步，而不是扩大范围继续写。
+
+实现时遵循小步闭环：先检查 `git status`，确认工作区没有未归属到当前 task 的脏变更；再定位相关代码和测试，做必要修改，运行 gate，修复失败，写 implementation doc 并刷新文档派生视图。此时先不要压缩 `plan.yaml`，要在当前 task 仍保留完整执行合同的状态下创建 task implementation commit；随后再压缩 task，创建 task completion ledger commit，并 push 两个 commit。不要顺手重构、重排格式或处理无关问题；如果发现无关风险，只记录或报告。
+
+## 输入
+
+- `<harnessRoot>/state/lifecycle.yaml`
+- `<harnessRoot>/state/plan.yaml`
+- 当前任务关联的 PRD 和技术方案
+- 当前源码和测试文件
+
+## 输出
+
+- 当前 task `allowed_paths` 范围内的源码改动
+- 当前 task `allowed_paths` 范围内的测试改动
+- `.docs/04_implementation/` 下的 implementation doc
+- `<harnessRoot>/state/gate_results.log` 中的 gate 结果
+- 更新后的 `<harnessRoot>/state/plan.yaml`
+- 更新后的 `.docs/INDEX.md`
+- 保留完整 open task 合同的 task implementation commit
+- 压缩 `plan.yaml` 后的 task completion ledger commit
+- 已 push 到当前 upstream branch 的远端提交
+
+## 语义切片
+
+- `SPRINTING` 阶段的执行单元是 `current_task_id`，不要在开发中重新生成整个 Sprint 计划。
+- 当前任务就是开发阶段的主要语义切片，代码、测试、gate 记录和 implementation doc 都围绕该任务闭环。
+- open task 在 `plan.yaml` 中直接保存 `docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和必要的 `working_notes`。
+- task implementation commit 必须发生在 task 压缩之前，此时 `plan.yaml` 中当前 task 仍保留 `docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和必要 `working_notes`。
+- task completion ledger commit 发生在 implementation commit 之后，只负责将该 task 压缩为 `summary`、`implementation_doc`、`gate_result` 等简短摘要。
+- 一个开发 task 默认对应一个主要 implementation commit 和一个轻量 completion ledger commit。implementation commit message 应包含 task id，例如 `DEV-003: implement login rate limit`；push 成功前，不进入下一个 task。
+- 本 Skill 不直接重切 PRD 或 tech plan；如果发现上游语义边界错误，进入 `BLOCKED`、创建 RFC，或请求回到 `ARCHITECTING`。
+- gate 通过后调用 `implementation_doc`，由该 Skill 按真实实现生成 `.docs/04_implementation/` slice。
+- 如果一个任务实际变成多个独立实现边界，应停止扩大范围，拆分后续任务或回到任务规划。
+
+## Plan Protocol
+
+每个 open task 都必须在 `plan.yaml` 中包含完整执行合同：
+
+1. `current_task_id` 指向正在执行的 open task。
+2. open task 直接声明 `docs`、`allowed_paths`、`required_gates`、`acceptance_criteria`。
+3. 任务执行中只保留恢复所需的简短 `working_notes`。
+4. gate、implementation doc、`.docs/INDEX.md` 和 `overview.md` 完成后，先保持 open task 完整合同不变，创建 task implementation commit。
+5. implementation commit 完成后，再把 task 标记为 `done`，并移除 `docs`、`allowed_paths`、`required_gates`、`acceptance_criteria`、`working_notes`。
+6. 将压缩后的 `plan.yaml` 和必要 gate 记录提交为 task completion ledger commit，并 `git push` 两个 commit 到当前 upstream branch。
+
+## 规则
+
+1. 一次只执行一个任务。
+2. 开始修改前检查 `git status`；如果存在不属于当前 task 的未提交变更，先完成对应 task 的 commit/push，或报告 blocker，不要混入当前 task。
+3. 只编辑当前 task 的 `allowed_paths` 允许的文件，以及 `SPRINTING` 阶段允许的 Harness 记账文件。
+4. 必须运行当前 task 的 `required_gates`。
+5. 如果 gate 因代码或测试逻辑失败，在任务范围内修复。
+6. 如果 gate 因基础设施、凭证缺失、产品行为不清或高风险架构变化失败，进入 `BLOCKED`。
+7. gate 通过后调用 `implementation_doc`。
+8. 只有 gate 通过且 implementation doc 校验通过后，才能把任务标记为 `done`。
+9. 任务完成并写入 implementation doc、刷新 `overview.md`、记录 gate 后，先创建 task implementation commit；此时不要压缩该 task。
+10. task implementation commit 必须包含未压缩的 open task 合同，确保 git history 能看到当时的 `allowed_paths`、`required_gates` 和 `acceptance_criteria`。
+11. implementation commit 完成后，压缩该 task，只保留简短摘要和 gate 结果，并创建 task completion ledger commit。
+12. 两个 commit 后必须 `git push` 到当前 upstream branch；如果没有 remote/upstream、权限或凭证导致无法 push，停止推进并报告 blocker。
+
+## 完成检查
+
+- [ ] 代码和测试改动都在当前 task `allowed_paths` 范围内。
+- [ ] 当前 task `required_gates` 已通过，或 blocker 已记录。
+- [ ] open task 在 `plan.yaml` 中包含完整执行合同。
+- [ ] 当前任务仍然是单一清晰的开发语义切片。
+- [ ] implementation doc 已生成并反映真实代码。
+- [ ] 任务状态和 gate 结果已更新。
+- [ ] task implementation commit 已在 task 压缩前创建，且包含完整 open task 合同。
+- [ ] done task 已在 implementation commit 之后压缩为简短摘要。
+- [ ] `.docs/INDEX.md` 已链接 implementation doc。
+- [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。
+- [ ] 已创建 task completion ledger commit。
+- [ ] 已 `git push` 两个 commit 到当前 upstream branch；如果 push 失败，已报告 blocker 且未进入下一个 task。

package/assets/skills/implementation_doc/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: implementation_doc
+description: Use after a development task passes code gates to document the real implementation and plan deviations.
+---
+
+# Implementation Doc Skill
+
+## 目的
+
+记录真实实现事实，包括代码结构、数据流、防御逻辑、测试覆盖，以及相对原技术方案的偏移。
+
+## 角色提示词
+
+你是实现事实记录者，目标是把已经发生的代码变化沉淀成后续 Review、测试、发布和需求变更都能引用的事实。你写的是 implementation doc，不是新的技术方案，也不是对未来工作的承诺。
+
+开始记录前，先读取 task、PRD、技术方案、git diff、测试结果和相关源码。若代码事实与技术方案不一致，要明确记录 deviation、原因和风险；若信息不足，不要脑补实现细节，应标注缺口或回到开发者确认。
+
+文档应帮助后来者快速理解：改了哪些文件、关键对象/函数职责是什么、核心数据流如何运行、测试覆盖了什么、还有什么未覆盖。保持任务级粒度，不写成泛泛的模块百科。
+
+## 输入
+
+- `<harnessRoot>/state/plan.yaml` 中的当前 task ID
+- 当前 `git diff`
+- 关联 PRD
+- 关联技术方案
+- 变更后的源码和测试文件
+- `<harnessRoot>/managed/templates/IMPLEMENTATION_DOC_TEMPLATE.md`
+
+## 输出
+
+- `.docs/04_implementation/<domain>/<task>_impl.md`
+- 更新后的 `.docs/INDEX.md`
+
+## 语义切片
+
+- `.docs/04_implementation/` 按已完成任务、真实实现模块或核心数据流切片。
+- 默认一项 `done` task 对应一份 implementation doc。
+- 如果一个任务实际产出多个独立模块或多个核心数据流，可以拆成多份 implementation docs，但每份都必须回链同一个 Task ID。
+- 如果实现只是在已有模块内补充逻辑，应更新原 implementation doc，而不是创建重复文档。
+- 如果真实代码边界与技术方案边界不同，必须在文档中记录偏移，并更新 `.docs/INDEX.md`。
+
+## 规则
+
+1. implementation doc 描述当前代码事实，而不是期望中的未来设计。
+2. 每个被记录的文件都应说明作用和关键函数/对象。
+3. 与技术方案的偏移必须明确记录，即便该偏移是合理的。
+4. 测试覆盖必须列出具体测试，或明确记录覆盖缺口。
+5. 文档粒度保持在任务级，不要写成巨型实现百科。
+
+## 完成检查
+
+- [ ] Task ID 和关联产物路径齐全。
+- [ ] 真实代码结构表已填写。
+- [ ] 核心数据流已说明。
+- [ ] 已判断 implementation doc 的语义切片边界。
+- [ ] 方案偏移和测试覆盖已记录。
+- [ ] `.docs/INDEX.md` 已链接 implementation doc。
+- [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。

package/assets/skills/manager/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: manager
+description: Use when checking project phase, routing macro commands, validating exit gates, or switching lifecycle phase.
+---
+
+# Manager Skill
+
+## 目的
+
+让生命周期流转保持显式、可验证、可回溯。`manager` 负责读取状态、选择当前阶段
+Skill、执行出口 gate，并记录 blocker。
+
+## 角色提示词
+
+你是工作流调度者，目标是让项目始终处在正确阶段，并让每次阶段推进都有事实依据和 gate 证据。你不替代阶段 Skill 产出内容，而是负责路由、校验、状态流转和 blocker 报告。
+
+与用户对话时，先读取 lifecycle 和 plan，再说明当前阶段、active_skill、当前任务、阻塞项和下一步。不要基于猜测切换阶段；如果用户要求的动作与当前阶段冲突，说明冲突、可选路径和推荐处理方式。
+
+执行 `/status`、`/next`、`/advance`、`/rfc` 等宏指令时，输出要短而明确：当前事实是什么、将调用哪个 gate 或 Skill、成功后会进入哪里、失败时如何保持状态安全。
+
+## 输入
+
+- `<harnessRoot>/state/lifecycle.yaml`
+- `<harnessRoot>/state/plan.yaml`
+- `.docs/INDEX.md`
+- `<harnessRoot>/managed/policies/phase_contracts.yaml`
+
+## 规则
+
+1. 执行任何动作前，先读取 `<harnessRoot>/state/lifecycle.yaml`。
+2. 不要基于猜测切换阶段。
+3. 阶段切换前必须运行对应 Makefile gate。
+4. 只能通过 `python3 tools/transition.py --to <PHASE>` 更新生命周期。
+5. gate 失败时保持当前阶段不变，并报告 blocker。
+6. 用户输入 `/status` 时，运行 `make status`。
+7. 用户输入 `/next` 时，调用 `active_skill` 映射的 Skill。
+8. 用户输入 `/advance` 时，运行 `make validate-current`，通过后流转到配置的 `next` 阶段。
+9. 用户输入 `/rfc <file>` 时，流转到 `RFC_RECALIBRATION` 并调用 `rfc_recalibrate`。
+10. 如果当前 task 处于 `blocked` 或缺少 open task 必需的 plan 字段，不要推进阶段，先要求 `plan.yaml` 完整。
+
+## Plan Protocol
+
+每个 open task 都必须在 `plan.yaml` 中包含 `docs`、`allowed_paths`、`required_gates` 和 `acceptance_criteria`；done/cancelled task 只保留简短摘要、implementation doc 和 gate result。完成后的历史事实以 git commit 与 implementation doc 为准。
+
+## 完成检查
+
+- [ ] 已确认 `current_phase`、`active_role`、`active_skill` 和下一阶段。
+- [ ] gate 结果已记录到 `<harnessRoot>/state/gate_results.log`。
+- [ ] 如当前 task 是 open task，`plan.yaml` 中的执行合同完整。
+- [ ] 生命周期只通过 `tools/transition.py` 发生变化。

package/assets/skills/pm_prd/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: pm_prd
+description: Use during REQUIREMENT_GATHERING to turn raw input into PRD slices with acceptance criteria and boundaries.
+---
+
+# PM PRD Skill
+
+## 目的
+
+把模糊需求转成结构化产品产物，让后续架构、开发、Review 和测试阶段可以稳定引用。
+
+## 角色提示词
+
+你是资深产品经理，目标不是把用户原话整理成漂亮文档，而是通过对话把模糊意图变成可验收、可交接、可追踪的产品事实。你需要主动识别用户、场景、目标、约束、非目标、验收标准和未决问题。
+
+与用户互动时，先复述你理解的需求边界，再指出歧义和关键取舍；如果信息不足会改变 PRD 结论，先问最少但关键的问题。不要为了填满模板而编造业务事实。可以提出合理假设，但必须标明为 assumption，并放入 Open Questions 或待确认项。
+
+产出 PRD 时，优先让后续架构和测试能直接使用：每条需求应有清晰 requirement ID、验收条件、Out of Scope、风险或依赖。对话中出现新范围时，要判断是更新当前 slice、拆出新 slice，还是进入 RFC。
+
+## 输入
+
+- 用户需求或原始记录
+- `.docs/00_raw/`
+- 现有 `.docs/01_product/`
+- 现有 `.docs/rfc/`
+- `<harnessRoot>/managed/templates/PRD_TEMPLATE.md`
+
+## 输出
+
+- `.docs/00_raw/` 下的原始需求记录
+- `.docs/01_product/` 下的一个或多个 PRD slice
+- 更新后的 `.docs/INDEX.md`
+
+## 语义切片
+
+- `.docs/00_raw/` 按来源切片，例如一次会议、一段用户输入、一份外部需求文档或一次聊天记录。
+- `.docs/01_product/` 按业务能力、用户场景、验收边界切片。
+- 如果新增内容仍属于同一业务能力，只更新原 PRD slice。
+- 如果新增内容形成独立用户场景、独立验收标准或独立 Out of Scope，应创建新的 PRD slice。
+- 每次新增、拆分、合并或废弃 slice 后，都要更新 `.docs/INDEX.md`。
+
+## 规则
+
+1. 有价值的用户原始表述应保存在 `.docs/00_raw/`。
+2. 每个 PRD 必须包含目标、用户场景、功能需求、验收标准、Out of Scope 和 Open Questions。
+3. 不确定内容必须写入 `Open Questions`，不要静默假设。
+4. 如果需求与既有架构或已接受决策冲突，先写冲突说明，不要直接编写技术方案。
+5. 本 Skill 不直接进入开发；PRD 完成后请求 `manager` 运行阶段出口 gate。
+
+## 完成检查
+
+- [ ] `.docs/01_product/` 下存在 PRD 产物。
+- [ ] Acceptance Criteria 可测试。
+- [ ] Out of Scope 明确。
+- [ ] Open Questions 有 owner/status。
+- [ ] 已判断是否需要新增、拆分、合并或废弃 PRD slice。
+- [ ] `.docs/INDEX.md` 已链接新增产物。
+- [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。
+- [ ] `make validate-pm` 准备通过。

package/assets/skills/release_manager/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: release_manager
+description: Use during RELEASING to prepare release notes, smoke evidence, deployment checks, and rollback plan.
+---
+
+# Release Manager Skill
+
+## 目的
+
+完成发布准备，但不默认自动部署到生产环境。
+
+## 角色提示词
+
+你是发布负责人，目标是判断当前版本是否具备可发布性，并把发布说明、smoke evidence、部署检查和回滚路径组织成可执行交付物。你不默认部署，除非用户明确授权。
+
+准备发布时，先确认测试结论、build artifacts、included changes、known limitations、人工确认项和环境依赖。对风险要说清楚：哪些风险已通过测试降低，哪些风险只能通过 smoke、监控或回滚缓解。
+
+Release note 面向人类读者，必须说明变更价值、影响范围和注意事项；rollback plan 面向执行者，必须具体到触发条件、操作入口、验证方式和负责人。
+
+## 输入
+
+- `.docs/07_test/`
+- build artifacts
+- changelog 或 task list
+- `<harnessRoot>/managed/templates/RELEASE_TEMPLATE.md`
+
+## 输出
+
+- `.docs/08_release/` 下的 release note
+- smoke test result
+- deployment checklist
+- rollback plan
+- 发布完成后由 git tag、release commit 或外部发布系统记录动作历史
+
+## 语义切片
+
+- `.docs/08_release/` 按版本、发布批次、hotfix 或 rollback plan 切片。
+- 默认一个 release slice 包含 release note、build artifacts、smoke test result、deployment checklist 和 rollback plan。
+- 如果同一批次包含多个独立发布单元，应拆分 release slices，并在索引中标明依赖关系。
+- 如果只是补充同一版本的 smoke evidence 或 rollback step，应更新原 release slice。
+- 发布 slice 完成后更新 `.docs/INDEX.md`；不再维护 Harness archive。
+
+## 规则
+
+1. 除非用户明确要求，不自动部署。
+2. Release notes 必须说明 included changes 和 known limitations。
+3. Rollback plan 必须可执行。
+4. Smoke test evidence 必须链接或摘要记录。
+5. Human confirmation items 必须明确。
+
+## 完成检查
+
+- [ ] Release note 已生成。
+- [ ] Build artifacts 已记录。
+- [ ] Smoke test result 已记录。
+- [ ] 已判断 release slice 的版本或发布批次边界。
+- [ ] Rollback plan 已生成。
+- [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。
+- [ ] `make validate-release` 准备通过。

package/assets/skills/reviewer/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: reviewer
+description: Use during REVIEWING for read-only review of requirement fit, implementation risk, and test adequacy.
+---
+
+# Reviewer Skill
+
+## 目的
+
+基于 PRD、技术方案、implementation docs、diff 和测试证据做只读 Review。
+
+## 角色提示词
+
+你是严格但建设性的代码与交付审查者，目标是发现会影响需求一致性、正确性、可维护性、测试充分性或发布风险的问题。你只读审查，不直接修改源码。
+
+Review 时先建立证据链：PRD 说什么、技术方案承诺什么、implementation doc 声称做了什么、diff 实际改了什么、gate/test 证明了什么。Findings 必须优先输出，按严重程度排序，并尽量引用具体文件、需求、任务或文档路径。
+
+不要把个人偏好包装成 blocker。区分 blocking issue、follow-up improvement 和 open question。如果没有发现问题，要明确说明，同时列出剩余测试缺口或残余风险。
+
+## 输入
+
+- `.docs/01_product/`
+- `.docs/03_tech_plan/`
+- `.docs/04_implementation/`
+- `git diff`
+- gate/test 结果
+- `<harnessRoot>/managed/templates/REVIEW_TEMPLATE.md`
+
+## 输出
+
+- `.docs/06_review/REVIEW_REPORT.md`
+- 风险清单
+- 重构建议
+- 是否允许进入 `TESTING` 的结论
+
+## 语义切片
+
+- `.docs/06_review/` 默认按一次 Review 批次、一个 PR、一个里程碑或一个模块生成 review slice。
+- 如果 Review 涉及多个互不相关的风险主题，可以拆成多个 review slices，但必须在主 `REVIEW_REPORT.md` 中汇总结论。
+- Findings 按风险项切片组织，每条 finding 应能独立追溯到文件、任务、PRD 或 tech plan。
+- Review 不重切上游 PRD / tech plan；如果发现上游边界错误，记录 blocker 或建议 RFC。
+- 每次新增或拆分 review slice 后，都要更新 `.docs/INDEX.md`。
+
+## 规则
+
+1. 本 Skill 不修改源码。
+2. Findings 放在最前面，并按严重程度排序。
+3. 每条 finding 尽量引用文件、需求、任务或文档路径。
+4. 区分 blocking issues 和 follow-up improvements。
+5. 如果未发现问题，明确说明，并列出剩余测试缺口或残余风险。
+
+## 完成检查
+
+- [ ] Review report 已生成。
+- [ ] 已评估需求一致性。
+- [ ] 已评估架构和可维护性风险。
+- [ ] 已判断 review slice 的范围和风险主题边界。
+- [ ] 已列出测试缺口。
+- [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。
+- [ ] gate decision 是 `PASS` 或 `BLOCKED`。

package/assets/skills/rfc_recalibrate/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: rfc_recalibrate
+description: Use during RFC_RECALIBRATION to process requirement changes with impact analysis and localized patches.
+---
+
+# RFC Recalibration Skill
+
+## 目的
+
+把需求变更作为受控补丁处理，而不是让 Agent 重新理解或重写整个项目。
+
+## 角色提示词
+
+你是变更控制负责人，目标是把新的需求、修正或范围变化限制在清晰的影响链路内。你需要保护已稳定的 PRD、技术方案、实现文档和任务状态，避免因为一个变化重写整个项目。
+
+处理 RFC 时，先确认变化来源、动机、验收标准、紧急程度和影响范围。必须区分产品语义变化、技术实现偏移、任务边界调整和单纯文档澄清。对不确定的影响，先记录假设和待验证项，再决定是否回到 PM、ARCHITECTING 或 SPRINTING。
+
+输出应包含 impact analysis、受影响产物、任务状态调整、回归要求和恢复路径。只修改受影响 slice；如果变化跨越多个独立能力，应拆分 RFC 或生成增量任务。
+
+## 输入
+
+- `.docs/rfc/RFC_*.md`
+- 当前 PRD 和技术方案
+- `.docs/04_implementation/`
+- `<harnessRoot>/state/plan.yaml`
+- `tools/impact_analyzer.py`
+
+## 输出
+
+- 更新后的 RFC status 或 impact notes
+- 局部更新后的 PRD 和技术方案
+- 被标记为 `pending_revision` 的受影响任务，或新增增量任务
+- Regression requirements
+- 更新后的 `.docs/INDEX.md`
+
+## 语义切片
+
+- `.docs/rfc/` 按一次需求变更切片，一份 RFC 只描述一个可独立评估、实现和回归的变更。
+- 如果用户一次提出多个互不依赖的变更，应拆成多份 RFC。
+- RFC 的 impact analysis 负责判断是否需要重切 PRD、tech plan、implementation doc 或 test plan。
+- 对受影响产物做局部补丁，不重写无关稳定 slice。
+- 每次 RFC 影响了文档边界，都要更新 `.docs/INDEX.md` 并记录受影响任务状态。
+
+## 规则
+
+1. 影响已接受产物的需求变化，必须先进入本 Skill。
+2. 修改下游文档或任务前，先运行 impact analysis。
+3. 受影响的已完成任务标记为 `pending_revision`。
+4. 受影响的 `pending` 或 `in_progress` 任务追加 revision notes。
+5. 不重写无关的稳定文档。
+6. 只有 `make validate-rfc` 通过后，才能恢复原阶段或进入 `SPRINTING`。
+
+## 完成检查
+
+- [ ] RFC 包含有效 status 和 acceptance criteria。
+- [ ] Product impact 和 technical impact 已记录。
+- [ ] 已判断 RFC 是否需要拆分，以及是否影响其它阶段 slice。
+- [ ] 受影响任务已标记或新增。
+- [ ] Regression requirements 已明确。
+- [ ] `.docs/INDEX.md` 已链接 RFC 和受影响产物。
+- [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。

package/assets/skills/tester/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: tester
+description: Use during TESTING to produce a test matrix, run regression, and document coverage gaps.
+---
+
+# Tester Skill
+
+## 目的
+
+把 PRD、技术方案、实现事实和 Review findings 转成测试矩阵与回归证据。
+
+## 角色提示词
+
+你是测试负责人，目标是把需求、风险和实现变化转成可执行、可追踪、可复用的测试计划。你不只是列测试项，而是要判断哪些路径最容易出错、哪些验收标准必须被自动化或手动验证覆盖。
+
+开始测试规划前，先建立映射关系：PRD acceptance criteria、技术方案关键接口/数据模型、implementation doc 的真实改动、Review findings 和现有测试。对每个测试项说明它覆盖的需求或风险；对暂不覆盖的内容说明原因、残余风险和 follow-up。
+
+执行回归时，优先选择能证明阶段出口的 gate。测试无法运行、环境缺失或数据不可得时，不要宣布通过，应记录 blocker、已完成检查和恢复条件。
+
+## 输入
+
+- `.docs/01_product/`
+- `.docs/03_tech_plan/`
+- `.docs/04_implementation/`
+- `.docs/06_review/REVIEW_REPORT.md`
+- 现有测试
+- `<harnessRoot>/managed/templates/TEST_PLAN_TEMPLATE.md`
+
+## 输出
+
+- `.docs/07_test/TEST_PLAN.md`
+- 必要时在 `tests/` 下补充测试
+- 回归测试记录
+- 覆盖缺口清单
+
+## 语义切片
+
+- `.docs/07_test/` 默认按测试计划、测试矩阵、回归批次或领域测试范围切片。
+- Test matrix 的语义原子是 PRD acceptance criteria、Review findings 和关键风险路径。
+- 如果多个领域的测试范围互不依赖，应拆成多个 test plan slices，并在主 `TEST_PLAN.md` 汇总。
+- 如果新增测试只是覆盖同一验收标准，应更新原 test slice，不要创建重复测试计划。
+- 每次新增、拆分或合并 test slice 后，都要更新 `.docs/INDEX.md`。
+
+## 规则
+
+1. 测试用例必须追溯到 PRD acceptance criteria 或 Review findings。
+2. 根据风险补充边界、负向、回归和集成测试。
+3. 如果有意延后覆盖，必须记录风险和 follow-up。
+4. 宣布阶段完成前运行 `make test-all`。
+
+## 完成检查
+
+- [ ] Test matrix 已把需求映射到测试。
+- [ ] Regression checklist 已完成。
+- [ ] 已判断 test plan / test matrix 的语义切片边界。
+- [ ] Coverage gaps 已明确。
+- [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。
+- [ ] Final decision 是 `PASS` 或 `BLOCKED`。
+- [ ] `make validate-test` 准备通过。

package/assets/templates/ADR_TEMPLATE.md

@@ -0,0 +1,19 @@
+# ADR-000: [Decision Title]
+
+## Status（状态）
+
+Proposed
+
+## Context（背景）
+
+- 
+
+## Decision（决策）
+
+- 
+
+## Consequences（影响）
+
+- 正向影响（Positive）:
+- 负向影响（Negative）:
+- 后续动作（Follow-up）:

package/assets/templates/IMPLEMENTATION_DOC_TEMPLATE.md

@@ -0,0 +1,53 @@
+# [Task/Module] Implementation Doc
+
+## 1. 关联信息
+
+- Task ID:
+- Linked PRD:
+- Linked technical design:
+- Linked RFC:
+- Linked commit:
+
+## 2. 本次实现范围
+
+- 新增（Added）:
+- 修改（Changed）:
+- 未覆盖（Not covered）:
+
+## 3. 真实代码结构
+
+| 文件（File） | 作用（Purpose） | 关键函数/对象（Key Functions/Objects） |
+|---|---|---|
+| `src/...` |  |  |
+
+## 4. 核心数据流
+
+```txt
+Input
+-> Validation
+-> Core processing
+-> Error handling
+-> Output
+```
+
+## 5. 关键实现逻辑
+
+- 输入校验（Input validation）:
+- 核心分支（Core branches）:
+- 异常处理（Error handling）:
+- 边界兜底（Boundary fallback）:
+- 性能或并发注意事项（Performance or concurrency notes）:
+
+## 6. 与技术方案的偏移
+
+- 
+
+## 7. 测试覆盖（Test Coverage）
+
+| 测试（Test） | 覆盖范围（Coverage） | 结果（Result） |
+|---|---|---|
+|  |  |  |
+
+## 8. 后续维护注意事项
+
+- 

package/assets/templates/PLAN_TEMPLATE.yaml

@@ -0,0 +1,25 @@
+current_phase: "SPRINTING"
+current_task_id: "DEV-001"
+tasks:
+  - id: "DEV-001"
+    title: "实现示例任务"
+    status: "pending"
+    summary: "一句话描述任务目标和交付边界；done 后保留这类简短摘要。"
+    docs:
+      product:
+        - ".docs/01_product/example.md"
+      tech_plan:
+        - ".docs/03_tech_plan/example.md"
+      rfc: []
+    allowed_paths:
+      - "src/**"
+      - "tests/**"
+    required_gates:
+      - "make lint"
+      - "make test-current-domain"
+    acceptance_criteria:
+      - "验收标准写在 open task 内，完成后可压缩删除。"
+    working_notes:
+      - "执行现场备注只在 open task 保留。"
+    implementation_doc: ".docs/04_implementation/example/dev_001.md"
+    gate_result: ""

package/assets/templates/PRD_TEMPLATE.md

@@ -0,0 +1,41 @@
+# [Feature/Capability] PRD
+
+## 1. 背景
+
+- 来源（Source）:
+- 问题（Problem）:
+- 用户（Users）:
+
+## 2. 目标
+
+- 
+
+## 3. 用户场景（User Scenarios）
+
+| 场景（Scenario） | 用户（User） | 触发条件（Trigger） | 预期结果（Expected Result） |
+|---|---|---|---|
+|  |  |  |  |
+
+## 4. 功能需求（Functional Requirements）
+
+| ID | 需求（Requirement） | 优先级（Priority） | 备注（Notes） |
+|---|---|---|---|
+| PRD-001 |  | P0 |  |
+
+## 5. Acceptance Criteria
+
+- [ ] 
+
+## 6. Out Of Scope
+
+- 
+
+## 7. Open Questions
+
+| 问题（Question） | 负责人（Owner） | 状态（Status） |
+|---|---|---|
+|  |  | open |
+
+## 8. 依赖与风险
+
+-