Dashboard KPI de harness Claude Code: prova, receita e risco em uma planilha

Por que criar um artefato próprio

Este artigo cria um dashboard KPI de harness para devs e operadores de conteúdo que já publicam com Claude Code. A falha comum é simples: as visualizações sobem, mas ninguém sabe qual artigo gerou prova, inscrição no PDF, clique Gumroad ou visita de consultoria. Um workflow com Claude Code não deve terminar em uma resposta confiante. Ele precisa deixar um artefato que outra pessoa consiga revisar. Aqui, o artefato é uma linha por artigo com status de prova, ação de receita e notas de risco.

Trate o artefato como contrato entre prompt, linha de comando e página pública. Ele mostra o que Claude Code leu, o que mudou, qual comando provou o resultado e qual rota de receita o leitor deve ver depois. Por isso o tema se conecta a harness engineering, getting started e permissions.

O loop operacional

Rode o loop em cinco passos: definir a ação, escolher a prova, deixar Claude Code fazer o menor trabalho útil, verificar a saída e registrar a próxima ação de receita. Aqui, prova útil não é só “o código rodou”. Observe inícios de PDF, cliques Gumroad, visitas a training, prova de build e riscos abertos. Com esses campos visíveis, a melhoria deixa de ser chute.

1. Um artigo de harness recebe busca mas pouco PDF; a próxima edição aproxima o checklist grátis do primeiro exemplo.

2. Um artigo iniciante gera PDF mas poucos cliques pagos; o CTA explica quando o Setup Guide fica útil.

3. Um artigo de permissões leva à consultoria; o texto de risco precisa continuar visível no meio.

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));
}

Três exemplos práticos

Exemplo 1. Um artigo de harness recebe busca mas pouco PDF; a próxima edição aproxima o checklist grátis do primeiro exemplo.

Exemplo 2. Um artigo iniciante gera PDF mas poucos cliques pagos; o CTA explica quando o Setup Guide fica útil.

Exemplo 3. Um artigo de permissões leva à consultoria; o texto de risco precisa continuar visível no meio.

Checklist de auto-revisão

Antes de transformar este workflow em hábito, revise o artigo como uma nota de release. O primeiro controle é escopo: o leitor precisa saber quando usar um dashboard KPI de harness e quando um checklist menor basta. O segundo controle é prova: cada recomendação deve apontar para comando, URL, diff ou métrica. O terceiro controle é routing: PDF grátis, guia Gumroad e consultoria não devem competir, mas responder a urgências diferentes.

Use uma regra pequena de ownership. Uma pessoa cuida do artefato, outra da verificação e outra do próximo experimento de CTA. Em operação solo pode ser a mesma pessoa, mas os papéis ainda devem aparecer na nota. Isso impede Claude Code de misturar publicação, medição e venda em uma tarefa vaga. A próxima execução também sabe de onde continuar.

A pergunta prática é: o que tornaria este artigo mais fácil de verificar amanhã cedo? Se for screenshot, salve. Se for um prompt melhor, coloque no prompt pack. Se for uma fronteira mais clara, registre nas notas de setup. uma linha por artigo com status de prova, ação de receita e notas de risco só é útil quando sobrevive à próxima sessão.

Falhas comuns

A primeira falha é usar pageviews como único score. A segunda é aprovar mudança sem comando de prova. A terceira é mandar todo leitor para o mesmo produto pago quando PDF grátis ou consultoria seria melhor. Escreva a regra de routing antes de mexer no CTA.

Rota de receita

Direcione pelo gargalo. Se falta fluência em comandos, envie para o PDF gratuito ou cheatsheet grátis no Gumroad. Se o trabalho se repete toda semana, use 50 Prompt Templates ou Setup Guide. Se o problema é rollout, risco ou receita, use consultoria. Neste artigo, Prompt Templates padroniza prompts de revisão, e Setup Guide estabiliza as regras do harness.

Métricas de verificação

Depois de publicar, HTTP 200 não basta. Confirme h1, canonical, hero image, abertura do texto, links CTA, mobile layout e idioma. Depois acompanhe inícios de PDF, cliques Gumroad, visitas a training, prova de build e riscos abertos. Se a métrica não mexer, ajuste o CTA perto do primeiro exemplo concreto.