piv-plan-implementation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan a new task

规划新任务

Feature: $ARGUMENTS

Resolve the input first

先处理输入

$ARGUMENTS

is either a tracker ticket (a key like

ACC-30

, or a Jira / Linear / GitHub issue URL) or a free-form feature description. Tell them apart and handle each:

A ticket (a key such as
```
ABC-123
```
, or an issue URL): fetch it from the tracker before you plan (Jira via the Atlassian MCP, GitHub via
```
gh issue view
```
, etc.). Read its summary, acceptance criteria, and per-ticket context. Then follow its links up to the epic and the epic's linked architecture page (Confluence via the Atlassian MCP) and inherit those decisions (see "Inherit, don't re-decide" below). Never plan from the bare key; the ticket body plus its epic and architecture are the real input.
A free-form description: plan directly from it (greenfield or ad-hoc), asking clarifying questions as needed.

$ARGUMENTS

是跟踪工单（如

ACC-30

这类密钥，或 Jira / Linear / GitHub 议题URL）或自由格式功能描述。需区分两者并分别处理：

工单（如
```
ABC-123
```
这类密钥，或议题URL）：规划前先从跟踪系统获取工单内容（Jira 通过Atlassian MCP，GitHub 通过
```
gh issue view
```
等）。阅读其摘要、验收标准和工单专属上下文。然后跟进其关联到史诗（epic）的链接以及史诗关联的架构页面（Confluence 通过Atlassian MCP），并继承这些决策（见下文“继承而非重新决策”）。绝不能仅通过密钥进行规划；工单正文及其史诗和架构文档才是真正的输入。
自由格式描述：直接基于该描述进行规划（全新项目或临时需求），必要时提出澄清问题。

Mission

任务目标

Transform a feature request into a comprehensive implementation plan through systematic codebase analysis, external research, and strategic planning.

Core Principle: We do NOT write code in this phase. Our goal is to create a context-rich implementation plan that enables one-pass implementation success for ai agents.

Key Philosophy: Context is King. The plan must contain ALL information needed for implementation - patterns, mandatory reading, documentation, validation commands - so the execution agent succeeds on the first attempt.

Inherit, don't re-decide: This is a per-ticket plan. If the ticket belongs to an epic that already has architecture decisions — a linked architecture page (e.g. a Confluence page from the

plan-architecture

skill, reached from the ticket's epic), an

## Architecture

## Engineering

section on the epic, or a local

architecture.md

engineering-plan.md

— read it first and treat its cross-cutting calls (stack & versions, data model, security boundaries, the seams new code plugs into) as already decided. Inherit them; don't reopen them. Plan only what's left at the ticket level: the specific files, the local patterns to mirror, the tests. If a ticket genuinely needs to break an epic-level decision, flag it in Open Questions rather than silently diverging.

通过系统化的代码库分析、外部研究和战略规划，将功能请求转化为全面的实现计划。

核心原则：此阶段不编写代码。我们的目标是创建上下文丰富的实现计划，确保AI Agent能够一次性实现成功。

关键理念：上下文为王。计划必须包含实现所需的所有信息——模式、必读文档、参考资料、验证命令——以便执行Agent能够首次尝试就成功。

继承而非重新决策：这是一份工单专属计划。如果工单属于已有架构决策的史诗——关联的架构页面（例如来自

plan-architecture

skill的Confluence页面，可从工单的史诗进入）、史诗上的

## Architecture

## Engineering

部分，或本地的

architecture.md

engineering-plan.md

——先阅读这些内容，并将其跨领域要求（技术栈与版本、数据模型、安全边界、新代码接入的衔接点）视为已确定的决策。直接继承这些决策，不要重新讨论。仅规划工单层面剩余的内容：具体文件、需遵循的本地模式、测试用例。如果工单确实需要打破史诗级决策，请在“未解决问题”中标记，而非擅自偏离。

Planning Process

规划流程

Phase 1: Feature Understanding

阶段1：需求理解

Deep Feature Analysis:

Extract the core problem being solved
Identify user value and business impact
Determine feature type: New Capability/Enhancement/Refactor/Bug Fix
Assess complexity: Low/Medium/High
Map affected systems and components

Create User Story Format Or Refine If Story Was Provided By The User:

As a <type of user>
I want to <action/goal>
So that <benefit/value>

深度需求分析:

