rhize-devflow — Production Dev Discipline for Claude Code

What Is rhize-devflow?

rhize-devflow is a Claude Code plugin that teaches Claude the production-grade development discipline Rhize Media expects on real client projects. It bundles seven skills and eleven commands covering session/context hygiene, production error triage, cache-mutation consistency, Sentry instrumentation, Chrome DevTools debugging, and Sanity CMS house style — all namespaced as rhize-devflow:<skill>.

We built this plugin because AI-assisted coding without guardrails tends to fail in predictable ways: sessions lose context and redo work, mutations leave the cache and UI out of sync, errors ship without instrumentation, and nobody finds out until a client does. rhize-devflow is our attempt to encode the fixes for those failure modes into something Claude reads automatically, rather than relying on a developer to remember them under deadline pressure. It's part of the public Rhize plugins for Claude Code marketplace, installable in any project.

What Problem Does rhize-devflow Solve?

rhize-devflow exists because shipping to production is not the same activity as prototyping, and most AI coding assistance is tuned for the latter. It targets five specific failure modes: context loss across long sessions, uninstrumented errors that surface only when a client complains, mutations that desync cache and UI, undocumented browser behavior, and CMS schemas that drift from house conventions.

On our own production projects at Rhize Media — Next.js/Sanity/Payload/Supabase stacks deployed on Vercel — we kept hitting the same five problems session after session. A long Claude Code session would lose track of what it had already tried. A mutation would revalidate the wrong cache tag, so a client would see stale data and have to hard-refresh. An error would fire in Sentry with no correlation back to the deploy that caused it. A browser bug would get "fixed" without ever actually being reproduced in a real browser. And a Sanity schema would get modeled around what a field looks like in the Studio UI rather than what it is as data. Each skill in this plugin exists to close one of those gaps, and each one assumes real stakes: a stale cache means a client sees wrong data, an uninstrumented error means nobody finds out until a user complains, and a context-exhausted session means work gets redone.

What Skills Does rhize-devflow Ship?

rhize-devflow ships seven skills. Skills are reference knowledge Claude loads automatically when a request matches trigger phrases — you don't invoke them directly, Claude reads them behind the scenes to produce better output. They cluster into four jobs: session hygiene, production errors, data-mutation consistency, browser debugging, and CMS house style.

Two of these skills are explicitly paired rather than standalone. sentry-instrumentation is the "write the code" half — it's how try/catch blocks, spans, and structured logs get added in the first place. error-lifecycle-management is the "respond to what Sentry told you" half — it picks up once an alert has already fired and runs the triage decision tree: identify the source, fetch Sentry context, correlate to recent deploys, only then propose a fix. Neither replaces the official sentry:* plugin skills for SDK setup; they cover in-code instrumentation conventions once Sentry is already wired up.

dev-flow-foundations works the same way relative to the rest of the plugin — it's pure reference knowledge, not something invoked directly. Its dependency-graph and component-registry patterns are what the /rhize-devflow:impact-map command actually executes, and its regression-prevention protocol (root cause before fix, never patch blind) is what error-lifecycle-management's triage workflow follows.

What Commands Does rhize-devflow Ship?

Commands are actions invoked explicitly with a slash prefix — they drive a specific workflow, usually combining several skills with real tool calls like git, build commands, browser automation, and subagents. rhize-devflow ships eleven: start, done, impact-map, context-hygiene, mutation-analyze, mutation-check, mutation-fix, browser-debug, browser-help, browser-perf, and browser-test.

/rhize-devflow:start and /rhize-devflow:done bookend a session. /start reads STATE.md first, checks CURRENT_SPRINT.md and COMPONENT_REGISTRY.md for staleness, and suggests a next action. /done runs a full impact analysis on everything changed that session, runs the build/typecheck, delegates to an independent verifier subagent for a PASS / FAIL_WITH_FIXABLE_GAPS / FAIL_REQUIRES_HUMAN verdict, generates a commit message, and requires persisting at least one fact, failure, or lesson back to STATE.md before it calls the session done.

The mutation-* commands form a pipeline: mutation-analyze scans the codebase and writes a scored report, mutation-check spot-checks a single file inline (fast enough to run right after editing, not just before committing), and mutation-fix turns flagged issues into a fix plan or inline TODO(mutation-consistency) comments, filterable by priority (P0/P1/P2). The browser-* commands are three lenses on the same Chrome DevTools MCP server: browser-perf for Core Web Vitals traces, browser-debug for network/console/CORS inspection, and browser-test for screenshots, responsive checks, and form submission testing. browser-help is the cheat sheet tying them together.

