collab-proof

collab-proof skill 概覽

collab-proof 的用途

collab-proof 是一個 Claude skill，用來把 AI 輔助的 coding session 轉成可用的協作證據：你做了哪些決策、Claude 貢獻了什麼、為什麼排除其他方案，以及哪些產出可以作為證明。它特別適合使用 Claude Code 的開發者，在完成有意義的工程工作後，需要更好的 session 回顧、作品集佐證、求職證明，或可長期保存的 Knowledge Capture。

collab-proof skill 不會只產出一般摘要，而是採用分層工作流程：先判斷 session 訊號強度、分類工作意圖、評估協作脈絡，再決定哪些文件證據值得生成。

最適合的使用者與情境

當你需要回答這類問題時，可以使用 collab-proof：

• 「Claude 在這裡實際貢獻了什麼？」
• 「哪些決策是我做的，哪些是 AI 建議的？」
• 「我能不能把這段工作放進作品集，而不誇大貢獻？」
• 「如果聊天紀錄消失了，哪些推理過程會跟著遺失？」

它特別適合用在 bug 診斷、架構選擇、功能實作、重構，以及設計取捨討論之後。相對地，如果只是很小的修改、純格式調整的 commit、升級 dependency，或整段 session 幾乎沒有推理過程，這個 skill 的效益就比較低。

collab-proof 的差異化重點

collab-proof 最大的差異在於校準過的歸因。它不只是摘要「改了什麼」，而是把開發者意圖、Claude 的建議、被採納的想法、被排除的替代方案，以及根因推理拆開來看。來源資料也包含使用 Git notes 與 SHA-256 hashes 建立防竄改證據的指引；如果你希望文件能夠連結到特定 commit，這一點就很重要。

在 Knowledge Capture 方面，當 session 裡包含決策、診斷、替代方案或理由，而這些內容無法從最終 diff 直接看出來時，collab-proof 的價值最高。

如何使用 collab-proof skill

collab-proof 安裝脈絡

從 repository 安裝這個 skill：

npx skills add alirezarezvani/claude-skills --skill collab-proof

skill 位於：

engineering/collab-proof/skills/collab-proof

安裝後，先檢查 SKILL.md，再閱讀說明證據模型的參考文件：

• references/ai-collaboration-evidence.md
• references/developer-portfolio-proof.md
• references/session-documentation-patterns.md
• references/tamper-evident-proof.md

skill 資料夾裡沒有 helper scripts，所以這是一個以 prompt 為核心的工作流程，而不是一行指令就能產生報告的工具。

collab-proof 需要的輸入

要讓 collab-proof 發揮效果，不要只給模糊請求。它最適合搭配以下資訊：

• 目前的 repository 狀態
• 最近的 commits 或相關 diff
• session 目標的簡短說明
• 任何重要的對話片段
• 要記錄的 bug、功能或決策
• 輸出用途是給自己、PR、作品集，還是求職證明

上游工作流程會要求 Claude 先執行 git log --oneline -10 和 git diff --stat HEAD~3..HEAD。這些指令有助於把 session 分類為高、中、低訊號。即使只是單一檔案的 bug fix，只要 transcript 包含根因診斷與修正理由，也仍然可能是高訊號。

有效的 prompt 寫法

較弱的 prompt 是：

「Use collab-proof on this project.」

較好的 prompt 是：

「Use collab-proof for the last session. The goal was to fix the login redirect bug. Please inspect recent commits and diff stats, classify the collaboration signal, identify root cause reasoning, separate my decisions from Claude’s suggestions, and produce portfolio-safe evidence. Emphasize why the chosen fix was better than the rejected middleware approach.」

這樣效果更好，因為它同時提供了任務、範圍、輸出讀者，以及需要保留下來的決策點。

建議的 collab-proof 工作流程

在 session 結束後、推理記憶還新鮮時，先做一個範圍明確的回顧。請 Claude 在撰寫最終文件前先判斷訊號等級。如果 session 是高訊號，可以要求 decision records、session history、worklog，以及可攜式的 proof output。如果是中訊號，一份精簡的 worklog 可能就足夠。如果是低訊號，就避免過度文件化。

如果要用在作品集或求職，請要求採用保守措辭。好的證據應該寫成「Claude identified X; I evaluated and chose Y because Z」，而不是「AI built the project」。

collab-proof skill 常見問題

collab-proof 只適合用在作品集嗎？

不是。作品集佐證是主要使用情境之一，但用 collab-proof 做 Knowledge Capture 同樣重要。它能保留 Git history 裡會消失的理由：bug 為什麼發生、設計為什麼改變、AI 注意到什麼，以及開發者在哪些地方推翻了 AI 的建議。

它比一般摘要 prompt 好在哪裡？

一般摘要 prompt 通常會把 session 壓縮成已完成的任務清單。collab-proof skill 的結構更完整：它會評估證據強度、區分人類與 AI 的貢獻、優先保留決策理由，並避免把每個 coding session 都視為同樣重要。這讓輸出更適合用於 review、回顧，以及工作成果證明。

初學者可以使用這個 skill 嗎？

可以，但初次使用時建議保持簡單。先要求 worklog 和 contribution breakdown，再進一步要求完整的作品集證據。真正困難的地方不是安裝，而是提供足夠脈絡，以及避免誇大 AI 做了什麼。

什麼時候不該使用 collab-proof？

不要把 collab-proof 用在沒有明確推理價值的例行 commit、產生式 boilerplate、外觀清理，或你無法安全摘要的私人 transcript。也不要把它當成真正測試、code review 或良好 commit hygiene 的替代品。它記錄的是協作過程；它不驗證程式是否正確。

如何改進 collab-proof skill 的使用效果

改善 collab-proof 的輸入

最常見的失敗模式是脈絡太薄。要改善結果，請提供 Claude session 目標、對話中的重要片段、受影響檔案、commit 範圍，以及預期讀者。如果輸出是為了求職，請明講。如果是內部 Knowledge Capture，請要求更多技術細節、少一點行銷式包裝。

實用的輸入格式：

• Goal: what you were trying to accomplish
• Change set: commits, files, or diff range
• Reasoning: alternatives considered and rejected
• Attribution: what you proposed, what Claude proposed, what changed
• Audience: private notes, PR, README, recruiter, portfolio

調整歸因與證據品質

針對每個重要決策，請要求校準過的歸因。好的 collab-proof 輸出應避免兩個極端：假裝所有事情都是開發者完成的，或聲稱 Claude 獨立建構了解法。可以要求使用這類證據措辭：「Claude suggested」、「developer selected」、「developer rejected」、「jointly refined」和「root cause identified from」。

如果是 bug fix，請明確要求 skill 捕捉成因、診斷路徑與修正理由。repository 的 BUG_FIXING 規則會把解釋清楚的單檔修正視為高價值證據。

第一次輸出後繼續迭代

不要盲目接受第一次生成的 proof。請檢查是否有誇大、遺漏替代方案、所有權不清楚，或無法驗證的說法。接著要求第二輪修訂：

「Revise this collab-proof output to be more conservative. Remove claims not supported by the diff or transcript. Add a short ‘developer-owned decisions’ section and a ‘Claude-assisted insights’ section.」

通常這會比一開始就要求精修成品，更能產生可信的文件。

需要時加入防竄改證據

如果證據可能對外分享，可以考慮 references/tamper-evident-proof.md 裡描述的 Git notes 工作流程。概念是對生成的 HTML proof file 做 hash，並用 git notes 把 hash 附加到相關 commit。這不會讓內容自動變成真實，但有助於證明某個特定 proof artifact 曾經存在於某個特定 code state。