workflow-feature-shipper

Feature Shipper

将“我想开发一个功能”转化为快速执行链。

输入（仅传入路径）

• feature.md：需求说明（验收标准 + 非目标）
• repo_root
• run_dir

可选标志（建议写在 feature.md 中）

• mode：plan-only | execute（默认：execute）
• feature_slug：用于命名产物的简短标识（默认：根据标题 + 时间戳生成）
• quality_bar：demo-ready | functional-only（默认：面向用户的 UI 功能使用 demo-ready）

输出（持久化）

• evidence/features/<feature_slug>-plan.md（检查清单计划：任务 + 验证）
• evidence/parallel/features/<feature_slug>/（若实现拆分）
• evidence/features/<feature_slug>-summary.md

流程

0. Hooks doctor（必需检查；非阻塞）：在会话开始时运行一次 tool-hooks-doctor，确认已启用 skill-evolution hooks。如果缺少 hooks，询问用户是否安装项目级 hooks；无论结果如何都继续。
1. 阅读 feature.md，并将内容归纳为：验收标准、边界、风险、回滚方案。
2. UI 原型规则（默认）：如果此功能会影响面向用户的 UI，且 quality_bar 不是 functional-only，则提出 1 个“演示时刻”（动画/微交互）并将其加入验收标准。必须遵循 prefers-reduced-motion。
3. 提供 2 个方案（A：最简；B：更完善但更慢），默认选择 A。如果用户在意“演示效果”，则明确提供 A-demo-ready 和 A-functional-only 两个子选项。
4. 拆分为 PR 规模的小步骤（每一步都可独立运行和回滚）。
5. 将计划写入 evidence/features/<feature_slug>-plan.md。
6. 如果 mode: plan-only，则到此为止，并在实现前请求确认。
7. 实现（分批执行 + 检查点）：
   • UI 视觉、布局或动画变更 → 首先调用 tool-design-style-selector，加载项目的 design-system.md，然后严格遵循它。如果已安装 tool-ui-ux-pro-max，则使用它来确定动效/UX 约束（搜索“animation” + “accessibility”）。对于复杂的视觉、动画或响应式设计，委派给 /gemini 前端 UI/UX 高级设计 Agent。
   • 业务逻辑、数据流或集成 → 直接实现。
   • 默认批次节奏：每批 3 个小任务 → 运行验证 → 汇报并等待反馈；如遇阻碍或验证失败，立即停止并寻求帮助。
   • 每批完成后（或合并前），建议使用 review-quality 进行全面审查并给出结论。
     • review-quality 是唯一入口，会自动分类处理：如果检测到 React/Next.js 性能风险，也会运行 review-react-best-practices。
     • 如果用户明确要求仅进行 React/Next.js 性能审计，则直接运行 review-react-best-practices。
8. 验证：可以运行、可以构建（且现有测试通过）。
   • 如果验证失败（测试/构建/运行时错误）：在尝试进一步修复前，先运行 tool-systematic-debugging。
   • 将调试产物持久化到：
     • evidence/features/<feature_slug>-debug.md（复现步骤、假设、根本原因、修复 + 重新验证）
9. 编写 evidence/features/<feature_slug>-summary.md：完成的工作、验证方式、后续步骤。
10. 收尾：完成 skill-evolution Evolution checkpoint（3 个问题）；如果用户选择“想要优化”，则根据此 run_dir 运行 skill-improver，生成精简的补丁建议。

交付要求

• 不进行“大爆炸式”重构
• 不要引入新的复杂性（除非能显著降低未来成本，并且用户确认）