start-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Start Task

启动任务

Overview

概述

Begin development on a task with proper setup and pre-flight checks.

通过正确的环境配置和预检检查，开始任务开发工作。

Definitions

定义

{TASK_KEY}: Story/Issue ID from the issue tracker (e.g.,
```
FB-6
```
,
```
PROJ-123
```
,
```
KAN-42
```
)
Branch Name Format: Use short format
```
{type}/{TASK_KEY}
```
(e.g.,
```
feat/FB-6
```
,
```
fix/PROJ-123
```
)
- Short format is recommended:
```
feat/FB-6
```
  (not
```
feat/FB-6-file-watching-workspace-commands
```
  )
- Important: Be consistent within a project - use the same format for all branches

{TASK_KEY}: 来自问题追踪系统的需求/问题ID（例如：
```
FB-6
```
,
```
PROJ-123
```
,
```
KAN-42
```
）
分支命名格式: 使用短格式
```
{type}/{TASK_KEY}
```
（例如：
```
feat/FB-6
```
,
```
fix/PROJ-123
```
）
- 推荐使用短格式：
```
feat/FB-6
```
  （而非
```
feat/FB-6-file-watching-workspace-commands
```
  ）
- 重要提示: 在项目内保持一致性 - 所有分支使用相同的命名格式

Prerequisites

前置条件

Before proceeding, verify (see Steps 1–2 for how):

MCP Status Validation: All required MCP servers connected and authorized. If any fail, STOP.
- MCP Tool Usage Standards: MCP tool usage should follow best practices (check schema files, validate parameters, handle errors gracefully). These standards are documented in AGENTS.md §3 Operational Boundaries if AGENTS.md exists, but apply universally regardless.

Spec or Plan exists: At least one of

specs/{FEATURE_DOMAIN}/spec.md

.plans/{TASK_KEY}-*.plan.md

. If neither, STOP and suggest

/create-plan {TASK_KEY}

Story in In Progress (or can be transitioned) and assigned to current user.

开始前，请验证以下内容（步骤1-2为验证方法）：

MCP状态验证: 所有必需的MCP服务器已连接并授权。如果任何服务器验证失败，请立即停止。
- MCP工具使用标准: MCP工具的使用应遵循最佳实践（检查 schema 文件、验证参数、优雅处理错误）。这些标准已记录在 AGENTS.md §3 操作边界中（如果AGENTS.md存在），无论该文件是否存在，标准均通用。
存在规格说明或计划: 至少存在
```
specs/{FEATURE_DOMAIN}/spec.md
```
或
```
.plans/{TASK_KEY}-*.plan.md
```
中的一个。如果两者都不存在，请停止并建议执行
```
/create-plan {TASK_KEY}
```
。
需求处于进行中状态（或可切换至该状态）且已分配给当前用户。

Steps

步骤

Pre-flight checks
- MCP Status Validation: Perform MCP server status checks (see
```
mcp-status.md
```
  for detailed steps)
  - Test each configured MCP server connection
  - Verify all required integrations are authorized and operational
  - If any MCP server fails validation, STOP and report the failure. Do not proceed.
- Read relevant documents:
  - First, check for Spec: Look for related spec in
```
specs/{FEATURE_DOMAIN}/spec.md
```
    - If feature spec exists, read Blueprint for architectural constraints and Anti-Patterns
    - Read Contract for Definition of Done and Regression Guardrails
    - Specs provide permanent context for how the feature works
  - Then, read Plan (if exists): Look for task plan at
```
.plans/{TASK_KEY}-*.plan.md
```
    - Plan File Selection: If multiple files match the pattern
      .plans/{TASK_KEY}-*.plan.md
      :
      - Use the most recently modified file (check file modification time)
      - If modification time cannot be determined, use the first file found alphabetically
      - Report which file was selected: "Using plan file: {filename}"
    - Plans provide transient task-level implementation steps
    - If no plan and no spec exist, STOP and report error: "No plan or spec found for {TASK_KEY}. Run
      /create-plan {TASK_KEY}
      first."
- Verify story is in "In Progress"
  - Fetch story status using
