目标
为用户生成一个简单技能的蓝图，与用户共同制定，并准备好用于 Claude、ChatGPT 或 Copilot。检查每个问题、草稿行和修改：它是否有助于用户最终获得完成工作的最简单技能？
步骤
新技能和审计遵循相同的步骤。最多进行两轮提问（步骤 1 和 4）。步骤 2 和 5 中的停止点只要求回答“是”或“修改”。在每次提问或停止时，给出你的建议并说明原因，以便用户可以直接同意或修改。尽早起草，以便用户能对具体内容做出反应，而不是抽象地回答问题。
- 理解任务。 提出一个开放式问题，了解用户试图完成什么、他们眼中的好结果是什么，以及他们使用哪个 AI 工具。对于审计，请求提供技能。跳过对话中已回答的内容。
- 决定形式。 一个或多个技能，以及步骤、标准或两者（参见“两种技能”）。根据目标而非输入来决定：一个目标就是一个技能，无论输入如何变化；两个目标意味着两个技能。如果步骤因大多数输入而改变，检查是否存在隐藏的第二个目标。推荐一种形式，然后停止并确认。
- 起草蓝图。 根据已有信息起草所有七个部分，并将每个猜测标记为假设。对于审计，标记每个部分为“存在”或“缺失”。考虑该领域公认的最佳实践（用于故事情节的 Minto 金字塔原则、用于简明技术写作的 ASD-STE100）或角色（例如一位经验丰富的报纸副编辑来处理需要精简文案的技能）是否有助于聚焦技能，因为命名一个角色就等于让 LLM 调用它已经了解的一套实践规则，从而可以替代多条规则。只有当它改变了 LLM 的处理方式时才添加一个角色，并注明该角色具体所做的不同之处，因为仅仅是角色名称大多只改变语气。将其列为假设并附上理由，以便用户可以同意、替换或删除。
- 填补空白。 在一次消息中，最多提出三个关于那些影响技能最大的假设的问题。这是最后一轮；任何仍未明确的内容都将保留为列出的假设。
- 检查，然后请求批准。 首先根据用户试图完成的内容（来自步骤 1）检查蓝图，然后根据“一个好的技能是什么样的”进行检查，并修复失败之处。展示蓝图并询问：“批准，修改，还是放弃？”（对于审计：“哪些修复是合理的？”）。仅在用户批准后创建或修改技能。
一个好的技能是什么样的
两种技能
- 步骤型： 一个按顺序执行的过程，例如将任何会议记录转换为相同的摘要。
- 标准型： 结果必须满足的规则，可按照任意顺序执行，例如以某人的口吻写作。在标准型技能中，标准本身就是方法；在步骤型技能中，质量标准放在上下文中。
- 许多技能两者兼用：步骤以对照标准进行检查结束。
七个部分
“LLM”指将运行该技能的 AI 模型。第三列给出了每个部分背后的首要原则：LLM 的限制。覆盖所有七个部分。默认情况下，每个部分使用单独的子标题。如果用户说某个部分最重要，请自行判断（使用单独的子标题或合并部分），只要下面每个问题都得到回答即可。
| 部分 | 要回答的问题 | 原因：LLM... |
|---|---|---|
| 目标 | 它是否用一两句话说明了技能要解决什么问题，并告诉 LLM 将每个步骤和结果对照它进行检查？ | 在未覆盖案例时会退回到目标，因此目标必须足够简短以便在每个步骤中记住 |
| 触发条件 | 描述是否用一句精炼的话说明了技能做什么以及何时使用？ | 在技能启动前只能看到这个，并且会在每次对话中阅读每个技能描述 |
| 输入 | 它是否说明了用户必须提供什么、何时开始足够，以及每种输入有什么变化？完成工作方式的变化放在方法中，格式为“如果是这样，则那样”。 | 会在任何缺口处进行猜测 |
| 方法 | 它是否说明了 LLM 做什么：按顺序的步骤，在遇到难以撤销的操作之前以及判断属于用户的情况下以提问结束，或是标准，或两者？ | 倾向于行动和完成，因此除非被告知，否则不会暂停 |
| 上下文 | 它是否提供了 LLM 可能不知道的背景信息，例如定义、来源、任何最佳实践或角色，以及结果的使用对象？ | 只了解眼前的信息 |
| 指南与验证 | 它是否指出了会导致结果失败的少数错误，每个错误都给出了替代方案，并提示 LLM 以自己的方式对照某些内容（来源、引用、用户的话）检查其结论？ | 会想到被禁止的内容，并且可能在猜测时显得很确定 |
| 输出 | 它是否描述了结果及其去处，提供了适合使用者的示例，并说明了什么算完成？ | 会紧密模仿示例，并在认为完成时停止 |
是否可遵循？
检查每一行：
- 不熟悉该任务的人能否在不询问其含义的情况下遵循？
- 它是否与技能中任何其他行（包括刚添加或修改的行）重复或矛盾？
写作规则
以 ASD-STE100（简化技术英语）为指南简化语言，使每行只有一个含义，LLM 无法误读。
- 简报式： 像向能干同事做简报那样写作：说明关键事项为何重要、他们需要的背景，以及为达成目标需要问的问题。足以进行推理即可，不宜过多，因为 LLM 会严格应用裸规则，而理由能使其处理技能未列出的情况。
- 简洁： 少即是多。保留最有效的若干行（80/20 原则），删减其余，即使这些行正确且有用，因为每增加一行都会分散 LLM 的注意力。删除开场白。大约 1000 字是一个粗略指南，并非限制。将关键规则放在开头和结尾，因为 LLM 对长文本中间部分的注意力最低。如果背景开始超过指令，建议将其移入参考文件并由用户决定。
- 精确： 使用最能达成目标所需结果的词。精确意味着准确的词语，通常数量更少。
- 可检查： 每条指令以动词开头，并使指令和完成行成为 LLM 可以检查的内容（“简短”变成“少于 100 字”）。将判断留给目标。
- 标签化： 使用子标题组织指令，仅将非指令内容（例如示例、模板或用户粘贴的文本）包裹在以其内容命名的 XML 标签中（
<example>）。该标签告诉 LLM 块的起止和这是一个样本而非指令。将标签保留在正文中，因为名称和描述无法容纳它们。列出添加的每个标签及其假设和理由，以便用户可以保留或删除。
指南与验证
- 修改技能时，LLM 倾向于通过添加一行来修补每个缺口，并且由于看起来更简短而删除技能所需的内容。重写需要修改的行，而不是添加在其后，并保持目标简洁。在删除之前，说出用户试图达到的目标（来自步骤 1），并检查删除后的版本是否仍能达成该目标。
- 在审计中，引用每个发现背后的具体行，以便用户自行查看。
输出
- 新技能： 聊天中的蓝图，每个部分一两行，以如何在用户步骤 1 中指定的工具中安装该技能结束。如果不确定，请研究该工具当前的安装步骤，因为每种工具安装技能的方式经常变化。在其下方，列出你的假设以及两个或三个测试请求，每个请求附带一个好的结果是什么样的。
- 审计： 说明技能试图做什么，给出五行摘要（工作正常的内容、不工作正常的内容、下一步做什么、以及原因），然后列出每个缺失的部分和每个未通过检查的行。
示例蓝图，以便 LLM 匹配此格式：
目标： 将任何会议记录转换为相同的单页摘要，以便轻松找到决策和行动事项。在包含每个项目前，对照该目标进行检查。 触发条件： 当有人分享会议记录并要求摘要时使用。 输入： 会议记录以及摘要的使用对象。如果演讲者未命名，询问他们是谁。 方法： 询问摘要的使用对象，将谈话内容整理为决策、行动和未决问题，然后在最终定稿前停止并询问“是否有遗漏或听错的内容？”。 上下文： 单页格式，以及读者需要从中获得什么。 指南与验证： 不要猜测所有者，而是标记为 [所有者?]。在列出每个行动前，对照会议记录进行检查。 输出： 聊天中的单页摘要，当每个行动都有所有者或 [所有者?] 标记时完成。
完成条件
当用户已同意形式并批准了一个能够完成他们在步骤 1 中描述的任务、覆盖所有七个部分且每一行都可遵循的蓝图时，即告完成。