Recibo de verificación para Claude Code: build, URL pública, CTA y capturas

Por qué hace falta un recibo de verificación

Claude Code puede corregir artículos, páginas de producto y enlaces con mucha rapidez. El riesgo no está en que edite archivos, sino en creer demasiado pronto que el cambio ya está listo para publicarse. Un diff razonable no demuestra que la URL pública esté actualizada. Un build local correcto no demuestra que el CTA apunte al producto adecuado. Una traducción puede estar en el archivo y, aun así, romper el botón en móvil por ser demasiado larga.

Llamo “recibo de verificación” a una nota breve de evidencia. Igual que un recibo permite reconstruir una compra, este recibo permite reconstruir una publicación: qué se cambió, por qué se cambió, qué comando se ejecutó, qué URL pública se abrió, qué CTA se revisó, qué capturas se guardaron y qué riesgo queda pendiente. Es una práctica pequeña, pero evita que el siguiente turno de trabajo dependa de memoria o de confianza.

Conviene usar este flujo junto con el triage de errores de build, la checklist de revisión y la checklist de permisos. Cada una cubre una parte diferente: fallos de compilación, revisión de cambios y límites de acceso para el agente.

Plantilla del recibo de verificación

Copia esta plantilla en el comentario final, en una PR o en el prompt de cierre para Claude Code. La regla es escribir hechos observables. “Parece bien” no sirve. “npm.cmd run build terminó”, “la página pública contiene el h1 esperado” y “el CTA abre Gumroad” sí sirven.

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

La línea “out of scope” evita que una mejora de artículo termine mezclada con cambios de navegación, dependencias o estilos globales. La línea “what should not change” protege slug, canonical, autor, fecha de publicación, enlaces de producto y rutas de consulta. En contenido público, romper cualquiera de esas piezas puede ser más caro que dejar un párrafo menos pulido.

Ejemplo concreto: build, URL pública, CTA y capturas

Empieza con una prueba local. Primero confirma que los archivos tocados son los esperados, luego revisa el tamaño del diff y ejecuta el build. En Windows, npm.cmd reduce sorpresas de resolución del comando.

git status --short
git diff --stat
cd site
npm.cmd run build

Después revisa la URL pública. No basta con HTTP 200, porque una página fallback también puede devolver 200. Comprueba cadenas específicas: h1, una frase del artículo y texto relacionado con el CTA o el producto.

const checks = [
  {
    url: "https://claudecode-lab.com/es/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Recibo de verificación", "Plantilla del recibo", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/es/training/",
    mustInclude: ["consulta"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

La revisión visual cierra el circuito. Las cadenas pueden estar presentes aunque el botón se vea mal, el bloque de código desborde o el texto traducido tape otro elemento. Si el proyecto tiene Playwright, guarda capturas de escritorio y móvil.

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/es/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop-es.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile-es.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

Al mirar las capturas, revisa la primera pantalla, el primer bloque de código, una sección central y el CTA final. Los artículos largos suelen fallar por espaciado, líneas demasiado largas o enlaces internos que quedan demasiado juntos en móvil.

Caso 1: ampliar un artículo demasiado fino

Cuando un artículo no supera una puerta de calidad, el objetivo no es inflarlo con frases repetidas. El objetivo es hacerlo útil. En este tema, el lector necesita una definición clara del recibo, una plantilla, comandos que pueda copiar, ejemplos de URL pública, una forma de revisar CTA y capturas, y fallos concretos que conviene evitar.

El recibo de esa mejora debe decir qué secciones se añadieron, qué enlaces internos se mantuvieron, qué enlaces externos se revisaron y qué código se puede ejecutar. También debe comprobar si la ruta comercial sigue siendo natural. Primero el PDF gratuito para crear hábito, luego Gumroad para plantillas y configuración, y finalmente consultoría cuando el lector necesita reglas de equipo.

Caso 2: cambiar un CTA o un enlace de producto

Un CTA parece pequeño, pero puede cambiar descargas, compras y solicitudes de consulta. No basta con ver que el enlace existe. El recibo debe incluir texto del botón, href, título de la página destino y acción esperada después del clic.

Para un PDF gratuito, revisa que la promesa sea clara y que la página de gracias o descarga tenga sentido. Para Gumroad, confirma nombre del producto, primera descripción y coherencia con el artículo. Para consultoría, verifica que el salto no parezca forzado. En un artículo sobre operaciones con Claude Code, la consultoría encaja cuando se habla de revisión, permisos, despliegue y rutas de ingresos en equipo.

Caso 3: publicar versiones multilingües

La localización necesita su propio recibo. El inglés puede caber en una línea, mientras que el español o el alemán ocupan más espacio. Una traducción literal de “verification receipt” puede sonar rara si no se explica como registro de evidencia. Cada idioma debe tener introducción natural, plantilla entendible, fallos reales y una ruta hacia recursos o consulta que no parezca pegada al final.

Las capturas son la forma más rápida de ver estos problemas. En móvil se notan botones demasiado largos, listas densas, bloques de código incómodos y CTAs que pierden contexto. Para contenido con ingresos, esos detalles no son cosméticos: afectan a la confianza del lector.

Fallos comunes y cómo evitarlos

El primer fallo es tratar HTTP 200 como publicación. Comprueba h1, canonical y texto propio de la página.

El segundo es detenerse en build exitoso. El build prueba que el código compila, no que el host público tenga la versión nueva.

El tercero es revisar solo la existencia del CTA. Hay que abrir el destino y confirmar que coincide con la promesa.

El cuarto es no guardar capturas. Sin capturas, la revisión visual se convierte en un recuerdo débil.

El quinto es pedir a Claude Code “verifica esto” sin darle formato. Dale la plantilla y exige comandos, URLs, CTAs, capturas y riesgos restantes.

De recursos gratuitos a Gumroad y consultoría

Si trabajas solo, empieza con el cheatsheet gratuito de Claude Code para fijar comandos y hábitos de verificación. Cuando repitas el mismo proceso varias veces, usa las plantillas de prompts y el Setup Guide para convertir CLAUDE.md, hooks y permisos en una rutina estable.

Si publicas artículos, landing pages o productos con un equipo, la verificación se vuelve una regla operativa. Hay que decidir quién mira la URL pública, dónde se guardan capturas, qué CTA se considera ruta de ingresos y qué fallos bloquean una publicación. Para eso, la consultoría es una continuación natural, no un añadido comercial.

• Cheatsheet gratuito de Claude Code
• 50 plantillas de prompts para Claude Code
• Claude Code Setup Guide
• Productos
• Consultoría

Qué verifiqué para este artículo

En este artículo separé la prueba local, la URL pública, el CTA y las capturas en una sola estructura de recibo. El resultado práctico es que la revisión deja de depender de una frase genérica y pasa a tener evidencias: build, página, enlaces de ingresos, visual móvil y riesgos restantes. Esa es la diferencia entre usar Claude Code rápido y publicar con control.