Back to Details

acceptance-criteria-define

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Acceptance Criteria: Define

验收标准：定义

Step 0: Check for Context

步骤0：检查上下文

If no request or task description was provided as context (the skill was invoked with no arguments and nothing in the conversation describes a feature, task, or plan to evaluate):
  • Output: "This skill needs a request or task description as context. Please describe the feature or task you want acceptance criteria for, or point me to a plan file."
  • STOP — do not continue.
如果没有提供请求或任务描述作为上下文（调用本技能时未携带任何参数，且对话中没有描述需要评估的功能、任务或计划）：
  • 输出："本技能需要请求或任务描述作为上下文。请描述你需要生成验收标准的功能或任务，或者指向对应的计划文件。"
  • 停止 — 不要继续执行。

Step 1: Identify the Plan File (if any)

步骤1：识别计划文件（如果存在）

Check whether the context references an implementation plan file:
  • Look for a file path ending in 
    .md
    mentioned in the request or conversation (e.g., 
    .agents/plans/feature-name.md
    )
  • Look for any 
    .agents/plans/*.md
    file that matches the feature being discussed
If a plan file is identified:
  • Read the entire plan file now
  • Scan for an existing 
    ## ACCEPTANCE CRITERIA
    or 
    ## Acceptance Criteria
    section
  • If found, extract and note the existing criteria — these are your starting point
  • Also scan the 
    ## TESTING STRATEGY
    , 
    ## VALIDATION COMMANDS
    , and 
    ## Feature Description
    sections to understand the full scope
If no plan file:
  • Proceed with the request description from conversation context only
检查上下文中是否提到了实现计划文件：
  • 查找请求或对话中提到的以
    .md
    结尾的文件路径（例如 
    .agents/plans/feature-name.md
    ）
  • 查找与正在讨论的功能匹配的任意
    .agents/plans/*.md
    文件
如果识别到计划文件：
  • 立即读取整个计划文件
  • 扫描是否存在已有的
    ## ACCEPTANCE CRITERIA
    或
    ## Acceptance Criteria
    章节
  • 如果找到，提取并记录现有标准 —— 这些就是你的起点
  • 同时扫描
    ## TESTING STRATEGY
    、
    ## VALIDATION COMMANDS
    和
    ## Feature Description
    章节，以了解完整的范围
如果没有计划文件：
  • 仅使用对话上下文中的请求描述继续执行

Step 2: Derive Acceptance Criteria

步骤2：推导验收标准

Based on the context (plan file, feature description, or request in conversation), derive the acceptance criteria.
Think through each of these dimensions and produce criteria for whichever apply:
基于上下文（计划文件、功能描述或对话中的请求）推导验收标准。
从以下各个维度思考，为适用的维度生成标准：

Functional Correctness

功能正确性

  • What must the feature actually do? (the happy paths)
  • What inputs/outputs define success?
  • What specific behaviors are required vs. optional?
  • 该功能实际必须实现哪些能力？（正常流程）
  • 哪些输入/输出定义了成功状态？
  • 哪些是必填行为，哪些是可选行为？

Error Handling & Edge Cases

错误处理与边界场景

  • What happens on bad input, missing data, or failures?
  • What state should the system be in after an error?
  • 遇到错误输入、数据缺失或故障时会发生什么？
  • 错误发生后系统应处于什么状态？

Integration & End-to-End Flow

集成与端到端流程

  • What connected systems must work together for the feature to be considered complete?
  • What does "it works" look like from the user's perspective end-to-end?
  • 要认为功能已完成，哪些关联系统必须协同工作？
  • 从用户的端到端视角来看，“正常运行”是什么样的？

Validation & Test Coverage

验证与测试覆盖

  • Which test levels are required: unit, integration, E2E?
  • What automated validation commands should pass before accepting the work?
  • Are there manual steps required for final verification?
  • 需要哪些测试层级：单元测试、集成测试、端到端测试？
  • 验收工作前，哪些自动化验证命令必须通过？
  • 最终验证是否需要手动步骤？

Non-Functional Requirements

非功能性需求

  • Performance: any latency, throughput, or load requirements?
  • Security: any auth, data handling, or secret management requirements?
  • Observability: logging, error reporting, tracing requirements?
  • 性能：是否有延迟、吞吐量或负载要求？
  • 安全：是否有身份验证、数据处理或密钥管理要求？
  • 可观测性：日志、错误上报、链路追踪的要求？

Not In Scope

不包含范围

  • Explicitly list what is NOT expected — this prevents scope creep during review
Format each criterion as a concrete, testable statement, not a vague goal.
Good: "The 
/mcp/mcp
endpoint returns HTTP 200 with a valid MCP tools list when the server is running" Bad: "The server should work correctly"
  • 明确列出不期望实现的内容 —— 这可以防止评审过程中出现范围蔓延
将每个标准格式化为具体的、可测试的陈述，而不是模糊的目标。
正面示例："服务器运行时，
/mcp/mcp
端点返回HTTP 200状态码及有效的MCP工具列表" 反面示例："服务器应该正常运行"

Step 3: Present Criteria to User

步骤3：向用户展示标准

Output your derived criteria in a clear, readable list. Use this format:
undefined
以清晰易读的列表形式输出你推导的标准。使用以下格式：
undefined

Proposed Acceptance Criteria

Proposed Acceptance Criteria

Functional

Functional

  • <criterion>
  • <criterion>
  • <criterion>
  • <criterion>

Error Handling

Error Handling

  • <criterion>
  • <criterion>

Integration / E2E

Integration / E2E

  • <criterion>
  • <criterion>

Validation

Validation

  • <criterion> — verified by: 
    <command or test>
  • <criterion> — verified by: 
    <command or test>

Out of Scope

Out of Scope

  • <item> — not required for this task

Then use **AskUserQuestion** to ask the user:

Question: "Do these acceptance criteria look right, or would you like to define them yourself?"
Options:
1. "Looks good — use these" — proceed with the proposed criteria as-is
2. "I want to add/change something" — user will provide modifications in free text
3. "Let me define them myself" — skip the proposed criteria entirely and wait for the user to write their own

---
  • <item> — not required for this task

然后使用**AskUserQuestion**向用户询问：

问题："这些验收标准是否合适，还是你希望自行定义？"
选项：
1. "看起来没问题 —— 使用这些标准" —— 直接按提议的标准继续执行
2. "我想要添加/修改部分内容" —— 用户会以自由文本形式提供修改意见
3. "让我自行定义" —— 完全跳过提议的标准，等待用户自行撰写

---

Step 4: Finalize the Criteria

步骤4：确定最终标准

If user selected option 1 (use as-is):
  • Use the proposed criteria verbatim
If user selected option 2 (add/change):
  • Read the user's modifications from their reply
  • Merge them with the proposed criteria:
    • Additions: append to the relevant section
    • Changes: replace the relevant criteria
    • Removals: remove any criteria the user rejected
  • Output the final merged list to the user before writing
If user selected option 3 (define themselves):
  • Wait for the user to provide the criteria
  • Do not invent or add criteria they did not provide
  • Use exactly what the user wrote
如果用户选择选项1（直接使用）：
  • 逐字使用提议的标准
如果用户选择选项2（添加/修改）：
  • 从用户回复中读取修改意见
  • 将其与提议的标准合并：
    • 新增内容：追加到对应章节
    • 修改内容：替换对应的标准
    • 删除内容：移除用户拒绝的所有标准
  • 写入前向用户输出最终合并后的列表
如果用户选择选项3（自行定义）：
  • 等待用户提供标准
  • 不要自行创建或添加用户未提供的标准
  • 完全使用用户撰写的内容

Step 5: Write the Criteria

步骤5：写入标准

Case A: A plan file was identified

场景A：已识别到计划文件

Rewrite the 
## ACCEPTANCE CRITERIA
section at the bottom of the plan file.
  • If the section already exists: replace its entire contents with the final criteria
  • If the section does not exist: append it before 
    ## COMPLETION CHECKLIST
    if that section exists, otherwise at the very end of the file
  • Use the exact heading 
    ## ACCEPTANCE CRITERIA
  • Format each criterion as a 
    - [ ]
    checkbox item
  • Include the "Out of Scope" list as a plain bullet list (not checkboxes) under a 
    ### Out of Scope
    subsection
Use the Edit tool to make this change — read the file first if you have not already.
After writing, output: "Acceptance criteria written to 
<plan-file-path>
."
重写计划文件底部的
## ACCEPTANCE CRITERIA
章节。
  • 如果该章节已存在：将其全部内容替换为最终标准
  • 如果该章节不存在：如果存在
    ## COMPLETION CHECKLIST
    章节，则追加到该章节之前，否则追加到文件末尾
  • 使用精确的标题
    ## ACCEPTANCE CRITERIA
  • 将每个标准格式化为
    - [ ]
    复选框项
  • 将“不包含范围”列表作为纯无序列表（不是复选框）放在
    ### Out of Scope
    子章节下
使用Edit工具进行修改 —— 如果你还没有读取文件，请先读取文件。
写入完成后，输出："验收标准已写入
<plan-file-path>
。"

Case B: No plan file — write to 
acceptance_criteria.md

场景B：没有计划文件 —— 写入到
acceptance_criteria.md

Check if 
acceptance_criteria.md
exists in 
.agents/
(preferred) or the project root.
检查
acceptance_criteria.md
是否存在于
.agents/
目录（优先）或项目根目录。

If the file does NOT exist:

如果文件不存在：

Create 
.agents/acceptance_criteria.md
with this structure:
markdown
undefined
创建
.agents/acceptance_criteria.md
，结构如下：
markdown
undefined

Acceptance Criteria

Acceptance Criteria

<short title derived from the request> — <date>

<short title derived from the request> — <date>

Context

Context

<2–4 sentence summary of the request or feature this criteria applies to>
<2–4 sentence summary of the request or feature this criteria applies to>

Criteria

Criteria

Functional

Functional

  • <criterion>
  • <criterion>

Error Handling

Error Handling

  • <criterion>
  • <criterion>

Integration / E2E

Integration / E2E

  • <criterion>
  • <criterion>

Validation

Validation

  • <criterion> — verified by: 
    <command>
  • <criterion> — verified by: 
    <command>

Out of Scope

Out of Scope

  • <item> 
undefined
  • <item> 
undefined

If the file ALREADY EXISTS:

如果文件已存在：

Read the file first. Append a new section after the last existing section:
markdown
---
先读取文件。在最后一个现有章节之后追加新的章节：
markdown
---

<short title derived from the request> — <date>

<short title derived from the request> — <date>

Context

Context

<summary>
<summary>

Criteria

Criteria

...

Do NOT modify any existing sections.

After writing, output: "Acceptance criteria written to `.agents/acceptance_criteria.md`."

---
...

不要修改任何现有章节。

写入完成后，输出："验收标准已写入`.agents/acceptance_criteria.md`。"

---

Step 6: Summary

步骤6：总结

Output a brief confirmation:
Acceptance criteria saved.

File: <path>
Criteria: <N> items
Next step: Run /execute <plan-file> to implement, or share the criteria with the agent executing this work.
If this skill was invoked as part of a planning or execution flow, return control to the calling skill now.
输出简短的确认信息：
Acceptance criteria saved.

File: <path>
Criteria: <N> items
Next step: Run /execute <plan-file> to implement, or share the criteria with the agent executing this work.
如果本技能是作为规划或执行流程的一部分被调用的，现在将控制权交还给调用方技能。