review-state

Review State

Use this skill on an existing state — the user's Crux — when the goal is diagnosis, quality review, or prioritizing follow-up work.

This skill is for:

• finding structural or behavioral problems
• inspecting representative queries and receipts
• reviewing governed groups and their outputs
• spotting repeated feedback or outcome patterns
• telling the user what is wrong and what should be fixed next

This skill is not the main build flow. By default, review first and surface findings before changing config, workflows, or graph state.

Phase 1: Establish review scope

Start by identifying:

1. what the user is worried about
2. whether the review is about:
   • graph quality
   • governed relationships
   • query quality
   • feedback or outcome patterns
   • overall state health
3. whether the state is a root state or an overlay
4. which user-facing queries or downstream decisions matter most
5. whether source files, prepared files, or prepare-data outputs are available for a source-to-state audit

Then inspect the current state:

cruxible state status
cruxible stats
cruxible evaluate

If the state is an overlay and the review is about overall health, local fit quality, or handoff readiness, include upstream pull compatibility in scope by default.

Phase 2: Inspect the most important surfaces

Work from the surfaces that actually affect users.

Workflows, providers, and implementation

If findings may come from how the state is built rather than only from final query outputs, inspect the implementation surfaces too:

• canonical workflows
• proposal workflows
• providers
• integrations
• relevant config sections and provider code

Use this to answer:

• is the bad behavior caused by graph shape, or by how workflows and providers are wired?
• are canonical workflows writing only deterministic, trusted results?
• are proposal workflows producing the right candidates, signals, and groups?
• is the likely fix in config design, provider code, or workflow implementation?