/react-hydration

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select react-hydration from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv react-hydration, /just-vibe react-hydration and /jv:react-hydration in Claude. See shortcut setup and context examples.

What the agent does

1. Reproduce the exact route and compare server markup with the first client render. Trace request-specific state, timestamps, locale, random values, browser-only APIs and invalid HTML nesting; distinguish parser repair from state mismatch.
2. Choose a stable initial contract and move browser-only transitions to the appropriate lifecycle. Ensure request-specific state is isolated across server requests; do not silence hydration warnings or disable rendering broadly to conceal the cause.
3. Verify direct server navigation and client navigation under differing locale/timezone and repeated requests where relevant. Confirm the page becomes interactive and retains its intended initial content, not merely that warnings disappeared.

Inputs

• SSR framework, route, server/client output, and logs.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Server/client initial-render consistency and hydration behavior; applicable only to hydrated applications.

Writes

Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.

Mode

Apply for a reported mismatch; SSR framework, route, server/client output, and logs.

Prerequisites

Component source, React/framework versions, state/data conventions, and relevant test tooling. Browser/profiler evidence is needed for measured rendering claims. Preserve existing framework and state libraries unless changing them is part of the request.

Expected output

• Hydration fix with server/client evidence.
• Mismatch source, initial-state contract and hydration plus interactivity checks.

How the work is checked

• Server and initial client output agree for the supported contract; interactivity and request isolation survive the repair. Suppressed warnings do not count as evidence.

When to stop or clarify

• Do not suppress warnings or disable SSR globally as a default fix. Client-only applications receive an applicability explanation.

Handling missing context

Infer

Read component callers, ownership of state, installed React/framework versions and existing interaction tests.

Assume

Retain the framework and state library; preserve intended loading/error/empty behavior while resolving the named bug.

Ask

Ask when product semantics such as persistence, optimistic failure or reset behavior have conflicting evidence; missing profiler access only blocks measured performance claims.

Technical guidance

Evidence

Compare server HTML and first client render with timezone, locale, random IDs, browser storage and DOM nesting.

Method

Find the first deterministic divergence; choose server-provided stable inputs or an explicit client-only boundary with appropriate loading behavior.

Pitfall

Suppressing hydration warnings does not repair invalid markup or mismatched event/state attachment.

Check

Load the real SSR page directly with varied timezone or saved state, inspect warnings and verify the affected interaction after hydration.

Situational decisions

When mismatch depends on user-specific data unavailable to the server: Define a consistent initial snapshot or intentional client-only boundary for that region.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring