Communitygithub.com

AkiGarage/readme-release-sync

Codex 技能,用於保持 README 與發行版文件與實際產品行為一致。

readme-release-sync 是什麼?

此技能旨在減少維護者的審查負擔,確保產品文件(包括 README、發行說明、變更日誌、產品螢幕截圖/GIF 以及雙語文件)在提交審查前就已與真實產品狀態完全對齊。它適用於任何涉及文件修改、產品改版或公開發行的場景,支援 Git、GitHub PR 流程以及中文(繁體)與英文雙語文件環境。核心工作流程要求 AI 代理首先從應用程式程式碼、UI 字串、使用者提供的螢幕截圖等來源識別當前的事實來源,然後根據事實來源更新文件與媒體檔案。此外,技能也規範了掃描過時產品名稱、版本號、UI 標籤的具體步驟,並要求在關閉前進行完整的驗證檢查,包括執行 lint 命令、使用 rg 掃描過時用語、確認 GitHub 渲染後的 README 視覺外觀獲得批准,以及檢查測試與建置狀態。輸出時必須提供一份包含所有檢查項目的摘要報告。

相容平台~Claude Code✓Codex CLI✓Cursor
npx skills add AkiGarage/readme-release-sync

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

README 與發行版同步

每當任務涉及 README 文案、發行說明、變更日誌、產品螢幕截圖/GIF,或雙語產品文件時,請使用此技能。

目標是減少維護者的審查負擔:文件應在審查人員發現過時的名稱、螢幕截圖、功能描述或英文/日文不匹配之前,就已與真實產品狀態一致。

核心規則

不要僅根據現有文件來編輯產品面向的文件。應首先識別當前的事實來源:應用程式程式碼、UI 字串、螢幕截圖/GIF、發行分支、版本檔案、套件中繼資料,或使用者提供的最新螢幕截圖/影片。

工作流程

  1. 確認目標狀態

    • 根據儲存庫檔案或使用者的明確指示,確認產品/應用程式名稱、分支、版本、二進位檔名稱以及平台範圍。
    • 檢查所描述功能的相關實作程式碼或 UI 字串。
    • 除非程式碼或分支上下文明顯矛盾,否則應將使用者提供的最新螢幕截圖/影片視為權威視覺證據。
  2. 同時更新文件與媒體

    • 當 UI 改變時,替換過時的螢幕截圖/GIF。
    • 驗證每個圖片參考都存在並指向預期的檔案。
    • 檢查螢幕截圖未明顯與當前的產品名稱、選單標籤、版本或 UI 狀態矛盾。
    • 當描述已移除的行為時,刪除舊的媒體參考。
    • 對於由私有儲存庫提供內容的公開發行版,在將經過清理的快照複製到公開儲存庫後,在 release/vX.Y.Z 分支上更新公開 README 檔案。不要將私有 README 視為最終的公開事實來源。
    • 將公開的 CHANGELOG、發行草案說明、安裝文件以及公開開發日誌視為同一組面向發行版的文件。它們應使用與 README 相同的產品名稱、版本、資產名稱、隱私聲明和麵向使用者的用語。
  3. 確保雙語文件等效

    • 逐項比較英文和日文(或繁體中文)的章節聲明。
    • 在兩種語言中保留相同的產品事實、功能順序、注意事項和設定要求。
    • 不要將重要的行為僅在其中一種語言中進行說明。
  4. 編寫可讀的公開 README 文案

    • 讓初次閱讀的章節易於掃讀:使用簡短段落,每段一個想法,並在能提高可讀性的地方使用空行。
    • 開頭說明產品的作用以及使用者可以看到或執行什麼。實作細節應放在後面,僅在與設定、安全性或疑難排解相關時才提及。
    • 優先使用清晰的行為說明而非密集的功能句子。一個良好的結構是先以一句話概述,接著是 2-4 條簡潔的功能說明。
    • 對於 UI 行為,描述可見的結果:拖曳以移動、從邊緣或角落調整大小、雙擊以重設。除非使用者需要,否則應避免提及內部框架細節,例如感應區塊(hit bands)、游標矩形(cursor rects)、縮放內部邏輯或確切的預設百分比。
    • 將詳細資訊保留在真正有用之處,但不要讓公開 README 承載僅供維護者使用的實作說明。
    • 將相同的可讀性規則應用於發行說明和變更日誌條目:避免使用內部精確用語,例如確切的預設百分比、感應區塊用語、游標矩形機制或建置系統細節,除非它們影響使用者可見的修復、安裝步驟或疑難排解路徑。
  5. 使日語(或當地語言)讀者友好

    • 在自然的情況下,優先使用一般的當地語言 UI 用語:例如 タブ、詳細パネル、マウスオーバー、最小表示、フローティングタブ。
    • 保持指令、路徑、套件名稱、應用程式名稱、URL 和程式碼識別碼等技術性文字為英文。
    • 移除冗餘的功能清單和重複段落;讓主要功能集對一般讀者來說易於快速掃讀。
  6. 掃描過時的產品差異

    • 過時的產品名稱、舊的應用程式名稱、舊的二進位檔名稱和舊的儲存庫名稱。
    • 歷史變更日誌條目之外的過時版本號碼。
    • 過時的 UI 標籤、已移除的平台說明以及來自舊行為的螢幕截圖。
    • 暗示某個相依性必須正在執行中的聲明,而實際只需安裝了 CLI 或套件即可。
  7. 關閉前進行驗證

    • 在可用時執行相關的文件 lint/檢查指令。
    • 執行範圍受限的 rg 掃描,檢查過時的名稱/版本/標籤。
    • 對 README 檔案、變更日誌、發行說明以及發行版中包含的任何公開文件執行過時/私有/過於內部的用語掃描,而不僅僅是頂層的 README。
    • 檢查 README 中的圖片連結是否存在。
    • 對於發行版 PR,提供維護者該分支/PR 的 GitHub 渲染 README URL,並等待明確的視覺批准。這必須與使用者實際看到的 GitHub 顯示一致;本地預覽、原始 Markdown、靜態螢幕截圖或自動化檢查僅作為輔助證據。
    • 檢查公開儲存庫的 git diff,以確保 README 聲明、版本中繼資料、發行資產名稱以及複製的實作變更一致。
    • 對於公開發行版,優先使用 release/vX.Y.Z 分支 -> PR -> CI -> 合併,然後再建立標籤或 GitHub Release。僅當維護者明確要求略過 PR 關卡時,才應直接推送到 main。
    • 如果程式碼已更改,請執行相關的測試或建置。
    • 總結事實來源的檢查結果,而不僅僅是編輯過的檔案。

輸出檢查清單

完成前,請報告:

  • 已檢查的產品名稱/版本/分支;
  • 已檢查的媒體參考;
  • 已檢查的當地語言/英文一致性;
  • 已收到 GitHub 渲染 README 的視覺批准,或明確仍待處理;
  • 過時用語掃描結果;
  • 已執行的測試/建置/文件檢查,或未執行的原因。

相關技能