用途
Writing Skills 是一个关于「如何编写技能」的技能。它的核心主张是：编写技能文档等同于把测试驱动开发（TDD）应用到流程文档上。作者认为，如果你没有亲眼看过某个代理在没有该技能时失败，你就无法确认这个技能教的是对的内容。
因此它适用于以下场景：创建新技能、编辑已有技能、以及在部署前验证技能是否真正生效。
主要能力
该技能把 TDD 的概念映射到技能创建流程：
- 测试用例 → 带子代理的压力场景
- 生产代码 → 技能文档（SKILL.md）
- 测试失败（RED）→ 代理在没有技能时违反规则（基线行为）
- 测试通过（GREEN）→ 代理在技能存在时遵守规则
- 重构 → 在保持合规的前提下堵住漏洞
整个技能创建流程遵循 RED-GREEN-REFACTOR 循环：先跑基线场景、观察失败并记录代理的狡辩理由，再针对这些具体违规点写最小技能，然后验证代理是否合规，最后反复「发现新狡辩 → 堵住 → 再验证」。
它还给出了何时应该创建技能的判断标准（技术并非显而易见、会跨项目反复参考、模式适用范围广、对他人也有价值），以及不应创建的情况（一次性方案、别处已有良好文档的标准实践、项目特定约定、可以用正则或校验自动化的机械约束）。此外它区分了技能类型：技术（Technique）、模式（Pattern）和参考（Reference）。
使用方式
技能存放在代理专属目录中，例如 Claude Code 的 ~/.claude/skills、Codex 的 ~/.agents/skills/。文档采用扁平命名空间，每个技能一个目录，其中 SKILL.md 为主参考文件（必需），仅在需要时添加支撑文件。
SKILL.md 的 frontmatter 为 YAML，只支持 name 和 description 两个字段，总计不超过 1024 个字符。name 只能使用字母、数字和连字符；description 使用第三人称，只描述「何时使用」而不是「做什么」。description 应以「Use when...」开头，包含具体症状、情境和上下文，并尽可能控制在 500 字符以内，且绝不要概括技能自身的流程或工作流。
文档正文推荐的章节结构包括：Overview、When to Use、Core Pattern、Quick Reference、Implementation、Common Mistakes、Real-World Impact（可选）。
技能还包含「Claude Search Optimization（CSO）」部分，说明如何让未来的 Claude 实例能够发现该技能，包括丰富的 description 字段、关键词覆盖（错误信息、症状、同义词、工具名）以及以动词开头的描述性命名（如 creating-skills 而非 skill-creation）。它还强调 token 效率，给出目标字数：getting-started 工作流每个少于 150 词、频繁加载的技能总计少于 200 词、其他技能少于 500 词，并可用 wc -w 验证。
关于引用其他技能，它要求只用技能名加上明确的必需标记（例如「REQUIRED SUB-SKILL」「REQUIRED BACKGROUND」），并明确不建议使用 @ 链接，因为 @ 语法会立即强制加载文件、消耗大量上下文。
关于流程图，它规定只用于非显而易见的决策点、可能过早停止的流程循环、以及「A 还是 B」的选择；绝不用于参考资料、代码示例或线性指令。文中还提到可用目录中的 render-graphs.js 把技能流程图渲染为 SVG，并给出了命令示例。
适用场景
适合需要编写或维护代理技能文档、并希望这些文档在真实使用中确实改变代理行为的场景。它特别强调对「强制纪律型技能」（规则/要求）、技术类技能、模式类技能和参考类技能分别采用不同的测试方法，例如对强制纪律型技能使用学术问题、压力场景和多重压力组合，并识别狡辩话术、加入明确的反驳。
限制
使用该技能有前置要求：使用者必须先理解 superpowers:test-driven-development，该技能定义了基础的 RED-GREEN-REFACTOR 循环。它还引用了一份官方指导文档 anthropic-best-practices.md 作为补充。文中强调一条「铁律」：没有失败的测试就不写技能，这条规则同样适用于对已有技能的编辑；若先写技能再测试，应删除并重来。文中还列出常见的跳过测试的借口及其反驳，并提到可参考 persuasion-principles.md 了解说服技巧的研究基础。
关于该技能的收费、价格、平台支持范围等具体信息，资料中暂未提供。