Claude Code sin dudar al aprobar: registro de decisiones read/edit/run/deploy

Un viernes por la tarde le pedí a Claude Code algo simple: “arregla solo los enlaces de esta página”. Lo que me devolvió fue una pantalla llena de mensajes de confirmación. Me preguntó “¿quieres ejecutar este comando?” y, agotado, pulsé Enter sin leer apenas lo que decía.

A la mañana siguiente, el precio mostrado en la web de producción había cambiado. De paso con los enlaces, la IA había “aprovechado” para tocar también otro archivo donde estaban escritos los precios. Y el que pulsó el botón de aprobar fui yo, sin ninguna duda.

El problema no era lo lista que es la IA. Era que la línea entre lo que aprobé ayer y lo que debería frenar hoy vivía solo dentro de mi cabeza y cambiaba cada vez. Si tu “bueno, da igual” depende del humor del día, el accidente es solo cuestión de tiempo. Hoy te cuento cómo sacar esa línea de tu cabeza con un “registro de aprobaciones”.

Puntos clave

• En Claude Code, separa las aprobaciones en “leer, editar, ejecutar y publicar” y la duda desaparece.
• Clasifica cada acción en “permitir, confirmar o prohibir”, y anota a diario en un solo archivo el motivo y el comando de comprobación.
• Deja a la IA la investigación y los borradores; reserva para ti cuatro cosas: precios, publicación en producción y borrado.
• Te dejo una plantilla de registro lista para copiar y un prompt para que la IA borre el primer reparto.
• Si dudas, no lo pongas en “permitir”. Solo con esto, los “accidentes de paso” casi desaparecieron.

Divide la aprobación en “leer, editar, ejecutar y publicar”

Cuando usas Claude Code, te llegan confirmaciones de todo tipo. Lo agotador es que las metes todas en el mismo saco de “¿sí o no?”. Si las repartes en cuatro tipos, la decisión se vuelve mucho más ligera.

• Leer: solo mirar el contenido de archivos o registros. Por norma general, permitir no da problemas.
• Editar: cambiar un archivo. Una errata de un artículo es algo trivial. La tabla de precios es otra cosa.
• Ejecutar: lanzar un comando. Comprobar que algo funciona es trivial; lo que afecta al exterior, con cuidado.
• Publicar: reflejar el cambio en la web de producción. Esto siempre lo trato como el último muro de contención.

Dentro de un mismo “editar”, una errata en el cuerpo de un blog y el archivo de configuración de pagos pesan de forma completamente distinta. Por eso decidí fijar no solo el tipo de acción, sino también “de qué archivo se trata”.

Reparte la decisión en tres niveles

Una vez divididas en cuatro tipos, reparte cada una en tres niveles. No hacen falta palabras difíciles.

Nivel	Significado	Ejemplo
Permitir	Puede seguir sin avisar	Leer la carpeta de artículos, corregir una errata del cuerpo
Confirmar	Pregúntame una vez	Editar el archivo de precios, publicar en producción
Prohibir	Esta vez no se hace	Borrado masivo de archivos, sobrescritura forzada

El truco es uno solo. Si dudas aunque sea un poco, no lo metas en “permitir”. De momento, déjalo en “confirmar”. Más adelante, cuando confirmes que “esto es seguro siempre”, lo asciendes a “permitir”. Al principio sujetas todas las riendas y solo aflojas las de lo que has comprobado que es seguro. Con solo respetar este orden, deja de pasar lo del accidente de precios del principio.

Anota a diario en un solo archivo: la plantilla del registro

Si intentas recordarlo de memoria, te derrumbas. Un archivo al día, donde solo escribes el reparto de ese día. El formato da igual, pero yo acabé usando este. Cópialo y úsalo tal cual.