```
mcp_atlassian_getJiraIssue
```
  - If status is NOT "In Progress":
    1. Get available transitions using
      mcp_atlassian_getTransitionsForJiraIssue
    2. Find transition to "In Progress" status
    3. Transition using
      mcp_atlassian_transitionJiraIssue
    4. Verify transition succeeded
  - If transition fails or "In Progress" status not available:
    - STOP and report: "Story {TASK_KEY} cannot be moved to 'In Progress'. Current status: {status}. Available transitions: {list}"
- Confirm story is assigned to current user
Set up development environment
- Determine branch type prefix based on task type:
  - Story →
```
feat/{TASK_KEY}
```
  - Bug →
```
fix/{TASK_KEY}
```
  - Task/Chore →
```
chore/{TASK_KEY}
```
  - Refactor →
```
refactor/{TASK_KEY}
```
  - Default to
```
feat/{TASK_KEY}
```
    if task type is unclear
- First, check if branch already exists:
  - Use
```
mcp_github_list_branches
```
    to list existing branches
  - Or use
```
run_terminal_cmd
```
    :
```
git branch -a | grep {type}/{TASK_KEY}
```
  - If branch exists:
    - Ask user: "Branch {type}/{TASK_KEY} already exists. Use existing branch or create new one?"
    - If "use existing": Checkout existing branch
    - If "create new": Use different name or delete old branch first
- If branch doesn't exist:
  - Create locally:
```
git checkout -b {type}/{TASK_KEY}
```
  - Or create on remote first:
```
mcp_github_create_branch
```
    (if remote-first workflow)
- Add work checklist comment to issue (include the actual branch name created):
  - Timing: Post immediately after branch creation, before starting implementation
  - This provides visibility that work has begun
  - Include the actual branch name created (e.g.,
```
feat/FB-6
```
    )
Implement according to spec and plan
- Read and understand documents:
  - Spec (if exists): Review Blueprint for design constraints, read Contract for acceptance criteria
  - Plan (if exists): Review implementation steps, identify files to create/modify
  - Understand dependencies and order
- Analyze existing codebase:
  - Use
```
codebase_search
```
    to find related code
  - Review similar implementations for patterns
  - Understand existing test structure
- Implement changes:
  - Create new files as specified
  - Modify existing files as needed
  - Follow existing code patterns and conventions
  - Respect Anti-Patterns from Spec (if spec exists)
- Write tests alongside code:
  - Create test files for new code
  - Update existing tests for modified code
  - Use Spec's Contract scenarios for test cases (if spec exists)
  - Ensure tests follow existing test patterns
- Update Spec if behavior changes:
  - If code changes API contracts, data models, or quality targets → update Spec
  - Spec updates must be committed in same commit as code changes (Same-Commit Rule)
  - See
```
specs/README.md
```
    for when to update specs
- Leave changes uncommitted for review:
  - Do NOT commit changes automatically
  - Changes remain in working directory for developer review and testing
  - Developer can review, test, and commit changes manually or use
```
/complete-task
```
    to commit and push

预检检查
- MCP状态验证: 执行MCP服务器状态检查（详细步骤请参考
```
mcp-status.md
```
  ）
  - 测试每个已配置的MCP服务器连接
  - 验证所有必需的集成已授权且可正常运行
  - 如果任何MCP服务器验证失败，请停止并上报故障，切勿继续。
- 阅读相关文档:
  - 首先，检查规格说明: 在
```
specs/{FEATURE_DOMAIN}/spec.md
```
    中查找相关规格
    - 如果功能规格存在，阅读蓝图部分了解架构约束和反模式
    - 阅读契约部分了解完成定义和回归防护规则
    - 规格说明提供了功能工作方式的永久上下文
  - 然后，阅读计划（如果存在）: 在
```
.plans/{TASK_KEY}-*.plan.md
```
    中查找任务计划
    - 计划文件选择: 如果有多个文件匹配
      .plans/{TASK_KEY}-*.plan.md
      模式:
      - 使用最近修改的文件（检查文件修改时间）
      - 如果无法确定修改时间，使用按字母顺序找到的第一个文件
      - 上报所选文件："正在使用计划文件: {filename}"
    - 计划文件提供了任务级别的临时实现步骤
    - 如果既无计划也无规格说明，请停止并上报错误: "未找到 {TASK_KEY} 的计划或规格说明。请先运行
      /create-plan {TASK_KEY}
      。"