提取待解决的核心问题
识别用户价值和业务影响
确定需求类型：新功能/功能增强/重构/BUG修复
评估复杂度：低/中/高
梳理受影响的系统和组件

创建用户故事格式或优化用户提供的故事:

作为<用户类型>
我希望<操作/目标>
以便<收益/价值>

Phase 2: Codebase Intelligence Gathering

阶段2：代码库信息收集

Use specialized agents and parallel analysis:

1. Project Structure Analysis

Detect primary language(s), frameworks, and runtime versions
Map directory structure and architectural patterns
Identify service/component boundaries and integration points
Locate configuration files (pyproject.toml, package.json, etc.)
Find environment setup and build processes

2. Pattern Recognition (Use specialized subagents when beneficial)

Search for similar implementations in codebase
Identify coding conventions:
- Naming patterns (CamelCase, snake_case, kebab-case)
- File organization and module structure
- Error handling approaches
- Logging patterns and standards
Extract common patterns for the feature's domain
Document anti-patterns to avoid
Check CLAUDE.md for project-specific rules and conventions

3. Dependency Analysis

Catalog external libraries relevant to feature
Understand how libraries are integrated (check imports, configs)
Find relevant documentation in docs/, ai_docs/, .claude/references or ai-wiki if available
Note library versions and compatibility requirements

4. Testing Patterns

Identify test framework and structure (pytest, jest, etc.)
Find similar test examples for reference
Understand test organization (unit vs integration)
Note coverage requirements and testing standards

5. Integration Points

Identify existing files that need updates
Determine new files that need creation and their locations
Map router/API registration patterns
Understand database/model patterns if applicable
Identify authentication/authorization patterns if relevant

Clarify Ambiguities — GATE:

Codebase analysis is done, so the open questions are now specific. This is the one moment where you know enough to ask well and have not yet written anything. GATE means: post the questions, then stop. End the turn and wait for the answers. Do not ask and answer in the same breath, and do not roll into Phase 3.

Ask in one cluster, numbered, 3-6 questions max, each carrying a recommended default so answering is cheap ("I'll mirror the first unless you say otherwise"). Draw them only from what the analysis actually left open:

Scope boundary — the adjacent thing a reasonable reader would assume is in scope. Confirm it is out.
Pattern fork — two existing patterns both fit. Name both with
```
file:line
```
and ask which to mirror.
Contract shape — the API surface, payload, or data-model change the ticket implies but never states.
Failure behavior — what happens on the error path the ticket is silent about.
Preference — a library or trade-off with no precedent in this codebase to inherit.
Done — an acceptance criterion that is missing, or written so that it cannot be checked.

Skip any category with nothing genuinely open; never manufacture questions to fill the list. If the ticket, its epic and the architecture doc genuinely settle everything, say so in one line and proceed. Silence is not the same as clearance.

Thin answers: reflect a vague answer back as the concrete choice it leaves open ("'handle errors gracefully' — a 4xx with a message, or retry then 503?") and ask once more. Never upgrade a vague answer into a confident plan.

If they decline ("just write it"): honour it, but name what you are guessing. Every unanswered item becomes an

Assumed — <the assumption>, confirm before execution

line in

OPEN QUESTIONS / ASSUMPTIONS

, and the task it affects carries a

**GOTCHA**

naming it. Never guess silently.

Already settled upstream: anything the ticket, its epic, or the linked architecture page already answers is not open. Inherit it and skip (see "Inherit, don't re-decide").

使用专用Agent和并行分析:

1. 项目结构分析

检测主要语言、框架和运行时版本
梳理目录结构和架构模式
识别服务/组件边界和集成点
定位配置文件（pyproject.toml、package.json等）
查找环境搭建和构建流程

2. 模式识别（必要时使用专用子Agent）

在代码库中搜索类似实现
识别编码规范：
- 命名模式（CamelCase、snake_case、kebab-case）
- 文件组织和模块结构
- 错误处理方式
- 日志模式和标准
提取需求领域的通用模式
记录需避免的反模式
查看CLAUDE.md获取项目特定规则和规范

3. 依赖分析

整理与需求相关的外部库
理解库的集成方式（检查导入、配置）
查找docs/、ai_docs/、.claude/references或ai-wiki中的相关文档（如有）
记录库版本和兼容性要求

4. 测试模式

识别测试框架和结构（pytest、jest等）
查找类似测试示例以供参考
理解测试组织方式（单元测试vs集成测试）
记录覆盖率要求和测试标准

