skill-capture

技能捕获

此技能的触发条件

用户提及以下任意内容时，激活此技能：

明确请求

• “我们把这个保存为技能吧”
• “这个工作流应该可以复用”
• “把这个捕获为技能”
• “把它做成技能”
• “把这个转换成技能”
• “保存这个模式”

工作流完成信号

• 经过多次迭代解决了复杂问题
• 成功执行了多步骤流程
• 通过研究发现了有价值的领域知识
• 形成了可供其他项目复用的代码模式

学习时刻

• “这个问题真不好解决”
• “真高兴我们终于让它跑起来了”
• “真希望我能早点知道这点”
• “这个应该记录下来”

---

捕获流程

捕获请求授权编辑匹配的技能。仅有完成信号时，只能提出建议，不得持久化或提交到跟踪器。遵循用户设定的范围，对范围之外的重大更改须先征求同意。

请按顺序遵循以下 5 个阶段：

阶段 1：识别

回顾对话，找出可捕获的内容：

关注点：

类别	示例
工作流	经过多次迭代才完善的多步骤流程
领域知识	需要研究或专业知识的信息
问题解决方案	解决复杂问题的方法
代码模式	可帮助其他项目的可复用模式
决策依据	理由明确的架构选择

需要自问：

• 这是否适用于当前项目之外的场景？
• 其他 Agent 会话是否能从这些知识中受益？
• 是否需要多次迭代才能做好？
• 这是否属于不明显的流程知识？

阶段 2：规划存放位置

确定技能应存放在哪里：

1. Check if an existing skill should be updated
   - Glob for skills/*/SKILL.md
   - Read related skills to check for overlap

2. If creating new skill:
   - Choose descriptive kebab-case name
   - Create in skills/<skill-name>/ directory

技能与规则的选择：

创建技能	捕获规则
多步骤工作流	单一偏好说明
流程知识	“始终／绝不执行 X”
领域专业知识	风格／格式偏好
有上下文的代码模式	导入／命名约定

如果内容属于规则／偏好，请改用 rules-capture 技能。

阶段 3：起草内容

将对话中的见解转换为 SKILL.md 格式：

---
name: <skill-name>
description: <One sentence describing what the skill does and when to use it>
metadata:
  version: "1.0.0"
  tags: relevant, tags
---

# <Skill Title>

<Brief description of the skill's purpose>

---

## When to Use

<Clear triggers for when this skill should activate>

---

## Process

<Step-by-step workflow or procedure>

---

## Examples

<Concrete examples showing the skill in action>

---

## Integration

<How this skill works with other skills, if applicable>

阶段 4：提炼

提取并完善内容：

1. 提取最终方案——只记录有效做法，不记录失败尝试
2. 泛化——移除不具备普遍适用性的项目专属细节
3. 补充背景——说明某些做法为何有效，而不只是说明该怎么做
4. 添加示例——提供展示用法的具体示例

检查清单：

• 移除了项目专属路径和名称
• 泛化了硬编码值
• 为不明显的步骤补充了解释性背景
• 在有帮助时加入了正例和反例
• 使用祈使语气

阶段 5：验证

确保技能可以投入使用：

质量检查：

检查项	要求
长度	少于 500 行（内容较多时使用 references/）
Frontmatter	有效的 YAML，包含 name 和 description
完整性	所有章节都有实质性内容
可操作性	指令足够具体，便于遵循
格式	遵循库中的模式（参见 rules-capture 作为参考）

验证：

# Run the package script to validate
scripts/package_skill.py skills/<skill-name>

---

适合捕获的内容

优质候选内容

• 经过多次迭代才完善的工作流
• 需要研究的领域知识
• 行之有效的问题解决方法
• 可在多个项目间复用的代码模式
• 架构选择的决策依据
• 工具或服务之间的集成模式
• 针对特定技术的调试方法

反模式（不要记录）

• 仅适用于单个项目的一次性解决方案
• 微不足道的修复或显而易见的模式
• 已在其他地方记录的信息
• 敏感或专有信息
• 仍在完善中的不完整工作流
• 没有流程价值的偏好（改用 rules-capture）

---

输出结构

为每项技能创建两个文件：

SKILL.md

参见上文的第 3 阶段模板。关键原则：

• 使用祈使句形式（“执行 X”，而不是“你应该执行 X”）
• 明确说明触发条件和激活条件
• 提供具体示例
• 引用随附资源

plugin.json

{
  "name": "<skill-name>",
  "version": "1.0.0",
  "description": "<Same description as SKILL.md frontmatter>",
  "author": {
    "name": "Ship Shit Dev",
    "email": "[email protected]",
    "url": "https://shipshit.dev"
  },
  "license": "MIT",
  "skills": "."
}

---

集成

此技能与以下内容集成：

技能	集成方式
rules-capture	委派偏好记录；负责创建技能
skill-creator	使用创建模式和验证
docs	为 SKILL.md 提供格式帮助

---

交互示例

情境：用户花了 30 分钟调试 NestJS 队列集成问题。解决方案涉及特定的配置模式。

用户：“这个问题真难搞。我们把解决方法保存下来，下次用吧。”

Agent：

I'll capture this as a skill. Let me analyze what we learned:

Capturable Knowledge:
- NestJS Bull queue configuration pattern
- Redis connection handling for queues
- Processor registration requirements

This would make a good standalone skill or could extend `nestjs-queue-architect`.

Let me check the existing skill...
[Reads skills/nestjs-queue-architect/SKILL.md]

The existing skill covers queue setup but not this specific debugging pattern.
I'll add a new "Troubleshooting" section.

Created: skills/nestjs-queue-architect/SKILL.md (updated)
- Added troubleshooting section
- Documented Redis connection requirements
- Added common error patterns

Should I also create session documentation for this debugging session?

---

激活触发条件

技能会在出现以下模式时激活：

# Explicit capture requests
(save|capture|turn|make).*(skill|reusable|pattern)
(this should be|let's make this).*(skill|documented|reusable)

# Workflow completion signals
(finally|glad).*(working|figured|solved)
(this was|that was).*(tricky|hard|difficult|complex)
(multiple|several).*(iterations|attempts|tries)

# Learning signals
(wish I knew|should have known|next time|for future)

会话回顾

建议使用 /retro 回顾已结束的会话，查找阻碍。Retro 会将候选技能转回此处。