- 验证需求处于"进行中"状态
  - 使用
```
mcp_atlassian_getJiraIssue
```
    获取需求状态
  - 如果状态不是"进行中":
    1. 使用
      mcp_atlassian_getTransitionsForJiraIssue
      获取可用的状态切换选项
    2. 找到切换至"进行中"的选项
    3. 使用
      mcp_atlassian_transitionJiraIssue
      执行状态切换
    4. 验证切换是否成功
  - 如果切换失败或"进行中"状态不可用:
    - 停止并上报: "需求 {TASK_KEY} 无法切换至'进行中'状态。当前状态: {status}。可用切换选项: {list}"
- 确认需求已分配给当前用户
配置开发环境
- 根据任务类型确定分支类型前缀:
  - 需求 →
```
feat/{TASK_KEY}
```
  - 缺陷 →
```
fix/{TASK_KEY}
```
  - 任务/杂项 →
```
chore/{TASK_KEY}
```
  - 重构 →
```
refactor/{TASK_KEY}
```
  - 如果任务类型不明确，默认使用
```
feat/{TASK_KEY}
```
- 首先，检查分支是否已存在:
  - 使用
```
mcp_github_list_branches
```
    列出已有分支
  - 或使用
```
run_terminal_cmd
```
    :
```
git branch -a | grep {type}/{TASK_KEY}
```
  - 如果分支已存在:
    - 询问用户: "分支 {type}/{TASK_KEY} 已存在。使用现有分支还是创建新分支？"
    - 如果选择"使用现有": 检出现有分支
    - 如果选择"创建新分支": 使用不同名称或先删除旧分支
- 如果分支不存在:
  - 在本地创建:
```
git checkout -b {type}/{TASK_KEY}
```
  - 或先在远程创建:
```
mcp_github_create_branch
```
    （如果采用远程优先工作流）
- 在问题中添加工作清单评论（包含实际创建的分支名称）:
  - 时机: 分支创建后立即发布，在开始实现之前
  - 此举可让团队知晓工作已启动
  - 包含实际创建的分支名称（例如：
```
feat/FB-6
```
    ）
根据规格说明和计划实现功能
- 阅读并理解文档:
  - 规格说明（如果存在）: 回顾蓝图部分了解设计约束，阅读契约部分了解验收标准
  - 计划（如果存在）: 回顾实现步骤，确定需要创建/修改的文件
  - 理解依赖关系和执行顺序
- 分析现有代码库:
  - 使用
```
codebase_search
```
    查找相关代码
  - 回顾类似实现的模式
  - 理解现有测试结构
- 实现变更:
  - 按要求创建新文件
  - 根据需要修改现有文件
  - 遵循现有代码模式和规范
  - 遵循规格说明中的反模式要求（如果规格说明存在）
- 随代码编写测试:
  - 为新代码创建测试文件
  - 为修改的代码更新现有测试
  - 使用规格说明契约中的场景作为测试用例（如果规格说明存在）
  - 确保测试遵循现有测试模式
- 如果行为变更，更新规格说明:
  - 如果代码修改了API契约、数据模型或质量目标 → 更新规格说明
  - 规格说明的更新必须与代码变更提交在同一个提交中（同提交规则）
  - 何时更新规格说明请参考
```
specs/README.md
```
- 保留未提交的变更供评审:
  - 请勿自动提交变更
  - 变更保留在工作目录中，供开发者评审和测试
  - 开发者可手动评审、测试并提交变更，或使用
```
/complete-task
```
    命令提交并推送

Tools

工具

MCP Tools (Atlassian)

MCP工具（Atlassian）

```
mcp_atlassian_atlassianUserInfo
```
- Verify Atlassian MCP connection
Obtaining CloudId for Atlassian Tools:
- Method 1 (Recommended): Use
```
mcp_atlassian_getAccessibleAtlassianResources
```
  - Returns list of accessible resources with
```
cloudId
```
    values
  - Use the first result or match by site name
  - Only call if cloudId is not already known or has expired
- Method 2: Extract from Atlassian URLs
  - Jira URL format:
```
https://{site}.atlassian.net/...
```
  - CloudId can be extracted from the URL or obtained via API
