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 成品中。
情境路由
請參閱 INDEX.md 以取得完整的 18 種單一成品標準與 7 個複合工作流程套件列表。
使用以下頂層路由規則：
| 訊號 | 路由至 |
|---|---|
| 使用者要求一個明確的成品，例如「撰寫 Release Notes」或「建立 PR 範本」 | 對應的單一成品參考 |
| 使用者要求一個發布套件、版本更新素材、重大版本發布準備或軟體更新組合 | references/version-release.md |
| 使用者希望首次發布或開源一個儲存庫 | references/project-launch.md |
| 使用者希望專案準備好迎接外部貢獻者 | references/contribution-setup.md |
| 使用者希望處理從回報或分類到修復 PR 的錯誤 | references/bug-fix-workflow.md |
| 使用者希望將想法轉化為討論、設計、Issue 和實作素材 | references/proposal-to-implementation.md |
| 使用者需要一個破壞性變更的溝通套件 | references/breaking-change-package.md |
| 使用者希望進行廣泛的文件更新或文件大改造 | references/docs-overhaul.md |
當提示混雜了 Issue、PR 和討論的語言時：
| 訊號 | 路由至 |
|---|---|
| 未來功能請求，無已實作的差異（diff） | 功能請求 |
| 改善現有行為 | 增強 |
| 社群意見，尚無確定解決方案 | 討論 |
| 分支、差異（diff）或 PR 實作了新功能 | 功能 PR |
| 分支、差異（diff）或 PR 修復了錯誤或回歸 | 錯誤修復 PR |
| 變更重組了程式碼但無行為改變 | 重構 PR |
| 僅文件變更 | 文件 PR |
| 使用者要求審查程式碼、PR 或差異（diff） | 程式碼審查 |
如果使用者要求將 PR、事後檢討或討論轉換為不同的成品，請根據請求的成品進行路由，而不是根據來源素材。
複合工作流程預設值
複合工作流程套件是編排器，而非範本。它們會選擇要載入哪些現有的單一成品標準。
- 僅審計的提示會產生建議，而非套件檔案。
- 僅在套件的決策規則無法安全選擇預設值時，才詢問一個套件選擇問題。
- 當在不詢問的情況下選擇了預設值時，請將所選選項和假設記錄在
package-manifest.md中。 - 在同一條訊息中包含可選的補充項目。
- 預設輸出位置為
.github-writing/<套件名稱>/<版本或日期>/下的本地草稿檔案。 - 如果不知道版本或日期，請使用
.github-writing/<套件名稱>/TBD/。 - 每個複合套件都應包含
package-manifest.md，列出產生的檔案、假設、TODO/TBD欄位、可安全寫入的檔案，以及需要維護者確認的檔案。 - 如果無法寫入檔案，請使用
## File: ...標題和圍欄區塊，以多檔案聊天輸出的形式顯示套件。請勿聲稱已寫入檔案。 - 除非使用者明確要求，否則請勿發布、建立 GitHub Release、推送標籤、開啟 PR 或修改遠端狀態。
參考索引
載入 INDEX.md 以取得完整導航。常見參考群組：
| 群組 | 參考資料 |
|---|---|
| Issue | bug-report.md, feature-request.md, enhancement.md, discussion.md |
| Pull Request | 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中。 - 將本地研究和驗證輸出保留在追蹤的執行時期內容之外。