HTML como output de Claude Code: prompts, checklist y galería

Thariq Shihipar, del equipo de Claude Code en Anthropic (y validado por Karpathy), recomienda dejar de pedir markdown como output y pedir HTML directamente. Specs, planes, code reviews, reports: todo se lee mejor en un archivo HTML que en un wall of markdown. Cuesta un poco más de tokens y de tiempo, pero la calidad del output sube tanto que merece la pena casi siempre.

Aquí tienes los 5 prompts que necesitas para empezar, el checklist de cuándo usarlo (y cuándo no), una galería curada de demos y un design-system mínimo para que todos tus HTMLs salgan con el mismo aspecto.

5 prompts copiables

Adaptados de los ejemplos de Thariq. Pégalos en Claude Code, sustituye lo que va entre <…> y dale.

1. Plan de implementación con mockups y data flow

Genera un único archivo HTML autónomo que sirva como plan de implementación
para <feature>. Tiene que incluir:

- Timeline con los milestones (boxes horizontales con dependencias).
- Diagrama del data flow entre componentes (SVG inline, no imágenes).
- 2-3 mockups de las pantallas clave (HTML/CSS, sin frameworks).
- Tabla de riesgos: riesgo, probabilidad, mitigación.
- Snippets de código de las funciones críticas, con resaltado de sintaxis.

Estilo: dark mode, tipografía sans, paleta sobria. Un solo archivo
.html sin dependencias externas.

Mejor que cualquier PLAN.md de 400 líneas. Lo abres en el navegador, lo lees de un tirón y lo compartes con un link.

2. Code review de un PR con anotaciones

Lee el diff de <branch> contra main y genera un archivo HTML con el
code review. Estructura:

- Header: título del PR, autor, ficheros tocados, líneas +/-.
- Por cada hunk relevante: el código en mono, con anotaciones al margen.
- Severidad por color: rojo (bug/blocker), amarillo (mejora), gris (nit).
- Jump-links a cada comentario desde un índice arriba.
- Sección final: 3 cosas que cambiaría antes de mergear.

Un solo archivo HTML. Sin dependencias externas.

El reviewer abre el HTML, ve el diff con tus comentarios al margen y sabe en 30 segundos qué bloquea el merge. Markdown te obliga a citar líneas y romper el flujo visual.

3. Explainer de feature con SVG y flowchart

Explica cómo funciona <sistema> en un único archivo HTML pensado para
onboarding de un dev nuevo. Incluye:

- TL;DR en una caja arriba (3 líneas máximo).
- Flowchart del happy path con SVG inline.
- Tabs con: request payload, response payload, errores comunes.
- Sección "gotchas" con los 3-5 fallos que más se cometen.
- Glosario lateral con los términos clave.

Estilo: dark mode, fuente sans, paleta sobria. Sin librerías externas.

Lo que antes era una página de Notion abandonada ahora es un HTML que se lee en 2 minutos y se comparte por Slack con un link.

4. Editor desechable para triage o reordenación

Necesito reorganizar <lista de items>. Genera un archivo HTML standalone
con:

- Cada item como tarjeta arrastrable.
- 4 columnas: Ahora, Siguiente, Después, Cortar.
- Drag and drop nativo (HTML5, sin librerías).
- Botón "Copy as markdown" arriba a la derecha que copia el estado
  actual al portapapeles en formato lista markdown agrupada por columna.

Datos iniciales precargados desde la lista que te he pasado.

El patrón clave de Thariq: siempre acabar con un export. Tú arrastras visualmente y devuelves el resultado al prompt sin escribir nada a mano.

5. Comparativa de 6 opciones visuales en grid

Estoy decidiendo <decisión de diseño>. Genera un archivo HTML con 6
variantes lado a lado en un grid 3x2. Cada variante:

- Renderizada en vivo (no imagen, HTML real).
- Etiqueta con el nombre de la variante.
- Lista corta de pros y contras debajo.
- Borde de color distinto para identificarla a simple vista.

Estilo coherente entre las 6 para que la comparación sea justa.
Un solo archivo HTML.

Tres bloques de markdown describiendo opciones no se comparan. Seis renders en un grid sí.

