VENTICINQUE, MAURO

Uso Claude Code todos los días desde marzo de 2025, en tres contextos que no se parecen: una plataforma con cinco años de historia, veintiséis repositorios de una agencia y clientes chicos sin relación entre sí. Lo que sigue no son afirmaciones sobre productividad. Son los artefactos.

Cinco hooks. Dos bloquean, tres verifican o inyectan. La diferencia entre bloquear y explicar no es de estilo: depende de si el comando es reversible.

block-vtex-critical corta en seco: vtex deploy, publish, release, promote, rollback, y del lado de GitHub pr create, merge, review --approve y ready. No los reescribe ni los pide confirmados: imprime el comando para que lo corra una persona. Publicar una versión de una app instalada en tiendas ajenas no es una operación que deba poder disparar un agente. guard-faststore-commands hace lo contrario y es más interesante: no bloquea, explica. En FastStore un git push a main ES el deploy de producción, y eso no es evidente leyendo el repositorio.

Escribí y mantengo el marketplace privado de Claude Code del equipo de VTEX de la agencia. Mis plugins llevan metodología y guardarraíles. El conocimiento de la plataforma lo llevan las skills oficiales de VTEX, fijadas en una versión validada.

El modelo de dos capas es la decisión que importa. Las skills oficiales de VTEX cubren el conocimiento del producto: contratos de apps, builders, políticas, GraphQL, Master Data. Mis skills cubren lo que esa documentación no puede cubrir, porque no es de VTEX: el flujo de Git y de pull requests del equipo, las reglas de CSS con los gotchas que ya nos comimos, el chequeo contra el design system. Las dos capas conviven porque cada skill declara cuándo se carga. Las oficiales están fijadas en una versión validada: una skill que se actualiza sola es una skill que cambia de opinión sin avisarte.

Dos cuentas de Claude Code, una por cliente, y el shell elige cuál según en qué carpeta estoy. El contexto de un cliente no tiene que poder filtrarse al de otro, y eso no se resuelve con disciplina: se resuelve con configuración. Los clientes chicos arrancan sin nada cargado —ni convenciones de equipo, ni skills, ni hooks—, porque un proyecto de dos semanas no necesita heredar las reglas de una agencia que no lo toca. El detalle que hace que funcione en la práctica es el orden de las reglas: hay un proyecto que vive físicamente entre los clientes chicos pero es trabajo de la agencia, así que se evalúa antes y recibe la configuración de la agencia.

claude() {
  case "$PWD" in
    ~/trabajo/agencia/*)   config="$HOME/.claude-agencia" ;;
    ~/trabajo/empleador/*) config="$HOME/.claude-empleador" ;;
    ~/trabajo/clientes/*)  aislado=1 ;;
  esac

  if [ -n "$config" ]; then
    CLAUDE_CONFIG_DIR="$config" command claude "$@"
  elif [ "$aislado" = 1 ]; then
    command claude --safe-mode "$@"
  else
    command claude "$@"
  fi
}

Tres niveles de contexto, y cada uno responde una pregunta distinta. El primero define QUIÉN trabaja: hay una configuración por cliente, con su propia cuenta. El segundo define DÓNDE: cada área de trabajo tiene un archivo que declara qué es, con qué cuenta corre y cuál es el comportamiento por defecto ahí — en la plataforma del empleador, leer el repositorio de backend antes de asumir un contrato de API; en los clientes chicos, arrancar sin ninguna configuración cargada. Y el tercero define QUÉ decisiones ya se tomaron en ese proyecto puntual: son 25 archivos versionados, uno por repositorio. La regla que los mantiene útiles: si algo ya lo dice el plugin del equipo, no se repite. Un dato guardado en dos lugares es un dato que va a divergir.

Publiqué este sitio con un conmutador de idioma en el header de todas las páginas apuntando a rutas que no existían. Cada /en/* devolvía 404, y el público al que ese botón le servía era justamente el que buscaba.

El inglés existe: mismo cuerpo de documento, mismas cifras, prosa escrita aparte. Y el cuerpo pasó a ser un componente compartido por los dos idiomas, así que no puede haber una versión con secciones que la otra no tenga.

Mi propia skill de licenciamiento documentó durante meses un fail-open que el boilerplate ya había reemplazado por un stale allow. Cualquiera que siguiera la skill iba a escribir el gate de licencia mal.

La corrección no fue editar el archivo. Instalé un hook de SessionStart que compara sin red la versión del boilerplate del repo contra la versión fijada en el plugin, y un comando que consulta las tags reales y contrasta el CHANGELOG contra lo que afirman las skills, reportando archivo y línea de los dos lados.

Claude Code no me hace más rápido escribiendo código. Me hace más rápido verificando. El costo se movió: ahora la parte lenta es decidir qué es verdad.

Lo que te queda cuando termino: el repositorio, el registro de decisiones fechado y los tests que lo cubren. No hace falta llamarme para entenderlo.

Errata completa →