DATASHEET

VENTICINQUE, MAURO

Frontend · Full-Stack

Rev. 2026.08supersedes 2025.11

Español

Copied

Practice

Verified

§5.2

I have used Claude Code daily since March 2025, across three contexts that have nothing in common: a platform with five years of history, twenty-six repositories belonging to an agency, and small unrelated clients. What follows are not claims about productivity. They are the artifacts.

Guardrails

Verified

§5.3

Five hooks. Two block, three verify or inject. Choosing between blocking and explaining is not a matter of style: it depends on whether the command is reversible.

Plugin hooks
HookEventModeWhat it prevents
block-vtex-critical.jsPreToolUsebloqueo duroimprime el comando para que lo corra yo
guard-faststore-commands.jsPreToolUseno bloquea, explicaen FastStore un push a main ES el deploy de producción
check-koru-boilerplate.jsSessionStartchequeocompara la app contra la versión del boilerplate
check-vtex-skills.jsSessionStartchequeoverifica que las skills oficiales estén en la versión fijada
inject-standards.jsSessionStartinyeccióncarga el flujo de Git/PR y las reglas de CSS del equipo
§5.4

block-vtex-critical stops them dead: vtex deploy, publish, release, promote, rollback, and on the GitHub side pr create, merge, review --approve and ready. It does not rewrite them or ask for confirmation — it prints the command for a person to run. Publishing a version of an app installed in someone else’s store is not an operation an agent should be able to trigger. guard-faststore-commands does the opposite, and it is the more interesting one: it does not block, it explains. In FastStore a git push to main IS the production deploy, and that is not obvious from reading the repository.

Inventory

Verified

§5.5

I wrote and maintain the private Claude Code marketplace for the agency’s VTEX team. My plugins carry methodology and guardrails. Platform knowledge is carried by VTEX’s official skills, pinned to a validated version.

Red-Clover-Consultoria/vtex-io-claude-marketplace
Plugins3
Skills propias13
Hooks5
Comandos2
Tests2
Líneas5.732
Commits57

The two-layer model is the decision that matters. VTEX’s official skills cover product knowledge: app contracts, builders, policies, GraphQL, Master Data. Mine cover what that documentation cannot, because it is not VTEX’s: the team’s Git and pull request flow, the CSS rules with the gotchas we already ran into, the design system check. The two layers coexist because every skill declares when it loads. The official ones are pinned to a validated version — a skill that updates itself is a skill that changes its mind without telling you.

§5.6

Two Claude Code accounts, one per client, and the shell picks which one based on the folder I am in. One client’s context must not be able to leak into another’s, and that is not solved by discipline — it is solved by configuration. Small client work starts with nothing loaded: no team conventions, no skills, no hooks, because a two-week project has no business inheriting the rules of an agency that does not touch it. The detail that makes it work in practice is rule order: one project sits physically among the small clients but is agency work, so it is evaluated first and gets the agency configuration.

~/.bashrc · rutas simplificadas
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
}
§5.7

Three levels of context, each answering a different question. The first defines WHO is working: one configuration per client, each with its own account. The second defines WHERE: every working area has a file declaring what it is, which account it runs under, and the default behaviour there — on the employer’s platform, read the backend repository before assuming an API contract; on small client work, start with nothing loaded. The third defines WHICH decisions have already been made in that particular project: 25 version-controlled files, one per repository. The rule that keeps them useful: if the team plugin already says it, the repo file does not repeat it. A fact stored in two places is a fact that will diverge.

When it fails

Verified

E-02

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.

E-01

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.

§5.9

Claude Code does not make me faster at writing code. It makes me faster at verifying. The cost moved: the slow part now is deciding what is true.

§5.10

What you keep when I am done: the repository, the dated decision log and the tests that cover it. You do not need to call me to understand it.