用途 feature-dev 是一个功能开发工作流技能，适用场景为实现功能、编写代码、验证、预提交、重构与简化。触发关键词包括：develop feature、implement、write code、verify、precommit、refactor、simplify。
不适用场景 如果只是想理解代码，应使用 Explore；如果只做代码审查，应使用 codex-code-review；如果只审查文档，应使用 doc-review；如果是没有功能变更的纯测试任务，应直接使用 /codex-test-review。
基本约定 该技能实现功能但不提交代码，并明确禁止执行 git add、git commit、git push（依据 @rules/git-workflow.md）。/precommit 仅是质量门禁。需要提交时，按 rules/git-workflow.md 的 Proactive Offer 提供菜单：在任何真实分支上提供提交选项，仅在 review-state.js 允许时提供 push 选项，并在被选中后调用 /smart-commit --execute；不应把命令打印出来让用户复制。技能标注了 budget: token_budget 200000。
工作流 整体流程为：需求 → 设计 → 实现 → 测试 + 审查 → 预提交门禁 → 文档同步。对应命令包括：设计阶段使用 /codex-architect 获取架构建议；实现阶段使用 /codex-implement 由 Codex 编写代码；测试运行使用 /verify（按 lint → typecheck → unit → integration 顺序）；测试审查使用强制性的 /codex-test-review（从 5 个维度审查测试充分性）；测试生成使用 /codex-test-gen 为缺口生成单元测试；集成测试使用 /post-dev-test 编写缺失的集成/e2e 测试；审查使用 /codex-review-fast（自动循环）；预提交使用 /precommit（lint + build + test，自动循环的标准路径）；文档同步使用 /update-docs 让文档与代码同步，以及 /create-request --update 更新请求进度；重构使用 /simplify 做最终重构。
意图加载 首先要加载意图：从任务、所遵循的 spec/requirements 或被修改的路径中识别该工作所属的功能，并读取 docs/features/<key>/intent-<key>.md（如果存在）——它会覆盖默认做法。若工作与其中某个 INV-* 不变量或 Non-goals 相矛盾，则停止并询问用户（引用对应行；修改意图是用户重新决策）。若无法识别功能，则无需加载，继续执行即可。
先设计后编码 对于非平凡变更，应简要考虑每个职责由谁承担、适合现有代码的最简形态以及原因，并在选择不明显时说明所选方案。清晰命名、小而内聚的函数、依赖方向、用组合降低耦合等原则是问题而非配额：绝不要为了展示设计而添加抽象。/codex-architect 用于真正困难的权衡（跨模块边界、新公共 API、持久抽象），而不是每个功能。
测试 + 审查阶段（核心） 这是 feature-dev 的核心，目的是在代码审查前确保测试覆盖充分。
第 1 步：运行现有测试。执行 /verify，若全部通过则进入第 2 步；若失败则修复失败项并重新运行 /verify。
第 2 步：测试充分性审查（代码变更必做）。执行 /codex-test-review，若测试充分则进入第 3 步；若不足则关闭缺口（第 2a 步），然后运行 /codex-test-review --continue。
第 2a 步：缺口关闭。单元测试缺失或不足时，使用 /codex-test-gen 编写测试，再运行 /verify；集成/E2E 缺失时，使用 /post-dev-test 编写测试，再运行 /verify。
第 3 步：代码审查（自动循环）。执行 /codex-review-fast，若就绪则进入预提交门禁；若未就绪则修复问题并重新运行 /codex-review-fast（自动循环）。
新鲜度规则：如果代码在最近一次“测试充分”门禁之后发生变更（例如根据代码审查做了修复），则在进入预提交门禁前需重新运行 /verify 和 /codex-test-review --continue。
测试要求 遵循 @rules/testing.md 的约定（AAA、命名、证据模型），并遵循 @rules/testing-project.md 的项目级覆盖（目录、运行器、充分性模式）。按变更类型的测试要求：新增服务/提供者必须有对应单元测试；修改现有逻辑需现有测试通过并测试新逻辑；缺陷修复必须添加回归测试；新增 API 端点需要集成测试；跨服务变更需要 E2E 测试。
测试文件映射 使用 @rules/testing-project.md 中的项目约定；若未定义覆盖，则按生态默认：src/<module>/ 对应 test/unit/<module>/ 或 test/<module>/；scripts/<name>.sh 对应 test/scripts/<name>.test.js；skills/<name>/SKILL.md 对应 test/skills/<name>.test.js。
输出 实现的功能代码 + 测试；测试充分性门禁：✅ Tests sufficient；审查门禁：✅ Ready；预提交结果：✅ All Pass。
验证清单 所有测试通过（/verify）；测试充分性已审查（/codex-test-review）；代码审查通过（/codex-review-fast ✅ Ready）；预提交通过（/precommit ✅ All Pass）；未执行 git add/commit/push。
文档同步 在预提交通过后自动触发（依据 @rules/auto-loop.md，属于行为层规则，非 hook 强制）。仅当变更映射到 docs/features/ 下的功能时执行。目标检测使用 3 级回退，详见 /update-docs。流程为：预提交通过 → 定位功能文档 → /update-docs docs/features/<feature>/2-tech-spec.md（当前权威文档）→ /create-request --update docs/features/<feature>/requests/<date>-<title>.md（仅记录状态与结果）→ /codex-review-doc（对上述所有被触及文档只派发一次）→ 安全阀：若出现新的代码 diff，则回到审查循环。
同步当前权威文档；向记录追加内容。技术规范描述当前真实情况，因此代码落地后会使其过时并被重写。请求工单、审查日志或 ADR 描述某一时间点决定或完成的事项，更新其状态与结果，绝不为了匹配今天的代码而重写，因为重写会破坏记录。scripts/lib/doc-metadata.js 决定文件的类型；/codex-review-doc 按分类对应的配置审查每个文件。对它们只调用一次 /codex-review-doc，而不是每个文件一次：被修改的文档构成单一审查计划。按文件派发曾把三文件文档同步放大成三次全文档审查。
审查循环 修复后必须重新审查直到通过（依据 @rules/auto-loop.md）：审查 → 发现问题 → 修复 → 重新审查 → …… → ✅ 通过 → 下一步。
示例 输入“实现一个费用计算方法”：执行 /codex-architect → /codex-implement → /verify → /codex-test-review → /codex-review-fast → /precommit。输入“这段代码需要重构”：执行 /simplify → /verify → /codex-test-review → /codex-review-fast → /precommit。输入“功能开发，继续（恢复工作）”：检查 git 状态 → 识别剩余任务 → 从当前阶段继续。
限制与说明 该技能不提交代码，禁止 git add/commit/push；文档同步仅在变更映射到 docs/features/ 下的功能时触发；其余信息（如具体收费、平台支持等）暂未提供。