5. 集成点

识别需要更新的现有文件
确定需要创建的新文件及其位置
梳理路由/API注册模式
理解数据库/模型模式（如适用）
识别认证/授权模式（如相关）

澄清歧义 —— GATE:

代码库分析完成后，未解决的问题会变得具体。这是你掌握足够信息、能够精准提问且尚未开始撰写内容的唯一时刻。GATE意味着：提出问题后停止操作。结束当前步骤并等待回复。不要自问自答，也不要直接进入阶段3。

将问题集中成一组，编号，最多3-6个，每个问题附带建议默认选项以降低回复成本（“除非你另有说明，否则我将遵循第一个选项”）。仅从分析过程中真正未解决的问题中选取：

范围边界——合理读者可能会认为属于范围的相邻内容。确认其是否在范围外。
模式选择——两种现有模式都适用。标注两者的
```
file:line
```
并询问应遵循哪一种。
契约形态——工单隐含但未明确说明的API接口、负载或数据模型变更。
错误行为——工单未提及的错误路径处理方式。
偏好选择——代码库中无先例可继承的库或权衡决策。
完成标准——缺失的验收标准，或表述模糊无法验证的标准。

如果某类问题没有真正未解决的内容，跳过该类；切勿为了凑数而编造问题。如果工单、其史诗和架构文档确实已解决所有问题，用一句话说明即可继续。沉默不等同于许可。

模糊回复：将模糊回复映射为其隐含的具体选择（例如“‘优雅处理错误’——返回带消息的4xx，还是重试后返回503？”）并再次询问。绝不能将模糊回复转化为确定的计划。

如果用户拒绝提供澄清（“直接编写即可”）：尊重其要求，但需明确记录你的假设。每个未回复的问题都要在“未解决问题/假设”中添加一行

Assumed — <具体假设>，执行前请确认

，且受影响的任务需标记

**GOTCHA**

说明该假设。切勿默默做出假设。

上游已解决：工单、其史诗或关联架构页面已回答的内容不属于未解决问题。直接继承并跳过（见“继承而非重新决策”）。

Phase 3: External Research & Documentation

阶段3：外部研究与文档收集

Use specialized subagents when beneficial for external research:

Documentation Gathering:

Research latest library versions and best practices
Find official documentation with specific section anchors
Locate implementation examples and tutorials
Identify common gotchas and known issues
Check for breaking changes and migration guides

Technology Trends:

Research current best practices for the technology stack
Find relevant blog posts, guides, or case studies
Identify performance optimization patterns
Document security considerations

Compile Research References:

markdown

undefined

必要时使用专用子Agent进行外部研究:

文档收集:

研究最新库版本和最佳实践
查找带特定章节锚点的官方文档
定位实现示例和教程
识别常见陷阱和已知问题
检查破坏性变更和迁移指南

技术趋势:

研究技术栈当前的最佳实践
查找相关博客文章、指南或案例研究
识别性能优化模式
记录安全注意事项

整理研究参考资料:

markdown

undefined

Relevant Documentation

Feature: <feature-name>

Feature: <功能名称>

The following plan should be complete, but its important that you validate documentation and codebase patterns and task sanity before you start implementing.

Pay special attention to naming of existing utils types and models. Import from the right files etc.

本计划应完整，但在开始实现前，务必验证文档、代码库模式和任务合理性。

特别注意现有工具类、类型和模型的命名。从正确的文件导入等。

Feature Description

功能描述

<详细描述功能、目的及其对用户的价值>

User Story

用户故事

As a <type of user> I want to <action/goal> So that <benefit/value>

作为<用户类型> 我希望<操作/目标> 以便<收益/价值>

Problem Statement

问题陈述

<明确定义该功能解决的具体问题或带来的机会>

Solution Statement

方案陈述

<描述提议的解决方案及其解决问题的方式>

Out of Scope / Non-Goals

范围外/非目标

Not included: <thing> (defer to <later / separate ticket>)
Not changing: <existing behavior to leave alone>

<明确界定工作范围：本功能不包含的内容。列出合理读者可能会认为属于范围但实际不属于的内容——这能防止Agent过度开发或解决错误的问题。>

不包含：<内容>（推迟至<后续/单独工单>）
不修改：<需保留的现有行为>

Feature Metadata

功能元数据

Feature Type: [New Capability/Enhancement/Refactor/Bug Fix] Estimated Complexity: [Low/Medium/High] Primary Systems Affected: [List of main components/services] Dependencies: [External libraries or services required]

功能类型: [新功能/功能增强/重构/BUG修复] 预估复杂度: [低/中/高] 主要受影响系统: [主要组件/服务列表] 依赖项: [所需外部库或服务]

Related Work

CONTEXT REFERENCES

上下文参考

Relevant Codebase Files IMPORTANT: YOU MUST READ THESE FILES BEFORE IMPLEMENTING!

New Files to Create

需创建的新文件

```
path/to/new_service.py
```
- Service implementation for X functionality
```
path/to/new_model.py
```
- Data model for Y resource
```
tests/path/to/test_new_service.py
```
- Unit tests for new service

```
path/to/new_service.py
```
- X功能的服务实现
```
path/to/new_model.py
```
- Y资源的数据模型
```
tests/path/to/test_new_service.py
```
- 新服务的单元测试

Relevant Documentation YOU SHOULD READ THESE BEFORE IMPLEMENTING!

Patterns to Follow

需遵循的模式

Naming Conventions: (for example)

Error Handling: (for example)

Logging Pattern: (for example)

Other Relevant Patterns: (for example)

<从代码库中提取的特定模式——包含项目中的实际代码示例>

命名规范:（示例）

错误处理:（示例）

日志模式:（示例）

其他相关模式:（示例）

IMPLEMENTATION PLAN

实现计划

Phases run top to bottom by default — each assumes the phase above it is done. Where that is NOT the true dependency, make it explicit with a

**Depends on:**

line under the phase header, and a

**Independent of:**

line where two phases don't block each other. Independent phases are candidates to run in parallel (e.g. separate worktrees / parallel loops). Only annotate where it changes execution order or unlocks parallelism — skip the obvious sequential case.

默认按从上到下的顺序执行阶段——每个阶段假设上一阶段已完成。如果实际依赖关系并非如此，请在阶段标题下明确标注

**Depends on:**

，并在两个阶段互不阻塞时标注

**Independent of:**

。独立阶段可考虑并行执行（例如使用独立工作区/并行循环）。仅在改变执行顺序或支持并行执行时进行标注——跳过明显的顺序执行情况。

Phase 1: Foundation

阶段1：基础准备

Tasks:

Set up base structures (schemas, types, interfaces)
Configure necessary dependencies
Create foundational utilities or helpers

<描述主要实现前需完成的基础工作>

任务:

设置基础结构（ schema、类型、接口）
配置必要依赖
创建基础工具类或辅助函数

Phase 2: Core Implementation

阶段2：核心实现

Depends on: Phase 1 (needs the base schemas/types)

Tasks:

Implement core business logic
Create service layer components
Add API endpoints or interfaces
Implement data models

Depends on: 阶段1（需要基础schema/类型）

<描述主要实现工作>

任务:

实现核心业务逻辑
创建服务层组件
添加API端点或接口
实现数据模型

Phase 3: Integration

阶段3：集成

Tasks:

Connect to existing routers/handlers
Register new components
Update configuration files
Add middleware or interceptors if needed

<描述功能与现有功能的集成方式>

任务:

连接到现有路由/处理器
注册新组件
更新配置文件
必要时添加中间件或拦截器

Phase 4: Testing & Validation

阶段4：测试与验证

Tasks:

Implement unit tests for each component
Create integration tests for feature workflow
Add edge case tests
Validate against acceptance criteria

<描述测试方法>

任务:

为每个组件实现单元测试
创建功能流程的集成测试
添加边缘情况测试
根据验收标准进行验证

STEP-BY-STEP TASKS

分步任务

IMPORTANT: Execute every task in order, top to bottom. Each task is atomic and independently testable.

重要：按顺序执行每个任务，从上到下。每个任务都是原子性的，可独立测试。

Task Format Guidelines

任务格式指南

Use information-dense keywords for clarity:

CREATE: New files or components
UPDATE: Modify existing files
ADD: Insert new functionality into existing code
REMOVE: Delete deprecated code
REFACTOR: Restructure without changing behavior
MIRROR: Copy pattern from elsewhere in codebase

使用信息密集的关键字以确保清晰：

