25 Claude Code prompts that make the work inspectable.

Explore this repository without changing files. Create a concise architecture map for [FEATURE OR DOMAIN]. Identify entry points, main modules, data flow, persistence, external services, tests, and configuration. Support every conclusion with file paths. Mark anything uncertain.

Trace [USER ACTION] from the first UI or API entry point to the final stored or displayed result. Show the important functions in order, validation and authorization boundaries, error paths, and the tests that cover them. Do not edit files.

Explain [FILE OR MODULE] to a new maintainer. Cover its responsibility, public interface, dependencies, state changes, invariants, failure modes, and callers. Use code references rather than generic descriptions. End with three safe extension points.

I need to add [BEHAVIOR]. Investigate only. Identify the smallest set of files likely to change, the existing pattern to follow, the tests that should prove the behavior, and risks to compatibility. Do not propose a rewrite.

Review the current implementation of [FEATURE] and list assumptions it makes about input, authentication, timing, data shape, network availability, and configuration. Separate assumptions enforced by code from assumptions that are merely hoped for.

Investigate this bug: [SYMPTOM]. First find or create the smallest reliable reproduction. Record expected versus actual behavior, relevant logs, and the failing path. Diagnose the root cause before editing. Then propose the smallest fix and a regression test.

Analyze the intermittent failure below. Build a hypothesis table with evidence for and against timing, race conditions, stale state, retries, shared resources, and environment differences. Add targeted instrumentation or a deterministic test before changing production logic. [LOGS / STEPS]

The operation [OPERATION] changed from [BEFORE] to [AFTER]. Locate measurable bottlenecks using existing profiling or timing tools. Distinguish CPU, I/O, database, network, and rendering costs. Recommend the smallest optimization, its trade-off, and a repeatable benchmark.

Debug the integration between [SYSTEM A] and [SYSTEM B]. Trace request construction, authentication, serialization, status handling, retries, idempotency, and error reporting. Redact secrets. Prove the failing boundary before modifying code.

Using the reproduction and repository evidence, write a root-cause analysis for [BUG]. Include trigger, faulty assumption, failure chain, user impact, why existing tests missed it, focused fix, regression test, and any follow-up prevention. Do not blame individuals.

Implement the smallest complete slice of [FEATURE]. Acceptance criteria: [CRITERIA]. Reuse existing architecture and UI patterns. Do not change [OUT OF SCOPE]. Add focused tests, handle loading/empty/error states where relevant, run the project checks, and summarize the final diff.

Add [METHOD] [PATH] for [PURPOSE]. Follow existing routing and response conventions. Validate input, enforce authorization, avoid leaking internal errors, preserve secrets server-side, and make repeated requests safe where required. Add success, invalid-input, unauthorized, and failure tests.

Build the [WORKFLOW] interface using the project's existing component and styling system. Requirements: [STATES AND BEHAVIOR]. Include keyboard access, visible focus, labels, validation, loading, success, empty, and error states. Verify on narrow and wide layouts.

Plan and implement the migration for [DATA CHANGE]. Preserve existing data, describe forward and rollback behavior, avoid long blocking operations, update application code compatibly, and add checks proving old and new records work. Stop if the repository does not reveal the deployment order.

Convert these acceptance criteria into focused tests before changing implementation: [CRITERIA]. Map each test to a user-visible behavior or invariant. Avoid testing private implementation details. Run the tests to establish the current baseline, then report what fails.

Refactor [MODULE] for clarity without changing observable behavior or public interfaces. First identify the behaviors protected by tests. Make the smallest coherent change, preserve naming conventions, avoid new dependencies, run the full relevant checks, and show evidence that behavior stayed stable.

Analyze coupling around [COMPONENT]. Identify which dependencies are essential, accidental, or circular. Propose a minimal boundary that reduces coupling without creating a speculative abstraction. Implement only after explaining migration risk and verification.

Split [FILE] because it currently mixes [RESPONSIBILITIES]. Preserve its public interface. Propose module boundaries based on real responsibilities and callers, move code in small steps, keep tests passing after each step, and avoid unrelated formatting churn.

Optimize [HOT PATH] while preserving correctness. Establish a repeatable baseline, identify the measured bottleneck, propose alternatives with complexity trade-offs, implement the smallest justified option, and compare before/after results. Do not optimize code that has not been measured.

Create an incremental migration from [LEGACY PATTERN] to [TARGET PATTERN]. Inventory callers, define compatibility boundaries, sequence changes so the repository remains buildable, add characterization tests, and identify the exact point where old code can be removed.

Review the complete diff as a skeptical maintainer. Check correctness, scope, consistency, hidden behavior changes, error paths, and unnecessary complexity. Map findings to file and line, rank by impact, and distinguish confirmed defects from questions. Do not edit during review.

Perform a defensive review of this authorized code change. Check authentication, authorization, input validation, secret handling, data exposure, unsafe defaults, dependency changes, and abuse cases. Do not create exploit payloads. For each finding, cite evidence and recommend a safe mitigation.

Review the changed user interface for semantic structure, keyboard operation, focus order and visibility, labels, announcements, contrast, motion, zoom, and responsive behavior. Cite the relevant component for each finding and suggest the smallest accessible correction.

Compare the changed behavior with the current tests. Identify untested user outcomes, failure paths, boundaries, and regressions—not just uncovered lines. Rank gaps by risk, then add the smallest high-value tests without rewriting the test suite.

Prepare a concise engineering handoff for this change. Include purpose, key files changed, important design decisions, verification commands and results, known limitations, deployment or migration steps, and the one thing the next reviewer should inspect most carefully.