- Error Handling: If cloudId cannot be determined, STOP and report: "Unable to determine Atlassian cloudId. Please verify MCP configuration."
```
mcp_atlassian_getJiraIssue
```
- Fetch story details by {TASK_KEY}
- Parameters:
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY}

mcp_atlassian_getTransitionsForJiraIssue

- Get available status transitions

Parameters:
```
cloudId
```
,
```
issueIdOrKey
```
= {TASK_KEY}

```
mcp_atlassian_transitionJiraIssue
```
- Transition issue to "In Progress" (if needed)
- Parameters:
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY},
```
transition
```
  = {id: "transition-id"}
```
mcp_atlassian_addCommentToJiraIssue
```
- Add work checklist comment to issue
- Parameters:
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY},
```
commentBody
```
  = markdown checklist

```
mcp_atlassian_atlassianUserInfo
```
- 验证Atlassian MCP连接
获取Atlassian工具的CloudId:
- 方法1（推荐）: 使用
```
mcp_atlassian_getAccessibleAtlassianResources
```
  - 返回包含
```
cloudId
```
    值的可用资源列表
  - 使用第一个结果或按站点名称匹配
  - 仅在cloudId未知或过期时调用
- 方法2: 从Atlassian URL中提取
  - Jira URL格式:
```
https://{site}.atlassian.net/...
```
  - CloudId可从URL中提取或通过API获取
- 错误处理: 如果无法确定cloudId，请停止并上报: "无法确定Atlassian cloudId。请验证MCP配置。"
```
mcp_atlassian_getJiraIssue
```
- 根据 {TASK_KEY} 获取需求详情
- 参数:
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY}

mcp_atlassian_getTransitionsForJiraIssue

- 获取可用的状态切换选项

参数:
```
cloudId
```
,
```
issueIdOrKey
```
= {TASK_KEY}

```
mcp_atlassian_transitionJiraIssue
```
- 将问题切换至"进行中"状态（如有需要）
- 参数:
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY},
```
transition
```
  = {id: "transition-id"}
```
mcp_atlassian_addCommentToJiraIssue
```
- 为问题添加工作清单评论
- 参数:
```
cloudId
```
  ,
```
issueIdOrKey
```
  = {TASK_KEY},
```
commentBody
```
  = markdown格式的清单

MCP Tools (GitHub)

MCP工具（GitHub）

A lightweight read-only GitHub MCP tool to verify connection (see Cursor Settings → Tools & MCP for exact names; e.g. a list/read tool)
```
mcp_github_list_branches
```
- List existing branches (check if branch already exists)

mcp_github_create_branch

- Create new branch on remote

Parameters:

owner

repo

branch

{type}/{TASK_KEY}

from_branch

main

(or default branch)

轻量级只读GitHub MCP工具，用于验证连接（具体名称请参考Cursor设置 → 工具与MCP；例如：列表/读取工具）
```
mcp_github_list_branches
```
- 列出已有分支（检查分支是否已存在）

mcp_github_create_branch

- 在远程创建新分支

参数:

owner

repo

branch

{type}/{TASK_KEY}

from_branch

main

（或默认分支）

Filesystem Tools

文件系统工具

glob_file_search

- Find specs matching

specs/{FEATURE_DOMAIN}/spec.md

or plans matching

.plans/{TASK_KEY}-*.plan.md

Pattern for plans:
```
**/.plans/{TASK_KEY}-*.plan.md
```
Pattern for specs:
```
**/specs/*/spec.md
```

read_file

- Read spec/plan files and existing code

Spec location:
```
specs/{FEATURE_DOMAIN}/spec.md
```
Plan location:
```
.plans/{TASK_KEY}-{description}.plan.md
```

```
write
```
- Create new files
```
search_replace
```
- Modify existing files (including specs when behavior changes)
```
list_dir
```
- Explore directory structure

glob_file_search

- 查找匹配

specs/{FEATURE_DOMAIN}/spec.md

的规格说明或匹配

.plans/{TASK_KEY}-*.plan.md

的计划

计划文件匹配模式:
```
**/.plans/{TASK_KEY}-*.plan.md
```
规格说明匹配模式:
```
**/specs/*/spec.md
```

