Back to Details

implement

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implement

执行流程

Load the context for a task. This skill prepares the ground: the feature was validated as an issue by 
to-spec
/ 
to-tickets
; now you gather and present the context so the user can implement it.
Read 
docs/agents/domain.md
for vocabulary and respect the ADRs in the area you touch. Fetch the originating issue per 
docs/agents/issue-tracker.md
.
为任务加载上下文。该技能负责准备基础工作：功能需求已通过
to-spec
/ 
to-tickets
验证为工单；现在你需要收集并呈现上下文，以便用户进行实现。
阅读
docs/agents/domain.md
了解相关术语，并遵循你所涉及领域的ADRs。根据
docs/agents/issue-tracker.md
获取原始工单。

Process

流程步骤

  1. Understand the task. Read the spec/ticket thoroughly. Identify:
    • The problem statement and solution approach
    • User stories and acceptance criteria
    • Implementation decisions and technical constraints
    • Affected modules and their interfaces
  2. Explore the codebase surface. Map the territory:
    • Read the files the change touches
    • Trace the real flow end to end
    • Identify existing patterns, helpers, and utilities
    • Note test seams and property frameworks in use
    • Check for sibling call sites (for bug fixes)
  3. Present the context. Summarize what you found:
    • Task objective and acceptance criteria
    • Files and modules involved
    • Existing patterns to reuse
    • Test strategy and seams
    • Minimalism considerations (see 
      docs/agents/workflow.md
      )
  4. Wait for user direction. The user is in control of implementation. Present the context clearly, then wait. Do not implement unless explicitly directed.
  1. 理解任务：仔细阅读需求文档/工单。明确：
    • 问题描述与解决方案思路
    • 用户故事与验收标准
    • 实现决策与技术约束
    • 受影响的模块及其接口
  2. 探索代码库表层：梳理相关范围：
    • 阅读变更涉及的文件
    • 追踪完整的实际流程
    • 识别现有模式、辅助工具与实用程序
    • 记录当前使用的测试切入点和属性框架
    • 检查同类调用位置（针对bug修复场景）
  3. 呈现上下文：总结你的发现：
    • 任务目标与验收标准
    • 涉及的文件与模块
    • 可复用的现有模式
    • 测试策略与切入点
    • 极简主义考量（参考
      docs/agents/workflow.md
      ）
  4. 等待用户指令：由用户掌控实现过程。清晰呈现上下文后等待，除非明确收到指令，否则不要进行实现。

Minimalism discipline (reference)

极简主义准则（参考）

The minimalism discipline is always on (see 
docs/agents/workflow.md
for the canonical ladder): stop at the first rung that holds — (1) does this need to exist? (YAGNI) → skip; (2) already in this codebase? → reuse; (3) stdlib does it? → use it; (4) native platform feature? → use it; (5) installed dependency? → use it; (6) one line? → one line; (7) only then the minimum that works.
Never cut validation, error handling, security, or accessibility.
始终遵循极简主义准则（参考
docs/agents/workflow.md
中的标准流程）：停在第一个可行的层级——(1) 是否真的需要这个功能？（YAGNI原则）→ 跳过；(2) 代码库中已有实现？→ 复用；(3) 标准库支持？→ 使用标准库；(4) 原生平台特性支持？→ 使用原生特性；(5) 已安装的依赖支持？→ 使用依赖；(6) 一行代码可实现？→ 用一行代码；(7) 仅在此时编写满足需求的最小实现。
绝不能省略验证、错误处理、安全或可访问性相关代码。

Bug fixes (context-loading mode)

Bug修复（上下文加载模式）

A ticket names a symptom. Before presenting context, find every caller of the affected function and present the root cause location where all callers route through — one guard in the shared function, not one in every caller. Note the regression test strategy.
工单会描述问题症状。在呈现上下文之前，找到受影响函数的所有调用方，并指出所有调用方共同经过的根本原因位置——在共享函数中添加一处防护，而非在每个调用方中分别添加。同时记录回归测试策略。

Boundaries

边界限制

Loads context for one spec/ticket. Sized to a single context window — if it doesn't fit, it should have been split by 
to-tickets
. Does not implement unless explicitly directed by the user. Does not self-merge or land the stack.
只为一个需求文档/工单加载上下文。内容规模需适配单个上下文窗口——如果无法适配，说明该工单应由
to-tickets
拆分。除非用户明确指令，否则不进行实现。不自动合并或提交代码栈。