Reglas de handoff para equipos con Claude Code: evidencia, permisos, rollback e ingresos

Por qué importa el handoff de equipo

Usar Claude Code en solitario puede funcionar con memoria personal. En equipo no. Cuando otra persona debe revisar un patch generado por IA, la pregunta no es solo si el diff se ve correcto. También hay que saber quién aprobó una acción sensible, qué URL pública se comprobó, qué evidencia se puede repetir y qué ruta de ingresos quedó protegida.

Esto se vuelve crítico en artículos, landing pages, páginas de producto, enlaces de Gumroad y formularios de consulta. Un build puede pasar aunque el botón del PDF gratuito apunte al idioma equivocado. Un texto puede sonar mejor aunque cambie una promesa comercial. Un formulario puede verse bien y fallar al enviar.

El objetivo del handoff no es escribir un diario largo de actividad. El objetivo es dejar un contrato breve de revisión: qué cambió, qué prueba existe, qué permiso se usó, cómo se vuelve atrás, qué no se debe tocar y si se revisaron PDF gratis, Gumroad y consulta.

Conviene leerlo junto con la plantilla de handoff de sesión, el Permission Budget Loop y la checklist de review. Para confirmar capacidades base del producto, usa también la documentación oficial de Claude Code.

Errores típicos al entregar trabajo

El primer error es pasar solo un log: “amplié el artículo”, “arreglé enlaces”, “corrí build”. Eso no le dice al reviewer qué debe creer, qué debe abrir ni qué camino de conversión fue comprobado. Para revisar no basta con historia; hace falta evidencia.

El segundo error es dejar las reglas de aprobación en una conversación oral. Alguien piensa que era una corrección menor, pero Claude Code termina tocando copy de precio, destino de CTA, configuración de deploy o un formulario público. Si el límite de permisos no está escrito, el reviewer tiene que reconstruir la intención desde el diff.

El tercer error es olvidar el rollback. Si el cambio de IA rompe la página tras publicarse, el equipo necesita saber el punto de restauración, el comando de reversión y el orden de recuperación. Sin eso, los primeros minutos se gastan en decidir quién se encarga, no en recuperar la página o el flujo de compra.

El cuarto error es tratar los ingresos como tarea de otra persona. En operaciones de contenido, el tráfico no es el final. El lector debe poder descargar el PDF gratuito, comprar el material de Gumroad o enviar una consulta. Esos caminos forman parte de la superficie funcional del artículo.

En el flujo de Masa, el problema no era solo que algunos artículos quedaran finos. El problema mayor era que el reviewer no podía ver con rapidez si el artículo seguía conectado al camino de aprendizaje y compra. Al añadir prueba, permisos, rollback e ingresos al handoff, los comentarios cambiaron de “¿qué miro?” a “esta prueba alcanza” o “falta verificar Gumroad”.

Evidencia que debes pasar a review

La buena evidencia es específica y repetible. El reviewer debe poder ejecutar el mismo comando, abrir la misma URL y entender el mismo límite de riesgo. Para un artículo, la evidencia mínima suele incluir longitud del cuerpo, cantidad de h2, enlaces internos, enlaces externos, bloques de código, heroImage, calidad de localización y destino de CTA.

Para una página de producto, incluye vista móvil, envío de formulario, copy de precio, enlace de compra, canonical y página de gracias. Para una tarea de desarrollo, incluye tests, type check, build, archivos afectados y riesgos pendientes. La checklist cambia, pero la pregunta es siempre igual: ¿qué puede verificar el reviewer sin adivinar?

Un registro mínimo de comandos puede verse así:

npm run build
node scripts/check-updated-article-quality.mjs

Si un comando no se ejecutó, no escribas solo “no probado”. Escribe por qué y dónde se comprobará: dependencias no instaladas, API key ausente, entorno solo disponible en CI o necesidad de preview online. Así el hueco queda visible y revisable.

Las capturas ayudan, pero no son prueba suficiente por sí solas. Una captura demuestra que un viewport se veía bien en un momento. No demuestra que el enlace destino, la compra ni el rollback funcionen. Combina captura con URL, comando ejecutado y nota de riesgo.

Kit mínimo para copiar y pegar

Pega este bloque Markdown en la descripción del PR, Issue, Slack o Notion. Es pequeño a propósito. Un formato que tarda veinte minutos en rellenarse no sobrevive al uso diario.

# Claude Code team handoff

## Change made
- 

## Proof
- build:
- public URL:
- screenshot:

## Revenue path checked
- free PDF:
- Gumroad:
- consultation:

## Next owner
- reviewer:
- decision needed:
- do not touch:

Conviene dejar los permisos en una forma que también pueda leer una máquina. Este JSON no sustituye una política de seguridad, pero da a Claude Code y al equipo el mismo vocabulario de límites.

{
  "approval_rules": {
    "safe": ["read files", "search", "small copy edit"],
    "review_required": ["pricing", "CTA links", "deployment"],
    "blocked": ["secrets", "force push", "delete customer data"]
  }
}

