Claude Code Verification Receipt: Prove AI Changes With Build, Public URL, CTA, and Screenshots

Why a verification receipt matters

Claude Code can make useful changes very quickly, but the risky moment is the point where a plausible diff starts to feel like a finished job. For a public article, product page, or consultation landing page, a local patch is only one signal. A build can pass while the deployed URL is still stale. A link can exist while the CTA points to the wrong product. A translated paragraph can be present while the mobile layout cuts the button in half. The verification receipt exists to slow down only the dangerous part of the workflow: the jump from “it looks changed” to “it is safe to publish.”

A verification receipt is a short evidence note. It records what changed, which proof command ran, which public URL was opened, which CTA or revenue path was checked, which screenshots were inspected, and what risk remains. It is not bureaucracy. It is the minimum audit trail that lets tomorrow’s session continue without guessing. When the next edit breaks the same area, you can compare receipts instead of reconstructing memory from chat logs.

This workflow pairs well with build error triage, the review workflow checklist, and the permission audit checklist. Build triage helps when the proof command fails. Review checklists help when the diff is broad. Permission audits help when the agent asks for more access than the task needs.

Verification receipt template

Copy this template into the final review prompt, a pull request comment, or a release note. The important rule is to write observations, not confidence. “Looks good” is not evidence. “npm.cmd run build completed”, “the public h1 contains the expected title”, and “the Gumroad CTA resolves to the product page” are evidence.

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

The “out of scope” line is more useful than it first appears. Claude Code is good at following momentum, so a focused article edit can accidentally grow into a navigation cleanup, a package update, or a copy rewrite in another locale. The receipt makes the boundary explicit. The “what should not change” line protects slugs, canonical URLs, author metadata, product links, and publication dates. Those are easy to disturb when the visible task is only “make this article less thin.”

Build, public URL, CTA, and screenshot checks

Start with the local proof. On Windows, npm.cmd avoids a few shell-resolution surprises. The first two commands show whether the change set is still limited to the files you intended to edit. The build is the minimum proof that the MDX, imports, code fences, and content schema still parse.

git status --short
git diff --stat
cd site
npm.cmd run build

The public URL check should not stop at HTTP 200. Static hosts and app routers can return a fallback page with a successful status. Check for page-specific strings: the exact h1, a body phrase unique to the article, and the CTA text or product name. This small Node script is enough for a daily receipt.

const checks = [
  {
    url: "https://claudecode-lab.com/en/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Claude Code Verification Receipt", "Verification receipt template", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/en/training/",
    mustInclude: ["Consultation"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

Text checks still miss layout problems. A receipt for a revenue page should include screenshots, especially at mobile width. If Playwright is already available in the project, save one desktop capture and one mobile capture in a temporary verification folder.

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/en/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

When you inspect the screenshots, look at the first viewport, the first code block, the middle of the article, and the final CTA area. Thin articles often fail on substance. Expanded articles often fail on spacing, long translated strings, and code blocks that push the layout sideways. The screenshot line in the receipt forces the review to include the actual page, not only the source file.

Use case 1: expanding a thin article

When you ask Claude Code to strengthen a thin article, the receipt should prove more than length. Length is only the gate that prevents a shallow summary. The stronger proof is that the article now answers a real search intent, gives copy-pasteable commands, names concrete failure modes, and guides the reader toward a next step without turning the article into a sales page.

For this workflow article, the practical target is clear. A reader should leave with a receipt template, a build command, a public URL check, a CTA check, and a screenshot habit. If the article only says “verify your work”, it does not earn the click. If it gives a template but no example, it remains abstract. If it gives examples but no failure cases, it will be hard to trust. The receipt for this change should therefore mention the added template, the command examples, the screenshot example, the failure section, and the education or consultation path.

Use case 2: changing a CTA or product link

CTA changes are deceptively small. One line of copy can decide whether a reader downloads a free PDF, buys a Gumroad guide, or asks for help. The source diff may show only one link, but the user-facing behavior includes the target page, the next step, and the promise around the button. A useful receipt lists the CTA label, the href, the destination page title, and the expected next action.

For a free PDF CTA, check that the reader can understand what they receive and where the next page leads. For a Gumroad CTA, check the product name, the first paragraph, and whether the purchase path still matches the article promise. For consultation, check that the article leads there naturally. In a Claude Code operations article, consultation makes sense when the reader needs team rules for review, deployment, permissions, and revenue-path checks. It feels forced if the article jumps from a basic command to “book a call” without explaining the operational risk.

Use case 3: publishing localized posts

Localization makes verification more important, not less. An English headline may be short, while the German or Spanish version wraps into three lines. A Japanese phrase may be natural, while a literal Chinese or Korean translation sounds like a machine note. Hindi can become unreadable if the article mixes too much English without explaining the term. Indonesian readers may prefer “alur kerja” in some contexts and “workflow” in others. The receipt should record that each locale has a readable opening, a localized explanation of “verification receipt”, concrete examples, failure cases, and a natural product path.

Screenshots are especially useful here. They reveal long labels, cramped cards, code blocks that need horizontal scrolling, and CTA text that no longer fits. For multilingual content, I like to capture the first viewport and the final CTA area for each language. It is not perfect QA, but it catches the mistakes that are most visible to readers.

Common failure cases

The first failure is treating HTTP 200 as publication. A fallback route can return a successful status while showing the wrong page. Always verify page-specific text, the h1, and, when relevant, the canonical URL.

The second failure is stopping at build success. The local build proves that the source can compile. It does not prove that the deployed host is fresh, that the image path is valid, or that the CTA survived the deployment pipeline.

The third failure is checking that a link exists but not where it goes. A CTA can point to an old product, a different language, a draft page, or a generic product index. For revenue content, the destination is part of the feature.

The fourth failure is letting the receipt become a wall of vague prose. Keep it short and structured. Three remaining risks are enough. If there are more than three, the work probably needs another pass before publication.

The fifth failure is asking Claude Code, “Please verify this” without telling it what evidence to return. Give it the receipt template. Ask for commands, URLs, CTA checks, screenshots, and remaining risk. The quality of the answer improves when the shape of the proof is explicit.

Education and consultation path

Start with the free Claude Code cheatsheet if you want a light daily habit: the commands to run, the language to use in a verification prompt, and the checks to repeat before publishing. Move to the prompt templates when the same review requests appear again and again. Use the Setup Guide when you want CLAUDE.md, hooks, and permission rules to make the receipt repeatable instead of dependent on memory.

Consultation becomes useful when the workflow affects a team or revenue. At that point, the question is no longer “which command should I run?” It becomes “who owns the public URL check, what counts as a release blocker, where do screenshots live, which CTA paths are protected, and how do we review AI-generated changes without slowing the team down?” Those are operating rules, and they are easier to design before a broken landing page costs money.

• Free Claude Code Cheatsheet
• 50 Claude Code Prompt Templates
• Claude Code Setup Guide
• Products
• Consultation

What I verified for this article

For this article, I separated the local build proof, the public HTML check, CTA checks, and screenshot capture into a receipt-shaped workflow. The practical result is that the article is no longer just a reminder to verify; it gives a reusable template and concrete commands. It also keeps the reader path intact: free PDF for a small habit, Gumroad material for repeatable prompts and setup, and consultation for teams that need deployment and revenue checks to become shared rules.