用途：把“我要做一个功能”转化为一条快速执行链，适用于需要端到端交付单个 PR 规模功能的场景，常见于 Next.js 项目中的核心产品功能。
输入（只传路径）：feature.md（需求描述，含验收标准与非目标）、repo_root、run_dir。可选标志通常写进 feature.md：mode 为 plan-only 或 execute（默认 execute）；feature_slug 用于产物命名（默认由标题加时间戳派生）；quality_bar 为 demo-ready 或 functional-only（面向用户界面的功能默认 demo-ready）。
输出（持久化）：evidence/features/<feature_slug>-plan.md 为清单式计划（任务与验证）；若实现被拆分，则产生 evidence/parallel/features/<feature_slug>/；以及 evidence/features/<feature_slug>-summary.md。
流程：会话开始先运行一次 tool-hooks-doctor 做 Hooks doctor 检查（必需但不阻塞），缺失时提示安装项目级 hooks，仍可继续；读取 feature.md 并归纳为验收标准、边界、风险、回滚；若涉及用户界面且 quality_bar 非 functional-only，提出一个“演示时刻”（动画或微交互）并纳入验收标准，须尊重 prefers-reduced-motion；给出两个方案（A 最小、B 更整洁但更慢），默认 A，若关注演示感则提供 A-demo-ready 与 A-functional-only 子选项；拆成可独立运行、可回滚的 PR 级小步并写入计划文件；plan-only 模式在此停下等待确认。实现阶段按批次执行与检查点：界面视觉、布局、动画改动先调用 tool-design-style-selector 加载设计系统并严格遵循，若安装 tool-ui-ux-pro-max 则用于约束动效与无障碍，复杂视觉或响应式设计可交给 /gemini 前端 UI/UX 高级设计代理；业务逻辑、数据流、集成直接实现；默认每批 3 个小任务后验证并等待反馈。每批之后或合并前建议用 review-quality 做结论性审查，它会自动分流，检测到 React/Next.js 性能风险时再跑 review-react-best-practices；若用户只要性能审计可直接运行后者。验证要求能运行、能构建且现有测试通过；验证失败先运行 tool-systematic-debugging，调试产物写入 evidence/features/<feature_slug>-debug.md；最后写 summary 并做技能演进检查点。限制：禁止大爆炸式重构；不引入新复杂度（除非显著降低未来成本且用户确认）。其余如具体安装命令、平台与收费信息暂未提供。