SimpleEve/development-skills

# Implement - 代码实现技能

根据 plan 文档进行代码实现，或根据 test/review 的反馈进行修复。

## 核心原则

1. **严格遵循 Plan**：按照已确认的 `plan.md` 中的 TODO 逐项实现
2. **架构一致**：遵循项目整体既有的架构设计、模块边界与依赖方向
3. **模块化与可扩展**：代码必须模块化，遵循 SOLID 原则和适当的设计模式
4. **最小变更**：只实现 Plan 要求的内容，不做额外的"优化"或"改进"

## 前置条件

- 对应功能的 `plan.md` 必须已存在且状态为"已确认"

# Plan - 实施计划技能

将已确认的 spec 文档转化为可执行落地的详细实施计划与任务清单。

## 核心原则

1. **不猜测**：代码侧的技术细节遇到不确定的，必须向用户澄清
2. **不模糊**：每个 TODO 子项必须描述清楚做什么、影响哪些文件、验收标准是什么
3. **不写代码**：不写详细实现代码，但可以描述接口签名、数据结构、模块职责
4. **固定产出**：输出到项目既有的需求目录；若无统一约定，建议使用 `spec/<spec-name>/plan.md`

## 前置条件

- 对应功能的 `spec.md` 必须已存在且状态为"已确认"

# Review - 代码审查技能

根据 spec 和 plan 文档对代码进行全面审查，产出结构化的审查报告。

## 核心原则

1. **对照文档审查**：严格依据 spec 和 plan 检查功能完整性与正确性
2. **最佳实践审查**：检查代码质量、命名规范、架构合理性
3. **结构化产出**：按 P0/P1/P2 分级，明确区分问题类型
4. **固定产出**：输出到项目既有的需求目录；若无统一约定，建议使用 `spec/<spec-name>/review.md`

## 前置条件

- 对应功能的 `spec.md` 和 `plan.md` 必须已存在

# Spec - 需求规格说明技能

将模糊的需求意图转化为清晰、无歧义的需求规格文档。

## 核心原则

1. **不猜测**：遇到任何模糊点，必须向用户提问澄清，绝不自行假设
2. **不模糊**：每个需求边界必须是确定的，In Scope / Out of Scope 必须明确列出
3. **不写代码**：绝不写任何代码，包括伪代码。只用自然语言描述需求行为
4. **固定产出**：输出到项目既有的需求目录；若无统一约定，建议使用 `spec/<spec-name>/spec.md`

## 工作流程

### 第一步：理解与澄清

# Test - 测试技能

根据 plan 文档编写并执行单元测试与集成测试，产出结构化测试报告。该技能的核心目标是**验证**而非**修复**。

## 职能边界

1. **绝对禁令**：**禁止修改任何非测试相关的业务源码**。即便发现 bug，也只能在测试报告中记录并建议修复，不得自行调用 `/implement` 或手动修改源码。
2. **操作范围**：仅允许修改、新增测试文件、测试目录内容，或项目明确归类为测试资产的文件。
3. **输出目标**：高质量的测试代码覆盖及详尽的 `test.md` 测试报告。

## 核心原则

1. **以 Plan 为准**：测试用例严格基于 `plan.md` 中的验收标准与测试规范。
2. **验证驱动**：所有职能围绕“证明代码是否符合预期”展开。