CREATE: 创建新文件或组件
UPDATE: 修改现有文件
ADD: 在现有代码中插入新功能
REMOVE: 删除废弃代码
REFACTOR: 重构但不改变行为
MIRROR: 复制代码库中其他位置的模式

{ACTION} {target_file}

IMPLEMENT: {Specific implementation detail}
PATTERN: {Reference to existing pattern - file:line}
IMPORTS: {Required imports and dependencies}
GOTCHA: {Known issues or constraints to avoid}
VALIDATE:
```
{executable validation command}
```
SATISFIES: {which acceptance criterion this task advances — e.g. AC #2 — so every task traces to a criterion}

IMPLEMENT: {具体实现细节}
PATTERN: {现有模式参考 - file:line}
IMPORTS: {所需导入和依赖项}
GOTCHA: {需避免的已知问题或约束}
VALIDATE:
```
{可执行的验证命令}
```
SATISFIES: {该任务推进的验收标准——例如AC #2——确保每个任务都对应一个验收标准}

<按依赖顺序继续列出所有任务...>

TESTING STRATEGY

测试策略

<基于项目测试框架和研究阶段发现的模式定义测试方法>

Unit Tests

单元测试

Design unit tests with fixtures and assertions following existing testing approaches

<基于项目标准的范围和要求>

按照现有测试方法设计带fixture和断言的单元测试

Integration Tests

集成测试

<基于项目标准的范围和要求>

Edge Cases

边缘情况

<列出该功能必须测试的特定边缘情况>

VALIDATION COMMANDS

验证命令

Execute every command to ensure zero regressions and 100% feature correctness.

<基于阶段2发现的项目工具定义验证命令>

执行所有命令以确保零回归和100%功能正确性。

Level 1: Syntax & Style

级别1：语法与风格

<Project-specific linting and formatting commands>

<项目特定的代码检查和格式化命令>

Level 2: Unit Tests

级别2：单元测试

<Project-specific unit test commands>

<项目特定的单元测试命令>

Level 3: Integration Tests

级别3：集成测试

<Project-specific integration test commands>

<项目特定的集成测试命令>

Level 4: Manual Validation

级别4：手动验证

<Feature-specific manual testing steps - API calls, UI testing, etc.>

<功能特定的手动测试步骤——API调用、UI测试等>

Level 5: Additional Validation (Optional)

级别5：额外验证（可选）

<MCP服务器或其他可用CLI工具>

ACCEPTANCE CRITERIA

验收标准

COMPLETION CHECKLIST

完成 checklist

OPEN QUESTIONS / ASSUMPTIONS

未解决问题/假设

<明确列出仍不确定的内容，而非默默假设。记录本计划做出的假设，以及任何答案不同会改变计划的问题。执行前向用户标记未解决的关键问题。>

NOTES (open canvas)

备注（开放区域）

<无固定格式。可自由记录：权衡后拒绝的备选方案及原因、权衡矩阵、顺序或发布风险、数据流草图、未解决事项、链接等——任何有助于计划的内容。以上部分规范了计划的结构，以便三方和实现Agent使用；本部分保留你的思考过程不受约束。支持散文、列表、表格、代码块等多种形式。>

AMENDMENTS

修订记录

<Append-only history of changes made to this plan AFTER it was first approved/executed. Leave empty at creation; newest entry at the bottom. Each entry: date — what changed and why.>

<ISO date> — <what changed and why, e.g. "scope cut: deferred bulk-import to a follow-up ticket after AC review">

undefined

<首次批准/执行后对本计划的更改记录，仅追加。创建时为空；最新记录在底部。每条记录：日期——更改内容及原因。>

<ISO日期> — <更改内容及原因，例如“范围缩减：AC评审后将批量导入推迟至后续工单”>

undefined

Output Format

输出格式

Filename:

.claude/plans/{kebab-case-descriptive-name}.md

Replace
```
{kebab-case-descriptive-name}
```
with short, descriptive feature name

Examples:

add-user-authentication.md

implement-search-api.md

refactor-database-layer.md

Directory: Create

.claude/plans/

if it doesn't exist

文件名:

.claude/plans/{kebab-case-descriptive-name}.md

将
```
{kebab-case-descriptive-name}
```
替换为简短、描述性的功能名称

示例:

add-user-authentication.md

implement-search-api.md

refactor-database-layer.md

目录: 如果

.claude/plans/

不存在则创建

Quality Criteria

质量标准

Context Completeness ✓

上下文完整性 ✓

Implementation Ready ✓

可直接实现 ✓

Another developer could execute without additional context
Tasks ordered by dependency (can execute top-to-bottom)
Each task is atomic and independently testable
Pattern references include specific file:line numbers

其他开发者无需额外上下文即可执行
任务按依赖关系排序（可从上到下执行）
每个任务都是原子性的，可独立测试
模式参考包含具体的file:line编号

Pattern Consistency ✓

模式一致性 ✓

Tasks follow existing codebase conventions
New patterns justified with clear rationale
No reinvention of existing patterns or utils
Testing approach matches project standards

任务遵循现有代码库规范
新模式有清晰的理由支撑
未重复发明现有模式或工具类
测试方法符合项目标准

Information Density ✓

信息密度 ✓

No generic references (all specific and actionable)
URLs include section anchors when applicable
Task descriptions use codebase keywords
Validation commands are non interactive executable

无通用引用（所有内容具体且可操作）
URL包含适用的章节锚点
任务描述使用代码库关键字
验证命令为非交互式可执行命令

Success Metrics

成功指标

One-Pass Implementation: Execution agent can complete feature without additional research or clarification — clarification the user owes the plan belongs in Phase 2's gate, not deferred to the execution agent

Validation Complete: Every task has at least one working validation command

Context Rich: The Plan passes "No Prior Knowledge Test" - someone unfamiliar with codebase can implement using only Plan content

Confidence Score: #/10 that execution will succeed on first attempt

一次性实现：执行Agent无需额外研究或澄清即可完成功能——用户应在阶段2的GATE环节提供所需澄清，而非推迟到执行Agent阶段

完整验证：每个任务至少有一个可用的验证命令

上下文丰富：计划通过“无前置知识测试”——不熟悉代码库的人仅使用计划内容即可实现功能

信心评分: #/10 首次尝试执行成功的可能性

Report

报告

After creating the Plan, provide:

Summary of feature and approach
Full path to created Plan file
Complexity assessment
Key implementation risks or considerations
Estimated confidence score for one-pass success

创建计划后，提供：

功能和方案摘要
计划文件的完整路径
复杂度评估
关键实现风险或注意事项
一次性成功的预估信心评分

piv-plan-implementation

Original

Translation

Plan a new task

规划新任务

Feature: $ARGUMENTS

Feature: $ARGUMENTS

Resolve the input first

先处理输入

Mission

任务目标

Planning Process

规划流程

Phase 1: Feature Understanding

阶段1：需求理解

Phase 2: Codebase Intelligence Gathering

阶段2：代码库信息收集

Phase 3: External Research & Documentation

阶段3：外部研究与文档收集

Relevant Documentation

相关文档

Phase 4: Deep Strategic Thinking

阶段4：深度战略思考

Phase 5: Plan Structure Generation

阶段5：生成计划结构

Feature: <feature-name>

Feature: <功能名称>

Feature Description

功能描述

User Story

用户故事

Problem Statement

问题陈述

Solution Statement

方案陈述

Out of Scope / Non-Goals

范围外/非目标

Feature Metadata

功能元数据

Related Work

相关工作

CONTEXT REFERENCES

上下文参考

Relevant Codebase Files IMPORTANT: YOU MUST READ THESE FILES BEFORE IMPLEMENTING!

相关代码库文件 重要：实现前必须阅读这些文件！

New Files to Create

需创建的新文件

Relevant Documentation YOU SHOULD READ THESE BEFORE IMPLEMENTING!

相关文档 实现前应阅读这些文档！

Patterns to Follow

需遵循的模式

IMPLEMENTATION PLAN

实现计划

Phase 1: Foundation

阶段1：基础准备

Phase 2: Core Implementation

阶段2：核心实现

Phase 3: Integration

阶段3：集成

Phase 4: Testing & Validation

阶段4：测试与验证

STEP-BY-STEP TASKS

分步任务

Task Format Guidelines

任务格式指南

{ACTION} {target_file}

{ACTION} {target_file}

TESTING STRATEGY

测试策略

Unit Tests

单元测试

Integration Tests

集成测试

Edge Cases

边缘情况

VALIDATION COMMANDS

验证命令

Level 1: Syntax & Style

级别1：语法与风格

Level 2: Unit Tests

相关代码库文件重要：实现前必须阅读这些文件！

相关文档实现前应阅读这些文档！