技能

技能是一套 agent 在需要的时候会拿出来用的说明 —— 一段写下来一次的流程,而不是每次都 往提示词里粘一遍。

内置哪些

六个流程随产品一起来,在任何目录都能用:

技能	做什么
spreadsheet-review	按写明的规则核查一张表,列出违规的行和行号
weekly-report	这里这段时间实际变了什么 —— 做完的、在做的、以及需要谁拍板的
inbox-triage	按「在要求什么」给消息分类,挑出必须由人回的
document-compare	两版之间实质变了什么,和只是措辞变了的分开
meeting-notes	把录音记录变成决定、带负责人的行动、和悬而未决的问题
records-review	在一堆记录里挑出值得核对的,并引用它来自哪一条

另外两个是继承来的,讲的是怎么写技能和装技能本身:skill-creator 和 skill-installer。

它们从哪里来

范围	目录
内置	~/.opencli/skills/.system —— 应用更新时重写
你自己的	~/.opencli/skills
这个项目的	工作目录里的 .opencli/skills

写一个

一个目录加一个 SKILL.md,前置信息里说明它是什么、以及什么时候该用它:

---
name: invoice-check
description: 按我们的付款规则核查发票，报出违反规则的。当被要求
  审查、核对或审计一批发票时使用。
metadata:
  short-description: 找出违反规则的发票
---

# 发票核查

## 先找到规则，再读数据
...

description 是 agent 拿来匹配请求的东西。一个只说「这是什么」的描述,会让模型自己去猜 什么时候适用 —— 内置的六个每一个都写明了它的场合,你的也应该。

什么让一个技能真的管用

读那六个内置的是看清形状最快的方式,但有三点反复出现:

• 说清楚读什么、按什么顺序读。 「最早的先读」是一条真指令;「审查这些记录」不是。
• 说清楚产出什么。 一个具名的文件,或者一个写明的结构。不是「一份总结」。
• 说清楚绝对不许做什么。 内置的病历技能有三分之一的篇幅在写这个,而那正是它能存在的原因。

还有一条是吃过亏才知道的:如果一个数字重要,就要说明这个数字必须从哪里来。表格核查 技能要求报出行数,而第一次运行凭记忆报了个数,错了一位。现在它要求这个数字必须来自 做核查的那个脚本。

关掉一个

每个技能在能力 → 技能里有开关。改动对下一个打开的对话生效,不是正在跑的这个。