oh-my-gh-writing 是做什么的？
面向 AI 代理的 GitHub 写作技能。路由请求，加载匹配的标准，保持证据边界明确，并生成接近可提交的 GitHub 草稿。
触发边界
仅在以下场景使用此技能：面向 GitHub 的写作制品以及本地 GitHub 写作草稿包。除非请求的输出是 GitHub 制品或 GitHub 仓库文件，否则不要将其用于通用文案、UI 文本、代码实现、产品策略或广泛的文档工作。
工作流程
- 判断用户需要的是单个制品还是多制品工作流包。
- 如果用户明确命名了单个制品，即使主题很宽泛，也直接路由到该制品。
- 如果用户请求的是宽泛的工作流、启动、部署、发布包或端到端材料集，则路由到匹配的复合工作流包。
- 如果用户要求检查、核对、审查就绪状态或推荐所需文件，则仅视为审计模式：仅输出差距分析和下一步文件推荐。除非用户明确要求起草、创建、编写、应用或更新文件，否则不要创建目标文件，不要创建
.github-writing/，也不要写入.github/或根仓库文件。 - 对于 README 请求，使用
references/readme.md中的三个问题提示。 - 对于复合工作流包，遵循该包的决策规则。仅当无法安全推断出包形态时才询问包选择问题；否则使用推荐的默认值，并将其记录在
package-manifest.md中。 - 在编写面向用户的输出之前，明确打开并读取匹配的
references/*.md文件。不要凭记忆推断或猜测引用的内容。 - 只读取由复合包选择的单个制品引用。不要预加载所有引用。
- 在需要徽章、警报、Mermaid、可折叠块、表情符号或复杂表格时，读取
references/weapons.md。 - 仅当用户请求详细的徽章设计或确切的 shields.io URL 模式时，才读取
references/badge-catalog.md。 - 当请求涉及表情符号或目标仓库已使用表情符号时，读取
references/emoji-guide.md。 - 当请求涉及大量事实、高风险、跨场景或需要明确输出质量规则时，读取
references/shared-principles.md。 - 在最终确定之前，使用
references/output-validation.md作为静默修订检查清单。如果草稿未通过检查，请在交付前进行修改。对于小型、干净的制品，保持验证静默；仅当制品复杂、高风险或存在明显阻碍时，才添加简短的输出后提交说明。
如果无法读取本地文件，请要求用户提供相关 references/*.md 的内容，或声明引用不可用，并仅根据可见的路由规则和共享原则生成保守的草稿。不要假装读取了你无法访问的文件。
渐进式披露：仅加载当前任务所需的文件。当确实需要多个引用且平台支持批量读取时，一次性读取它们，而不是串行调用工具。
语言保真度：匹配用户请求的语言或目标仓库的主要语言。此技能指令的语言不得泄露到最终的 GitHub 制品中。
场景路由
有关 18 个单制品标准和 7 个复合工作流包的完整列表，请参阅 INDEX.md。
使用以下顶级路由规则：
| 信号 | 路由至 |
|---|---|
| 用户请求一个明确的制品，例如“编写发布说明”或“创建 PR 模板” | 匹配的单制品引用 |
| 用户请求一个发布包、版本更新材料、主要发布准备或软件更新包 | references/version-release.md |
| 用户希望首次发布或开源一个仓库 | references/project-launch.md |
| 用户希望项目准备好迎接外部贡献者 | references/contribution-setup.md |
| 用户希望处理从报告或分类到修复 PR 的 Bug | references/bug-fix-workflow.md |
| 用户希望将一个想法转化为讨论、设计、Issue 和实现材料 | references/proposal-to-implementation.md |
| 用户需要一个破坏性变更沟通包 | references/breaking-change-package.md |
| 用户希望进行广泛的文档刷新或文档改造 | references/docs-overhaul.md |
当提示混合了 Issue、PR 和讨论语言时：
| 信号 | 路由至 |
|---|---|
| 未来功能请求，无已实现的差异 | 功能请求 |
| 对现有行为的改进 | 增强 |
| 社区意见，尚无定论 | 讨论 |
| 分支、差异或 PR 实现了新功能 | 功能 PR |
| 分支、差异或 PR 修复了 Bug 或回归 | 修复 Bug PR |
| 变更重构了代码但未改变行为 | 重构 PR |
| 仅更改了文档 | 文档 PR |
| 用户要求审查代码、PR 或差异 | 代码审查 |
如果用户要求将 PR、事后剖析或讨论转换为不同的制品，则根据请求的制品而不是源材料进行路由。
复合工作流默认值
复合工作流包是编排器，而不是模板。它们选择要加载哪些现有的单制品标准。
- 仅审计的提示产生推荐，而不是包文件。
- 仅当包的决策规则无法安全选择默认值时，才询问一个包选择问题。
- 当未询问就选择了默认值时，在
package-manifest.md中记录所选选项和假设。 - 在同一条消息中包含可选的补充内容。
- 默认输出位置是
.github-writing/<pack-name>/<version-or-date>/下的本地草稿文件。 - 如果不知道版本或日期，使用
.github-writing/<pack-name>/TBD/。 - 在每个复合包中包含
package-manifest.md，列出生成的文件、假设、TODO/TBD字段、可以安全写入的文件以及需要维护者确认的文件。 - 如果无法写入文件，则使用
## 文件: ...标题和围栏代码块将包显示为多文件聊天输出。不要声称文件已写入。 - 除非用户明确要求，否则不要发布、创建 GitHub 发行版、推送标签、打开 PR 或修改远程状态。
引用索引
加载 INDEX.md 以获取完整导航。常见引用分组：
| 分组 | 引用 |
|---|---|
| Issues | bug-report.md, feature-request.md, enhancement.md, discussion.md |
| Pull requests | feature-pr.md, bug-fix-pr.md, refactor-pr.md, documentation-pr.md |
| 审查和提交 | code-review.md, standard-commit.md |
| 文档 | readme.md, contributing.md, changelog.md |
| 发布和设计 | release-notes.md, migration-guide.md, rfc.md |
| 模板 | issue-form-yaml.md, pr-template.md |
| 复合包 | version-release.md, project-launch.md, contribution-setup.md, bug-fix-workflow.md, proposal-to-implementation.md, breaking-change-package.md, docs-overhaul.md |
| 附录 | shared-principles.md, weapons.md, badge-catalog.md, emoji-guide.md, output-validation.md, source-catalog.md |
缺失信息
仅当无法安全推断出必需的选择时（例如目标包名称、发布版本、破坏性变更意图、输出包形态或会改变制品结构的范围选择），才询问一个简短的后续问题。否则，使用 TBD 或 TODO，简要陈述假设，并在没有证据时移除可选部分。
仓库维护
- 将
SKILL.md保留为轻量级运行时路由器。 - 将特定场景和复合包的规则放入匹配的
references/*.md文件中。 - 将
INDEX.md仅作为导航使用。 - 默认情况下，将运行时指令保留为英文。
- 当发现 README 错误时，在
references/readme.md中更新面向 README 的经验教训。 - 将本地研究和验证输出保留在跟踪的运行时内容之外。