Qiaomu GitHub Publisher

將一個工作中的專案轉變為人們可以理解、試用、加星、安裝和信任的 GitHub 倉庫。

X: https://x.com/vista8
GitHub: https://github.com/joeseesun/
設定檔來源: ~/.agents/skills/qiaomu-profile

核心工作流程

在撰寫之前檢查倉庫:
- README.md、package.json / 專案元資料、螢幕截圖、範例、文件、授權條款、部署腳本、測試腳本。
- GitHub 和社群展示面: About 描述、首頁、主題、社群預覽、授權條款、SECURITY.md、CONTRIBUTING.md、CODE_OF_CONDUCT.md、Issue 範本、PR 範本、Release/Changelog（若存在）。
- 透過 gh repo view --json name,description,homepageUrl,repositoryTopics,url,defaultBranchRef,isPrivate,licenseInfo 取得 GitHub 遠端狀態。
決定公開定位:
- 一行鉤子（Hook），中文和英文並陳，中文版本優先。
- 目標用戶以及他們為何現在就該試試看。
- 在產品價值、技術架構和私有/本地設定之間劃分明確界線。
- 預期的發布姿態: 僅展示、用戶可安裝工具、外部貢獻者專案、函式庫/套件或已部署產品。
將 README 重寫或修補為產品頁面:
- README.md 是 GitHub 的門面。對於 Qiaomu 擁有的倉庫，預設必須是中文優先且雙語。
- 先放中文，再放英文。除非用戶明確要求僅用英文，或該倉庫有記錄在案的非 Qiaomu 上游要求，否則都應這樣做。
- 允許有獨立的 README.zh-CN.md，但它本身不能滿足此要求；預設的 README.md 必須先顯示中文。
- 英文可以是一個由 # English 錨定的完整下部區塊、一個連結的 README.en.md，或一個精簡的鏡像區塊，但安裝/試用、驗證、限制以及授權條款/存取期望必須讓英文讀者能夠理解。
- 建立一個易於掃描的組合: 語言切換、真實的英雄媒體、簡短的故事鉤子、證明條、精簡的徽章、“什麼/為什麼”、功能矩陣、最快的快速入門、可展開的手動設定、使用方式、產品巡遊、相容性/生態系統目錄、工作流程/架構、驗證、限制和信任連結。
- 當有真實截圖或輸出樣本時，請使用它們；不要憑空發明截圖。
設定 GitHub About:
- 對於 Qiaomu 擁有的公開倉庫，預設使用精簡的雙語描述，中文在前，英文在後。
- 當有即時展示時，加入首頁 URL。
- 加入有針對性的主題；避免主題濫發。
- 為了公開發布時的完善度，建立或要求一張社群預覽圖片。如果無法自動化，請將手動的 GitHub 設定步驟記錄為後續待辦事項，而不是假裝它已被設定。
根據發布姿態改善信任表面:
- 對於開源倉庫，始終驗證授權條款狀態。
- 對於外部貢獻者專案，在缺少或過期時，新增或更新 CONTRIBUTING.md、CODE_OF_CONDUCT.md、SECURITY.md、Issue 範本和 PR 範本。
- 對於僅展示的倉庫，解釋為何刻意省略了貢獻/社群檔案。
驗證 README 承諾的內容:
- 在相關時執行專案提供的 lint/build/test 命令。
- 對於技能（Skill），驗證 npx skills add 的可發現性/可安裝性。
- 對於網站，在部署後驗證即時 URL/API/健康狀態。
透過乾淨的 GitHub 流程發布:
- 使用特性分支和 PR。
- 絕不直接推送到 main。
- 如果驗證通過且用戶未明確要求保留，請將 PR 合併到 main。
- 在最終回應中，包含 PR URL 和合併提交。

來源支持的展示模型

此技能的基礎是 GitHub 自身的倉庫展示面：

README：GitHub 表示倉庫的 README 應說明專案的用途、為何有用、用戶如何開始、從哪裡獲得協助，以及誰在維護它。GitHub 會自動向訪客展示一個可識別的 README。
主題：GitHub 主題幫助人們根據目的、主題領域、社群、語言或其他重要特質來發現倉庫。
授權條款：GitHub 的授權條款指南指出，公開倉庫需要一個開源授權條款，其他人才能清楚地自由使用、修改和散佈它。
社群資料：GitHub 的公開倉庫清單會檢查 README、授權條款、行為準則、貢獻指南、安全政策和 Issue/PR 範本。
安全政策：SECURITY.md 告訴人們如何回報漏洞。
Issue 和 PR 範本：範本標準化了貢獻者在開啟 Issue 或 Pull Request 時所提供的資訊。
社群預覽：GitHub 允許倉庫維護者從倉庫設定中設定社群預覽圖片；當透明度可能導致渲染結果不可預測時，請使用純色背景。