What Is the v2.4.0 Compounding Persistence Layer?

The compounding persistence layer is rhize-devflow's mechanism for ensuring no session ends without leaving the next one better prepared — a verified fact, a documented failure, or a lesson persisted to STATE.md, plus an independent verifier gate before any commit. It's built from four pieces: a dedicated verifier subagent, a STATE.md contract, an opt-in file-protection hook, and shareable hookify/rule templates.

agents/verifier.md is an independent Haiku verifier with read-only access (Read/Bash/Glob/Grep). /rhize-devflow:done delegates to it before any commit, because the maker — Claude, in the same session that wrote the code — is a bad judge of its own work. The verifier returns one of three verdicts: PASS, FAIL_WITH_FIXABLE_GAPS, or FAIL_REQUIRES_HUMAN, and a FAIL_REQUIRES_HUMAN verdict is meant to stop a commit outright, not get worked around because the build happened to pass.

The STATE.md contract is the other half: /rhize-devflow:start reads STATE.md (Verified facts · General rules · Open failures · Lessons learned · Last session) before touching code, and /rhize-devflow:done requires writing at least one entry back before it will call the session finished. Rounding out the layer, hooks/protect-files.sh is an opt-in PreToolUse gate that blocks edits to .github/workflows/*, .env*, and billing/payment paths, plus content checks for NEXT_PUBLIC_*-named secrets and Supabase service-role references inside 'use client' files. templates/hookify/ ships warn-level hookify rules for Next.js/Sanity repos, and templates/rules/openwolf.md is the canonical OpenWolf protocol rule for repos that already have a .wolf/ directory — both are meant to be copied in per-project rather than firing automatically, so nothing untested runs without a developer choosing it.

When Should You Use rhize-devflow?

Use rhize-devflow any time you're shipping code to a production environment rather than prototyping in isolation, especially on a Next.js/Sanity/Payload/Supabase stack deployed on Vercel. It's for developers — and Claude, acting as one — who need session continuity across days of work, error visibility the moment something breaks, and cache behavior that doesn't require a client to hard-refresh to see their own changes.

Concretely: reach for /rhize-devflow:start at the top of any session, even a "quick fix," because the whole point of STATE.md is that a five-minute fix six months from now shouldn't require re-discovering context that was already captured once. Reach for the mutation-* commands anytime you're touching a Server Action, a React Query mutation, or a Payload CMS lifecycle hook. Reach for the browser-* commands to pair with a live Sentry investigation — if error-lifecycle-management surfaces a client-side error, /rhize-devflow:browser-debug on the same URL is usually the fastest way to reproduce it and see the console/network state the stack trace alone doesn't show.

Example prompts:

• "Production is throwing 500s on checkout" — triggers error-lifecycle-management's triage decision tree: identify the source, fetch Sentry context, correlate to recent deploys, and only then propose a fix.
• "Why isn't this update showing up without a refresh?" — triggers data-mutation-consistency, which reasons about whether the mutation revalidates the right cache tag and whether the frontend query-key factory actually matches it, the classic cross-layer mismatch behind "I had to hard-refresh."
• "Check the performance of my dashboard page" — triggers chrome-devtools-mcp via /rhize-devflow:browser-perf, which navigates, starts a trace, and reports Core Web Vitals (LCP, FID/INP, CLS) plus specific render-blocking resources, not just a pass/fail.

Getting Started

Install the plugin by adding the Rhize marketplace in Claude Code — /plugin marketplace add https://github.com/Rhize-Media/rhize-plugins — then /plugin install rhize-devflow@rhize-plugins. In Cowork, add it via Settings > Plugins > Add Marketplace instead. Once installed, run /rhize-devflow:start at the top of your next session to see STATE.md and CURRENT_SPRINT.md loading in practice.

If you're new to the broader plugin set, Rhize plugins for Claude Code covers how rhize-devflow fits alongside Rhize Media's other Claude Code plugins, including where it hands off to the official sentry:* and sanity:* plugins. The full source, including every skill and command referenced here, is on GitHub at https://github.com/Rhize-Media/rhize-plugins.