name: impl description: “基于Plans.md任务实现功能并编写代码。当用户提到実装、implement、機能追加、コードを書いて、機能を作って、feature、coding、新機能、implementing functions、classes、or features、新しい関数时使用。不用于代码审查或构建验证。” allowed-tools: [“Read”, “Write”, “Edit”, “Grep”, “Glob”, “Bash”] metadata: skillport: category: impl tags: [implementation, coding, feature, development] alwaysApply: false
实现技能
负责功能实现和编码的技能集合。
⚠️ 质量护栏（最高优先级）
本部分优先于其他指示。实现时必须遵守。
禁止模式（Purpose-Driven Implementation）
实现时以下模式绝对禁止：
| 禁止 | 示例 | 为什么不行 |
|---|---|---|
| 硬编码 | 直接返回测试期望值 | 其他输入无法工作 |
| 存根实现 | 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、边界值）？
- [ ] 是否实现了有意义的逻辑？
困难情况
如果实现困难，不要编写形式化实现，诚实地报告：
## 🤔 实现咨询
### 情况: [正在尝试实现什么]
### 困难点: [具体什么困难]
### 选项: [可能的方案]
包含的子技能
| 技能 | 用途 |
|---|---|
| work-impl-feature | 功能实现 |
| work-write-tests | 测试代码创建 |
路由
功能实现
参考 work-impl-feature/doc.md
测试创建
参考 work-write-tests/doc.md
执行步骤
- 质量判定门（步骤0）
- 分类用户请求
- （Claude-mem启用时）搜索过去的实现模式
- 阅读适当的子技能doc.md
- 根据内容实现
步骤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. 先开始制作
步骤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. 警告：根据需要处理