當此指南與部落格檢查清單衝突時，優先使用官方文件。

可供學習（非盲目複製）的參考案例：santifer/career-ops 將其 README 呈現為一個精簡的啟動頁面。它以語言選擇、真實的英雄圖片、三行起源故事、來外部的證明、展示、量化成果、精簡的徽章開頭，然後進入「它是什麼」、「功能」、「快速入門」、「使用方式」、「工作流程」、「結構」、「技術堆疊」、「免責聲明」和「聯絡方式」。當它適合 Qiaomu 倉庫時，請重用該排序邏輯，但絕不發明新聞稿、社群、下載量、星數、用戶成功案例或使用聲明。

複雜產品的參考案例：nexu-io/open-design 將其 README 視為大型生態系統的產品地圖。它使用發布/呼籲行動通知、強大的產品巡遊區塊、分組的展示畫廊、平台相容性表格、多路徑快速入門、代理/MCP 使用方式、技能/設計系統/插件目錄、架構與安全說明、路線圖、社群/貢獻表格、維護者、倉庫活動和來源/傳承。將此作為 Qiaomu 倉庫（具有多個展示面）的模組化檢查清單，但絕不複製規模數字、支援矩陣、付費服務聲明、社群聲明、安全性保證或第三方傳承，除非已在當前倉庫中驗證。

README 標準

語言閘門

對於 Qiaomu 擁有的公開倉庫，README.md 在發布前必須是中文優先的雙語版本：