Cuándo HTML, cuándo markdown

Decisión rápida. No es dogma — es coste-beneficio.

Usa HTML cuando:

• El output supera 100 líneas y vas a leerlo entero.
• Hay información espacial (diffs, diagramas, flowcharts, comparativas lado a lado).
• Lo vas a compartir con alguien que no abre tu repo (PM, diseñador, cliente).
• Necesitas interacción (sliders, drag-and-drop, toggles para explorar).
• El artifact es desechable de un solo uso (editor de triage, prompt tuner).

Quédate en markdown cuando:

• Son <50 líneas y se leen de una vez.
• El output va a vivir dentro del repo y se va a editar a mano (READMEs, docs versionados).
• El diff en git importa más que la lectura — markdown diffea limpio, HTML genera ruido.
• Estás haciendo iteración rápida y cada segundo cuenta — HTML tarda 2-4× más en generar.

La regla práctica: si lo vas a leer entero o lo vas a compartir por link, HTML. Si lo vas a editar a mano o commitear, markdown.

Galería curada (5 demos que merece la pena ver)

La galería completa de Thariq tiene 20 demos. Estos son los 5 que más rentan para devs hispanohablantes:

• 16-implementation-plan — Plan de implementación con timeline, data flow y mockups. La plantilla mental para sustituir tus PLAN.md.
• 03-code-review-pr — Code review con anotaciones al margen y severidad por color. El demo que más te va a vender la idea.
• 18-editor-triage-board — Editor de triage drag-and-drop con export a markdown. El mejor ejemplo del patrón “editor desechable”.
• 14-research-feature-explainer — Explainer de rate limiting con tabs, snippets y FAQ. Plantilla directa para onboarding de devs.
• 09-slide-deck — Slide deck en un solo HTML, navegable con flechas. Si haces decks técnicos, esto sustituye a Keynote.

Design-system mínimo

Thariq lo recomienda en el ensayo: si quieres que tus HTMLs salgan consistentes, dale a Claude un archivo de referencia con tu paleta y tipografía. Este es uno mínimo que puedes pegar como design-system.html en tu repo y referenciar desde los prompts con “usa los tokens de design-system.html”:

<!doctype html>
<html lang="es">
<head>
  <meta charset="utf-8">
  <title>Design system base</title>
  <style>
    :root {
      --bg: #0b0b0c;
      --surface: #151517;
      --border: #2a2a2e;
      --text: #ededed;
      --text-dim: #9a9aa0;
      --accent: #7c9cff;
      --ok: #6bcf7f;
      --warn: #ffcc66;
      --bad: #ff6b6b;
      --radius: 10px;
      --font-sans: ui-sans-serif, system-ui, -apple-system, "Inter", sans-serif;
      --font-mono: ui-monospace, "JetBrains Mono", Menlo, monospace;
    }
    html, body { background: var(--bg); color: var(--text); font-family: var(--font-sans); margin: 0; padding: 2rem; line-height: 1.55; }
    h1, h2, h3 { color: var(--text); font-weight: 600; }
    code, pre { font-family: var(--font-mono); background: var(--surface); border: 1px solid var(--border); border-radius: 6px; padding: 0.15rem 0.4rem; }
    pre { padding: 1rem; overflow-x: auto; }
    .card { background: var(--surface); border: 1px solid var(--border); border-radius: var(--radius); padding: 1.25rem; }
  </style>
</head>
<body>
  <!-- Referencia: paleta, tipografía y card base. Reutilizar variables en todos los HTMLs generados. -->
</body>
</html>

Con esto Claude no se inventa una paleta distinta en cada artifact: todos tus HTMLs tienen el mismo dark mode, la misma tipografía y la misma card base. Cinco minutos de setup, consistencia visual para los próximos 200 outputs.

La regla de oro

Si vas a leerlo entero o compartirlo por link, pídelo en HTML. El extra de tokens lo recuperas en que de verdad lo lees — y eso es la diferencia entre que tu spec sirva para algo o muera en el repo.

---

Sígueme para más trucos con Claude Code e IA → @pabloinpublic

Waitlist de la comunidad → pabloinpublic.com