collab-proof
por alirezarezvanicollab-proof ayuda a los usuarios de Claude Code a convertir sesiones de programación asistidas por IA en evidencia de colaboración, separando decisiones del desarrollador, aportes de Claude, alternativas descartadas y artefactos de prueba para retrospectivas, portfolios, contratación y Knowledge Capture.
Esta skill obtiene 78/100, lo que la convierte en una candidata sólida para usuarios de directorios que buscan evidencia estructurada de colaboración humano-vs-IA después de sesiones de programación. El repositorio aporta un flujo de trabajo real, frases de activación claras, criterios de decisión y justificación de apoyo, aunque su adopción se ve algo limitada por la falta de instrucciones de instalación y por depender de la ejecución manual de prompts en lugar de scripts incluidos.
- Alta capacidad de activación: el frontmatter incluye disparadores explícitos como `/collab-proof`, session retrospective, AI contribution analysis, collaboration evidence y “what did Claude do”.
- Sustancia operativa sólida: SKILL.md incluye un flujo de detección de señales que empieza con `git log --oneline -10` y `git diff --stat HEAD~3..HEAD`, además de reglas de clasificación HIGH/MEDIUM y excepciones para corrección de bugs.
- Buen contexto para decidir la instalación: cuatro archivos de referencia explican la lógica de portfolio, documentación de sesión, ADR y prueba a prueba de manipulación que sustenta la skill.
- No hay comando de instalación ni README en el directorio de la skill, por lo que los usuarios del directorio pueden necesitar conocimientos previos sobre cómo instalar skills de Claude desde este repo.
- El flujo de trabajo parece nativo de prompts y no incluye scripts ni automatización; los agentes deben ejecutar manualmente comandos de git, clasificar evidencias y generar artefactos, lo que puede generar variabilidad.
Descripción general de collab-proof skill
Para qué sirve collab-proof
collab-proof es una Claude skill para convertir una sesión de programación asistida por IA en evidencia de colaboración útil: qué decidiste, qué aportó Claude, por qué se descartaron alternativas y qué artefactos lo demuestran. Es especialmente adecuada para desarrolladores que usan Claude Code y quieren mejores retrospectivas de sesión, pruebas para portafolio, evidencia para procesos de contratación o Knowledge Capture duradero después de trabajo de ingeniería relevante.
En lugar de producir un resumen genérico, collab-proof skill aplica un flujo de trabajo por capas: detecta la fuerza de la señal de la sesión, clasifica la intención del trabajo, puntúa el marco de colaboración y luego decide qué artefactos de documentación vale la pena generar.
Usuarios y trabajos para los que encaja mejor
Usa collab-proof cuando necesites responder preguntas como:
- “¿Qué aportó Claude realmente aquí?”
- “¿Qué decisiones fueron mías y cuáles fueron sugeridas por la IA?”
- “¿Puedo mostrar este trabajo en un portafolio sin exagerar mi participación?”
- “¿Qué razonamiento se perdería si desapareciera la transcripción del chat?”
Resulta especialmente útil después de diagnosticar bugs, tomar decisiones de arquitectura, implementar funcionalidades, hacer refactors y discutir tradeoffs de diseño. La skill es menos útil para cambios mínimos, commits solo de formato, actualizaciones de dependencias o sesiones en las que no hubo razonamiento significativo.
Qué la hace diferente
El principal diferenciador es la atribución calibrada. collab-proof no se limita a resumir “qué cambió”; separa la intención del desarrollador, las sugerencias de Claude, las ideas aceptadas, las alternativas rechazadas y el razonamiento de causa raíz. El material fuente también incluye orientación para crear pruebas resistentes a manipulaciones mediante Git notes y hashes SHA-256, algo importante si quieres documentación que pueda vincularse a un commit específico.
Para Knowledge Capture, collab-proof funciona mejor cuando la sesión contiene decisiones, diagnóstico, alternativas o justificación que no serían evidentes solo a partir del diff final.
Cómo usar collab-proof skill
Contexto de instalación de collab-proof
Instala la skill desde el repositorio con:
npx skills add alirezarezvani/claude-skills --skill collab-proof
La skill se encuentra en:
engineering/collab-proof/skills/collab-proof
Después de instalarla, revisa primero SKILL.md y luego lee los archivos de referencia que explican el modelo de evidencia:
references/ai-collaboration-evidence.mdreferences/developer-portfolio-proof.mdreferences/session-documentation-patterns.mdreferences/tamper-evident-proof.md
No hay scripts auxiliares en la carpeta de la skill, así que espera un flujo de trabajo basado en prompts, no un generador de reportes de un solo comando.
Entradas que necesita la skill
Para usar bien collab-proof, aporta algo más que una solicitud vaga. La skill funciona mejor con:
- El estado actual del repositorio
- Commits recientes o el diff relevante
- Una breve descripción del objetivo de la sesión
- Fragmentos importantes de la conversación
- El bug, la funcionalidad o la decisión que se está documentando
- Si la salida es para ti, para un PR, para un portafolio o como evidencia de contratación
El flujo de trabajo original pide a Claude ejecutar primero git log --oneline -10 y git diff --stat HEAD~3..HEAD. Esos comandos ayudan a clasificar la sesión como de señal alta, media o baja. Un fix de bug en un solo archivo aun así puede ser de señal alta si la transcripción incluye diagnóstico de causa raíz y justificación de la solución.
Patrón de prompt sólido
Un prompt débil sería:
“Use collab-proof on this project.”
Un prompt más sólido sería:
“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.”
Funciona mejor porque le da a la skill una tarea, un alcance, una audiencia para la salida y los puntos de decisión que debe preservar.
Flujo de trabajo sugerido
Empieza con una retrospectiva acotada justo después de la sesión, mientras el razonamiento sigue fresco. Pide a Claude que identifique el nivel de señal antes de redactar los artefactos finales. Si la sesión tiene señal alta, solicita registros de decisión, historial de sesión, un worklog y una salida de prueba portable. Si tiene señal media, quizá baste con un worklog conciso. Si tiene señal baja, evita documentar de más.
Para portafolios o procesos de contratación, pide una redacción conservadora. La mejor evidencia dice “Claude identificó X; yo evalué y elegí Y porque Z”, no “la IA construyó el proyecto”.
Preguntas frecuentes sobre collab-proof skill
¿collab-proof es solo para portafolios?
No. La prueba para portafolio es un caso de uso importante, pero collab-proof para Knowledge Capture es igual de valioso. Ayuda a preservar la justificación que desaparece del historial de Git: por qué ocurrió un bug, por qué cambió un diseño, qué detectó la IA y en qué puntos el desarrollador decidió no seguir a la IA.
¿En qué es mejor que un prompt de resumen común?
Un prompt de resumen normal suele comprimir la sesión en tareas completadas. collab-proof skill es más estructurada: puntúa la solidez de la evidencia, distingue contribuciones humanas y de IA, prioriza la justificación de decisiones y evita tratar todas las sesiones de programación como si tuvieran la misma importancia. Eso hace que la salida sea más útil para revisiones, retrospectivas y prueba de trabajo realizado.
¿Pueden usar esta skill quienes están empezando?
Sí, pero quienes están empezando deberían mantener la primera ejecución simple. Pide un worklog y un desglose de contribuciones antes de solicitar evidencia completa para portafolio. Lo difícil no es la instalación, sino aportar suficiente contexto y evitar afirmaciones infladas sobre lo que hizo la IA.
¿Cuándo no debería usar collab-proof?
No uses collab-proof para commits rutinarios sin razonamiento significativo, boilerplate generado, limpieza cosmética o transcripciones privadas que no puedas resumir de forma segura. Tampoco lo uses como sustituto de pruebas reales, code review o buena higiene de commits. Documenta la colaboración; no valida la corrección del código.
Cómo mejorar collab-proof skill
Mejorar las entradas de collab-proof
El modo de fallo más común es dar poco contexto. Mejora los resultados proporcionando a Claude el objetivo de la sesión, fragmentos importantes de la conversación, archivos afectados, rango de commits y lector previsto. Si la salida es para contratación, dilo. Si es para Knowledge Capture interno, pide más detalle técnico y menos pulido de marketing.
Formato de entrada útil:
- Objetivo: qué intentabas lograr
- Conjunto de cambios: commits, archivos o rango de diff
- Razonamiento: alternativas consideradas y rechazadas
- Atribución: qué propusiste tú, qué propuso Claude, qué cambió
- Audiencia: notas privadas, PR, README, recruiter, portafolio
Ajustar la atribución y la calidad de la evidencia
Pide atribución calibrada para cada decisión importante. Una buena salida de collab-proof debería evitar ambos extremos: fingir que el desarrollador hizo todo o afirmar que Claude construyó la solución de forma independiente. Solicita frases de evidencia como “Claude suggested,” “developer selected,” “developer rejected,” “jointly refined,” y “root cause identified from.”
Para fixes de bugs, pide explícitamente a la skill que capture la causa, la ruta de diagnóstico y la justificación del fix. La regla BUG_FIXING del repositorio trata un fix de un solo archivo bien explicado como evidencia de alto valor.
Iterar después de la primera salida
No aceptes a ciegas la primera prueba generada. Revísala para detectar afirmaciones exageradas, alternativas omitidas, propiedad poco clara y declaraciones que no se puedan verificar. Luego pide una segunda pasada:
“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.”
Esto suele producir documentación más creíble que pedir un artefacto pulido desde el inicio.
Añadir prueba resistente a manipulaciones cuando haga falta
Si la evidencia puede compartirse externamente, considera el flujo de trabajo con Git notes descrito en references/tamper-evident-proof.md. La idea es calcular el hash del archivo HTML de prueba generado y adjuntar ese hash al commit relevante con git notes. Eso no hace que el contenido sea automáticamente verdadero, pero ayuda a mostrar que un artefacto de prueba específico existía para un estado de código concreto.