```
read_file
```
- 读取规格说明/计划文件和现有代码
- 规格说明位置:
```
specs/{FEATURE_DOMAIN}/spec.md
```
- 计划文件位置:
```
.plans/{TASK_KEY}-{description}.plan.md
```
```
write
```
- 创建新文件
```
search_replace
```
- 修改现有文件（包括行为变更时的规格说明）
```
list_dir
```
- 浏览目录结构

Codebase Tools

代码库工具

```
codebase_search
```
- Search for similar implementations, patterns, or related code
- Query: "How is [similar feature] implemented?"
- Query: "Where is [component] used?"
```
grep
```
- Find specific patterns, functions, or classes
- Pattern: function names, class names, imports, etc.

```
codebase_search
```
- 查找类似实现、模式或相关代码
- 查询示例: "[类似功能] 是如何实现的？"
- 查询示例: "[组件] 在哪里被使用？"
```
grep
```
- 查找特定模式、函数或类
- 匹配模式: 函数名、类名、导入语句等

Terminal Tools

终端工具

```
run_terminal_cmd
```
- Execute git commands
- ```
git status
```
  - Check current branch and status
- ```
git checkout -b {type}/{TASK_KEY}
```
  - Create and checkout new branch locally
- ```
git branch
```
  - List branches
- Note: Committing changes is handled in
```
/complete-task
```
  , not in this command

```
run_terminal_cmd
```
- 执行git命令
- ```
git status
```
  - 检查当前分支和状态
- ```
git checkout -b {type}/{TASK_KEY}
```
  - 在本地创建并检出新分支
- ```
git branch
```
  - 列出分支
- 注意: 提交变更由
```
/complete-task
```
  命令处理，本命令不负责提交

Pre-flight Checklist

预检清单

MCP status validation performed (see
```
mcp-status.md
```
)
All MCP servers connected and authorized
Relevant docs checked (spec and/or plan)
Spec read (if exists) - Blueprint and Contract sections
Plan read (if exists) - implementation steps
Story status is "In Progress"
Story assigned to current user
Feature branch created
Branch checked out locally
Work checklist posted to issue

已执行MCP状态验证（参考
```
mcp-status.md
```
）
所有MCP服务器已连接并授权
已检查相关文档（规格说明和/或计划）
已阅读规格说明（如果存在）- 蓝图和契约部分
已阅读计划（如果存在）- 实现步骤
需求状态为"进行中"
需求已分配给当前用户
已创建功能分支
已在本地检出分支
已在问题中发布工作清单

Implementation Checklist

实现清单

Guidance

指导原则

Role

角色

Act as a software engineer responsible for beginning development work on a task. You are methodical, thorough, and follow established development workflows and standards.

作为负责启动任务开发工作的软件工程师，你需要有条理、细致，并遵循既定的开发工作流和标准。

Instruction

指令

Execute the start-task workflow to begin development on a specified task. This includes:

Performing pre-flight validation checks
Setting up the development environment (branch creation, issue updates)
Implementing work according to the plan
Following all established conventions and standards

执行启动任务工作流，开始指定任务的开发。包括：

执行预检验证检查
配置开发环境（分支创建、问题更新）
根据计划实现工作
遵循所有既定的规范和标准

Context

上下文

The task is tracked in an issue management system (Jira, Azure DevOps, etc.)
Specs may exist at
```
specs/{FEATURE_DOMAIN}/spec.md
```
with permanent feature contracts
Plans may exist at
```
.plans/{TASK_KEY}-*.plan.md
```
with transient task-level implementation steps
Specs define State (how feature works), Plans define Delta (what changes)
The task should already be in "In Progress" status and assigned to the current user
MCP integrations provide access to issue trackers and version control
The codebase has existing patterns, conventions, and architectural decisions that should be respected
Same-Commit Rule: If code changes behavior/contracts, update spec in same commit
ASDLC patterns: The Spec, The PBI, Context Gates
ASDLC pillars: Factory Architecture (command station), Quality Control (pre-flight gates)

任务在问题管理系统（Jira、Azure DevOps等）中追踪
规格说明可能存储在
```
specs/{FEATURE_DOMAIN}/spec.md
```
，包含永久的功能契约
计划可能存储在
```
.plans/{TASK_KEY}-*.plan.md
```
，包含临时的任务级实现步骤
规格说明定义状态（功能如何工作），计划定义增量（需要变更什么）
任务应已处于"进行中"状态并分配给当前用户
MCP集成提供对问题追踪系统和版本控制的访问
代码库已有既定的模式、规范和架构决策，需遵循这些内容
同提交规则: 如果代码变更了行为/契约，需在同一个提交中更新规格说明
ASDLC模式: The Spec, The PBI, Context Gates
ASDLC支柱: 工厂架构（命令站）、质量控制（预检门）

