writing-skills 是一个关于“如何编写技能”的技能；这里的技能指供未来智能体查找和使用的可复用技术、模式或工具参考指南。它把测试驱动开发（TDD）的 RED-GREEN-REFACTOR 循环套用到流程文档上：先写测试（用子代理构造压力场景），观察失败（无技能时的基线行为），再写技能文档，观察测试通过（智能体遵守），最后重构以封堵漏洞。
核心原则：如果没有亲眼看到智能体在缺少该技能时失败，就无法判断技能是否教了正确的东西。文中强调必须先理解 test-driven-development 技能，并设有“铁律”：任何新技能或对现有技能的编辑都必须先有失败测试；若先写后测，则应删除重来。
主要能力与内容规范：区分技能与非技能（技能是可复用技术、模式、工具、参考指南，而不是“我某次如何解决问题”的叙述）；按触发方式把技能分为技术、模式、参考三类；给出技能目录结构（skills/skill-name/SKILL.md 及必要的支撑文件）和 SKILL.md 的结构（YAML frontmatter 必填 name 与 description，总计不超过 1024 字符，name 仅用字母、数字和连字符，description 用第三人称、以“Use when...”开头、只描述何时使用而不总结工作流，尽量少于 500 字符）。
技能发现优化（SDO）：强调 description 是智能体决定是否加载技能的依据，只写触发条件、症状与上下文，不概括流程，否则智能体会按 description 走捷径而不读正文；要求覆盖错误信息、症状、同义词和工具名等关键词，采用动词优先的描述性命名（如 creating-skills），控制 Token（入门工作流少于 150 词、高频加载技能总计少于 200 词、其他少于 500 词），并通过交叉引用、压缩示例、消除冗余来精简。
交叉引用与流程图：引用其他技能时只写技能名并加明确的必需标记（如 REQUIRED SUB-SKILL、REQUIRED BACKGROUND），不用路径或 @ 链接，避免强制加载消耗上下文；流程图只用于非显而易见的决策点、可能过早停止的流程循环和“A 与 B 如何选择”，不用于参考材料、代码示例或线性步骤。
代码示例与文件组织：建议一个完整可运行、注释说明原因、来自真实场景的示例，而非多语言实现或填空模板；按自包含技能、含可复用工具的技能、含大量参考的技能三种方式组织文件，重引用（100 行以上）和可复用工具放到独立文件。脚本调用需通过解释器（如 bash scripts/tool.sh、node scripts/tool.js），不要直接使用裸路径。
测试方法：按技能类型区分测试重点：纪律约束型技能用学术问题和多重压力场景检验合规；技术型技能用应用、变体和信息缺失场景检验能否正确运用；模式型技能用识别、应用和反例场景检验；参考型技能用检索、应用和缺口测试检验。文中还列出跳过测试的常见理由（如“技能很明显”“只是参考”“测试过度”），并逐一反驳。
适用场景：当需要创建新技能、编辑现有技能或在部署前验证技能是否有效时使用；也用于把某类修复或继续原有任务的流程记录成可复用文档。限制：文中多处提到具体运行时的技能目录（如 ~/.claude/skills/、~/.grok/skills、~/.agents/skills/）和配套文件（如 anthropic-best-practices.md、codex-tools.md、gemini-tools.md、graphviz-conventions.dot、render-graphs.js），但该页面未提供这些文件的完整内容，具体安装、收费、平台支持等信息暂未提供。