The Reproduce-Fix-Verify Codebase Demo

Setup: what the audience sees

The impressive part is not a code snippet. It is the full loop: read the project, find the failure, edit the right files, run verification, and explain the behavioral change.

The setup matters because Claude demos fail when the prompt hides the goal, mixes private data into a public reveal, or asks for a finished answer without giving the model a way to expose assumptions.

• Use a toy repo or a low-risk branch for the public demo.
• Start with a real failing test or a reproducible bug report.
• Give Claude explicit permission boundaries: inspect, change only relevant files, run focused tests, then summarize.

What this does not prove

It does not prove the change is merge-ready without human review, CI, and domain-specific QA. It demonstrates a repo-aware debugging workflow.

<task>Fix this bug in the current repository.</task>
<bug>
When a user saves an empty display name, the settings page shows a blank heading
instead of falling back to "Untitled profile".
</bug>
<rules>
- First inspect the relevant code and tests.
- Reproduce the failure or explain exactly why it cannot be reproduced.
- Make the smallest maintainable change.
- Add or update a focused test if the repo has a nearby test pattern.
- Run the narrowest useful test command, then report command output.
- Do not refactor unrelated files.
</rules>

The reveal: what should happen

• Claude should search before editing and should state the exact files it touched.
• A strong run includes a failing test before the fix or a clear explanation when that is not possible.
• The final answer should distinguish verified behavior from untested assumptions.

Verification steps

A demo becomes useful when the audience can inspect it. Use the steps below to turn the reveal from theater into a repeatable workflow.

1. Review the diff yourself.
2. Run the same test command locally or in CI.
3. Check whether the fix handles surrounding edge cases, not just the single reported path.

Guardrails

• Use version control and a throwaway branch for demos.
• Do not grant secrets or production access for a public demo.
• Ask for a narrow fix; broad "make this better" prompts hide risk.

Variations

• Turn a console error into a reproducing test.
• Turn a flaky test into a diagnosis report before any fix.
• Turn a code review comment into a patch plus verification summary.

FAQ

Is this the same as a Claude Code best-practices guide?

No. This page is a demo script. For deeper engineering practice, the network should route to Claude Ships Code.

What makes the demo credible?

A credible demo shows the test command, the scope of edits, and the remaining risk instead of only showing a polished patch.