Claude Code Harness KPI Dashboard: Track Proof, Revenue, and Risk in One Sheet

Why this deserves its own artifact

This article builds a harness KPI dashboard for developers and content operators who already publish with Claude Code. The common failure is simple: pageviews rise but nobody can tell which article produced proof, a PDF signup, a Gumroad click, or a consultation visit. A good Claude Code workflow does not stop at a confident answer. It leaves an artifact that another person can inspect. In this case the artifact is one dashboard row per article with proof status, revenue action, and risk notes.

Treat the artifact as a contract between the prompt, the command line, and the public page. It should show what Claude Code read, what it changed, what command proved the result, and which revenue path the reader should see next. That is why this topic connects to harness engineering, getting started, and permissions.

The operating loop

Run the loop in five passes: define the action, choose the proof, let Claude Code do the smallest useful work, verify the output, then record the next revenue action. For this topic, the useful proof is not only “the code ran.” Watch PDF starts, Gumroad clicks, training-page visits, build proof, and unresolved risk flags. When those fields are visible, you can improve the article without guessing.

1. A harness article gets many visits from search but no PDF starts, so the next edit should move the free checklist closer to the first example.

2. A getting-started article gets PDF starts but no paid clicks, so the next CTA should explain when the Setup Guide becomes useful.

3. A permission article sends people to consultation, so the dashboard should keep the risk language visible instead of hiding it at the bottom.

Copy-paste starter

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

Three field examples

Example 1. A harness article gets many visits from search but no PDF starts, so the next edit should move the free checklist closer to the first example.

Example 2. A getting-started article gets PDF starts but no paid clicks, so the next CTA should explain when the Setup Guide becomes useful.

Example 3. A permission article sends people to consultation, so the dashboard should keep the risk language visible instead of hiding it at the bottom.

Self-review checklist

Before this workflow becomes a habit, review the article like a release note. The first check is scope: the reader should know exactly when to use a harness KPI dashboard and when a smaller checklist is enough. The second check is proof: every recommendation should point to a command, a URL, a diff, or a metric. The third check is routing: the free PDF, Gumroad guide, and consultation path should not compete with each other. They should answer different levels of urgency.

Use a small ownership rule. One person owns the artifact, one person owns verification, and one person owns the next CTA experiment. In a solo workflow those may be the same person, but the roles should still be named in the note. That naming prevents Claude Code from treating publishing, measuring, and selling as one blurry task. It also gives the next run a concrete place to continue.

The most practical review question is: what would make this article easier to verify tomorrow morning? If the answer is a saved screenshot, add it. If the answer is a stronger prompt, add it to the prompt pack. If the answer is a clearer boundary, add it to the setup notes. one dashboard row per article with proof status, revenue action, and risk notes is useful only when it survives the next session.

Failure cases

The first failure case is treating pageviews as the only score. The second is approving a change without a proof command. The third is sending every reader to the same paid product even when a free PDF or consultation is the better next step. The fix is to write the routing rule before the CTA is changed.

Revenue route

Route the reader by bottleneck. If they need command fluency, send them to the free PDF or the free Gumroad cheatsheet. If they repeat the same work weekly, send them to 50 Prompt Templates or Setup Guide. If the issue is rollout, risk, or revenue design, send them to consultation. For this article, Prompt Templates help standardize the review prompts, while the Setup Guide helps teams keep the harness rules stable.

Verification metrics

After publishing, do not only check HTTP 200. Confirm h1, canonical, hero image, opening body, CTA links, mobile layout, and language. Then watch PDF starts, Gumroad clicks, training-page visits, build proof, and unresolved risk flags. If the metric is flat, revise the CTA near the first concrete example before rewriting the whole article.