メニュー
当创建新技能、编辑现有技能或在部署前验证技能工作时使用
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
当面临 2+ 个独立任务，可以在没有共享状态或顺序依赖的情况下工作时使用
当在当前会话中执行具有独立任务的撰写计划时使用
当你有一个书面的撰写实施计划，需要在一个单独的会话中执行，并带有审查检查点时使用
当收到同行评审反馈时使用，在实施建议之前，特别是当反馈看起来不清楚或在学术上值得商榷时——需要学术严谨和验证，而不是表演性的同意或盲目实施
当撰写完成，所有逻辑检查通过，你需要决定如何整合工作时使用——通过展示清晰的合并、提交审阅或清理选项来指导完成开发工作
在进行任何创造性工作之前必须使用此技能——无论是撰写新章节、构建理论框架、增加论据还是修改论证逻辑。在撰写正文之前，先探索研究目标、要求和论证设计。
| name | sa-meta_skills |
| description | 当创建新技能、编辑现有技能或在部署前验证技能工作时使用 |
编写技能就是应用于流程文档的论证驱动写作 (ADW)。
你编写验证场景（带有子智能体的压力场景），观察它们失败（基线行为），编写技能（文档），观察验证通过（智能体遵守），然后完善（堵塞漏洞）。
核心原则： 如果你没有看到智能体在没有技能的情况下失败，你就不知道技能是否教授了正确的东西。
所需背景： 在使用此技能之前，你必须了解 superpowers:sa-writing (ADW)。该技能定义了基本的“主张-证据-完善”循环。本技能将 ADW 改编为文档编写。
技能是经过验证的技术、模式或工具的参考指南。技能帮助未来的智能体实例找到并应用有效的方法。
技能是： 可重用的技术、模式、工具、参考指南 技能不是： 关于你曾经如何解决问题的叙述
| ADW 概念 | 技能创建 |
|---|---|
| 待证主张 | 压力场景下的预期行为 |
| 正文/证据 | 技能文档 (SKILL_zh.md) |
| 验证失败 | 智能体在没有技能的情况下违反规则（基线） |
| 验证通过 | 智能体在有技能的情况下遵守规则 |
| 完善 | 在保持合规的同时堵塞漏洞 |
| 先提出主张 | 在编写技能之前运行基线场景 |
| 看它失败 | 记录智能体使用的确切借口 |
| 最简证据 | 编写针对那些特定违规行为的技能 |
| 看它通过 | 验证智能体现在遵守了 |
| 完善循环 | 发现新借口 → 堵塞 → 重新验证 |
整个技能创建过程遵循 主张-证据-完善 (Claim-Evidence-Refine)。
创建当：
不要创建用于：
具体的遵循步骤（condition-based-waiting, root-cause-tracing）
思考问题的方式（flatten-with-flags, test-invariants）
API 文档，语法指南，工具文档
skills/
skill-name/
SKILL_zh.md # 主要参考（必需）
supporting-file.* # 仅在需要时
扁平命名空间 - 所有技能在一个可搜索的命名空间中
单独文件用于：
保持内联：
Frontmatter (YAML):
name 和 descriptionname: 仅使用字母、数字和连字符description: 第三人称，仅描述何时使用（不是它做什么）
---
name: Skill-Name-With-Hyphens
description: 当 [具体的触发条件和症状] 时使用
---
# 技能名称
## 概述
这是什么？用 1-2 句话概括核心原则。
## 何时使用
[如果决定不明显，使用小型内联流程图]
带有症状和用例的要点列表
何时**不**使用
## 核心模式 (用于技术/模式)
代码/逻辑的 前/后 对比
## 快速参考
用于浏览常见操作的表格或要点
## 实施
简单模式的内联代码
链接到重型参考或可重用工具的文件
## 常见错误
什么会出错 + 修正
## 现实世界影响 (可选)
具体结果
发现的关键： 未来的智能体需要找到你的技能
目的： 智能体阅读描述以决定为给定任务加载哪些技能。让它回答：“我现在应该阅读这个技能吗？”
格式： 以“当...时使用”开始，专注于触发条件
关键：描述 = 何时使用，而不是技能做什么
描述应仅描述触发条件。不要在描述中总结技能的流程或工作流。
陷阱： 总结工作流的描述会创建一个智能体采取的捷径。技能正文变成智能体跳过的文档。
使用智能体可能会搜索的词：
使用主动语态，动词优先：
creating-skills 而不是 skill-creationwriting 而不是 writing-method目标字数：
仅在以下情况使用流程图：
绝不用于：
一个优秀的示例胜过许多平庸的示例
选择最相关的语言/格式。
好的示例：
没有先行的验证失败，就没有技能
(NO SKILL WITHOUT A FAILING TEST FIRST)
这适用于新技能和对现有技能的编辑。
在测试之前编写技能？删除它。重新开始。
示例： ADW, submission_check
测试方法：
示例： condition-based-waiting, root-cause-tracing
测试方法：
测试方法：
测试方法：
执行纪律的技能需要抵制合理化。智能体很聪明，会在压力下寻找漏洞。
不要只陈述规则——禁止具体的变通方法：
```markdown 在提出主张之前写正文？删除它。重新开始。无例外：
</Good>
### 解决“精神 vs 字面”的争论
尽早添加基本原则：
```markdown
**违反规则的字面意思就是违反规则的精神。**
在没有技能的情况下运行压力场景。记录确切行为：
编写解决那些特定借口的技能。不要为假设情况添加额外内容。
在有技能的情况下运行相同的场景。智能体现在应该遵守。
智能体找到了新借口？添加明确的反制措施。重新测试直到无懈可击。
主张阶段 - 编写验证失败：
证据阶段 - 编写最简技能：
完善阶段 - 堵塞漏洞：
质量检查：
创建技能就是用于流程文档的 ADW。
同样的铁律：没有先行的失败验证就没有技能。 同样的循环：主张（基线）→ 证据（编写技能）→ 完善（堵塞漏洞）。 同样的好处：更好的质量，更少的意外，无懈可击的结果。