collab-proof
por alirezarezvanicollab-proof ajuda usuários do Claude Code a transformar sessões de programação assistidas por IA em evidências de colaboração, separando decisões do desenvolvedor, contribuições do Claude, alternativas rejeitadas e artefatos de prova para retrospectivas, portfólios, contratação e Knowledge Capture.
Esta skill recebe 78/100, o que a torna uma candidata sólida para usuários do diretório que querem evidências estruturadas da colaboração entre humano e IA após sessões de programação. O repositório oferece substância real de fluxo de trabalho, frases de acionamento claras, rubricas de decisão e justificativas de apoio, mas a adoção fica um pouco limitada pela ausência de instruções de instalação e pela dependência de execução manual de prompts, em vez de scripts incluídos.
- Alta capacidade de acionamento: o frontmatter traz gatilhos explícitos como `/collab-proof`, session retrospective, AI contribution analysis, collaboration evidence e “what did Claude do”.
- Conteúdo operacional consistente: SKILL.md inclui um fluxo de detecção de sinais que começa com `git log --oneline -10` e `git diff --stat HEAD~3..HEAD`, além de regras de classificação HIGH/MEDIUM e exceções para correção de bugs.
- Bom contexto para decisão de instalação: quatro arquivos de referência explicam a lógica de portfólio, documentação de sessão, ADR e prova resistente a adulteração por trás da skill.
- Não há comando de instalação nem README no diretório da skill, então usuários do diretório talvez precisem já saber como instalar skills do Claude a partir deste repo.
- O fluxo parece ser nativo de prompts, sem scripts ou automação; os agentes precisam executar comandos git manualmente, classificar evidências e gerar artefatos, o que pode gerar variação.
Visão geral da skill collab-proof
Para que serve collab-proof
collab-proof é uma skill do Claude para transformar uma sessão de programação assistida por IA em evidência de colaboração utilizável: o que você decidiu, com o que o Claude contribuiu, por que alternativas foram descartadas e quais artefatos comprovam isso. Ela é mais indicada para desenvolvedores que usam Claude Code e querem retrospectivas melhores de sessão, provas para portfólio, evidências para processos seletivos ou Knowledge Capture durável depois de trabalho de engenharia relevante.
Em vez de produzir um resumo genérico, a skill collab-proof aplica um fluxo em camadas: detecta a força do sinal da sessão, classifica a intenção do trabalho, pontua o enquadramento da colaboração e então decide quais artefatos de documentação valem a pena gerar.
Usuários e trabalhos mais indicados
Use collab-proof quando precisar responder a perguntas como:
- “Com o que o Claude realmente contribuiu aqui?”
- “Quais decisões foram minhas e quais foram sugeridas pela IA?”
- “Posso mostrar este trabalho em um portfólio sem exagerar o meu papel ou o da IA?”
- “Que raciocínio seria perdido se o histórico do chat desaparecesse?”
Ela é especialmente útil depois de diagnóstico de bugs, escolhas de arquitetura, implementação de funcionalidades, refatorações e discussões sobre tradeoffs de design. A skill é menos útil para edições muito pequenas, commits apenas de formatação, atualizações de dependências ou sessões em que não houve raciocínio relevante.
O que torna a skill diferente
O principal diferencial é a atribuição calibrada. collab-proof não apenas resume “o que mudou”; ela separa a intenção do desenvolvedor, sugestões do Claude, ideias aceitas, alternativas rejeitadas e raciocínio de causa raiz. O material de origem também inclui orientação para prova resistente a adulteração usando Git notes e hashes SHA-256, algo importante se você quer uma documentação que possa ser vinculada a um commit específico.
Para Knowledge Capture, collab-proof é mais forte quando a sessão contém decisões, diagnóstico, alternativas ou justificativas que não ficariam óbvias apenas pelo diff final.
Como usar a skill collab-proof
Contexto de instalação do collab-proof
Instale a skill a partir do repositório com:
npx skills add alirezarezvani/claude-skills --skill collab-proof
A skill fica em:
engineering/collab-proof/skills/collab-proof
Depois da instalação, inspecione primeiro SKILL.md e então leia os arquivos de referência que explicam o modelo de evidências:
references/ai-collaboration-evidence.mdreferences/developer-portfolio-proof.mdreferences/session-documentation-patterns.mdreferences/tamper-evident-proof.md
Não há scripts auxiliares na pasta da skill, então espere um fluxo nativo de prompt, não um gerador de relatório de comando único.
Entradas de que a skill precisa
Para usar bem collab-proof, forneça mais do que um pedido vago. A skill funciona melhor com:
- O estado atual do repositório
- Commits recentes ou o diff relevante
- Uma breve descrição do objetivo da sessão
- Trechos importantes da conversa
- O bug, a funcionalidade ou a decisão que está sendo documentada
- Se a saída é para você, um PR, um portfólio ou prova para contratação
O fluxo upstream pede que o Claude rode primeiro git log --oneline -10 e git diff --stat HEAD~3..HEAD. Esses comandos ajudam a classificar a sessão como de sinal alto, médio ou baixo. Uma correção de bug em um único arquivo ainda pode ser de alto sinal se a transcrição incluir diagnóstico de causa raiz e justificativa da correção.
Bom padrão de prompt para collab-proof
Um prompt fraco seria:
“Use collab-proof neste projeto.”
Um prompt mais forte seria:
“Use collab-proof para a última sessão. O objetivo era corrigir o bug de redirecionamento no login. Inspecione os commits recentes e as estatísticas do diff, classifique o sinal de colaboração, identifique o raciocínio de causa raiz, separe minhas decisões das sugestões do Claude e produza evidências seguras para portfólio. Destaque por que a correção escolhida foi melhor do que a abordagem de middleware rejeitada.”
Isso funciona melhor porque dá à skill uma tarefa, um escopo, um público para a saída e os pontos de decisão que devem ser preservados.
Fluxo de trabalho sugerido
Comece com uma retrospectiva estreita logo após a sessão, enquanto o raciocínio ainda está fresco. Peça ao Claude para identificar o nível de sinal antes de escrever os artefatos finais. Se a sessão tiver sinal alto, solicite registros de decisão, histórico da sessão, um worklog e uma saída de prova portátil. Se tiver sinal médio, um worklog conciso pode ser suficiente. Se tiver sinal baixo, evite documentar demais.
Para uso em portfólio ou contratação, peça uma redação conservadora. A melhor evidência diz “Claude identificou X; eu avaliei e escolhi Y por causa de Z”, não “a IA construiu o projeto”.
FAQ da skill collab-proof
collab-proof serve só para portfólios?
Não. Prova para portfólio é um caso de uso importante, mas collab-proof para Knowledge Capture é igualmente relevante. Ela ajuda a preservar justificativas que desaparecem do histórico do Git: por que um bug aconteceu, por que um design mudou, o que a IA percebeu e onde o desenvolvedor contrariou a IA.
Por que é melhor do que um prompt comum de resumo?
Um prompt normal de resumo costuma comprimir a sessão em tarefas concluídas. A skill collab-proof é mais estruturada: ela pontua a força da evidência, diferencia contribuições humanas e da IA, prioriza a justificativa das decisões e evita tratar todas as sessões de programação como igualmente importantes. Isso torna a saída mais útil para revisões, retrospectivas e prova de trabalho.
Iniciantes podem usar esta skill?
Sim, mas iniciantes devem manter a primeira execução simples. Peça um worklog e uma divisão de contribuições antes de solicitar evidência completa para portfólio. As partes mais difíceis não são a instalação; são fornecer contexto suficiente e evitar alegações infladas sobre o que a IA fez.
Quando não devo usar collab-proof?
Não use collab-proof para commits rotineiros sem raciocínio relevante, boilerplate gerado, limpeza cosmética ou transcrições privadas que você não pode resumir com segurança. Também evite usá-la como substituto para testes reais, revisão de código ou boa higiene de commits. Ela documenta a colaboração; não valida a correção técnica.
Como melhorar a skill collab-proof
Melhore as entradas do collab-proof
O modo de falha mais comum é contexto raso. Melhore os resultados dando ao Claude o objetivo da sessão, trechos importantes da conversa, arquivos afetados, intervalo de commits e o leitor pretendido. Se a saída for para contratação, diga isso. Se for para Knowledge Capture interno, peça mais detalhe técnico e menos polimento de marketing.
Formato útil de entrada:
- Objetivo: o que você estava tentando realizar
- Conjunto de mudanças: commits, arquivos ou intervalo de diff
- Raciocínio: alternativas consideradas e rejeitadas
- Atribuição: o que você propôs, o que o Claude propôs, o que mudou
- Público: notas privadas, PR, README, recrutador, portfólio
Ajuste a atribuição e a qualidade das evidências
Peça atribuição calibrada para cada decisão importante. Uma boa saída de collab-proof deve evitar os dois extremos: fingir que o desenvolvedor fez tudo ou afirmar que o Claude construiu a solução de forma independente. Solicite expressões de evidência como “Claude suggested”, “developer selected”, “developer rejected”, “jointly refined” e “root cause identified from”.
Para correções de bugs, peça explicitamente que a skill capture causa, caminho de diagnóstico e justificativa da correção. A regra BUG_FIXING do repositório trata uma correção bem explicada em um único arquivo como evidência de alto valor.
Itere depois da primeira saída
Não aceite cegamente a primeira prova gerada. Revise o conteúdo em busca de exageros, alternativas ausentes, autoria pouco clara e afirmações não verificáveis. Depois, peça uma segunda rodada:
“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.”
Isso normalmente produz uma documentação mais crível do que pedir um artefato polido logo de início.
Adicione prova resistente a adulteração quando necessário
Se as evidências puderem ser compartilhadas externamente, considere o fluxo com Git notes descrito em references/tamper-evident-proof.md. A ideia é gerar um hash do arquivo HTML de prova e anexar esse hash ao commit relevante com git notes. Isso não torna o conteúdo automaticamente verdadeiro, mas ajuda a mostrar que um artefato de prova específico existia para um estado específico do código.