collab-proof

collab-proof skill の概要

collab-proof の用途

collab-proof は、AI 支援のコーディングセッションを、実際に使えるコラボレーションの証跡へ変換するための Claude skill です。何を判断したのか、Claude が何に貢献したのか、なぜ別案を採用しなかったのか、それを裏づける成果物はどれかを整理できます。Claude Code を使っている開発者が、セッションの振り返り、ポートフォリオ用の実績提示、採用・選考向けの根拠、あるいは意味のあるエンジニアリング作業後の継続的な Knowledge Capture を強化したい場合に特に向いています。

collab-proof skill は、単なる汎用サマリーを作るのではなく、段階的なワークフローを使います。セッションに含まれるシグナルの強さを検出し、作業の意図を分類し、協働のフレームを評価したうえで、生成する価値のあるドキュメント成果物を判断します。

向いているユーザーと用途

次のような問いに答えたいときに collab-proof を使います。

• 「ここで Claude は実際に何に貢献したのか？」
• 「どの判断が自分のもので、どれが AI からの提案だったのか？」
• 「過大に見せずに、この作業をポートフォリオで示せるか？」
• 「チャット履歴が消えたら、どの推論が失われるか？」

特に、バグ診断、アーキテクチャ上の判断、機能実装、リファクタリング、設計上のトレードオフ検討の後に役立ちます。一方で、ごく小さな修正、フォーマットだけのコミット、依存関係の更新、推論らしい推論が行われていないセッションにはあまり向きません。

何が違うのか

最大の違いは、貢献の帰属を慎重に調整できる点です。collab-proof は「何が変わったか」を要約するだけではありません。開発者の意図、Claude の提案、採用されたアイデア、却下された代替案、根本原因に関する推論を分けて整理します。ソース資料には、Git notes と SHA-256 ハッシュを使った改ざん検知可能な証跡の作り方も含まれています。特定のコミットと結びつけられるドキュメントが必要な場合、この点は重要です。

Knowledge Capture では、最終的な diff だけでは読み取れない判断、診断、代替案、根拠がセッション内に含まれているほど、collab-proof の価値が高くなります。

collab-proof skill の使い方

collab-proof のインストール前提

リポジトリから 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 フォルダ内に補助スクリプトはありません。そのため、ワンコマンドでレポートを生成するというより、プロンプト上で進めるワークフローとして考えるのが適切です。

skill に渡すべき入力

collab-proof をうまく使うには、曖昧な依頼だけでは不十分です。次の情報があるほど効果的です。

• 現在のリポジトリ状態
• 直近のコミット、または関連する diff
• セッションの目的を短く説明したもの
• 重要な会話の抜粋
• 記録したいバグ、機能、判断
• 出力先が自分用、PR 用、ポートフォリオ用、採用・選考向けの証跡のどれか

上流のワークフローでは、最初に Claude に git log --oneline -10 と git diff --stat HEAD~3..HEAD を実行させるよう求めます。これらのコマンドは、セッションを high、medium、low のどのシグナルに分類するかを判断する助けになります。単一ファイルのバグ修正でも、履歴に根本原因の診断と修正理由が含まれていれば、high signal になり得ます。

効果的なプロンプト例

弱いプロンプトは次のようなものです。

「このプロジェクトに collab-proof を使って。」

より良いプロンプトは次のようになります。

「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.」

このほうがうまく機能するのは、skill に対して作業内容、範囲、想定読者、残すべき判断ポイントを明確に渡しているからです。

おすすめの進め方

推論の記憶が新しいうちに、セッション直後に範囲を絞った振り返りから始めます。最終成果物を書く前に、まず Claude にシグナルレベルを判定させます。high signal のセッションなら、意思決定記録、セッション履歴、作業ログ、持ち運び可能な証跡出力を依頼します。medium signal なら、簡潔な作業ログで十分な場合があります。low signal なら、過剰にドキュメント化しないほうがよいでしょう。

ポートフォリオや採用・選考で使う場合は、控えめな表現を依頼します。優れた証跡は「Claude が X を特定し、私は Y を評価して Z の理由で選択した」と説明します。「AI がプロジェクトを作った」とは書きません。

collab-proof skill の FAQ

collab-proof はポートフォリオ専用ですか？

いいえ。ポートフォリオ用の証跡は主要なユースケースですが、Knowledge Capture のための collab-proof も同じくらい重要です。Git 履歴からは消えてしまう根拠、つまり、なぜバグが起きたのか、なぜ設計を変えたのか、AI が何に気づいたのか、開発者がどこで AI の提案を上書きしたのかを残すのに役立ちます。

通常の要約プロンプトより何が優れていますか？

通常の要約プロンプトは、多くの場合、セッションを「完了したタスク」に圧縮します。collab-proof skill はより構造化されています。証跡の強さを評価し、人間と AI の貢献を区別し、判断の根拠を優先し、すべてのコーディングセッションを同じ重要度として扱わないようにします。そのため、レビュー、振り返り、作業実績の証明により使いやすい出力になります。

初心者でも使えますか？

はい。ただし、最初の実行はシンプルにするのがおすすめです。完全なポートフォリオ用証跡を求める前に、作業ログと貢献の内訳を依頼してください。難しいのはインストールではありません。十分な文脈を渡すことと、AI が何をしたかについて誇張した主張を避けることです。

collab-proof を使わないほうがよい場面は？

意味のある推論がない定型的なコミット、生成されたボイラープレート、見た目だけのクリーンアップ、安全に要約できないプライベートな会話履歴には collab-proof を使わないでください。また、実際のテスト、コードレビュー、コミット管理の代替として使うのも避けるべきです。collab-proof は協働を記録するものであり、正しさを検証するものではありません。

collab-proof skill を改善する方法

collab-proof への入力を改善する

最もよくある失敗は、文脈が薄いことです。結果を改善するには、セッションの目的、会話内の重要な抜粋、影響を受けたファイル、コミット範囲、想定読者を Claude に渡します。採用・選考向けの出力なら、その旨を明記します。社内向けの 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」のような証跡表現を使うよう依頼します。

バグ修正では、原因、診断の過程、修正理由を明示的に記録するよう skill に求めます。このリポジトリの BUG_FIXING ルールでは、よく説明された単一ファイルの修正も価値の高い証跡として扱われます。

最初の出力をもとに反復する

最初に生成された証跡をそのまま受け入れないでください。過大な主張、抜けている代替案、不明確な所有権、検証できない記述がないか確認します。そのうえで、次のように二回目の修正を依頼します。

「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 証跡ファイルをハッシュ化し、そのハッシュを git notes で関連コミットに添付します。これによって内容が自動的に真実になるわけではありませんが、特定のコード状態に対して特定の証跡成果物が存在していたことを示しやすくなります。