Examples

示例

ASDLC: Context Gates — MCP and plan checks act as input gates before implementation.

Example Branch Names:

```
feat/PROJ-123
```
(story/feature)
```
fix/PROJ-456
```
(bug fix)
```
chore/PROJ-789
```
(maintenance task)
```
refactor/PROJ-321
```
(refactoring)

Note on Commits: Changes are left uncommitted in this command. Use

/complete-task

to commit, push, and optionally create a PR when ready.

Example Issue Comment (Work Checklist):

undefined

ASDLC: Context Gates — MCP和计划检查是实现前的输入门控。

分支名称示例:

```
feat/PROJ-123
```
（需求/功能）
```
fix/PROJ-456
```
（缺陷修复）
```
chore/PROJ-789
```
（维护任务）
```
refactor/PROJ-321
```
（重构）

关于提交的说明: 本命令中变更不会被提交。准备好后使用

/complete-task

命令提交、推送并可选创建PR。

问题评论示例（工作清单）:

undefined

Work Checklist

工作清单

Plan reviewed
Branch created:
```
feat/PROJ-123
```
Implementation in progress
Code changes in progress
Tests being written
Documentation updated


Note: The branch name in the comment must match the actual branch name created (including the type prefix).

已回顾计划
已创建分支:
```
feat/PROJ-123
```
实现工作进行中
代码变更进行中
正在编写测试
已更新文档


注意: 评论中的分支名称必须与实际创建的分支名称一致（包括类型前缀）。

Constraints

约束

Rules (Must Follow):

Operational Standards Compliance: This command follows operational standards (documented in AGENTS.md if present, but apply universally):
- MCP Tool Usage: Check schema files, validate parameters, handle errors gracefully
- Safety Limits: Never commit secrets, API keys, or sensitive data. Never commit changes automatically without user review.
- AGENTS.md Optional: Commands work without AGENTS.md. Standards apply regardless of whether AGENTS.md exists.
- See AGENTS.md §3 Operational Boundaries (if present) for detailed standards
Read Spec First (if exists): Check for feature spec in
```
specs/
```
and read Blueprint + Contract before implementation
Respect Anti-Patterns: If spec exists, do NOT implement forbidden approaches listed in Anti-Patterns section
Same-Commit Rule: If code changes API contracts, data models, or quality targets → update spec in same commit
Unit Tests Required: All new code must have corresponding unit tests. Use Contract scenarios from spec (if exists) for test cases.
No Automatic Commits: Do NOT commit changes automatically. Leave changes uncommitted for developer review and testing. Committing is handled by
```
/complete-task
```
.
Branch Naming: Use short format:
```
{type}/{TASK_KEY}
```
(e.g.,
```
feat/FB-6
```
,
```
fix/PROJ-123
```
)
- Determine type prefix from task type:
  - Story →
```
feat/
```
  - Bug →
```
fix/
```
  - Task/Chore →
```
chore/
```
  - Refactor →
```
refactor/
```
  - Default to
```
feat/
```
    if task type is unclear
- Example: Story FB-6 →
```
feat/FB-6
```
  (short format, not descriptive format)
- Important: Be consistent - use short format for all branches
Pre-flight Validation: Do not proceed if:
- MCP status validation fails (see
```
mcp-status.md
```
  for validation steps - if any MCP server is not connected or authorized, STOP immediately)
- Neither spec nor plan exists (STOP and suggest running
```
/create-plan {TASK_KEY}
```
  first)
- Story is not in "In Progress" status
- Story is not assigned to current user
Code Quality:
- Follow existing code patterns and conventions
- Maintain or improve test coverage
Documentation: Update relevant documentation when adding features or changing behavior

Existing Standards (Reference):

