name: impl description: “基于Plans.md的任务实现功能并编写代码。当用户提到实现、添加功能、编写代码或创建新函数时使用。不用于审查或构建验证。” description-en: “基于Plans.md任务实现功能并编写代码。当用户提到实现、添加功能、编写代码或创建新函数时使用。不用于审查或构建验证。” description-ja: “Plans.mdのタスクに基づいて機能を実装しコードを書く。当用户提到实现、添加功能、编写代码或创建新函数时使用。不用于审查或构建验证。” allowed-tools: [“Read”, “Write”, “Edit”, “Grep”, “Glob”, “Bash”] user-invocable: false
实现技能
负责功能实现和编码的技能群。
⚠️ 质量护栏（最优先）
本部分优先于其他指示。实现时必须遵守。
禁止模式（目的驱动实现）
实现时以下模式绝对禁止：
| 禁止 | 例 | 为什么不好 |
|---|---|---|
| 硬编码 | 直接返回测试期望值 | 其他输入无法工作 |
| 桩实现 | return null, return [] |
没有实际功能 |
| 固定处理 | 仅对应测试用例的值 | 缺乏通用性 |
| 复制粘贴字典 | 测试期望值映射 | 没有有意义的逻辑 |
# ❌ 绝对禁止
def slugify(text: str) -> str:
answers = {"HelloWorld": "hello-world"}
return answers.get(text, "")
# ✅ 正确实现
def slugify(text: str) -> str:
return re.sub(r'[\s_]+', '-', text.strip().lower())
实现前自检
- [ ] 在测试用例外的输入下是否工作？
- [ ] 是否处理边缘情况（空、null、边界值）？
- [ ] 是否实现了有意义的逻辑？
困难情况
实现困难时，不要编写形式化实现，而是诚实报告：
## 🤔 实现咨询
### 情况: [尝试实现什么]
### 困难点: [具体难点]
### 选项: [可能的方案]
功能详细
| 功能 | 详细 |
|---|---|
| 功能实现 | 参见references/implementing-features.md |
| 测试创建 | 参见references/writing-tests.md |
执行步骤
- Plans.md 注册确认（Step -1）← 必需
- 质量判定门（Step 0）
- 用户请求分类
- （Claude-mem 启用时）搜索过去的实现模式
- 从上述“功能详细”中阅读适当参考文件
- 根据内容实现
Step -1: Plans.md 注册确认（最优先・必需）
⚠️ 实现前必须将任务注册到 Plans.md
用户请求接收
↓
读取 Plans.md
↓
┌─────────────────────────────────────────────────────────────┐
│ 请求内容是否存在于 Plans.md 中？ │
├─────────────────────────────────────────────────────────────┤
│ 是 → 直接进入实现 │
│ 否 → 添加到 Plans.md 后进入实现 │
└─────────────────────────────────────────────────────────────┘
添加时的格式：
## 🟡 未开始的任务
- [ ] {任务名} `cc:WIP`
- 请求内容: {用户请求摘要}
- 添加时间: YYYY-MM-DD HH:MM
显示消息：
📝 已向 Plans.md 添加任务
| 任务 | 状态 |
|--------|-----------|
| {任务名} | `cc:WIP` |
开始实现...
为什么必需：确保所有工作可追踪，进度管理、审查、交接可靠。
Step 0: 质量判定门（最初执行）
任务开始前判定质量基准，必要时提案：
任务信息收集
↓
┌─────────────────────────────────────────┐
│ 质量判定门 │
├─────────────────────────────────────────┤
│ 判定项目: │
│ ├── 推荐TDD？（[feature] + 业务） │
│ ├── 注意安全？（auth/api/） │
│ └── 注意性能？（DB/循环） │
└─────────────────────────────────────────┘
↓
提出相应判定
TDD 判定基准
| 条件 | 推荐度 | 提案内容 |
|---|---|---|
| [feature] + src/core/ | ★★★ | “从测试开始写吗？” |
| [feature] + src/services/ | ★★★ | “从测试开始写吗？” |
| [bugfix] | ★★☆ | “先写重现测试吗？” |
| [config], [docs] | - | 判定跳过 |
安全判定基准
| 路径 | 提案内容 |
|---|---|
| auth/, login/, session/ | 显示安全检查清单 |
| api/, routes/ | 确认输入验证・授权检查 |
| payment/, billing/ | 支付安全检查 |
提案模板
面向工程师：
🎯 质量判定结果
| 判定 | 推荐度 | 理由 |
|------|--------|------|
| TDD | ★★★ | [feature] + 业务逻辑 |
从测试文件开始创建吗？
面向VibeCoder：
🎯 此作业注意事项
1. **先确定成功标准**
- 列出“什么完成后算OK”
选择进行方式：
1. 从成功标准开始创建（推荐）
2. 先开始创建
Step 1: LSP 活用指南
推荐在实现前使用LSP工具理解现有代码：
| LSP 操作 | 活用场景 | 效果 |
|---|---|---|
| goToDefinition | 确认现有函数实现 | 把握模式 |
| findReferences | 事前调查影响范围 | 防止破坏性更改 |
| hover | 确认类型信息・JSDoc | 正确接口 |
实现流程：
LSP.goToDefinition确认相关代码LSP.findReferences把握影响范围- 实现
LSP.diagnostics错误检查
使用例：
# 1. 确认相关函数实现
LSP operation=goToDefinition filePath="src/utils/auth.ts" line=25 character=10
# 2. 调查影响范围
LSP operation=findReferences filePath="src/utils/auth.ts" line=25 character=10
# 3. 确认类型信息
LSP operation=hover filePath="src/types/user.ts" line=15 character=12
注：仅在设置LSP服务器的语言中工作。
Step 2: 过去的实现模式搜索（Memory-Enhanced）
Claude-mem启用时，实现前搜索过去类似模式：
# 使用mem-search搜索过去的实现模式
mem-search: type:feature "{实现功能关键词}"
mem-search: concepts:pattern "{相关技术}"
mem-search: concepts:gotcha "{使用库/框架}"
mem-search: type:decision "{设计方针相关关键词}"
显示例：
📚 过去的实现模式
| 日期 | 模式 | 文件 |
|------|---------|---------|
| 2024-01-15 | API 端点: RESTful 设计 | src/api/*.ts |
| 2024-01-20 | 表单验证: Zod 使用 | src/components/forms/*.tsx |
💡 过去的gotcha（陷阱）：
- CORS: 服务器端必须设置Allow-Origin
- 类型安全: 禁止any，推荐unknown + type guard
相关决定事项显示：
⚖️ 相关设计决定
- D5: 状态管理采用Zustand（比Redux轻量）
- D8: API通信使用tRPC（类型安全）
💡 请根据上述决定实现
注：Claude-mem未设置时，跳过此步骤。
🔧 LSP 功能活用
实现时积极活用LSP（Language Server Protocol）。
实现前调查
| LSP 功能 | 用途 |
|---|---|
| Go-to-definition | 确认现有函数实现模式 |
| Find-references | 事前把握更改影响范围 |
| Hover | 确认类型信息・API 文档 |
实现中验证
| LSP 功能 | 用途 |
|---|---|
| Diagnostics | 即时检测类型错误・语法错误 |
| Completions | 使用正确API，防止拼写错误 |
实现后确认
实现完成时检查：
1. 执行LSP Diagnostics
2. 确认错误: 0件
3. 警告: 根据需要应对