Claude Code Harness Smoke Test: A 15-Minute Proof Loop Before You Trust an Agent

The first production-like Claude Code task does not need a large automation system. It needs a small smoke test. Name the files Claude may read, the files it may edit, the areas it must not touch, and the proof that ends the run.

The search intent is practical: a beginner or early intermediate user wants to know how far to trust an agent. On a revenue site, that proof must include the free PDF path, Gumroad path, and consultation path, not only a green local build.

Related reading: Claude Code harness engineering, first repo audit checklist, permission safety ladder.

Why this pattern works

A harness smoke test does not prove that the model is always safe. It proves that the working environment has boundaries. Even a small article edit can damage revenue if the PDF form, product link, or consultation link drifts.

Fifteen minutes is short enough to repeat daily. Instead of building a perfect CI system first, pass through read scope, limited edit, build, public URL, and screenshot proof.

The practical workflow

1. Write the goal in one sentence and limit editable files to three or fewer
2. Mark secrets, billing, customer data, and deploy settings as blocked areas
3. Choose the proof command, diff check, public URL, and screenshot target before editing
4. For articles and landing pages, add free PDF, Gumroad, and consultation CTA checks
5. Keep the run card so tomorrow’s agent work starts from evidence

Situation	Safe move	Proof
New article	Allow content and frontmatter only; keep layouts and APIs read-only	build plus public URL
Product page	Change copy and card order only; verify every checkout URL	Gumroad link check
Team rollout	Begin read-only, then allow one low-risk edit	diff and screenshot

Copy-paste prompt and code

Run a 15-minute harness smoke test for this repository. Do not make a broad edit yet. Return the goal, editable files, blocked areas, proof commands, public URL checks, and free PDF/Gumroad/consultation CTA checks.

const runCard = {
  slug: "claude-code-harness-smoke-test-loop",
  goal: "publish one safe content change",
  allowedFiles: ["site/src/content/blog-en/example.mdx"],
  blockedAreas: [".env", "billing/", "cloudflare/"],
  proof: ["npm.cmd run build", "public URL screenshot"],
  ctas: ["free PDF", "Setup Guide", "consultation"]
};

function readyForAgent(card) {
  return card.allowedFiles.length > 0 &&
    card.blockedAreas.length > 0 &&
    card.proof.some((item) => item.includes("build")) &&
    card.ctas.length >= 3;
}

console.log(readyForAgent(runCard) ? "ready" : "tighten scope");

The code turns a vague agent request into a run card. Use the same shape in PR templates, publishing checklists, or consultation prep notes.

Three real examples

Astro article publishing

Limit the edit to body, heroImage, and CTA. A green build is not enough if the production h1 or CTA belongs to another page.

Small UI change

For a button copy change, check mobile wrapping and tap area. If the button leads to a product, verify the product URL in the same pass.

First team adoption call

Do not begin by writing code. Map README, permissions, tests, and blocked areas. That artifact becomes the agenda for consultation.

Failure cases to avoid

• Asking Claude Code to improve everything makes scope explode.
• Stopping at a local build misses production fallback pages and stale CTAs.
• Skipping Gumroad checks can send beginner traffic to the wrong paid offer.

Multilingual publishing adds one more risk: the slug can match while the body and CTA are stale. Check the public page, not only the frontmatter.

How to route readers to PDF, Gumroad, and consultation

Readers who need command fluency should start with the free cheatsheet. Readers blocked by permissions, CLAUDE.md, hooks, MCP, or CI should use the Setup Guide.

Readers who repeat review and debugging prompts should use 50 Prompt Templates. Teams that need rollout design should use consultation. Readers comparing options can start at products.

What to verify before and after publishing

Before publishing, verify frontmatter, heroImage, internal links, and Gumroad links. After publishing, use mobile width to inspect h1, opening body, and CTA area. A 200 response is not enough if it is a fallback page.

Metrics to watch next

Watch search traffic, PDF starts, Gumroad clicks, product-page visits, and training-page visits for this slug. If pageviews rise without product clicks, the CTA stage is wrong.

A 30-minute operations review

When you put the harness smoke test into real work, the most useful review happens the next day. Read the run log and write down the allowed scope, the files that changed, the proof commands, and the public pages that were inspected. Avoid vague notes such as “checked the page.” Write the exact receipt: mobile h1, opening paragraph, CTA area, Gumroad link, and consultation path.

Then separate worker confidence from reader behavior. Worker confidence means blocked areas were not touched, build proof exists, the public URL is the same slug, and translated pages are not silently using English body text. Reader behavior means the article gives a clear next step after the point of need: free PDF for command fluency, Gumroad when the reader has a repeatable bottleneck, and consultation when the issue is workflow design.

Finally, turn the review into one future rule. Do not add ten rules after every problem. Add one rule that would have prevented the mistake: ask before editing a layout, click every Gumroad URL on production, or screenshot the opening body for each locale. Small rules that survive daily use are stronger than a long policy nobody reads.