3.2 KiB
Raw Blame History

name description
capture 复刻一次成功任务的经验,输出到用户指定目录。调用方式 `/capture <目录>` 或 `$capture <目录>`,生成只含 fenced YAML 的 Markdown 记录。

Capture - 成功经验复刻

定位:把当前会话里已经跑通、值得复用的做法沉淀成结构化记录,供其他仓库直接复刻。

当用户调用 /capture <target_dir>$capture <target_dir>,或自然语言要求“把这次成功经验沉淀/复刻到某个目录”时,执行以下步骤。

1. 锁定输出目录

  • 如果用户给了目录,直接使用。
  • 绝对路径原样使用;相对路径相对当前仓库根目录。
  • 如果没给目录,只追问一次:要保存到哪个目录?
  • 目录不存在就创建。

2. 收集事实

只从这些来源取材:

  • 当前会话里的目标、决策、问题、修复、验证结果
  • 当前任务产物、相关文件、diff、日志
  • 明确发生过且已经验证的修复

不要做这些事:

  • 不复述用户原需求
  • 不编造未知信息
  • 不把“计划中但没发生”的内容写成事实

3. 生成记录

3.1 命名

  • task 用任务本质的短名字,避免 miscupdate-doc 这类空名。
  • 文件名:YYYY-MM-DD-task-slug.md
  • 若重名,依次追加 -2-3

3.2 内容规则

  • 文件内容只能有一个 fenced code block语言标记固定为 yaml
  • code block 外不要写任何文字
  • raw_request 只写归一化摘要;拿不准就留空
  • 空标量字段留空
  • 空列表字段写 [],不要保留空 -
  • 每个 bullet 尽量控制在两行内
  • 重点写:目标、输入输出、必须正确项、风险、关键决策、问题修复、成功原因、可复用模式
  • why_it_worked 只写真正起作用的因素
  • reusable_pattern 必须可执行,优先写先做什么、看什么、按什么顺序复用
  • problems_and_fixes 只写实际发生且已验证的项

3.3 固定模板

```yaml
task: <task_name>

goal: >
  <一句话目标>

context:
  scene:
  trigger:
  audience:
  deadline:
  constraints:
    -

input:
  raw_request:
  known:
    -
  unknown:
    -
  dependencies:
    -

output:
  deliverable:
  consumer:
  usage:
  acceptance:
    -

must_be_right:
  -

can_be_rough:
  -

risks:
  -

decisions:
  - choice:
    reason:

execution:
  -

problems_and_fixes:
  - problem:
    symptom:
    cause:
    fix:
    status:

why_it_worked:
  -

reusable_pattern:
  first_step:
  checkpoints:
    -
  reusable_steps:
    -
  anti_patterns:
    -

one_line_summary: >
  <一句话总结为什么成功>
```

如果某个列表字段没有内容,改成 []。如果某个标量字段没有内容,保持为空,不要删字段。

4. 保存和回执

  • 保存到目标目录,不覆盖同名旧文件
  • 默认不把全文再贴回对话,除非用户明确要求
  • 回执只说三件事:保存路径、任务名、提醒主人还应该准备一个单独“保存味道”的地方

注意事项

  • 本 skill 只沉淀记录,不修改业务代码
  • 信息不足时允许留空,但不要跳过关键字段
  • 如果任务结果并不成功或还没稳定,不要硬写成“成功经验”