Back to Details

implement

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implement

功能实现流水线

End-to-end feature implementation pipeline. Runs pre-flight validation, TDD cycle, scope enforcement, and quality commit as a single orchestrated flow.
端到端功能实现流水线，将预检验证、TDD循环、范围管控和高质量提交整合为一个协调的工作流。

Pipeline Phases

流水线阶段

Phase 0: Pre-flight (< 30 seconds)

阶段0：预检（< 30秒）

Before writing any code, validate the workspace is ready:
  1. Git status — check for uncommitted changes that might conflict
  2. Monorepo freshness — if shared/library packages exist, check if source is newer than compiled output. If yes, rebuild first.
  3. Workspace typecheck — run 
    tsc --noEmit
    (or equivalent) on the target workspace
  4. Existing test check — if a test file exists for the target module, run it to confirm green baseline
If any check fails, report and ask the user how to proceed before writing code.
在编写任何代码之前，验证工作区是否就绪：
  1. Git状态 — 检查是否存在可能导致冲突的未提交变更
  2. 单体仓库新鲜度 — 若存在共享/库包，检查源代码是否比编译输出更新。若是，先重新构建
  3. 工作区类型检查 — 在目标工作区运行
    tsc --noEmit
    （或等效命令）
  4. 现有测试检查 — 若目标模块存在测试文件，运行该文件确认基线状态正常
如果任何检查失败，在编写代码前向用户报告并询问后续处理方式。

Phase 1: Understand & Plan (no code yet)

阶段1：需求理解与规划（暂不编写代码）

  1. Read the target file(s) mentioned in 
    $ARGUMENTS
  2. Identify the module type (route handler, repository, plugin, utility, service, component)
  3. Determine the mock strategy — check nearest test files for established patterns
  4. Plan what tests to write and what implementation to add
Present a brief summary: "I'll add X tests covering Y, then implement Z." Wait for user confirmation if the scope seems large (> 3 files).
  1. 读取
    $ARGUMENTS
    中指定的目标文件
  2. 识别模块类型（路由处理器、仓库、插件、工具类、服务、组件）
  3. 确定Mock策略 — 查看最近的测试文件，参考已有的模式
  4. 规划要编写的测试内容和要实现的功能
呈现简要总结："我将添加X个测试覆盖Y场景，然后实现Z功能。"若范围较大（> 3个文件），等待用户确认后再继续。

Phase 2: Bootstrap Mock (1 test)

阶段2：初始化Mock（1个测试用例）

Follow 
/tdd
Step 3 exactly:
  1. Check test runner config for mock reset/restore settings
  2. Write ONE minimal test that imports the module and verifies mocks resolve
  3. Run it, confirm it passes
  4. If it fails, diagnose mock wiring before proceeding
严格遵循
/tdd
步骤3：
  1. 检查测试运行器配置中的Mock重置/恢复设置
  2. 编写一个最小化测试用例，导入模块并验证Mock解析正常
  3. 运行测试，确认通过
  4. 若失败，先排查Mock配置问题再继续

Phase 3: Red — Write Failing Tests

阶段3：红阶段 — 编写失败的测试用例

Write test cases for:
  • Happy path
  • Edge cases
  • Error cases
Run the test file — all new tests MUST fail. If any pass unexpectedly, the tests aren't testing new behavior.
编写以下场景的测试用例：
  • 正常路径
  • 边缘场景
  • 错误场景
运行测试文件 — 所有新增测试必须失败。若有测试意外通过，说明该测试未覆盖新的行为。

Phase 4: Green — Minimum Implementation

阶段4：绿阶段 — 最小化实现

Write the minimum code to make all tests pass. Do NOT:
  • Add features not covered by tests
  • Optimize prematurely
  • Refactor existing code
Run the test file — all tests MUST pass.
编写最少代码使所有测试通过。禁止：
  • 添加测试未覆盖的功能
  • 过早优化
  • 重构现有代码
运行测试文件 — 所有测试必须通过。

