How to Review and Debug Production Code With Claude Code

To review and debug production changes with Claude Code, give it a concrete failure, the affected deployment and a verifiable definition of done. Have it inspect evidence before changing code, map what the change touches, reproduce the problem, run relevant checks and obtain an independent review. The rhize-devflow plugin packages that process; it does not make a successful build permission to deploy.

What should you check before changing production code?

Start with the actual error or failing workflow. For a production incident, inspect the deployment-specific logs and error event, including environment, release and time. A stack trace from an older release or a preview environment can send an otherwise careful investigation toward the wrong code. When a connector is unavailable, record that gap rather than claiming the investigation is complete.

Then reproduce the behavior under a controlled scenario. For a stale dashboard, identify the record being changed, the mutation response, the cache invalidation and the frontend query. For an error after deployment, compare the relevant code and configuration with the deployment where the event occurred. These are hypotheses to test; a familiar symptom is not proof of a familiar cause.

How do you install the workflow?

In Claude Code, register the marketplace with /plugin marketplace add https://github.com/Rhize-Media/rhize-plugins. Install /plugin install rhize-devflow@rhize-plugins. For the full session-context and semantic impact-map workflow, also install /plugin install rhize-context-manager@rhize-plugins. These packages have separate responsibilities.

Start a fresh session after installation. Ask for the available Dev Flow commands, then run /rhize-devflow:doctor. Installation health and connected service access are different checks: a healthy plugin can still lack access to Sentry, Vercel, GitHub or a browser. Read its capability-specific findings before starting a task that needs those services.

When updating, refresh the marketplace first with claude plugin marketplace update rhize-plugins, then run claude plugin update rhize-devflow and update Context Manager if installed. Start a fresh session and verify discovery again. The current package also provides Codex discovery; use its documented host-specific installation and trust steps rather than assuming an already-open session has refreshed.

What is the review workflow?

1. Map the change with /rhize-devflow:impact-map. Identify affected files, callers, data boundaries, tests and required checks. An existing healthy CodeGraph index can help with structure; the workflow records a text-search fallback when that capability is absent. It does not silently create an index or invent a component registry.

2. Implement the smallest change that addresses the reproduced cause. Keep unrelated cleanup separate. If the evidence changes the scope, update the map before continuing. A fix to one layer is incomplete if an affected caller still depends on the old behavior.

3. Run /rhize-devflow:simplify against the task diff. This is a behavior-preserving review of duplication and accidental complexity, not permission to redesign nearby code. A verified decision to leave the code alone is a valid result.

4. Run /rhize-devflow:check. It builds an evidence packet and selects relevant checks from repository instructions and declared scripts. It should report what ran, what failed and what remains unavailable. Passing a narrow test is not a substitute for a repository-mandated release check.

5. Run /rhize-devflow:review for the exact base and head being considered. Non-trivial work requires independent skeptical review. Its possible outcomes include passing, fixable gaps and a need for human judgment. The command reviews; it does not commit, push, merge or deploy.

6. Release only when the user or repository policy authorizes it. Verify the actual deployed version and user path after deployment where the release contract requires that proof. A local commit, merged pull request and healthy production route are separate pieces of evidence.

How do you debug a stale screen?

A useful request is: "After saving this customer, the dashboard still shows the old value. Reproduce it and trace the mutation through the server and frontend before editing." Ask the assistant to inspect the write response, persistence, invalidation and read path. A cache-tag/query-key mismatch is one possible cause, alongside failed writes, stale reads or local UI state.

Use /rhize-devflow:mutation-check on the affected paths for a read-only consistency review. Its --fix-plan option proposes work without editing source. After a fix, repeat the same user action and check the displayed result, including the error path if the write fails. Browser evidence complements source tests; neither replaces the other.

How do browser and error tools fit?

/rhize-devflow:browser-qa works from scenarios: the functional path, console and network errors, an accessibility smoke check, responsive behavior and performance when requested. It uses the browser tooling actually connected in that session. Ask it to state unavailable coverage rather than converting a screenshot into a claim that every interaction works.

The error-lifecycle and instrumentation skills complement specialist tools. Error triage reads the observed event and relevant deployment evidence before proposing a fix. Instrumentation adds appropriate errors, spans or structured logs to make the next investigation easier. Official Sentry and Sanity documentation remain the reference for their APIs; Dev Flow supplies an engineering procedure around them.

Which commands moved?

Session continuity belongs to rhize-context-manager: /start, /done, /context-hygiene and /context-doctor. Context Manager reads and maintains session state; its /done can call Dev Flow review when code changed. Use /rhize-devflow:impact-map, /check and /review for the change itself. Old browser-debug, browser-perf, browser-test and mutation-analyze/fix names are compatibility adapters, not separate current workflows.

The test-evidence capability classifies and validates state-bound test packets. The current documented runner does not execute arbitrary project tests through a trusted sandbox adapter; it reports execution_unavailable for that missing path. Real test execution still needs the appropriate authorized project tooling. Do not report a packet validation as a completed behavioral test.

What do the hooks enforce?

Current hooks can require impact preparation before material source writes and reconciliation before release or completion. A separate credential guard steers explicitly targeted Keychain GUI operations toward private CLI handling. Host support, trust and enabled hook definitions matter; installation alone is not proof that interception is active.

Other guards, including protected-file and mutation hints, are opt-in capabilities. The setup manifest describes them. None is an operating-system sandbox or proof that every possible tool path is covered. Keep repository permissions, secret handling and human approval boundaries in place.

What should the next session inherit?

Record the verified cause, changed behavior, tests and remaining limits in the project state or other designated context file. A later session should be able to tell what was proven without reconstructing the entire conversation. For a failed investigation, preserve the reproduction and missing evidence instead of writing a success summary.

Start with one existing bug or bounded code change. Browse the Rhize plugin marketplace, install the workflow and verify it on that task before making it part of every release.

Sources and implementation references

Current Dev Flow setup and command reference: https://github.com/Rhize-Media/rhize-plugins/blob/main/rhize-devflow/README.md