collab-proof

collab-proof skill 概览

collab-proof 的用途

collab-proof 是一个 Claude skill，用来把 AI 辅助编码会话整理成可用于协作证明的材料：你做了哪些决策、Claude 贡献了什么、为什么没有采用其他方案，以及哪些产物可以作为证据。它特别适合使用 Claude Code 的开发者，用于更高质量的会话复盘、作品集证明、求职材料，或在完成有意义的工程工作后沉淀可长期保存的 Knowledge Capture。

collab-proof skill 不会只生成一份泛泛的总结，而是采用分层工作流：先判断本次会话的信号强度，再分类工作意图、评估协作框架，最后决定哪些文档产物值得生成。

最适合的用户与场景

当你需要回答这类问题时，可以使用 collab-proof：

• “Claude 在这里到底贡献了什么？”
• “哪些决策是我做的，哪些是 AI 建议的？”
• “我能不能把这项工作放进作品集，同时不夸大事实？”
• “如果聊天记录消失了，会丢失哪些推理过程？”

它尤其适用于 bug 诊断、架构选择、功能实现、重构，以及设计取舍讨论之后。对于很小的改动、只改格式的 commit、依赖版本升级，或没有发生实质性推理的会话，这个 skill 的价值就不高。

它的不同之处

collab-proof 的主要差异点在于校准过的归因。它不只是总结“改了什么”，而是区分开发者意图、Claude 的建议、被采纳的想法、被否决的备选方案，以及根因分析过程。源材料还包含使用 Git notes 和 SHA-256 hashes 生成防篡改证据的指导；如果你希望文档能关联到某个具体 commit，这一点很重要。

用于 Knowledge Capture 时，collab-proof 在会话中包含决策、诊断、备选方案或设计理由时最有价值，因为这些内容通常无法从最终 diff 中直接看出来。

如何使用 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 文件夹中没有辅助脚本，因此应预期这是一个以 prompt 为核心的工作流，而不是一条命令生成报告的工具。

skill 需要哪些输入

要有效使用 collab-proof，不要只给一个模糊请求。它在获得以下信息时效果最好：

• 当前 repository 状态
• 最近的 commits 或相关 diff
• 对本次会话目标的简短描述
• 任何重要的对话摘录
• 正在记录的 bug、feature 或决策
• 输出用途：自用、PR、作品集，还是求职证明

上游工作流会要求 Claude 先运行 git log --oneline -10 和 git diff --stat HEAD~3..HEAD。这些命令有助于把会话分类为高、中、低信号。即使只是单文件 bug 修复，如果 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.”

这种写法更有效，因为它为 skill 提供了任务、范围、输出受众，以及需要保留下来的决策点。

推荐工作流

在会话刚结束、推理过程仍然清晰时，先做一次范围较窄的复盘。让 Claude 在编写最终产物前先判断信号等级。如果会话是高信号，要求生成决策记录、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 只适合做作品集吗？

不是。作品集证明是一个重要用例，但用于 Knowledge Capture 的 collab-proof 同样重要。它可以保留 Git history 中看不到的理由：bug 为什么发生、设计为什么改变、AI 注意到了什么，以及开发者在哪些地方否定了 AI 的建议。

它比普通总结 prompt 好在哪里？

普通总结 prompt 通常会把会话压缩成“完成了哪些任务”。collab-proof skill 的结构更清晰：它会评估证据强度、区分人类和 AI 的贡献、优先保留决策理由，并避免把每一次编码会话都视为同等重要。因此，它生成的内容更适合用于 review、复盘和工作证明。

初学者可以使用这个 skill 吗？

可以，但初次使用时应保持简单。先请求生成 worklog 和贡献拆分，再要求完整的作品集证据。难点通常不在安装，而在于提供足够上下文，并避免夸大 AI 实际做了什么。

什么时候不应该使用 collab-proof？

不要把 collab-proof 用在没有实质性推理的常规 commit、生成式 boilerplate、纯外观清理，或你无法安全总结的私密 transcript 上。也不要把它当作真实测试、code review 或良好 commit 习惯的替代品。它记录的是协作过程，不负责验证代码正确性。

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

改进 collab-proof 输入

最常见的失败模式是上下文太薄。要提升结果质量，请向 Claude 提供会话目标、对话中的重要片段、受影响文件、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 修复，请明确要求 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 proof file 做 hash，并用 git notes 把 hash 附加到相关 commit 上。这并不会自动证明内容为真，但有助于说明某个具体 proof artifact 曾经存在于某个具体代码状态下。