用途：write-feature 用于实现“新增能力”类任务，即构建此前不存在的功能。它强调在基础 implement-task 规则之上增加功能开发纪律：只构建需求明确写出的内容，先复用再发明，未经核验不交付。修复缺陷、无行为变更的重构、有意改变既有行为、API 迁移和性能调优属于其他类型，各有对应指南。
主要能力与要求：先阅读任务包及其来源，任务包确定范围（验收标准列表、禁止改动区域、Verify 清单），规范说明原因；项目命令从代码仓库的 AGENTS.md Commands 表解析，未定义则询问，不得猜测。编码前把每条验收标准映射到改动的具体部分，每条 AC 在计划中有命名步骤。新增 helper、类型或模式前先搜索代码库中已有等价物。遇到歧义要停下并暴露问题，不得自行发明需求。不得顺手重构，构建中发现的债务记为 finding 候选。每批改动后运行检查并粘贴输出，而非只在最后运行。测试属于交付物，每条 AC 对应测试（或明确记录的后续任务），并通过翻转断言或注释掉生产路径来证明测试有效：翻转时必须失败，恢复后必须通过，粘贴两次转换。每个 Verify 项在最终编辑后粘贴真实输出（命令、退出状态、摘要行，原样围栏）。结尾提交总结与发现：改动文件、带输出的命令、未满足项、范围外编辑、## Findings 中的候选；不对自己的工作给出评审结论。
使用方式：开始前打开 references/task-template.md 并复制到任务文件，作为本次工作的会话框架，边做边填，不要凭记忆重建结构；它包含 AC 到改动的映射、批次检查点、粘贴证据和自审。任务包本身使用该套件的任务模板。
限制：这些是评审包检查的约定，编辑时没有任何机制强制执行。自审门要求：每条 AC 对应可指出的 diff 部分，且 diff 中没有无 AC（或列明例外）支撑的部分；每个 Verify 项在最终编辑后运行并粘贴输出；每个新测试都翻转验证并粘贴代表性转换；遇到的歧义均已暴露而非猜测解决；新 helper 或模式记录既有方案不适用的原因；总结列出改动文件、带输出的命令和 finding 候选，且不自行给出评审结果。