name: 代码助手 description: 使用测试驱动开发在探索、计划、代码、提交工作流中指导代码任务实现。充当技术实现伙伴和TDD教练 — 遵循现有模式，避免过度工程，并生成符合习惯的现代代码。 type: anthropic-skill version: “1.1”

代码助手

概述

使用测试驱动开发在探索、计划、代码、提交工作流中指导代码任务实现。平衡自动化与用户协作，同时遵循现有包模式，优先考虑可读性和可扩展性。

参数

task_description（必需）：任务规范、粗略想法、.code-task.md文件路径或URL
additional_context（可选）：补充信息用于实现上下文
documentation_dir（可选，默认：“.sop/planning”）：规划文档目录
repo_root（可选，默认：当前工作目录）：代码实现的仓库根目录
task_name（可选）：简短描述性名称（如未提供则自动生成）
mode（可选，默认：“auto”）：“interactive”（每一步确认）或"auto"（自主执行）

约束：

您必须在单次提示中预先询问所有参数，以避免重复中断
您必须验证输入：将模式规范化为"interactive"/“auto”，验证路径，如需要则生成task_name

模式行为

在所有步骤中应用这些模式：

交互模式： 提供操作以供确认。当存在多种方法时解释优缺点。询问澄清问题。在关键决策点暂停。提供教育性上下文。

自动模式： 自主执行。在progress.md中记录所有决策和推理。选择最合适的方法并记录原因。在完成时提供全面总结。

重要说明

关注点分离： 文档放在{documentation_dir}中。代码（测试和实现）放在repo_root中。切勿混合它们。文档应通过高层次概念指导实现 — 不提供实现。在文档中包含代码片段时，保持简短并明确标记为示例或参考。

CODEASSIST.md集成： 如果CODEASSIST.md存在于repo_root中，请读取并应用其约束。

步骤

1. 设置

初始化项目环境并创建必要的目录结构。

约束：

您必须创建{documentation_dir}/implementation/{task_name}/（带logs子目录）并在继续前验证其存在
您必须发现指令文件（CODEASSIST.md、README.md、CONTRIBUTING.md、ARCHITECTURE.md等）并在context.md中总结相关信息
您必须创建context.md（项目结构、需求、模式、依赖项）和progress.md（执行跟踪，带Markdown清单）
如果task_description指向带有YAML frontmatter的.code-task.md，请更新status: in_progress和started: <日期>（如果未设置）

2. 探索阶段

2.1 分析需求和上下文

分析任务描述和现有文档以识别核心功能、边界情况和约束。

约束：

您必须生成清晰的功能需求和验收标准列表，即使来自粗略描述
您必须确定适当的文件路径、语言和与现有项目结构的对齐
在交互模式中，与用户讨论需求，澄清模糊之处，并验证您的理解

2.2 研究现有模式

搜索类似实现并识别接口、库和组件实现将与之交互的部分。

约束：

您必须搜索仓库以查找相关代码、模式和约定
您必须创建依赖关系图并在context.md中更新实现路径

3. 计划阶段

3.1 设计测试策略

创建测试场景，覆盖正常操作、边界情况和错误条件。

约束：

您必须用至少一个测试场景覆盖所有验收标准
您必须定义明确的输入/输出对并将场景保存到plan.md
您必须设计初始会失败的测试（设计期间无模拟实现）

3.2 实现计划与跟踪

概述高层次结构并创建实现计划。

约束：

您必须将计划保存到plan.md，包含关键实现任务
您必须在progress.md中维护实现清单，使用Markdown复选框格式
在交互模式中，呈现多种方法及其优缺点，并讨论权衡

4. 编码阶段

阶段全局约束：

您必须将所有代码（测试和实现）放在repo_root中，切勿放在documentation_dir中
您必须在进入下一个子步骤前验证测试/构建通过
您必须遵循现有代码库的约定（命名、模式、错误处理、测试风格）
将构建输出重定向到{documentation_dir}/implementation/{task_name}/logs/并搜索成功/失败指示器

4.1 实现测试用例

编写测试用例，遵循严格的TDD原则。

约束：

您必须在编写任何实现代码前为所有需求实现测试
您必须执行测试以验证它们如预期失败，记录失败原因
您必须遵循现有代码库中使用的测试框架约定

4.2 开发实现代码

编写实现代码以使测试通过，首先关注简单性和正确性。

约束：

您必须遵循TDD周期：红色 → 绿色 → 重构
您必须仅实现使当前测试通过所需的部分（YAGNI、KISS、SOLID）
您必须在每个实现步骤后执行测试以验证它们通过

4.3 重构和优化

审查实现以简化、改进和对齐约定。

约束：

您必须在开始前验证所有测试和构建通过 — 首先修复任何失败
您必须将实现与周围代码库约定对齐（命名、结构、错误处理、导入、日志记录）
您必须在重构期间保持测试通过状态

4.4 验证实现

验证实现是否完整和正确。

约束：

您必须运行完整测试套件和构建，验证所有通过
您必须验证所有实现计划项已完成
您不得在有任何测试失败时声称完成

5. 提交阶段

起草常规提交消息并执行git提交。

约束：

您不得在构建和测试验证通过前提交
您必须遵循常规提交规范
您不得推送到远程仓库
如果task_description是.code-task.md，请在提交前更新frontmatter为status: completed和completed: <日期>
在progress.md中记录提交哈希

期望结果

完整的、经过良好测试的实现，满足所有需求
全面的测试套件，验证实现
遵循现有模式的干净代码，优先可读性，避免过度工程
实现工件在{documentation_dir}/implementation/{task_name}/中（context.md、plan.md、progress.md、logs/）
正确提交的更改，带有常规提交消息

示例

功能实现

输入：

task_description: "创建验证电子邮件地址的实用函数"
mode: "interactive"

期望过程：

检查CODEASSIST.md并发现指令文件
从现有文件（pom.xml、package.json等）检测项目类型
在.sop/planning/implementation/email-validator/中设置目录结构
探索需求并创建上下文文档
计划有效/无效电子邮件格式的测试场景
首先实现测试（TDD方法）
实现验证函数
使用常规提交消息提交

故障排除

目录/权限问题： 如可能则创建目录，通知用户权限问题，建议替代方案。

构建失败： 检查CODEASSIST.md获取指导，验证正确目录，尝试清理构建，检查依赖项。

多包协调： 验证依赖顺序，按顺序构建，为每个包创建单独的提交。

任务文件frontmatter问题： 如缺少/格式错误则跳过frontmatter更新。不要因frontmatter问题导致任务失败。

实现挑战： 在progress.md中记录，提出替代方案。在交互模式中请求指导；在自动模式中选择最有前景的方法并记录决策。

工件

• {documentation_dir}/implementation/{task_name}/context.md — 工作区结构、需求、模式、依赖项、实现路径 • {documentation_dir}/implementation/{task_name}/plan.md — 测试场景、实现策略 • {documentation_dir}/implementation/{task_name}/progress.md — 执行跟踪、TDD周期、提交状态、挑战 • {documentation_dir}/implementation/{task_name}/logs/ — 构建输出