⚡

功能实现技能Skill impl

这个技能专注于基于Plans.md任务进行功能实现和代码编写，强调质量保证和测试驱动开发（TDD）。它禁止硬编码和存根实现，提倡使用LSP工具进行代码分析，帮助确保代码质量和可维护性。关键词：功能实现、代码编写、Plans.md、质量保证、TDD、LSP、软件开发、测试创建。

测试 0 次安装 0 次浏览 更新于 3/10/2026

name: impl description: “基于Plans.md的任务实现功能并编写代码。当用户提到实现、添加功能、编写代码或创建新函数时使用。不用于审查或构建验证。” description-en: “基于Plans.md的任务实现功能并编写代码。当用户提到实现、添加功能、编写代码或创建新函数时使用。不用于审查或构建验证。” description-ja: “Plans.mdのタスクに基づいて機能を実装しコードを書く。Use when user mentions implementation, adding features, writing code, or creating new functions. Do not use for review or build verification.” 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

执行步骤

  1. Plans.md 注册确认（步骤 -1）← 必须
  2. 质量判定门（步骤 0）
  3. 分类用户的请求
  4. （Claude-mem 有效时）搜索过去的实现模式
  5. 从上述“功能详细”阅读适当参考文件
  6. 根据其内容实现

步骤 -1: Plans.md 注册确认（最优先·必须）

⚠️ 实现前必须在 Plans.md 注册任务

用户请求接收
    ↓
读取 Plans.md
    ↓
┌─────────────────────────────────────────────────────────────┐
│ 请求内容在 Plans.md 中存在吗？                          │
├─────────────────────────────────────────────────────────────┤
│  YES → 直接进入实现                                   │
│  NO  → 添加到 Plans.md 后进入实现                    │
└─────────────────────────────────────────────────────────────┘

添加时格式:

## 🟡 未着手任务

- [ ] {任务名} `cc:WIP`
  - 请求内容: {用户请求摘要}
  - 添加日期: YYYY-MM-DD HH:MM

显示消息:

📝 在 Plans.md 添加了任务

| 任务 | 状态 |
|--------|-----------|
| {任务名} | `cc:WIP` |

开始实现...

为什么必须: 使所有作业可追踪，确保进度管理·审查·交接。

步骤 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. 先开始制作

步骤 1: LSP 活用指南

实现前推荐用 LSP 工具理解现有代码:

LSP 操作 活用场景 效果
goToDefinition 确认现有函数实现 把握模式
findReferences 事前调查影响范围 防止破坏性变更
hover 确认类型信息·JSDoc 正确接口

实现流程:

  1. LSP.goToDefinition 确认相关代码
  2. LSP.findReferences 把握影响范围
  3. 实现
  4. 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 服务器的语言中工作。

步骤 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. 警告: 根据需要对应

详细: docs/LSP_INTEGRATION.md