También fija el prompt del reviewer. Sin un alcance claro, la revisión se desvía hacia preferencias de estilo, discusiones antiguas de producto o refactors que no pertenecen a esta entrega.

You are receiving a Claude Code handoff.
Check the proof first.
Then review only:
1. whether the stated goal was met
2. whether protected links still work
3. whether the next owner has one clear action

Plantilla de permisos, rollback e ingresos

En equipo, permisos, rollback e ingresos deben vivir en la misma plantilla. Muchas incidencias empiezan cuando alguien aprueba algo de palabra, nadie registra el punto de restauración y todos asumen que el CTA sigue bien.

handoff:
  owner: "Masa"
  reviewer: "team-reviewer"
  permission:
    safe:
      - "copy edit inside the article body"
      - "run local quality checks"
    needs_review:
      - "price copy"
      - "CTA destination"
      - "deployment setting"
    blocked:
      - "secrets"
      - "customer data"
      - "force push"
  rollback:
    restore_point: "commit or branch before Claude Code work"
    command: "git revert <commit>"
    priority_path:
      - "public article page"
      - "free PDF signup"
      - "Gumroad purchase"
      - "consultation form"
  revenue:
    free_pdf: "checked"
    gumroad: "checked"
    consultation: "checked"

La plantilla no busca burocracia. Para una edición pequeña de artículo se rellena en cinco minutos. Si el cambio toca precio, compra, formulario, datos de clientes o deploy, estos campos deberían estar completos antes de pedir review.

Cuatro casos de uso reales

El primer caso es publicación de artículos. Un redactor amplía el texto con Claude Code; luego un editor o engineer revisa script de calidad, página pública, enlaces internos, enlace externo, heroImage y CTA del PDF gratuito. El reviewer no tiene que leer todo el sitio: verifica si la mejora prometida y la ruta de conversión siguen funcionando.

El segundo caso es copy de producto. Un PM puede pedir a Claude Code que reescriba la descripción de un material de Gumroad, pero precio, condiciones, destino de CTA y enlace de compra quedan en review_required. Así se evita que el texto suene mejor pero cambie una promesa comercial sin aprobación.

El tercer caso es mejora de la página de consulta. Claude Code puede ordenar títulos, reescribir preguntas y quitar repeticiones. Aun así, el handoff debe demostrar que el formulario envía, que los errores se muestran y que la página de gracias abre. Si no, el equipo mejora palabras y rompe leads.

El cuarto caso es mantenimiento de política de permisos. Si el lead decide que lectura y búsqueda son safe, precio y deploy requieren review, y secrets o datos de cliente están blocked, esa regla debe entregarse como diff. La siguiente sesión de Claude Code puede recibir el mismo contexto.

Cómo debería leerlo el reviewer

El reviewer empieza por la evidencia, no por el diff. Comprueba build o script de calidad, abre la URL de preview o producción, mira la captura si existe y prueba enlaces protegidos. Si falta evidencia, devuelve el handoff como incompleto en vez de inferir el resultado desde el código.

Después revisa el alcance de permisos. Si el cambio quedó en safe, basta una review normal. Si toca precio, CTA, deploy, formularios o copy de ingresos, debe confirmarlo el owner correspondiente. Si toca algo blocked, no se mergea aunque el resultado parezca útil.

Por último revisa rollback. Un handoff sin rollback no está listo para operación. En un artículo puro quizá baste revertir un commit. En producto, checkout, tracking o consulta, el orden importa: primero recuperar la página pública, luego PDF gratuito, Gumroad y formulario de consulta.

Ruta natural hacia materiales y consultoría

Para adopción individual, empieza con el cheatsheet gratuito de Claude Code. Es suficiente si el bloqueo principal es recordar comandos y hábitos seguros. Cuando los prompts de review, debugging, mejora de artículos o documentación se repiten, usa 50 Claude Code Prompt Templates.

Para equipos, la Claude Code Setup Guide ayuda a estandarizar CLAUDE.md, hooks, permisos, MCP y comandos de verificación. Sirve cuando el equipo puede ejecutar el proceso, pero necesita estructura.

Si la parte cara es decidir quién aprueba, qué enlaces se protegen y cómo conectar AdSense, Gumroad y consultas, compara la página de productos y usa la página de consulta. La consultoría no resuelve un prompt aislado; diseña responsabilidad, evidencia, rollback y prioridades de ingresos.

El camino natural es simple: PDF gratuito para hábitos, Gumroad para flujos repetibles y consulta para reglas específicas del equipo. Así la recomendación encaja con la madurez del lector.

Qué verifiqué para este artículo

Este artículo incluye handoff Markdown, reglas JSON, prompt de reviewer y plantilla YAML de permisos, rollback e ingresos. La intención es que el trabajo de Claude Code sea revisable por otra persona, no solo entendible por quien ejecutó la sesión. En la práctica, el handoff funciona cuando el siguiente owner puede responder rápido: qué cambió, qué prueba existe y qué camino debe mantenerse protegido.