{
  "date": "2026-06-07",
  "alcance": "solo cambiar el cuerpo del artículo y el enlace de llamada a la accion",
  "leer":     { "permitir": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "editar":   { "permitir": ["archivos de articulo nuevos"], "confirmar": ["precios", "configuracion de pagos", "secretos de produccion"] },
  "ejecutar": { "permitir": ["npm run build", "comprobacion visual de la URL publica"], "confirmar": ["publicar", "git push"] },
  "publicar": { "confirmar_hasta": ["el build pasa", "el h1 de la URL publica es correcto", "revision visual de cada idioma"] },
  "nota_siguiente": "Los precios siguen en confirmar. El cambio de enlace del articulo pasa a permitir tras verificar seguridad."
}

Escribirlo lleva dos o tres minutos. Pero esos dos o tres minutos te ahorran los diez minutos del día siguiente dándole vueltas a “¿qué hice ayer con esto?”. La línea de alcance rinde más de lo que parece. Si escribes de antemano hasta dónde llega el trabajo de hoy, te das cuenta en el instante en que la IA se sale de ese límite.

Qué dejar a la IA y qué decides tú

Si mezclas esto, hay accidente. Conviene dejar la línea bien clara.

Lo que puedes dejar a la IA

• Buscar qué archivos podrían estar implicados.
• Crear el borrador de los cambios.
• Mostrar la diferencia antes y después del cambio.
• Lanzar el comando que comprueba si “el build pasa”.

Lo que siempre decides tú

• Cualquier cambio que toque precios, pagos o el formulario de inscripción.
• La publicación en la web de producción (el botón de publicar lo pulsas tú).
• El borrado de archivos o datos.
• Cualquier trabajo cuya marcha atrás no sepas explicar.

Mi regla es simple: cuando entran en juego “dinero”, “producción”, “borrar” o “irreversible”, la decisión final la tomo siempre con mi propia mano. Dicho al revés, la investigación previa y los borradores se los paso a la IA sin reparos. Esta forma de trazar la línea también la comento en la introducción a Claude Code para quienes no son ingenieros, pero aunque no tengas conocimientos técnicos, basta con decidir que “el dinero y la producción son míos” para protegerte de sobra.

Un prompt para que la IA borre el reparto

También puedes pedirle a la IA que te ayude con el reparto en sí. Eso sí, no te tragues el resultado tal cual: al final lo revisas tú. Puedes pegar este texto de instrucción tal cual.

Sobre el trabajo de hoy con Claude Code, reparte las acciones en "permitir, confirmar y prohibir".
Los tipos a considerar son cuatro: leer / editar / ejecutar / publicar.

Para cada apartado, devuelve lo siguiente:
1. Lista de acciones que se pueden permitir.
2. Lista de acciones que conviene confirmar una vez.
3. Lista de acciones prohibidas esta vez.
4. Comando de comprobacion para verificar la seguridad (ej: npm run build).
5. Nota para la proxima vez (condicion para subir de confirmar a permitir).

Cualquier accion que afecte a precios, pagos, publicacion en produccion o borrado, ante la duda metela en "confirmar".

La clave está en la última línea. Si la incluyes, evitas que la IA, por su cuenta, decida que “esto se puede permitir” y afloje el criterio. Si quieres pulir más la forma de escribir tus prompts, échale un vistazo también al diseño de prompts en Claude Code.

Dónde se nota de verdad (tres casos)

1. Cambiar el enlace de un artículo del blog Quieres sustituir un solo enlace de inscripción que aparece bajo un artículo popular. Si en esos casos pides “arregla lo que parezca relacionado”, el alcance se vuelve demasiado amplio. Anota antes en el registro “qué archivos puedo tocar”, “qué archivos no toco” y “qué URL pública compruebo”. Así, la revisión posterior pasa de “parece que está bien” a “con esta prueba puedo publicar”.

2. Clasificar las consultas que llegan Haces que la IA lea las consultas entrantes y te diga solo las que parecen tener potencial. Leer puede quedarse en “permitir”. Pero el registro en la lista de clientes lo dejas en “confirmar”. Aunque la IA se equivoque al clasificar, se detiene antes de escribir por su cuenta en los datos de producción.

3. Revisión previa a publicar artículos multilingües Aunque la configuración de idioma del frontmatter sea correcta, a veces el cuerpo se queda en inglés. Revisa en cada idioma el titular, la entradilla y los enlaces de acción, y comprueba que el lector de ese idioma entiende cuál es su siguiente paso. Fija esta revisión visual como un punto del “hasta confirmar antes de publicar” en el registro.

Listo para copiar: script de comprobación del registro

Aunque escribas el registro, si te saltas lo importante (la comprobación previa a publicar), no sirve de nada. Por eso conviene dejar en un único script la comprobación que pasas siempre antes de publicar. Es un ejemplo que hace que la máquina verifique si el build pasa y si el titular de la URL de producción es correcto. Funciona con tener Node.js.

node check-before-deploy.mjs https://claudecode-lab.com/es/blog/claude-code-permission-decision-log/

El contenido es solo esto.

import { execSync } from "node:child_process";

// Comprueba la URL publica pasada como argumento
const url = process.argv[2];
if (!url) {
  console.error("Pasa la URL publica que quieres comprobar");
  process.exit(1);
}

// 1. Verifica que el build pasa (si falla aqui, no se publica)
try {
  console.log("Comprobando el build...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("El build ha fallado. Se detiene la publicacion.");
  process.exit(1);
}

// 2. Comprueba que la URL publica tiene un solo titular h1
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`No se puede abrir la URL (codigo de estado: ${res.status}). Hay que revisar la publicacion.`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`Hay ${h1Count} titulares h1. Deja solo uno antes de publicar.`);
  process.exit(1);
}

console.log("Build, URL y titular comprobados. Se puede publicar sin problema.");

