功能设计记录器
这个 skill 帮助您在 docs/designs/ 目录下记录计划开发的功能。
使用场景
当用户说"我想开发 xx 功能"或"我想为 xx 命令添加一个功能"时：
- •提取功能描述 从用户输入中获取
- •创建文件名 使用格式：
YYYY-MM-DD-feature-name.md（日期 + 简短英文描述） - •创建 markdown 文件 在
/docs/designs/目录下 - •记录功能详情 用户提供的内容
- •分析业务代码位置 如果是为命令添加功能，分析相关代码位置
核心原则
⚠️ 绝对禁止修改代码
- •本 skill 仅用于功能设计和记录
- •无论如何都不会修改任何源代码文件
- •即使在 plan 模式下讨论后，也绝不执行代码修改
- •只创建文档文件，不触碰任何 .ts、.js、.json 等代码文件
- •如果用户要求修改代码，必须明确拒绝并说明本 skill 的职责范围
语言要求
重要：全程使用中文生成文档
- •所有功能描述和文档内容必须使用中文
- •文件名中的英文描述除外（保持技术命名规范）
- •plan模式讨论和最终生成的.md文档都必须是中文
- •代码分析和建议也要用中文表达
文件命名规范
- •使用当前日期格式：YYYYMMDD
- •添加功能的简短英文描述
- •用连字符分隔单词
- •保持简洁且具有描述性
示例：
- •
20240218-user-authentication.md - •
20240218-api-rate-limiting.md - •
20240218-dashboard-analytics.md
业务代码位置说明
如果是为某个命令添加功能，业务代码位于：/Users/linzhibin/Documents/coding/cli-tools/packages/cli/src/business 目录下
命令与目录对应关系：
- •
eng命令 →translate目录 - •其他命令 → 同名目录（如
git命令对应git目录）
分析步骤：
- •识别用户提到的命令名称
- •根据对应关系找到正确的业务目录
- •分析现有代码结构和服务文件
- •在功能记录中注明相关代码位置
文件内容结构
markdown
# 功能: [功能名称] **日期**: [当前日期] **状态**: 计划中 **相关命令**: [如果是为命令添加功能] **业务代码位置**: [具体的目录路径] ## 描述 [用户的功能描述] ## 需求 - [如果提供了需求列表] ## 代码分析 [对现有代码结构的分析和建议] ## 备注 [额外的备注或考虑事项]
重要说明
- •全程使用中文：包括plan模式讨论和最终文档内容
- •绝不修改代码：这是本 skill 的核心原则
- •文件创建在
/docs/designs/目录下 - •创建文件前确保目录存在
- •使用 markdown 格式以提高可读性
- •对于命令功能添加，会分析现有业务代码结构
示例输出
当用户说"我想为git命令添加分支合并历史查看功能"时，生成的文档将包含：
- •中文的功能描述和分析
- •指出相关代码在
/packages/cli/src/business/git目录下 - •用中文分析现有git命令的结构
- •所有内容都是中文，除了文件名中的技术术语
- •但不会修改任何git相关的代码文件
边界说明
如果用户试图让本 skill 修改代码：
- •明确告知本 skill 只负责功能设计和记录
- •建议用户使用其他适当的工具或 skill 来修改代码
- •坚持只创建文档文件的原则