skill-writer

name	skill-writer
description	编写、压缩或重构 BK-CI skill 时使用，例如收紧 `description`、统一主文件骨架、下沉重内容到 `reference/`，并固化渐进式披露规则。当用户要新增或规范化 skill 时优先使用。

Skill Writer

适用场景

• 新建项目级或个人级 skill
• 压缩过长的 SKILL.md
• 将百科式文档拆成 SKILL.md + reference/
• 重写 description，提升 skill 路由命中率
• 统一一批 skill 的结构、命名和风格

不适用场景

• 只是补一两行普通说明，不涉及 skill 结构调整
• 只是新增业务知识，但不需要形成可复用 skill
• 用户要修改的是 rule、hook、普通文档，而不是 skill

快速指导

1. 先确定 skill 的单一职责。一个 skill 只解决一类问题，不要把总览、教程、百科和脚本说明混在一起。
2. 把 description 当成路由触发器，而不是功能简介。优先写“用户在什么场景下会需要它”。
3. 主 SKILL.md 只保留高信号内容：
   • 适用场景
   • 不适用场景
   • 快速指导
   • 高信号规则
   • 关键陷阱
   • 延伸阅读入口
4. 默认假设模型已经知道通用常识。只保留项目特有约定、容易出错的边界、历史坑点和明确偏好。
5. 主 SKILL.md 的目标不是“尽量短”，而是“短到只剩路由和行动指导”。在当前仓库里，主文件通常应收紧到约 40-80 行。
6. 重内容放到 reference/：
   • 大段背景知识
   • 长表格
   • 代码目录
   • 完整案例
   • FAQ
   • payload 示例
   • 状态枚举
   • 确认模板
7. 只有在流程高度确定、稳定且容易出错时，才把逻辑下沉到 scripts/ 或模板文件。
8. 所有链接尽量保持一层深度，避免主 skill 还要继续跳很多层目录。
9. 同 skill 内部优先使用相对路径；跨 skill 优先写 skill 名称，不要写死仓库目录路径。
10. 新增或重构时，优先清理遗留 frontmatter 字段，如 token_estimate、core_files、related_skills，除非仍有明确消费方依赖。

推荐骨架

# Skill 名称