Solo cuando este script se pone en verde se permite “publicar”. Dicho al revés, lo que no se pone en verde no se publica pase lo que pase. El truco es confiar la decisión al sí o no de la máquina, y no al humor de la persona.

Errores típicos y cómo corregirlos

Te lo digo con honestidad: yo los cometí todos.

Cambiar solo la configuración sin escribir el motivo. Si actualizas solo el archivo de configuración y no dejas constancia de “por qué lo hiciste”, al día siguiente tú mismo repites la misma duda. La solución es simple: escribe una sola línea con el motivo en la “nota para la próxima vez” del registro. Algo como “los precios se quedan en confirmar porque van directos a la confianza”.

Permitir la publicación por inercia. Con el impulso de que el build ha pasado, acabas permitiendo de paso hasta la publicación. Pero la comprobación previa a publicar es otra cosa. Fija en el “hasta confirmar” los puntos que revisas (titular de la URL de producción, maquetación rota, vista en móvil) y no publiques hasta pasar la comprobación de la máquina.

Tratar igual el trabajo ligero y el pesado. Si gestionas con el mismo “permitir” la corrección de una errata del cuerpo y el cambio de un enlace de inscripción o de un precio, algún día ocurre el accidente del principio. El trabajo que toca enlaces de gumroad, precios o formularios va en un estante distinto al de las erratas. Si dejas esta línea escrita como regla en cómo escribir tu CLAUDE.md, te ahorras pensarlo cada vez.

Preguntas frecuentes

P. ¿En qué se diferencia el registro de aprobaciones de la configuración de seguridad? R. La configuración de seguridad fija “qué se permite”; el registro de aprobaciones deja constancia de “por qué tomaste hoy esa decisión”. La configuración es la regla; el registro se parece más a un diario. Con los dos, tú mismo al día siguiente o tu equipo pueden reproducir la misma decisión.

P. Escribirlo a diario es pesado. ¿Algún truco para mantenerlo? R. No buscar la perfección. Al principio, con solo las dos columnas de “editar” y “publicar” ya rinde de sobra. Déjalo en un formato que se escriba en dos o tres minutos y conviértelo en la primera entrada que pegas antes de empezar a trabajar; así se mantiene.

P. ¿Me puedo fiar del reparto que propone la IA? R. Como borrador es cómodo, pero la decisión final la toma la persona. Sobre todo en las líneas que tocan precios, producción o borrado, aunque la IA diga “esto puede ir en permitir”, bájalo tú a confirmar. El objetivo es reducir el esfuerzo de decidir, no es una herramienta para delegar la decisión en sí.

P. ¿A qué hay que prestar atención al usarlo en equipo? R. Reúne el registro en un solo sitio y, para las acciones que metes en “permitir”, escribe un motivo que lleve a cualquiera a la misma decisión. Un permiso sin motivo se interpreta de forma distinta según la persona y es origen de accidentes. Para ampliar las aprobaciones de forma gradual, también te sirve la escalera para subir la autonomía con seguridad.

P. ¿Hace falta llegar hasta aquí en un blog pequeño? R. Cuanto más pequeña es la escala, más directamente repercuten en las ventas los accidentes de precios o de enlaces. Precisamente las personas o los equipos pequeños tienen mucho que ganar empezando por una sola regla: “el dinero y la producción solo en confirmar”.

Enlaces de referencia

• Guía de permisos de Claude Code
• Guía para empezar con Claude Code
• Documentación oficial de Anthropic: Claude Code settings

Lo que comprobé al probarlo de verdad

Después de mantener este registro de aprobaciones unas dos semanas, lo que más me sirvió fue, sorprendentemente, el “trabajo ligero”. Las erratas del cuerpo las puedo dejar en permitir con tranquilidad; los precios, los enlaces, el formulario de inscripción y la configuración de publicación se quedan en confirmar. Con solo escribir esta distinción de antemano, desapareció el esfuerzo de tener que replantearme cada vez, tras leer la respuesta de la IA, “¿este trabajo era de los que puedo permitir?”.

Donde más dudas me surgían era, como era de esperar, en “ejecutar” y “publicar”. El build lo puedo permitir, pero publicar sin haber comprobado la URL de producción todavía es pronto. Una vez que verifiqué con mis ojos el titular, la maquetación y la vista en móvil, pude subir a permitir las publicaciones del mismo tipo a partir de entonces. Como los niveles van quedando registrados de este modo, mi sensación actual es que lo más realista es usar el registro de aprobaciones no como un documento de seguridad rígido, sino como una nota para aligerar las decisiones de cada día.

Si quieres ordenar la línea de los permisos para tu propio equipo, o pulir conmigo las reglas de publicación en producción, en formación y consultoría podemos bajarlo a una operativa concreta.