首屏：專案名稱、中文價值主張、英文價值主張、徽章/連結，以及一個可見的語言切換器，例如 **中文** | [English](#english)。
主體：首先是中文區塊，作為預設的讀者體驗。
英文存取：提供一個實質的英文區塊或連結的英文 README。至少，英文讀者必須理解它的用途、如何試用/安裝、已驗證了什麼，以及主要的限制/前提條件。
諸如 README.zh-CN.md 和 README.en.md 的翻譯檔案可能存在，但 GitHub 預設的 README.md 仍然必須以中文優先開啟，除非用戶明確批准了不同的受眾。
如果 README.md 是僅英文、英文優先，或依賴一個單獨的中文檔案來提供中文體驗，請停止並在開啟/合併發布 PR 之前修復它。

首屏閘門

README.md 的頂部應能通過 60 秒陌生人測試：

這是什麼，用一句具體的話說明？
它為誰解決什麼痛苦？
我可以立即點擊、安裝或試用什麼？
我能看到什麼證明：截圖、展示、樣本輸出、CI 徽章或驗證過的命令？
我應該信任什麼：授權條款、維護者、安全/隱私邊界，以及最後驗證的狀態？

避免徽章牆、抽象標語和以架構為開頭的方式。架構應在用戶理解產品價值之後才出現。

公開的 README 必須快速回答五個問題：

這個解決了什麼痛苦？
安裝/執行後我能得到什麼？
我能在截圖、展示或範例輸出中看到證明嗎？
我如何在五分鐘內試用它？
限制、成本或前提條件是什麼？

組成閘門

使用一個既可作為產品頁面又可作為技術文件的 README 佈局：

以成果和證明開頭，然後才是內部結構：專案名稱、語言切換器、真實的產品媒體、一兩行具體的價值主張、主要動作連結，以及一行可信的證明。
使證明具體且可驗證：即時展示、安裝命令、套件/發布徽章、CI 結果、截圖、樣本輸出、基準測試、案例研究、用戶成果、新聞報導或星標圖表。如果未經驗證或未獲得，則省略。
當有 4 個以上功能時，使用功能表格。每一行應將命名的功能映射到用戶可見的結果，而不僅僅是列出模組。
將最快的成功路徑放在手動設定之前。先使用一個命令或最短的驗證路徑，然後將較長的手動設定藏在 <details> 中，以免淹沒頁面。
在快速入門之後，加入使用命令、工作流程/運作方式、專案結構和技術堆疊。這些區塊應幫助認真的用戶檢查系統，而不延遲他們的首次嘗試。
將隱私、資料所有權、成本、第三方條款、“非託管服務”和“不能做 X”的邊界放在一個可見的限制/免責聲明區塊中（當相關時）。
保持視覺資產有目的性。英雄圖片、展示 GIF、標誌、徽章和圖表應用於證明產品或狀態；它們不應成為裝飾或借用權威。

複雜產品目錄閘門

當倉庫不僅僅是一個單一的應用程式/函式庫時使用此閘門：多平台應用程式、代理生態系統、插件/範本目錄、設計系統、媒體管道、MCP 伺服器、自架堆疊，或具有大量社群/貢獻表面的專案。

在深入的內部結構之前加入產品巡遊。按用戶表面或工件類型對截圖/展示進行分組，並為每個項目提供一行結果：入口應用程式、工作室/編輯器、儀表板、插件市場、產生的輸出、API、CLI、MCP、行動/桌面檢視等。
當產品跨平台、代理、提供者、作業系統、部署模式或套件管理器執行時，加入相容性矩陣。欄位應具體：目標、狀態、安裝命令、驗證命令和已知限制。
為技能、插件、範本、設計系統、提供者、範例或整合加入生態系統目錄。僅在從倉庫產生或最新驗證時使用計數；否則，請說“許多”或連結到該目錄。好的欄位：項目、類別/模式、受眾、輸出、來源路徑。
按角色/路徑提供快速入門：桌面或託管應用程式、僅 CLI/代理、Docker/自架、從原始碼開發者路徑。將推薦的路徑放在前面，並為每個路徑提供成功檢查。
當倉庫有守護進程、MCP 伺服器、代理、本地資料庫、憑證、產生的工件或網路邊界時，將架構和安全放在一起討論。傾向於使用精簡的圖表/表格，連結到權威的深度文件，並避免重複易於漂移的儲存或機密處理細節。
當倉庫邀請外部工作或捆綁第三方資產時，包含路線圖、社群、貢獻、維護者和來源區塊。來源應指明上游專案、授權條款邊界以及進行了哪些改寫或捆綁。
控制目錄密度：使用表格進行掃描，使用 <details> 處理長清單，使用深度文件處理詳盡清單。README 應為新手指明方向，而不應成為完整手冊。

建議結構：

# 專案名稱

**中文** | [English](#english)

![產品截圖或英雄圖](docs/assets/product-screenshot.png)

> 中文價值主張
> English value proposition

[即時展示] [安裝] [文件] [授權條款] [CI]

**已驗證:** `npm test` / `npx skills add ...` / 健康狀態檢查 / 樣本輸出

## 這是什麼
## 為什麼值得用
## 核心能力

| 能力 | 用戶得到什麼 |
|---|---|
| ... | ... |

## 樣本輸出
## 快速開始

### 最快路徑

```bash
...

...

使用方式

產品巡遊 / Demo

平台相容 / 生態目錄

工作流程 / 原理

架構與安全模型

專案結構

部署 / API / Skill

路線圖 / 社群 / 貢獻

來源譜系 / License 邊界

實測驗證

限制、隱私與邊界

Troubleshooting

關於向陽喬木

English section


### 證明與媒體

- 在頂部附近優先使用一張真實的螢幕截圖、展示 GIF、終端機記錄、API 回應、產生的工件或託管展示。
- 每張螢幕截圖或樣本都必須與當前的驗證狀態相符。除非明確標示為設計模型，否則請勿使用模擬圖片。
- 量化的聲明應是當前的且有來源：範例包括已處理項目的數量、已產生的工件、已安裝的版本、相容性目標、目錄計數、基準測試結果或已發布的案例研究。如果倉庫無法從程式碼、產生的元資料、測試、發布工件或文件中證明某個數字，請改用驗證過的命令/輸出。
- 對於 CLI/工具，包含一個簡短的命令執行成功記錄和一個失敗/疑難排解範例。
- 對於網站/應用程式，在可行時包含即時 URL、部署目標、健康/API 檢查以及桌面/行動裝置的螢幕截圖。
- 保持 README 大小舒適地低於 GitHub 的 500 KiB 渲染截斷限制；如果文件變得很大，將更深入的資料拆分到 `docs/` 中並連結它們。

## GitHub 展示面標準

### GitHub About 標準

對於 Qiaomu 擁有的公開倉庫，預設使用精簡的雙語形式：

```text
中文短描述 | English short description.

保持具體。好的範例：

把 App Store 評價變成產品研究證據，發現痛點、機會和版本風險 | Turn App Store reviews into product research evidence: pain points, opportunities, and version risks.
把任意資料整理成 NotebookLM 可用知識包 | Turn messy sources into NotebookLM-ready knowledge packs.

主題應具有針對性且有用：

領域：app-store, app-reviews, notebooklm, geo
技術堆疊：nextjs, agent-skill, deepseek
受眾/工作流程：product-management, ai-workflow

避免使用像 tool, website, ai 這樣的一般性主題，除非它們能增加可發現性。

首頁、徽章與社群預覽

將首頁設定為即時展示、文件、安裝頁面或產品主頁。如果不存在，則留空，而不是指向不相關的頁面。
使用一個小型的徽章行：CI/建置、授權條款、套件

joeseesun/qiaomu-github-publisher

qiaomu-github-publisher 是什麼？

在你喜歡的 AI 中提問

預覽

說明文件