Menu
Use after completing a logical chunk of edits to rescan the project and detect new rule violations or health regressions against the session baseline. Catches structural regressions before they reach review.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Use after a rescan to surface structural regressions across a time window. Diffs the latest scan against the saved baseline AND the trend history, ranking dimensions that worsened, files newly hot, and rules newly tripped. Configurable window (7d, 30d, 90d). Use periodically (daily, weekly, or pre-PR).
Use when the user explicitly asks for a structural audit, architecture review, dead-code report, test-gap analysis, or evolution hotspot scan. Heavier and noisier than the other raysense skills — only run on demand, not as part of the routine edit loop.
Use at the start of any coding session in a repository to scan the structure, save a baseline, and materialize splayed-table memory for fast follow-up queries. Establishes the "before" reference point that the verify skill diffs against later.
Use before refactoring, deleting, moving, or substantially modifying a file to compute its blast radius, coupling profile, and cycle exposure. Lets the agent edit with awareness of downstream effects rather than discovering them after the fact.
Use when the agent has a structural question about the saved baseline that the typed MCP tools (health, hotspots, rules, blast radius, coupling, cycles, evolution) do not directly answer. Runs Rayfall expressions against splayed baseline tables via raysense_baseline_query. Three modes are available - select queries for filter/project/aggregate (most common), .graph.* algorithms (PageRank, Louvain, topsort, shortest-path, betweenness, closeness, MST, k-shortest, BFS expand) for centrality and reachability over the call graph, and Datalog rules with transitive closure for declarative reachability ("reaches", "depends-on", "tainted-by"). Reach for this when the question shape is "files where X and Y," "most-central callers," "what does X transitively reach," or any custom slice across the 18 baseline tables.
Based on SOC occupation classification
| name | verify |
| description | Use after completing a logical chunk of edits to rescan the project and detect new rule violations or health regressions against the session baseline. Catches structural regressions before they reach review. |
Call this after a meaningful chunk of edits — typically before
suggesting the user run tests or commit. It rescans the project and
diffs the result against the baseline that bootstrap
established.
All tools take a path argument; pass the current repo root as an
absolute path.
raysense_rescan with path: <cwd>. Forces a
fresh walk; uses cached config and plugin state.raysense_check_rules. Pass/fail per rule.
A rule that was passing at bootstrap and is failing now is a
regression to flag explicitly.raysense_baseline_diff with
path: <cwd>. Health-dimension deltas vs the saved baseline.
Anything that dropped a grade letter (B → C, etc.) is worth
surfacing.raysense_remediations for suggested fixes.
Surface the regression and the suggestion to the user before
continuing.Be concise. The user does not want a wall of metrics. A good verify report is:
max_blast_radius,
was 18 / threshold 25 / now 27)."git diff --stat is one or two lines).For verify checks the typed tools don't cover natively:
raysense_policy_check -- evaluates .rfl files in
<repo>/.raysense/policies/. Use this when the team has shipped
custom architectural rules; they fire alongside the built-in
raysense_check_rules but are code-reviewable in the repo. Exit
code 1 = a policy itself failed to evaluate, 2 = at least one
error-severity finding.raysense_baseline_query -- the query skill covers
the syntax. Useful when a verify-time question is shaped like "did
any new file land that violates X" and X needs a custom Rayfall
expression.