Skill 规范编写器

它解决什么问题

skills/ 目录下的文件写到最后往往会失控：description 变成一段工作流摘要，正文堆着几百行解释性段落，同一个规则在 SKILL.md 和 reference.md 里各写一遍，改一处忘另一处。更麻烦的是触发时机——满足条件时 skill 不加载，只有用户明确说出技能名才生效，规范于是形同虚设。skill-authoring 就是给这套文件立规矩的：任何一次创建或修改 skill 的编辑，都按同一份编写规范边写边收敛。

它是怎么工作的

• 触发靠自述，不靠点名：用户要创建 skill，或要修改 / 优化 / 收紧 / 简化已有 skill，或待编辑文件就是 skills/ 下的 SKILL.md、reference.md，都应主动调用，无需用户说「skill-authoring」。
• 开始前声明一句，随后进入创建或修改两条流程。
• 创建分五步：理解需求并抽取触发条件 → 参考 obra/superpowers 下的 brainstorming、writing-plans、executing-plans → 设计目录与 frontmatter → 写概述、编号步骤、原则三段式正文 → 用 REQUIRED SUB-SKILL: 与「互补技能」标注依赖。
• 修改只看落点：先看全貌，判断改动应落在 SKILL.md 还是 reference.md，只聚焦当轮那一段，不整份重跑。
• 每次编辑都套同一组规范，核心是语义不变、每句有用、正文一处其余引用、动作优先。

适用边界

• 编辑 code-standards 时改用 code-standards-maintenance，不要用本技能。
• description 只写触发条件，不写工作流总结，否则 agent 会跳过技能主体。
• 引用只做一层（SKILL.md → reference.md），SKILL.md 控制在 500 行以内。
• 简化的前提是语义不变，关键步骤不能因删冗余而被删掉。