Back to Details

workflow-feature-shipper

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Feature Shipper

Feature Shipper

Turn "I want to build a feature" into a fast execution chain.
将「我想要构建一个功能」转化为快速执行流程。

Input (Pass Paths Only)

输入（仅传递路径）

  • feature.md
    : Requirements description (acceptance criteria + non-goals)
  • repo_root
  • run_dir
  • feature.md
    ：需求说明（验收标准+非目标）
  • repo_root
  • run_dir

Optional flags (recommended inside 
feature.md
)

可选标记（建议在
feature.md
中设置）

  • mode
    : 
    plan-only
    | 
    execute
    (default: 
    execute
    )
  • feature_slug
    : short slug for artifact naming (default: derived from title + timestamp)
  • quality_bar
    : 
    demo-ready
    | 
    functional-only
    (default: 
    demo-ready
    for user-facing UI features)
  • mode
    ：
    plan-only
    （仅计划）| 
    execute
    （执行）（默认值：
    execute
    ）
  • feature_slug
    ：用于产物命名的短别名（默认值：从标题+时间戳生成）
  • quality_bar
    ：
    demo-ready
    （可演示）| 
    functional-only
    （仅功能可用）（默认值：面向用户的UI功能使用
    demo-ready
    ）

Output (Persisted)

输出（持久化存储）

  • evidence/features/<feature_slug>-plan.md
    (checklist plan: tasks + verification)
  • evidence/parallel/features/<feature_slug>/
    (if implementation is split)
  • evidence/features/<feature_slug>-summary.md
  • evidence/features/<feature_slug>-plan.md
    （检查清单式计划：任务+验证项）
  • evidence/parallel/features/<feature_slug>/
    （当实现被拆分时生成）
  • evidence/features/<feature_slug>-summary.md

Process

流程

  1. Hooks doctor (required check; non-blocking): Run 
    tool-hooks-doctor
    once at the start of the session to verify 
    skill-evolution
    hooks are enabled. If missing, offer to install project-level hooks; continue either way.
  2. Read 
    feature.md
    , normalize into: acceptance criteria, boundaries, risks, rollback.
  3. Prototype UI rule (default): if this feature affects user-facing UI and 
    quality_bar
    isn’t 
    functional-only
    , propose 1 “demo moment” (animation/micro-interaction) and add it to acceptance criteria. Must respect 
    prefers-reduced-motion
    .
  4. Produce 2 options (A: minimal; B: cleaner but slower), default to A. If user cares about “demo feel”, offer A-demo-ready vs A-functional-only as explicit sub-options.
  5. Split into PR-sized small steps (each independently runnable + rollback-able).
  6. Write plan to 
    evidence/features/<feature_slug>-plan.md
    .
  7. If 
    mode: plan-only
    , stop here and ask for confirmation before implementing.
  8. Implement (batch execution + checkpoints):
    • UI visual/layout/animation changes → First call 
      tool-design-style-selector
      to load the project’s 
      design-system.md
      , then strictly follow it. If 
      tool-ui-ux-pro-max
      is installed, use it to ground motion/UX constraints (search “animation” + “accessibility”). For complex visual/animation/responsive design, delegate to 
      /gemini
      frontend UI/UX senior design agent.
    • Business logic/data flow/integration → Implement directly.
    • Default batch rhythm: 3 small tasks per batch → run verification → report and wait for feedback; stop immediately for help when blocked/verification fails.
    • After each batch (or before merge), recommend using 
      review-quality
      for a conclusive review + verdict. 
      • review-quality
        is the single entry point and will auto-triage: if React/Next.js performance risk is detected, it will also run 
        review-react-best-practices
        .
      • If the user explicitly wants only a React/Next.js perf audit, run 
        review-react-best-practices
        directly.
  9. Verification: can run, can build (and existing tests pass).
    • If verification fails (tests/build/runtime error): run 
      tool-systematic-debugging
      before attempting more fixes.
    • Persist debugging artifacts to: 
      • evidence/features/<feature_slug>-debug.md
        (repro steps, hypotheses, root cause, fix + re-verify)
  10. Write 
    evidence/features/<feature_slug>-summary.md
    : what was done, how verified, next steps.
  11. Wrap up: Do a 
    skill-evolution
    Evolution checkpoint (3 questions); if user chooses "want to optimize", run 
    skill-improver
    based on this 
    run_dir
    to produce minimal patch suggestions
  1. Hooks检查器（必填检查；非阻塞）：在会话开始时运行一次
    tool-hooks-doctor
    ，以验证
    skill-evolution
    钩子已启用。如果缺失，提议安装项目级钩子；无论是否安装都继续流程。
  2. 读取
    feature.md
    ，标准化为：验收标准、边界、风险、回滚方案。
  3. 原型UI规则（默认）：如果该功能影响用户面向的UI且
    quality_bar
    未设置为
    functional-only
    ，则提议1个「演示时刻」（动画/微交互）并将其添加到验收标准中。必须遵循
    prefers-reduced-motion
    （减少动画偏好）设置。
  4. 生成2种方案（A：最简方案；B：更整洁但耗时更长），默认选择A。如果用户关注「演示体验」，则明确提供A-可演示版 vs A-仅功能版作为子选项。
  5. 拆分为PR规模的小步骤（每个步骤均可独立运行+回滚）。
  6. 将计划写入
    evidence/features/<feature_slug>-plan.md
    。
  7. 如果
    mode: plan-only
    ，则在此处停止，并在实现前请求用户确认。
  8. 实现（批量执行+检查点）：
    • 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
        。
  9. 验证：可运行、可构建（且现有测试通过）。
    • 如果验证失败（测试/构建/运行时错误）：在尝试更多修复前先运行
      tool-systematic-debugging
      。
    • 将调试产物持久化到： 
      • evidence/features/<feature_slug>-debug.md
        （复现步骤、假设、根因、修复方案+重新验证）
  10. 编写
    evidence/features/<feature_slug>-summary.md
    ：已完成工作、验证方式、下一步计划。
  11. 收尾：进行
    skill-evolution
    进化检查点（3个问题）；如果用户选择「想要优化」，则基于当前
    run_dir
    运行
    skill-improver
    以生成最小化补丁建议

Delivery Requirements

交付要求

  • No "big bang" refactoring
  • Don't introduce new complexity (unless it significantly reduces future cost, and user confirms)
  • 禁止「大爆炸式」重构
  • 不要引入新的复杂度（除非能显著降低未来成本，且经用户确认）