MCP status validation: See
```
mcp-status.md
```
for detailed MCP server connection checks
Spec guidance: See
```
specs/README.md
```
for when to update specs and Same-Commit Rule
Branch naming: Type prefix format (
```
{type}/{TASK_KEY}
```
) as shown in current workflow
Test requirements: Tests written alongside code (per Implementation Checklist)
Commit workflow: Changes are committed in
```
/complete-task
```
, not in this command
Issue workflow: Tasks transition through "To Do" → "In Progress" → "Code Review" → "Done"
ASDLC patterns: The Spec (permanent state), The PBI (transient delta)

必须遵循的规则:

操作标准合规: 本命令遵循操作标准（如果存在AGENTS.md，记录在其中；无论该文件是否存在，标准均通用）:
- MCP工具使用: 检查schema文件、验证参数、优雅处理错误
- 安全限制: 切勿提交密钥、API密钥或敏感数据。未经用户评审，切勿自动提交变更。
- AGENTS.md可选: 命令可在无AGENTS.md的情况下运行。无论是否存在AGENTS.md，标准均适用。
- 详细标准请参考AGENTS.md §3操作边界（如果存在）
优先阅读规格说明（如果存在）: 检查
```
specs/
```
目录中的功能规格，在实现前阅读蓝图和契约部分
遵循反模式要求: 如果规格说明存在，请勿实现反模式部分列出的禁用方案
同提交规则: 如果代码变更了API契约、数据模型或质量目标 → 在同一个提交中更新规格说明
必须编写单元测试: 所有新代码必须有对应的单元测试。如果规格说明存在，使用契约场景作为测试用例。
禁止自动提交: 请勿自动提交变更。保留未提交的变更供开发者评审和测试。提交操作由
```
/complete-task
```
命令处理。
分支命名: 使用短格式:
```
{type}/{TASK_KEY}
```
（例如：
```
feat/FB-6
```
,
```
fix/PROJ-123
```
）
- 根据任务类型确定前缀:
  - 需求 →
```
feat/
```
  - 缺陷 →
```
fix/
```
  - 任务/杂项 →
```
chore/
```
  - 重构 →
```
refactor/
```
  - 如果任务类型不明确，默认使用
```
feat/
```
- 示例: 需求FB-6 →
```
feat/FB-6
```
  （短格式，非描述性格式）
- 重要提示: 保持一致性 - 所有分支使用短格式
预检验证: 以下情况请勿继续:
- MCP状态验证失败（参考
```
mcp-status.md
```
  中的验证步骤 - 如果任何MCP服务器未连接或未授权，立即停止）
- 既无规格说明也无计划（停止并建议先运行
```
/create-plan {TASK_KEY}
```
  ）
- 需求状态不是"进行中"
- 需求未分配给当前用户
代码质量:
- 遵循现有代码模式和规范
- 保持或提高测试覆盖率
文档: 添加功能或变更行为时，更新相关文档

现有标准（参考）:

MCP状态验证: 详细的MCP服务器连接检查请参考
```
mcp-status.md
```
规格说明指导: 何时更新规格说明及同提交规则请参考
```
specs/README.md
```
分支命名: 类型前缀格式 (
```
{type}/{TASK_KEY}
```
) 如当前工作流所示
测试要求: 随代码编写测试（参考实现清单）
提交工作流: 变更由
```
/complete-task
```
命令提交，本命令不负责提交
问题工作流: 任务通过"待办"→"进行中"→"代码评审"→"完成"的状态流转
ASDLC模式: The Spec（永久状态）、The PBI（临时增量）

Output

输出

Development Work: Implement the work specified in spec/plan:
- Code changes implemented according to spec constraints and plan steps (left uncommitted for review)
- Unit tests created or updated alongside code (using Contract scenarios if spec exists)
- Spec updated if behavior/contracts changed (Same-Commit Rule)
- Documentation updated as needed
- Changes ready for developer review and testing
- Use
```
/complete-task
```
  when ready to commit, push, and optionally create a PR

开发工作: 根据规格说明/计划实现工作:
- 按照规格约束和计划步骤完成代码变更（保留未提交状态供评审）
- 随代码创建或更新单元测试（如果规格说明存在，使用契约场景）
- 如果行为/契约变更，更新规格说明（同提交规则）
- 根据需要更新文档
- 变更已准备好供开发者评审和测试
- 准备好后使用
```
/complete-task
```
  命令提交、推送并可选创建PR