Guía de ClaudeNivel 3 · AutomatizarLevel 3 · Automating

Calidad sin burocraciaQuality without bureaucracy

Qué significa “terminado”, un registro de errores y una revisión semanal que corre sola.What “done” means, an error log and a weekly review that runs on its own.

Con 16 proyectos y Claude haciendo buena parte del trabajo, empezaron a escaparse errores: un apunte publicado con un dato viejo, rutas rotas después de una migración, un Estado que decía algo que no era cierto. Ninguno grave. Todos, sin embargo, del mismo tipo, porque nadie había definido cuándo algo estaba terminado ni qué hacer cuando no.

Armé un sistema de calidad mínimo, con tres archivos y una regla: si una pieza no se usa en un mes, se saca. Nada de burocracia.

1. Qué significa “terminado”

Una tabla corta, por tipo de entregable. Algunos ejemplos de la mía:

  • Texto firmado: pasó la skill de corrección, está en mi voz y lo aprobé yo.
  • Código: las pruebas en verde, el cambio con descripción, la versión en el CHANGELOG.md y su etiqueta.
  • Normativa y datos: cada dato tiene una fuente oficial con link y fecha, y un segundo paso lo verificó contra esa fuente.
  • Tarea programada: su resumen dice qué hizo, y no envió, publicó ni borró nada fuera de lo permitido.

Cada archivo de proyecto la nombra en una línea; no se copia.

2. Un registro de errores

Todo error que llega a un archivo, una tarea o un entregable se anota en una línea: fecha, proyecto, qué pasó, causa, corrección, qué cambia para que no se repita y si está abierto o cerrado. Los errores de redacción no van ahí, sino a la lista de errores frecuentes de mi hoja de estilo.

¿La columna que importa? La de “qué cambia”. De la migración de carpetas salieron tres reglas: los lotes que escriben van de a uno, los reemplazos con barras invertidas van por script y nunca por el shell, y antes de correr un script que escribe hay que leer cómo se usa.

La regla está en mi archivo general, así que Claude la sigue solo: cuando se equivoca, lo anota.

3. Riesgos y proveedores

Una página con lo que puede salir mal y qué hago si pasa: un borrado que se propaga entre computadoras, la PC servidor que se rompe, las tareas que necesitan la app abierta, el cupo de cada conector, la cuota semanal.

Lo que viene: la revisión de los miércoles

La parte que todavía estoy armando es la automática. Un script que no gasta tokens revisa que las rutas existan, que ningún Estado tenga más de un mes, qué pruebas fallan y cuándo fue el último backup; una tarea de los miércoles a la noche lo corre, escribe un borrador con un semáforo por proyecto y le pasa los números al newsletter del día siguiente.

El prompt

Armá un sistema de calidad mínimo para mis proyectos con las plantillas CRITERIOS.md y NO-CONFORMIDADES.md que te adjunto. Primero proponé los criterios de “terminado” para cada tipo de entregable que tengo. Después revisá mis archivos de contexto y skills: cuáles pasan los 3 KB, qué Estados tienen más de dos semanas, qué rutas no existen y qué instrucciones se repiten. Anotá como no conformidad cada error que encuentres, con su causa y una prevención. Proponé todo como diff y no guardes nada sin que lo apruebe.

With 16 projects and Claude doing a good part of the work, errors started slipping through: a note published with outdated data, broken paths after a migration, a Status that said something untrue. None serious. All of the same kind, though, because nobody had defined when something was done or what to do when it wasn't.

I built a minimal quality system, with three files and one rule: if a piece isn't used in a month, it goes. No bureaucracy.

1. What “done” means

A short table, by type of deliverable. A few examples from mine:

  • Signed text: it went through the proofreading skill, it's in my voice and I approved it.
  • Code: tests green, the change with a description, the version in the CHANGELOG.md and its tag.
  • Regulations and data: every data point has an official source with a link and a date, and a second pass checked it against that source.
  • Scheduled task: its summary says what it did, and it didn't send, publish or delete anything outside what's allowed.

Each project file names it in one line; it isn't copied.

2. An error log

Every error that reaches a file, a task or a deliverable gets written down in one line: date, project, what happened, cause, fix, what changes so it doesn't repeat and whether it's open or closed. Writing errors don't go there, but into the list of frequent errors in my style sheet.

The column that matters? The “what changes” one. Three rules came out of the folder migration: batches that write go one at a time, replacements with backslashes go through a script and never through the shell, and before running a script that writes you have to read how it's used.

The rule is in my general file, so Claude follows it on its own: when it makes a mistake, it writes it down.

3. Risks and providers

One page with what can go wrong and what I do if it happens: a deletion that propagates between computers, the server PC breaking, tasks that need the app open, each connector's allowance, the weekly quota.

What's coming: Wednesday's review

The part I'm still building is the automatic one. A script that spends no tokens checks that the paths exist, that no Status is more than a month old, which tests fail and when the last backup was; a task on Wednesday nights runs it, writes a draft with a traffic light per project and hands the numbers to the next day's newsletter.

The prompt

Build a minimal quality system for my projects with the CRITERIA.md and NONCONFORMITIES.md templates I'm attaching. First propose the “done” criteria for each type of deliverable I have. Then review my context files and skills: which ones go over 3 KB, which Statuses are more than two weeks old, which paths don't exist and which instructions repeat. Log every error you find as a nonconformity, with its cause and a prevention. Propose everything as a diff and don't save anything until I approve it.