Back to Details

quick-implement

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Quick Implement

快速实施

Purpose

目的

Implement small features or bug fixes directly, with strict scope control and verification.
Use this skill for speed only when risk is low and requirements are clear.
直接实施小型功能或bug修复，严格控制范围并进行验证。
仅在风险低且需求明确时，为追求速度使用此skill。

Scope Gate (Required Before Coding)

范围准入（编码前必填）

Treat a task as quick-implement eligible only if all conditions below are true:
  1. Clear requirement
    • Expected behavior is explicit
    • No major product/architecture ambiguity
  2. Small change surface
    • Usually touches a small number of files (rough guideline: <= 5 files)
    • No broad cross-module refactor
  3. Low architectural risk
    • No foundational redesign
    • No migration-heavy change
    • No multi-phase rollout dependency
  4. Straightforward verification
    • Can validate with targeted tests/checks quickly
    • No long exploratory debugging loop required
If any condition fails, escalate to 
write-plan
.
只有当以下所有条件都满足时，任务才符合快速实施的资格：
  1. 需求明确
    • 预期行为清晰明确
    • 无重大产品/架构歧义
  2. 变更面小
    • 通常仅涉及少量文件（大致参考：≤5个文件）
    • 无广泛的跨模块重构
  3. 架构风险低
    • 无基础性重新设计
    • 无大量迁移类变更
    • 无多阶段发布依赖
  4. 验证简单直接
    • 可通过针对性测试/检查快速验证
    • 无需长时间探索性调试循环
如果任何条件不满足，升级为
write-plan
。

Hard Stop Escalation Criteria

强制升级标准

Immediately stop quick implementation and switch to planning when any of these appear:
  • Requirement ambiguity that needs design decisions
  • Unexpected coupling across multiple subsystems
  • Significant data model or schema changes
  • Security-sensitive or compliance-critical changes
  • Performance work requiring benchmarks/design trade-offs
  • Refactor growing beyond original small scope
  • Repeated failed attempts without a clear root cause
  • Need for phased delivery, feature flags, or migration strategy
Escalation message template:
  • "This change exceeds rapid-implementation safety limits. Recommend 
    write-plan
    first to define phased execution and risk controls."
当出现以下任何情况时，立即停止快速实施并切换到规划流程：
  • 需求存在歧义，需要设计决策
  • 多个子系统间出现意外耦合
  • 数据模型或架构有重大变更
  • 涉及安全敏感或合规关键的变更
  • 需要基准测试/设计权衡的性能优化工作
  • 重构范围超出最初的小型范围
  • 多次尝试失败且未找到明确根本原因
  • 需要分阶段交付、功能开关或迁移策略
升级消息模板：
  • "此变更超出了快速实施的安全限制。建议先执行
    write-plan
    来定义分阶段执行方案和风险控制措施。"

Workflow

工作流程

Step 1: Analyze and Contextualize

步骤1：分析与上下文梳理

  1. Understand the user request and define acceptance criteria.
  2. Review relevant project documentation first: 
    • docs/project-pdr.md
    • docs/architecture.md
    • docs/codebase.md
    • docs/code-standard.md
  3. Inspect only the minimum necessary code paths.
  4. Confirm the task still passes the Scope Gate.
  5. If ambiguity remains, ask clarifying questions before coding.
  1. 理解用户需求并定义验收标准。
  2. 首先查阅相关项目文档： 
    • docs/project-pdr.md
    • docs/architecture.md
    • docs/codebase.md
    • docs/code-standard.md
  3. 仅检查必要的最小代码路径。
  4. 确认任务仍符合范围准入条件。
  5. 若仍有歧义，在编码前先提出澄清问题。

Step 2: Implement

步骤2：实施

  1. Make the smallest correct change to satisfy requirements.
  2. Reuse existing patterns and conventions.
  3. Avoid opportunistic refactors unrelated to the request.
  4. Keep changes idempotent and safe to rerun when applicable.
  1. 做出满足需求的最小正确变更。
  2. 复用现有模式和规范。
  3. 避免进行与当前请求无关的机会主义重构。
  4. 适用时，确保变更具有幂等性且可安全重跑。

Step 3: Verify

步骤3：验证

Run proportional validation for the change:
  1. Targeted tests related to modified behavior
  2. Relevant lint/type checks for touched areas
  3. Build or runtime verification if applicable
If verification fails unexpectedly:
  • Attempt focused fixes if clearly local
  • If failures suggest broader impact, escalate to 
    write-plan
对变更进行相应的验证：
  1. 与修改行为相关的针对性测试
  2. 涉及代码区域的相关 lint/类型检查
  3. 若适用，进行构建或运行时验证
如果验证意外失败：
  • 若问题明显是局部的，尝试针对性修复
  • 若失败表明影响范围更广，升级为
    write-plan

Step 4: Complete

步骤4：完成

  1. Summarize what changed and why.
  2. List modified files.
  3. Report verification commands and outcomes.
  4. Update documentation if behavior, architecture, or domain rules changed (typically 
    docs/project-pdr.md
    , 
    docs/codebase.md
    , 
    docs/architecture.md
    ).
  1. 总结变更内容及原因。
  2. 列出修改的文件。
  3. 报告验证命令及结果。
  4. 若行为、架构或领域规则有变更，更新相关文档（通常为
    docs/project-pdr.md
    、
    docs/codebase.md
    、
    docs/architecture.md
    ）。

Execution Boundaries

执行边界

  • Do not expand scope without explicit user approval.
  • Do not assume unspecified behavior; clarify instead.
  • Do not force completion when risk increases—escalate early.
  • 未经用户明确批准，不得扩大范围。
  • 不得假设未明确说明的行为，应先澄清。
  • 当风险增加时，不得强行完成任务——尽早升级。

Output Checklist

输出检查清单

Before final response, confirm:
  • Scope Gate was satisfied
  • No hidden architectural changes were introduced
  • Verification was run and reported
  • Escalation was used if safety limits were exceeded
在最终回复前，确认：
  • 满足范围准入条件
  • 未引入隐藏的架构变更
  • 已执行并报告验证
  • 若超出安全限制，已进行升级

Integration

集成

  • Escalate to 
    write-plan
    when complexity or risk exceeds quick-implement limits.
  • Use 
    fix
    when the task is primarily debugging an issue.
  • 当复杂度或风险超出快速实施的限制时，升级为
    write-plan
    。
  • 当任务主要是调试问题时，使用
    fix
    。