opensource-pipeline

opensource-pipeline

熱門

開源管道:複製、清理並封裝私有專案,以安全地公開釋出。串聯 3 個代理(複製器、清理器、封裝器)。觸發詞:'/opensource'、'open source this'、'make this public'、'prepare for open source'。

23萬星標
3.5萬分支
更新於 2026/7/21
SKILL.md
readonlyread-only
name
opensource-pipeline
description

開源管道:複製、清理並封裝私有專案,以安全地公開釋出。串聯 3 個代理(複製器、清理器、封裝器)。觸發詞:'/opensource'、'open source this'、'make this public'、'prepare for open source'。

開源管道技能

透過 3 階段管道安全地將任何專案開源:複製(移除機密)→ 清理(驗證乾淨)→ 封裝CLAUDE.md + setup.sh + README)。

何時啟用

  • 使用者說「將此專案開源」或「讓它公開」
  • 使用者想要準備一個私有儲存庫以供公開釋出
  • 使用者需要在推送至 GitHub 前移除機密
  • 使用者呼叫 /opensource fork/opensource verify/opensource package

指令

指令 動作
/opensource fork PROJECT 完整管道:複製 + 清理 + 封裝
/opensource verify PROJECT 對現有儲存庫執行清理器
/opensource package PROJECT 產生 CLAUDE.md + setup.sh + README
/opensource list 顯示所有暫存中的專案
/opensource status PROJECT 顯示暫存專案的報告

協定

/opensource fork PROJECT

完整管道 — 主要工作流程。

步驟 1:收集參數

解析專案路徑。如果 PROJECT 包含 /,則視為路徑(絕對或相對)。否則檢查:目前工作目錄、$HOME/PROJECT,然後詢問使用者。

SOURCE_PATH="<解析後的絕對路徑>"
STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}"

詢問使用者:

  1. 「哪個專案?」(如果找不到)
  2. 「授權條款?(MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)」
  3. 「GitHub 組織或使用者名稱?」(預設:透過 gh api user -q .login 偵測)
  4. 「GitHub 儲存庫名稱?」(預設:專案名稱)
  5. 「README 的描述?」(分析專案以提供建議)
步驟 2:建立暫存目錄
mkdir -p $HOME/opensource-staging/
步驟 3:執行複製器代理

啟動 opensource-forker 代理:

Agent(
  description="複製 {PROJECT} 以開源",
  subagent_type="opensource-forker",
  prompt="""
複製專案以開源釋出。

來源:{SOURCE_PATH}
目標:{STAGING_PATH}
授權條款:{chosen_license}

遵循完整的複製協定:
1. 複製檔案(排除 .git、node_modules、__pycache__、.venv)
2. 移除所有機密與憑證
3. 將內部參考替換為佔位符
4. 產生 .env.example
5. 清理 git 歷史
6. 在 {STAGING_PATH}/FORK_REPORT.md 產生 FORK_REPORT.md
"""
)

等待完成。讀取 {STAGING_PATH}/FORK_REPORT.md

步驟 4:執行清理器代理

啟動 opensource-sanitizer 代理:

Agent(
  description="驗證 {PROJECT} 的清理結果",
  subagent_type="opensource-sanitizer",
  prompt="""
驗證開源複製的清理結果。

專案:{STAGING_PATH}
來源(供參考):{SOURCE_PATH}

執行所有掃描類別:
1. 機密掃描(嚴重)
2. PII 掃描(嚴重)
3. 內部參考掃描(嚴重)
4. 危險檔案檢查(嚴重)
5. 設定完整性(警告)
6. Git 歷史稽核

在 {STAGING_PATH}/ 內產生 SANITIZATION_REPORT.md,包含 PASS/FAIL 判定。
"""
)

等待完成。讀取 {STAGING_PATH}/SANITIZATION_REPORT.md

如果 FAIL: 向使用者顯示發現。詢問:「修復這些問題並重新掃描,或中止?」

  • 如果修復:套用修復,重新執行清理器(最多重試 3 次 — 3 次 FAIL 後,呈現所有發現並要求使用者手動修復)
  • 如果中止:清理暫存目錄

如果 PASS 或 PASS WITH WARNINGS: 繼續步驟 5。

步驟 5:執行封裝器代理

啟動 opensource-packager 代理:

Agent(
  description="封裝 {PROJECT} 以開源",
  subagent_type="opensource-packager",
  prompt="""
為專案產生開源封裝。

專案:{STAGING_PATH}
授權條款:{chosen_license}
專案名稱:{PROJECT_NAME}
描述:{description}
GitHub 儲存庫:{github_repo}

產生:
1. CLAUDE.md(指令、架構、關鍵檔案)
2. setup.sh(單指令啟動,設為可執行)
3. README.md(或增強現有檔案)
4. LICENSE
5. CONTRIBUTING.md
6. .github/ISSUE_TEMPLATE/(bug_report.md、feature_request.md)
"""
)
步驟 6:最終審查

向使用者呈現:

開源複製就緒:{PROJECT_NAME}

位置:{STAGING_PATH}
授權條款:{license}
產生的檔案:
  - CLAUDE.md
  - setup.sh(可執行)
  - README.md
  - LICENSE
  - CONTRIBUTING.md
  - .env.example({N} 個變數)

清理結果:{sanitization_verdict}

後續步驟:
  1. 審查:cd {STAGING_PATH}
  2. 建立儲存庫:gh repo create {github_org}/{github_repo} --public
  3. 推送:git remote add origin ... && git push -u origin main

是否繼續建立 GitHub 儲存庫?(是/否/先審查)
步驟 7:GitHub 發布(使用者核准後)
cd "{STAGING_PATH}"
gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"

/opensource verify PROJECT

獨立執行清理器。解析路徑:如果 PROJECT 包含 /,則視為路徑。否則檢查 $HOME/opensource-staging/PROJECT,然後 $HOME/PROJECT,然後目前目錄。

Agent(
  subagent_type="opensource-sanitizer",
  prompt="驗證清理結果:{resolved_path}。執行所有 6 個掃描類別並產生 SANITIZATION_REPORT.md。"
)

/opensource package PROJECT

獨立執行封裝器。詢問「授權條款?」和「描述?」,然後:

Agent(
  subagent_type="opensource-packager",
  prompt="封裝:{resolved_path} ..."
)

/opensource list

ls -d $HOME/opensource-staging/*/

顯示每個專案及其管道進度(FORK_REPORT.md、SANITIZATION_REPORT.md、CLAUDE.md 是否存在)。


/opensource status PROJECT

cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md

暫存目錄結構

$HOME/opensource-staging/
  my-project/
    FORK_REPORT.md           # 來自複製器代理
    SANITIZATION_REPORT.md   # 來自清理器代理
    CLAUDE.md                # 來自封裝器代理
    setup.sh                 # 來自封裝器代理
    README.md                # 來自封裝器代理
    .env.example             # 來自複製器代理
    ...                      # 清理後的專案檔案

反模式

  • 絕不在未經使用者核准的情況下推送至 GitHub
  • 絕不跳過清理器 — 它是安全閘門
  • 絕不在清理器 FAIL 後未修復所有嚴重發現就繼續
  • 絕不在暫存目錄中留下 .env*.pemcredentials.json

最佳實踐

  • 對於新釋出,始終執行完整管道(複製 → 清理 → 封裝)
  • 暫存目錄會保留直到明確清理 — 可用於審查
  • 在發布前,任何手動修復後都應重新執行清理器
  • 將機密參數化而非刪除 — 保留專案功能

相關技能

請參閱 security-review 以了解清理器使用的機密偵測模式。