Phase 5: Scope Guard

阶段5：范围管控

Before committing, self-audit the changes:
  1. Run 
    git diff --name-only
    to see all modified files
  2. Compare against the original task from 
    $ARGUMENTS
  3. Flag any files that don't relate to the task:
    • Formatting-only changes → revert with 
      git checkout -- <file>
    • Unrelated refactors → revert or split into separate commit
    • Docstring additions to untouched code → revert
If scope creep is detected, report it and ask the user whether to keep or revert the extra changes.
提交前，自动审计变更：
  1. 运行
    git diff --name-only
    查看所有修改的文件
  2. 与
    $ARGUMENTS
    中的原始任务对比
  3. 标记任何与任务无关的文件：
    • 仅格式变更 → 使用
      git checkout -- <file>
      撤销
    • 无关重构 → 撤销或拆分为单独提交
    • 对未修改代码添加文档注释 → 撤销
若检测到范围蔓延，向用户报告并询问是否保留或撤销额外变更。

Phase 6: Full Suite + Quality Gates

阶段6：全量测试套件 + 质量门禁

  1. Run the full test suite (e.g., 
    npx vitest run --reporter=dot
    )
  2. Run workspace typecheck (
    tsc --noEmit
    or equivalent)
  3. Run linter on changed files only
If any gate fails:
  • Test failure: determine if your change caused it (regression) or pre-existing
  • Type error: fix it
  • Lint error in your files: fix it
  • Lint error in files you didn't touch: ignore, note in commit message
  1. 运行完整测试套件（例如
    npx vitest run --reporter=dot
    ）
  2. 运行工作区类型检查（
    tsc --noEmit
    或等效命令）
  3. 仅对变更文件运行代码检查工具
若任何门禁检查失败：
  • 测试失败：判断是你的变更导致的回归还是原有问题
  • 类型错误：修复该错误
  • 你的文件存在代码检查错误：修复该错误
  • 未修改文件存在代码检查错误：忽略，并在提交信息中注明

Phase 7: Commit

阶段7：提交代码

Stage only the files you changed (NEVER 
git add -A
). Commit with conventional format:
type(scope): description

Co-Authored-By: Claude <noreply@anthropic.com>
仅暂存你修改的文件（绝对不要使用
git add -A
）。使用约定式提交格式：
type(scope): description

Co-Authored-By: Claude <noreply@anthropic.com>

Abort Conditions

终止条件

STOP the pipeline and ask the user if:
  • Pre-flight finds the workspace in a broken state
  • More than 5 files need modification (scope may be too large)
  • Bootstrap mock test fails after 2 attempts
  • Full suite regression is caused by your changes
在以下情况时，停止流水线并询问用户：
  • 预检发现工作区处于损坏状态
  • 需要修改超过5个文件（范围可能过大）
  • 初始化Mock测试尝试2次后仍失败
  • 你的变更导致全量测试套件出现回归

Arguments

参数

  • $ARGUMENTS
    : What to implement
    • Example: 
      /implement add rate limiting to POST /api/search
    • Example: 
      /implement src/routes/admin/settings.ts — add PATCH endpoint for theme
    • If empty, ask the user what to implement
  • $ARGUMENTS
    : 要实现的内容
    • 示例：
      /implement add rate limiting to POST /api/search
    • 示例：
      /implement src/routes/admin/settings.ts — add PATCH endpoint for theme
    • 若为空，询问用户要实现的内容

Integration

集成说明

This skill orchestrates:
  • /tdd
    — Phase 2-4 (mock bootstrap, red, green)
  • /quality-commit
    — Phase 7 (stage + commit with gates)
Use 
/implement
instead of calling these individually for full pipeline coverage.
该技能整合了：
  • /tdd
    — 阶段2-4（Mock初始化、红阶段、绿阶段）
  • /quality-commit
    — 阶段7（暂存+门禁提交）
为了覆盖完整流水线，请使用
/implement
而非单独调用上述技能。