collab-proof

Overview of collab-proof skill

What collab-proof is for

collab-proof is a Claude skill for turning an AI-assisted coding session into usable collaboration evidence: what you decided, what Claude contributed, why alternatives were rejected, and which artifacts prove it. It is best for developers using Claude Code who want better session retrospectives, portfolio proof, hiring evidence, or durable Knowledge Capture after meaningful engineering work.

Instead of producing a generic summary, the collab-proof skill applies a layered workflow: detect the strength of the session signal, classify work intent, score the collaboration frame, then decide which documentation artifacts are worth generating.

Best-fit users and jobs

Use collab-proof when you need to answer questions like:

• “What did Claude actually contribute here?”
• “Which decisions were mine versus AI-suggested?”
• “Can I show this work in a portfolio without overclaiming?”
• “What reasoning would be lost if the chat transcript disappeared?”

It is especially useful after bug diagnosis, architecture choices, feature implementation, refactors, and design tradeoff discussions. The skill is less useful for tiny edits, formatting-only commits, dependency bumps, or sessions where no reasoning happened.

What makes it different

The main differentiator is calibrated attribution. collab-proof does not just summarize “what changed”; it separates developer intent, Claude suggestions, accepted ideas, rejected alternatives, and root-cause reasoning. The source material also includes guidance for tamper-evident proof using Git notes and SHA-256 hashes, which matters if you want documentation that can be tied to a specific commit.

For Knowledge Capture, collab-proof is strongest when the session contains decisions, diagnosis, alternatives, or rationale that would not be obvious from the final diff.

How to Use collab-proof skill

collab-proof install context

Install the skill from the repository with:

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

The skill lives at:

engineering/collab-proof/skills/collab-proof

After install, inspect SKILL.md first, then read the reference files that explain the evidence model:

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

There are no helper scripts in the skill folder, so expect a prompt-native workflow rather than a one-command report generator.

Inputs the skill needs

For good collab-proof usage, provide more than a vague request. The skill works best with:

• The current repository state
• Recent commits or the relevant diff
• A short description of the session goal
• Any important conversation excerpts
• The bug, feature, or decision being documented
• Whether the output is for yourself, a PR, a portfolio, or hiring proof

The upstream workflow asks Claude to run git log --oneline -10 and git diff --stat HEAD~3..HEAD first. Those commands help classify the session as high, medium, or low signal. A single-file bug fix can still be high signal if the transcript includes root cause diagnosis and fix rationale.

Strong prompt pattern

A weak prompt is:

“Use collab-proof on this project.”

A stronger prompt is:

“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.”

This works better because it gives the skill a job, a scope, an output audience, and the decision points to preserve.

Suggested workflow

Start with a narrow retrospective immediately after the session while the reasoning is still fresh. Ask Claude to identify signal level before writing final artifacts. If the session is high signal, request decision records, session history, a worklog, and portable proof output. If it is medium signal, a concise worklog may be enough. If it is low signal, avoid over-documenting.

For portfolio or hiring use, ask for conservative wording. The best evidence says “Claude identified X; I evaluated and chose Y because Z,” not “AI built the project.”

collab-proof skill FAQ

Is collab-proof only for portfolios?

No. Portfolio proof is a major use case, but collab-proof for Knowledge Capture is just as important. It helps preserve rationale that disappears from Git history: why a bug happened, why a design changed, what the AI noticed, and where the developer overrode the AI.

How is it better than an ordinary summary prompt?

A normal summary prompt usually compresses the session into tasks completed. The collab-proof skill is more structured: it scores evidence strength, distinguishes human and AI contributions, prioritizes decision rationale, and avoids treating every coding session as equally important. That makes the output more useful for reviews, retrospectives, and proof of work.

Can beginners use this skill?

Yes, but beginners should keep the first run simple. Ask for a worklog and contribution breakdown before requesting full portfolio evidence. The harder parts are not installation; they are providing enough context and avoiding inflated claims about what the AI did.

When should I not use collab-proof?

Do not use collab-proof for routine commits with no meaningful reasoning, generated boilerplate, cosmetic cleanup, or private transcripts you cannot safely summarize. Also avoid using it as a substitute for real tests, code review, or commit hygiene. It documents collaboration; it does not validate correctness.

How to Improve collab-proof skill

Improve collab-proof inputs

The most common failure mode is thin context. Improve results by giving Claude the session goal, important snippets from the conversation, affected files, commit range, and the intended reader. If the output is for hiring, say so. If it is for internal Knowledge Capture, ask for more technical detail and less marketing polish.

Useful input format:

• 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

Tune attribution and evidence quality

Ask for calibrated attribution on every important decision. Strong collab-proof output should avoid both extremes: pretending the developer did everything or claiming Claude independently built the solution. Request evidence phrases such as “Claude suggested,” “developer selected,” “developer rejected,” “jointly refined,” and “root cause identified from.”

For bug fixes, explicitly ask the skill to capture cause, diagnosis path, and fix rationale. The repository’s BUG_FIXING rule treats a well-explained one-file fix as high-value evidence.

Iterate after the first output

Do not accept the first generated proof blindly. Review it for overclaiming, missing alternatives, unclear ownership, and unverifiable statements. Then ask for a second pass:

“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.”

This usually produces more credible documentation than asking for a polished artifact immediately.

Add tamper-evident proof when needed

If the evidence may be shared externally, consider the Git notes workflow described in references/tamper-evident-proof.md. The idea is to hash the generated HTML proof file and attach the hash to the relevant commit with git notes. That does not make the content automatically true, but it helps show that a specific proof artifact existed for a specific code state.