Dashboard KPI para harness de Claude Code: prueba, ingresos y riesgo en una hoja

Por qué merece su propio artefacto

Este artículo construye un dashboard KPI de harness para desarrolladores y operadores de contenido que ya publican con Claude Code. El fallo común es simple: suben las visitas pero nadie sabe qué artículo generó prueba, registro PDF, clic de Gumroad o visita de consultoría. Un workflow con Claude Code no termina con una respuesta segura. Debe dejar un artefacto que otra persona pueda revisar. En este caso el artefacto es una fila por artículo con estado de prueba, acción de ingresos y notas de riesgo.

Trata el artefacto como contrato entre prompt, línea de comandos y página pública. Debe mostrar qué leyó Claude Code, qué cambió, qué comando probó el resultado y qué ruta de ingresos verá después el lector. Por eso conecta con harness engineering, getting started y permissions.

El loop operativo

Ejecuta el loop en cinco pasadas: definir la acción, elegir la prueba, dejar que Claude Code haga el trabajo mínimo útil, verificar la salida y registrar la siguiente acción de ingresos. Aquí la prueba útil no es solo que el código corra. Mira inicios de PDF, clics Gumroad, visitas a training, prueba de build y riesgos abiertos. Con esos campos visibles puedes mejorar sin adivinar.

1. Un artículo de harness recibe búsquedas pero pocos PDF; la siguiente edición acerca el checklist gratis al primer ejemplo.

2. Un artículo de inicio logra registros PDF pero pocos clics de pago; el CTA explica cuándo conviene el Setup Guide.

3. Un artículo de permisos envía gente a consultoría; la tabla mantiene visible el lenguaje de riesgo.

Starter para copiar

const rows = [
  { slug: "claude-code-harness-engineering", sessions: 1882, pdfStarts: 42, gumroadClicks: 9, consultationVisits: 3, riskFlags: 1 },
  { slug: "claude-code-getting-started-complete", sessions: 760, pdfStarts: 28, gumroadClicks: 6, consultationVisits: 1, riskFlags: 0 },
];

function revenueSignal(row) {
  return row.pdfStarts * 1 + row.gumroadClicks * 4 + row.consultationVisits * 9 - row.riskFlags * 3;
}

for (const row of rows) {
  console.log(row.slug, revenueSignal(row));
}

Tres ejemplos reales

Ejemplo 1. Un artículo de harness recibe búsquedas pero pocos PDF; la siguiente edición acerca el checklist gratis al primer ejemplo.

Ejemplo 2. Un artículo de inicio logra registros PDF pero pocos clics de pago; el CTA explica cuándo conviene el Setup Guide.

Ejemplo 3. Un artículo de permisos envía gente a consultoría; la tabla mantiene visible el lenguaje de riesgo.

Checklist de auto-revisión

Antes de convertir este workflow en hábito, revisa el artículo como si fuera una nota de release. El primer control es el alcance: el lector debe saber cuándo usar un dashboard KPI de harness y cuándo basta un checklist más pequeño. El segundo control es la prueba: cada recomendación debe apuntar a un comando, una URL, un diff o una métrica. El tercer control es el routing: el PDF gratuito, la guía de Gumroad y la consultoría no deben competir, sino responder a distintos niveles de urgencia.

Añade una regla pequeña de ownership. Una persona es dueña del artefacto, otra de la verificación y otra del siguiente experimento de CTA. En un flujo individual pueden ser la misma persona, pero los roles deben quedar escritos. Eso evita que Claude Code mezcle publicación, medición y venta en una sola tarea borrosa. También permite que la siguiente ejecución continúe desde un punto concreto.

La pregunta práctica es: ¿qué haría este artículo más fácil de verificar mañana por la mañana? Si la respuesta es una captura, guárdala. Si es un prompt más fuerte, súbelo al prompt pack. Si es un límite más claro, añádelo a las notas de setup. una fila por artículo con estado de prueba, acción de ingresos y notas de riesgo solo sirve cuando sobrevive a la siguiente sesión.

Fallos comunes

El primer fallo es tratar las páginas vistas como único score. El segundo es aprobar cambios sin comando de prueba. El tercero es enviar a todos los lectores al mismo producto pagado aunque un PDF gratuito o una consulta encaje mejor. Escribe la regla de routing antes de tocar el CTA.

Ruta de ingresos

Rutea por cuello de botella. Si falta fluidez de comandos, manda al PDF gratuito o al cheatsheet gratuito en Gumroad. Si repiten el mismo trabajo cada semana, usa 50 Prompt Templates o Setup Guide. Si el problema es rollout, riesgo o diseño de ingresos, usa consultoría. En este artículo, Prompt Templates ayuda a estandarizar prompts de revisión y Setup Guide fija reglas del harness.

Métricas de verificación

Después de publicar, no basta HTTP 200. Confirma h1, canonical, hero image, inicio del cuerpo, enlaces CTA, mobile layout e idioma. Luego mira inicios de PDF, clics Gumroad, visitas a training, prueba de build y riesgos abiertos. Si la métrica no se mueve, revisa el CTA cerca del primer ejemplo concreto antes de reescribir todo.