⚖ Command review (the Thing)Early access
When turned on for a category, a command that would normally stop to ask you is instead checked by a panel of AI reviewers before it runs. Each one looks for a different problem: Forseti checks for security risks, Mímir checks the command is correct, and Heimdall watches for hidden instructions trying to trick the system (a “prompt injection”). Thor breaks a tie if they disagree. They vote allow / edit / deny, and a reviewer may rewrite a risky command into a safe one (re-checked before it runs). You are interrupted only when the panel can’t decide; every verdict is logged. It can only resolve the ask cases — it can never unblock the always-denied “danger zone” commands (like force-pushing or wiping a folder). Costs credits on every reviewed command — treat it as a high-stakes guard, not a daily setting. Design: tribunal-review-feature-design.md · concern catalog.
Live for twelve categories: the five shell categories plus network_write (allow / edit / deny); six tool-shape categories (file_edit_*, file_read_*, network_read, mcp_tools) are allow / deny only. Turn each on via its toggle inside the category card below.
Is command review for me? (scope & when it’s optional)
Command review exists to put portable, model-agnostic guardrails on agentic AI that routes across multiple model vendors (e.g. GitHub Copilot CLI using Claude + ChatGPT + Grok), where Claude Code’s native auto permission mode is unavailable (it is Anthropic-API/Claude-only). There it is the only layer giving you a deterministic catastrophe floor, a self-tamper guard, secret-egress prevention, cross-vendor anti-correlated review, and low-touch allow / edit / deny disposition.
If you run only Claude Code, native auto mode may be enough — it adds a hardened classifier plus a non-configurable 3-consecutive / 20-total runaway brake. On pure Claude Code, prefer auto for containment and treat command review as an optional add-on for its domain concerns, audit trail, and yes/no decision-routing. The tribunal earns its credits cost most clearly where auto cannot run.
file_edit_globalofffile_edit_projectofffile_read_globalofffile_read_projectoffmcp_toolsoffnetwork_readoffnetwork_writeoffshell_code_execoffshell_local_mutateoffshell_package_installoffshell_readonlyoffshell_remote_mutateoffAdvanced — seat models, confidence & per-tier panel
Which model fills each seat and how unsure a seat may be before the tie-breaker is convened. Applies wherever a category’s review toggle is on.
✓ Loaded from.ravenclaude/comfort-posture.yamlReads are never interrupted, and the tribunal always blocks or rewrites dangerous commands — this only changes which safe-looking commands you confirm.
Per-tier panel (advanced)
Override which seats convene and how confident the panel must be at each risk tier. A required seat (set by the tier’s mandatory list) is always checked and can’t be removed.
By default Mímir + Heimdall convene; Heimdall is required.
By default Forseti + Mímir + Heimdall convene; Heimdall is required.
By default Forseti + Mímir + Heimdall convene; Forseti + Heimdall are required.
Low risk runs no panel — clean reads pass the deterministic screen for free and are never sent to the tribunal.
Each row below is a type of action Claude might take — for example, shell_code_exec means “run code such as python -c …”. For each one you pick Deny (never), Ask (check with me first), or Allow (go ahead). Start from the ★ Recommended preset above and loosen or tighten from there as you build trust. Where these actually bind: Save & apply writes Claude Code’s permission engine, so under Claude Code they are enforced. Under GitHub Copilot CLI enforcement comes instead from the wired hooks plus command review. Under OpenAI Codex the real boundary is its own OS sandbox (sandbox_mode / approval_policy), which the installer writes separately. On any other host these levels are advisory and CI is the backstop.
Danger Zone
The following patterns are ALWAYS denied, regardless of category levels. Unblock individual rules at your own risk.
These are preventive guardrails, not a malware scanner. They block the common routes malware and damage travel through — running remote scripts (curl | sh), gaining root (sudo), wiping files, and reading secrets — and they stop the command before it runs.
What they don’t do: inspect a file’s contents — so they cannot catch malware hidden inside something you explicitly approve. Treat the floor as a seatbelt, not a reason to skip reviewing what Claude produced.
The floor and the hooks behind it (guard-destructive blocks destructive shell commands, enforce-layout blocks off-pattern file writes) are maintained in the RavenClaude marketplace and periodically re-reviewed by the Researcher meta-skill, which adds new dangerous patterns here as they emerge. Learn more: Claude Code permissions · how hooks work · this plugin’s security rules.
Bash(rm -rf:*)Recursive force-delete — removes a directory tree without confirmation.
Bash(git push --force:*)Force-push, overwriting remote branch history.
Bash(git push -f:*)Short flag for force-push.
Bash(git reset --hard:*)Discard working-tree and staged changes irreversibly.
Bash(git clean -fd:*)Force-remove untracked files and directories.
Bash(npm publish:*)Publish a package to the npm registry.
Bash(pnpm publish:*)Publish a package via pnpm.
Bash(yarn publish:*)Publish a package via yarn.
Bash(cargo publish:*)Publish a Rust crate to crates.io.
Bash(curl * | sh)Pipe downloaded content directly into a shell — the 'curl pipe sh' install pattern.
Bash(curl * | bash)Variant of curl-pipe-sh.
Bash(wget * | sh)wget variant of curl-pipe-sh.
Bash(wget * | bash)wget variant of curl-pipe-bash.
Bash(sudo:*)Run a command as the superuser (root) — full administrative privileges over the machine.
Read(.env)Read an .env file (environment-variable definitions).
Read(.env.*)Read .env.local, .env.production, .env.staging, etc.
Read(**/*.pem)Read a PEM-encoded private key (TLS certs, SSH keys).
Read(**/*.key)Read any .key file (generic private-key extension).
Read(**/credentials*)Read any file literally named 'credentials' (AWS, GCP, etc.).
Read(**/secrets*)Read any file literally named 'secrets' (generic catch-all).
Guardrail pipeline
Everything an AI agent passes through, top to bottom. Each box shows whether it's on right now, what it does (in plain words), the step-by-step of how it works, and the knobs you can turn. Changes save to your .ravenclaude/comfort-posture.yaml.
IMPORTANT — these guardrails fire under Claude Code, GitHub Copilot CLI, OpenAI Codex CLI, Cursor, and Gemini CLI, and nowhere else yet. “Always on” below means “not a knob you can switch off”; it does NOT mean every host runs it. Under Aider and Windsurf / Devin Desktop nothing here wires itself, so none of it fires — the stages are shown for reference, not as protection you currently have.
The two middle checkpoints repeat for every command and file edit — that's the ↺ loop. Open “How it works, step by step” on any box to see exactly what it checks and what happens if it trips. Badges: Always on can't be turned off · Advisory only nudges, never blocks · On / Off depends on your settings (filled in live below).
ravenclaude dashboard --project <repo> to edit and apply.Right when the robot wakes up, it loads your settings and reminds itself what it's allowed to do.
Loads your saved safety settings so they're on from the very first step.
How it works, step by step
- Reads your saved settings file (.ravenclaude/comfort-posture.yaml).
- Turns each rule into a real Claude Code permission.
- Writes them into .claude/settings.json so they're active right away.
If it trips: If there's no settings file, it does nothing — no harm done.
Where it’s set: Change these in the Settings tab; the Save button writes the file.
Picks a safe mode to start the session in.
How it works, step by step
- Checks what mode the session is starting in.
- If nothing was chosen, picks a safe default.
If it trips: Only steps in when no mode was set — otherwise it leaves your choice alone.
Where it’s set: Built in — nothing to tune.
Reminds the robot what tools and access it already has, so it doesn't say “I can't” by mistake.
How it works, step by step
- Looks at what tools, logins, and permissions are available.
- Writes a short summary into the session so the robot knows what it can do.
- Adds a line about recent guardrail activity (how many things were blocked, when settings last changed).
If it trips: Read-only — it never changes anything, it only informs.
Where it’s set: Built in.
This is the busiest checkpoint. Every command and every file edit goes through these in order before it's allowed to happen.
Stops really dangerous commands (like deleting everything) before they can run.
How it works, step by step
- Looks at the command about to run.
- Matches it against a list of never-allowed patterns (delete everything, force-push, wipe history).
- Blocks it before it can run if it matches.
If it trips: Blocks the command and writes a note in the alert log (Perimeter alerts tab).
Where it’s set: Built-in safety floor — always on, can't be turned off.
A panel of robot reviewers votes yes / no / fix on a command before it runs. You choose how strict it is.
How it works, step by step
- Runs quick free checks first, so the obvious-dangerous ones are caught with no waiting.
- If the command is risky enough, a panel of reviewers reads it.
- They vote: allow, fix (rewrite it to be safe), or block.
- Low-risk reads skip the panel completely — no waiting.
If it trips: A block stops the command; a fix rewrites it; anything safe just runs.
Where it’s set: Turn it on (and on/off per command type) and tune the panel in Settings — quick toggles below.
Turn individual command types on/off, and tune the reviewer panel, in the Settings tab.
Counts the robot's steps. If it loops forever or takes way too many steps, it pauses so it can't run away.
How it works, step by step
- Counts every tool the robot uses this session.
- Watches for the same command repeated over and over.
- Pauses if it loops, or if it passes your step limit.
If it trips: Pauses the robot so it can't run away with your time or money.
Where it’s set: Turn the brake off, or set the two limits, in the boxes below.
By default the robot splits a job across as many helpers at once as the job allows.
How it works, step by step
- Watches when the robot wants to fan work out to helpers (subagents / worktrees).
- By default it runs every independent piece at the same time, with no limit.
- Caps how many run at once if you set a limit — or works one at a time if you turn it off.
If it trips: Nothing is blocked. This only tells the robot how wide to spread the work.
Where it’s set: Set a most-at-once limit, or tick “Conserve tokens” to make it work one step at a time.
The default is MAXIMUM: fan-out work (subagents / worktrees) runs in parallel with no limit. Untick “No limit” and set a cap to batch it, or untick “Allow parallel workers” to keep the work sequential. “Conserve tokens” is the standing exception — it makes the robot work one step at a time until you turn it back off. It also switches on by itself when a prompt says “conserve tokens” or the session runs low on room.
Keeps a copy of the robot's long-term notes before it rewrites them, and stops it from throwing most of them away in one go.
How it works, step by step
- Saves a copy of the robot's long-term notes before every rewrite.
- Stops a rewrite that would delete more than 15% of them, and asks for a diff instead.
If it trips: Growing the notes, or trimming a little, is always fine — only a big one-shot deletion is stopped.
Where it’s set: Set `memory_guard: max_shrink_pct: N`, or allow one deliberate cleanup with RC_MEMORY_COMPACTION_OK=1.
.repo-layout.json.ravenclaude/task-scope.jsonMakes sure new files go in the right folders, and that the robot only touches the files this task is allowed to.
How it works, step by step
- Checks where a new file is about to be written.
- Compares it to your allowed-folders list (.repo-layout.json).
- If a task-file list is set, checks the file is part of this task (.ravenclaude/task-scope.json).
If it trips: Blocks the write and suggests the correct folder.
Where it’s set: Edit the two file lists in the boxes below.
.repo-layout.json.ravenclaude/task-scope.jsonStops the robot building something new on top of a result it never double-checked.
How it works, step by step
- Watches for a check that came back empty or failed (a 404, a not-found, a search with no hits).
- If the robot then tries to CREATE a brand-new code file, it pauses.
- Asks for one more check that would come back differently if the robot were wrong.
- Run that check and the pause clears itself.
If it trips: Blocks only the creation of a NEW code file, and only while an unchecked failed result is outstanding. Editing existing files, notes and tests are never touched. If its recorder is missing it blocks anyway — it will not say 'all clear' when it cannot see.
Where it’s set: Built in. Set RC_PREMISE_OVERRIDE=1 to go ahead anyway (it gets written down), or RC_PREMISE_CONTROL to name the check you already ran.
When the robot would ask you a yes/no question, a panel answers the easy ones so you're not interrupted.
How it works, step by step
- Notices when the robot is about to ask you a yes/no question.
- Sends the simple, low-risk ones to a small panel.
- Big or risky questions always come to you.
If it trips: In binding mode the panel answers the easy ones; risky ones still reach you.
Where it’s set: Pick off / advisory / binding in the box below.
Lets you pick which websites the robot may open without asking, and which are always off-limits.
How it works, step by step
- Before the robot fetches a web page, checks your allow / deny lists.
- An allowed site opens with no prompt; a denied site is blocked.
- A site on neither list falls through to the normal once / this-session / permanently / deny prompt.
If it trips: Blocks a denied site; otherwise it asks you the first time, exactly like today.
Where it’s set: Set up allow / deny lists on the Web access page. “Not configured yet” is fine — sites just fall through to the normal ask prompt.
Not configured yet — every website falls through to the normal ask prompt (allow once / this session / permanently / deny). The guard never blocks web access until you set up lists, so this is a safe default.
Set up allow / deny lists on the Web access page — saved to .ravenclaude/web-access.yaml, enforced by guard-web-access.sh. Nothing to configure here; this is a shortcut to that editor.
Routes team-lead planning to Claude when your host CLI isn't Claude Code. Inert under Claude Code.
How it works, step by step
- Checks whether the host is already Claude Code — if so, does nothing.
- Reads the orchestrator knob from .ravenclaude/comfort-posture.yaml.
- decide: sends the task to Claude and gets back a JSON plan the host CLI executes.
- full: sends the full task to Claude and gets back artifact content the host writes.
If it trips: If Claude is unavailable or auth fails, falls back to host orchestration automatically — never blocks.
Where it’s set: Pick off / decide / full below. Inert under Claude Code (host already IS Claude).
[host-only — inert under Claude Code] Active only when your CLI is not Claude Code (e.g. GitHub Copilot routing GPT/Grok). Under Claude Code the host already is Claude — this knob is a no-op. off — zero cost, host orchestrates as always. decide — Claude returns a JSON dispatch plan; host runs the agents (brain / hands split; lower cost). full — one Claude call reasons through the task and returns artifact content; host writes the files (guaranteed intent; highest cost, bounded).
Routes well-defined everyday work (tests, summaries, mechanical edits) to a cheaper coding agent instead of spending Claude's own turn on it.
How it works, step by step
- A deterministic router decides whether a task is well-defined enough to leave the Claude session.
- advise: the delegated agent's output comes back as a suggestion only — nothing is applied automatically.
- agent: the delegated agent writes to a disposable, sandboxed git worktree — you review the diff before it merges.
If it trips: An ambiguous or escalation-shaped task always stays with Claude — the router defaults to keeping work local.
Where it’s set: Pick off / advise / agent, the tier, and the coding agent below.
Off by default — nothing here executes until mode is set to advise or agent. advise — the delegated agent runs in an isolated scratch dir with no repo access; its output is a suggestion for you to apply, never applied automatically. agent — the delegated agent runs in a disposable git worktree with write access; you review the diff before it merges. A task the router judges ambiguous, escalation-shaped, or security-sensitive always stays on Claude regardless of this setting — the routing asymmetry is deliberate. See skills/cheap-lane-delegation/SKILL.md.
After something happens, these tidy up and double-check the work.
Strips instruction-shaped junk from a page or MCP tool result the robot just received, before it reads it.
How it works, step by step
- After a web fetch or any mcp__* tool call, strips fake system-reminder blocks from the result.
- If the cleaner crashes, the original result is left in place (fail-open).
If it trips: Rewrites the fetched body or MCP result the robot sees. Never blocks the call.
Where it’s set: Built in.
Tidies up a file's formatting right after it's saved.
How it works, step by step
- Runs right after a file is saved.
- Runs the formatter for that kind of file.
- Saves the tidied version.
If it trips: Skips files it doesn't have a formatter for — never blocks.
Where it’s set: Built in.
Stops the robot from making endless copies of itself.
How it works, step by step
- Watches for the robot launching copies of itself.
- Warns if those copies nest too deep.
If it trips: Warns (it doesn't hard-block) so you can step in.
Where it’s set: Built in.
When a command fails or returns nothing, lists the possible reasons instead of letting the robot guess one.
How it works, step by step
- Watches commands that come back angry or empty.
- Lists the CANDIDATE causes, each with the one check that tells them apart.
- Refuses to let 'the thing is absent' be the top answer without a positive control.
If it trips: Advises only, never blocks. Wired after its fire rate was measured at 2.588% over 46,557 real commands (the bar was 3%).
Where it’s set: `cause_triage: off` in .ravenclaude/comfort-posture.yaml.
Reminds the robot to say where a fact came from when it writes one into a document.
How it works, step by step
- Reads facts written into knowledge / docs files.
- Checks each big claim says where it came from.
- Nudges if a source is missing.
If it trips: Advisory only — it nudges, it never blocks.
Where it’s set: No knob — fires whenever a comfort-posture exists.
Reminds the robot to run a check itself instead of telling you to go look, when it already has the access.
How it works, step by step
- Reads knowledge / docs files the robot writes.
- Looks for “open the portal / check it yourself / verify manually” phrasing.
- Nudges the robot to run the check itself when it already holds the access.
If it trips: Advisory only — it nudges, it never blocks.
Where it’s set: No knob — fires whenever a comfort-posture exists.
Notices when a work file lands somewhere the NEXT CLI would never look for it.
How it works, step by step
- Stays quiet for the two agreed places: .ravenclaude/runs/<task>/ and docs/.
- Speaks up only for a scratch-NAMED file at the repo root (notes.md, plan.md, output.txt), pointing at `rc artifacts new`.
If it trips: Advisory only — nothing is ever blocked. Deliberately narrow: a nudge that fires on everything gets ignored.
Where it’s set: No knob — put `placement-ok` in a file to silence it for that file.
Before the robot is allowed to stop, it proves the work is really finished.
Before the robot says “done,” it runs your tests. If they fail, it keeps working.
How it works, step by step
- Fires when the robot tries to stop.
- Runs your test / build command.
- If it fails, the robot keeps working instead of stopping.
If it trips: Blocks the stop until tests pass (up to a retry limit, then it lets the robot stop with a warning).
Where it’s set: Set your test command and the retry limit in the boxes below.
Leave the command empty to turn the done-check off.
A gentle nudge to run the tests when there's no done-check set up.
How it works, step by step
- Fires on stop when no done-check is set.
- Prints a friendly reminder to run the tests.
If it trips: Advisory only — just a nudge.
Where it’s set: Becomes unnecessary once you set a done-check above.
Proactively writes a full handoff brief before context gets tight, so a fresh session (or a teammate) can pick up without losing the thread.
How it works, step by step
- Watches live context usage as the robot works.
- nag: at Stop, on Claude Code, gently suggests writing a handoff brief.
- block: on hosts a suggestion can't reach (like Copilot), requires the brief before the robot can stop.
If it trips: Off by default — nothing here runs until you pick nag or block.
Where it’s set: Pick off / nag / block in the box below.
Proactively writes a full handoff brief before compaction, so a fresh session or a teammate can pick up without losing the thread. off = never; nag = suggest to Claude Code at Stop; block = required on hosts where nag can't reach the agent (e.g. Copilot, whose Stop hook has no context-injection field).
Concern reliability
Per-concern false-positive signals from the command-review Sága log. Stripped means the orchestrator deterministically caught a cite the seat shouldn’t have made (e.g. xc.outside-project-tree on a file the path-classifier already proved is in-tree). Heimdall-disagreed means another seat cited the concern and voted deny while Heimdall (injection-only) voted allow — a behavioural false-positive signal. A high FP ratio is the queue of concerns worth tuning. Read live from .ravenclaude/runs/thing/ via /__concern-stats; static hosts show an empty state.
| Concern | Cited | Stripped | Heimdall ≠ | Final deny | FP ratio |
|---|
Web access — allow & deny lists
Domains the agent may fetch without asking (allow) or never (deny). Saves to .ravenclaude/web-access.yaml via the dashboard server; the guard-web-access.sh hook enforces it for Claude when the plugin is installed, and any cloned CLI tool can read the same plain-YAML file. On the static/published copy edits stay in your browser — use Download. One domain per line; a rule matches the domain and its subdomains (e.g. github.com also allows api.github.com). Unlisted domains fall through to the agent's once / this-session / permanently / deny prompt.
Allow auto-approved
Deny always blocked
No local dashboard server behind this page, so Save to repo is off. Run ravenclaude dashboard (or bash .ravenclaude/dashboard.sh) and reopen, or use Download and drop the file into .ravenclaude/web-access.yaml.
📜 Run feed
Run history from .ravenclaude/runs/ — newest first. Each card is one multi-step run (its summary, structured-result status, and event count). Command-review verdicts live in the Review log tab.
Loading activity…
⚖ Review log
Loading review log…
Session
Claude Code session state for this project (Mímir’s well) — drawn live from ~/.claude/ and .claude/settings.json. Read-only; in-process-only fields render with an explainer, never a dash.
Settings
Loading…
Current session
Loading…
Activity summary
Loading…
Recent project sessions
Loading…
In-process only
Loading…
Streams
Agentic Work-Streams for this project — named logical workstreams under .ravenclaude/streams/, drawn live from the served dashboard. Read-only; the per-stream history shows derived labels only (never your prompt text). Switch the active stream with /stream set <id> or rc streams set-active <id>.
Streams
Loading…
Active stream — recent activity (derived)
Loading…
Lineage
Plugin lineage (The Norns) for ravenclaude-core — past, present, and proposed future, drawn live from git history, surfaced scenarios, and the manifest.
Urðr (Lessons & history) · Verðandi (Current) · Skuld (Proposed)
Urðr Lessons & history
Loading…
Verðandi Current
Loading…
Skuld Proposed
Loading…
Perimeter alerts
Perimeter alerts — a read-only mirror of what your guardrails already flagged. Heimdall never blocks anything itself; it shows the most recent hook denials, CI runs, and version drift so you can answer “what tripped, when, and why?” in one glance.
Recent hook denials
When did a guardrail say “no”? (red = irrecoverable, amber = blocked, grey = advisory)
Loading hook events…
Recent CI runs
The last few GitHub Actions runs on this marketplace.
Loading CI status…
Plugin version drift
Does each plugin’s version match the marketplace catalog?
Active alarms (Gjallarhorn)
The highest-severity signal currently flagged.
Knowledge health (Idunn)
How current is the marketplace’s knowledge layer? Click a bucket to drill into the files in it.
Loading knowledge health…
Security log
Posture & security event log (Víðarr’s shoe) — a read-only chronological record of how your security posture changed and which guardrails blocked an action. Víðarr’s shoe was assembled from leather scraps across all of time; this log is the same — small events accumulating against the day someone needs to know exactly what happened.
Loading security log…
Debt watch (Níðhöggr)
Slow-rotting bits at the foundations — low-noise marketplace maintenance signals.
Loading debt signals…
Help
Install & update guides, the full command catalog, and where the retired tabs went. Everything that used to have its own tab now lives here.
Where things moved
| Old link(s) | Where it is now |
|---|---|
#/home · #/overview · #/configure · #/simulator | Control (Settings) — the marketing home, the Overview tab, the non-writing posture editor (incl. its 167 always-checked “Plugin activation” toggles wired to nothing), and the “Preview a review” tab were removed. Settings is the one editor that saves; /__classify is kept for parity. |
#/team | Catalog — the specialist roster now lives in the marketplace. |
#/about · #/bifrost · #/install · #/commands | Help — folded into this drawer as the About, Claude Code, Copilot CLI, and Commands sections below. |
#/learn · #/trees · #/concepts | The standalone dashboard (rc dashboard → /dashboard) and the Pages copy — these Learn / decision-trees / Concepts payloads are not shipped in this portal. |
About & help — what this dashboard is
About this dashboard
Your control panel for working with Claude Code under RavenClaude. Set what Claude may do on its own and see the safety checks every command passes through (Set up); review past decisions, live runs, perimeter alerts, and your security log (Look back); read plain-English explainers, command playbooks, and decision-tree guidance (Learn); and add plugins or wire RavenClaude into your tools (Install & help). The Settings page is where you tune permissions — Deny (never), Ask (check first), or Allow (go ahead) per action type, across three layers (User, Local, Project) where the strictest wins; it saves to .ravenclaude/comfort-posture.yaml and the /set-posture skill turns that into Claude Code's own .claude/settings.json rules.
ravenclaude-core · static dashboard, no backend. Your edits stay in your browser until you click Download.
How the pages are organized
Everything is reachable from the navigation. The pages group into a few areas:
- Control — The Thing (what Claude may do on its own), the guardrail Pipeline every command passes through, and Web access.
- Activity — the live Run feed, plus the Review log, Session, Streams, and Lineage.
- Guardrails — Perimeter alerts, the Security log, and Debt watch.
- Plugins — each installed plugin, the specialists it adds, and how to install more.
- Learn & help — plain-English explainers, the command catalog, and install & update guides for Claude Code and GitHub Copilot CLI — including this page.
Claude Code — install & update a plugin (the Bifröst bridge)
Install & Update — Claude Code
Bifröst is the rainbow bridge between the marketplace and your Claude Code project. Follow these four steps to install a plugin, then see Updating an installed plugin below. Each step is copy-paste only — Bifröst guides you, but you cross the bridge yourself. Nothing here runs a command for you; you run each in your Claude Code session and paste the result back so Bifröst can light the next step. Using GitHub Copilot CLI instead? See the Copilot CLI guide (Help).
-
Not started
Step 1. Add the marketplace
Point Claude Code at the RavenClaude marketplace (a URL or a local path to a clone).
/plugin marketplace add <url-or-path>Paste what Claude Code printed (e.g. “marketplace added” or an error).
-
Not started
Step 2. Install the plugin
Install a plugin from the marketplace into your project. The name must match an entry in
marketplace.json’splugins[]./plugin install <plugin-name>@ravenclaudePaste the install result.
-
Not started
Step 3. Reload plugins
Make Claude Code pick up the newly-installed plugin.
/reload-pluginsConfirm you can see the plugin in your
/pluginmenu, then paste anything it printed (or type “I see it”). -
Not started
Step 4. Verify the bridge
Confirm the project is agent-ready with the plugin wired in.
/init-agent-ready --checkPaste the check output — green means the bridge holds.
If the bridge is down…
Check the URL or path. Common causes: a typo, a missing .claude-plugin/marketplace.json at that location, or no read permission. For a local clone, pass the absolute path to the repo root.
Check that the plugin name exactly matches an entry in the marketplace’s marketplace.json plugins[] array, and that you added the marketplace in step 1 (the @ravenclaude suffix is the marketplace name).
Try fully restarting Claude Code — the plugin cache can be stale. If it still doesn’t appear, re-run step 2; a partial install won’t show in the /plugin menu.
Open plugins/<plugin>/CLAUDE.md for the plugin’s required environment (env vars, CLIs, MCP servers). A red check usually means a missing prerequisite, not a broken install.
Updating an installed plugin
Once a plugin is installed you don’t re-run the wizard to update it — just refresh the marketplace catalog and reload. Run both in your Claude Code session:
/plugin marketplace update ravenclaude
/reload-plugins
Plugin versions bump on every user-visible change, so the catalog update is what surfaces a new version. Re-run /init-agent-ready --check (step 4) afterward to confirm the bridge still holds.
Verify the cache actually advanced
Claude Code reads installed plugins from ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/, indexed by ~/.claude/plugins/installed_plugins.json. If a reload doesn’t seem to take, check the cache directly — the most common failure mode is a stale entry. Run these in a shell (not in Claude Code):
jq -r '.plugins["ravenclaude-core@ravenclaude"][0].version' ~/.claude/plugins/installed_plugins.json
ls ~/.claude/plugins/cache/ravenclaude/ravenclaude-core/
The cached version should match the marketplace’s current version in plugins/ravenclaude-core/.claude-plugin/plugin.json. If they differ, re-run the two commands above (catalog update + reload). If they still differ, fully restart Claude Code — the cache lookup is read once at startup and the running session won’t pick up a newly-extracted version mid-flight.
Copilot CLI — install & update RavenClaude
Install RavenClaude — GitHub Copilot CLI
Follow these steps in order. Every command has a Copy button — you don’t need to type anything. Each step tells you what to expect after you run it. Using Claude Code instead? See the Claude Code guide (Help). Using OpenAI Codex CLI? Run the same installer with the Codex host flag — “ravenclaude install --host codex” — which wires skills into .agents/skills and hooks into .codex/hooks.json. One thing you must do there and nowhere else: Codex trusts hooks by hash, so run /hooks inside Codex to trust them, and again after every update — until you do they are skipped, and no banner will tell you, because the banner is itself a hook.
What is this?
RavenClaude is a kit of AI agents (architect, coder, reviewer, and friends) you can use
inside coding tools. GitHub Copilot CLI is GitHub’s command-line chatbot —
you type copilot in a terminal and it answers like a chat. This page shows how to plug
the RavenClaude kit into Copilot so the agents are there when you chat.
Before you start — what you need
Run each of these three checks. They print a version number if you have the thing already.
node --version
copilot --version
gh auth status
Missing the Copilot CLI? Install it:
npm install -g @github/copilot
Not signed into Copilot? Run copilot once. When it opens, type
/login and follow the prompts — you sign in with your GitHub account.
Step 1: Get RavenClaude onto your machine
RavenClaude lives in a GitHub repo. You clone (download) it once, into your home folder.
The squiggly line ~ means “your home folder” — on a Mac that’s
/Users/yourname, on Linux it’s /home/yourname, and in a Codespace
it’s /home/codespace.
gh repo clone mcorbett51090/RavenClaude ~/RavenClaude
After this: You have a folder at ~/RavenClaude with all the agent kits.
Every command below points back to this folder.
If the clone fails with “permission denied”: the repo is private —
make sure you ran gh auth login first and signed in with your GitHub account, then try the
clone again.
Step 2: Pick how you’re working
Two situations. Pick the one that matches you. (Click to expand.)
Situation A: I’m using a brand-new GitHub Codespace
A Codespace is a cloud computer GitHub gives you for a repo — it opens in your browser and looks like VS Code. If that’s you, follow these four steps to make RavenClaude set itself up automatically every time the Codespace opens.
-
Inside your Codespace’s terminal, run this once. It copies two
setup files into your project’s
.devcontainer/folder.bash ~/RavenClaude/scripts/ravenclaude init-codespace --project . -
Wire up THIS session right now (so you don’t have to rebuild to test).
Pick the plugins you want here — see Step 3 for what each one does.
Just the base kit (core only)
bash ~/RavenClaude/scripts/ravenclaude setup --project .Core + power-platform (example: a Microsoft Power Platform project)bash ~/RavenClaude/scripts/ravenclaude setup --project . --with-plugin power-platform -
Reload your shell so the new
rccommand works.source ~/.bashrc -
Commit and push the
.devcontainer/files so future Codespace builds are fully automatic.git add .devcontainer && git commit -m "Add RavenClaude Codespace auto-setup" && git push
After this: Every time you (or anyone on your team) opens a Codespace for this
repo, RavenClaude sets itself up automatically. The dashboard URL opens by itself in a new
browser tab. You just type rc to launch Copilot.
Situation B: I’m on my own computer (no Codespace)
Three steps. Pretty similar to Situation A, just without the Codespace auto-setup file.
-
Go to your project folder in a terminal. Replace the path with your
actual folder.
cd /path/to/your/project -
Wire RavenClaude into this project. Pick the plugins you want — see
Step 3 for what each one does.
Just the base kit (core only)
bash ~/RavenClaude/scripts/ravenclaude setup --project .Core + power-platformbash ~/RavenClaude/scripts/ravenclaude setup --project . --with-plugin power-platform -
Reload your shell so the new
rccommand works.If you use bashsource ~/.bashrcIf you use zsh (most Macs)source ~/.zshrc
After this: RavenClaude is wired into THIS project on this computer.
You type rc in a terminal (from this project’s folder) to launch Copilot.
Step 3: Pick your plugins
RavenClaude is split into plugins — separate kits for different jobs. Step 2
above showed how to pick them with the --with-plugin flag. Add the flag once per plugin
— for example: --with-plugin power-platform --with-plugin finance.
What’s in each plugin?
- ravenclaude-core — Always on. The base kit of generalist agents (architect, coder, reviewer, etc.) and the team-lead dispatch pattern. You never have to ask for this one.
- power-platform — Microsoft Power Platform specialists (Dataverse, Power Automate, Power Apps). Use this for any Microsoft project.
- finance — Finance-domain specialists for accounting workflows.
- web-design — Web design specialists (UX, visual, accessibility, performance).
- data-platform — Data engineering, ELT, dashboards, multi-tenant.
- and 12 others — see the Learn tab for the full list.
Already installed and want to add a plugin later? Re-run the setup command with the new plugin name. It’s safe to run again — it just adds the new skills alongside what’s already there.
bash ~/RavenClaude/scripts/ravenclaude setup --project . --with-plugin power-platform
Then, inside your running Copilot session:
/skills reload
Step 4: Launch Copilot with RavenClaude
One word from any terminal:
rc
What rc does: It pulls the latest RavenClaude (so you always have the
newest version), then launches Copilot with the agents and skills loaded. (rc is
short for “ravenclaude” — ravenclaude setup added it to your shell’s
~/.bashrc or ~/.zshrc.)
Updating later
rc auto-updates every time you launch — so usually you don’t do anything
extra. A few common variants:
1. Update and relaunch in one step — the everyday move:
rc
2. Update without launching Copilot — e.g. from a scratch shell or a script:
bash ~/RavenClaude/scripts/ravenclaude update
Then, inside your running Copilot session, pick up changed skills:
/skills reload
3. Verify what’s wired in this project — lists the version, the wired skills, the hook adapter, and the MCP entry:
bash ~/RavenClaude/scripts/ravenclaude status --project .
4. Relaunch from a running Copilot session — needed when you changed a hook or an MCP server (skills alone don’t need this; /skills reload is enough). Press Ctrl+C twice to quit, then:
rc
Using Claude Code on the same machine? ravenclaude update only refreshes
the Copilot side — it does not touch Claude Code’s plugin cache at
~/.claude/plugins/cache/. To update that side too, run
/plugin marketplace update ravenclaude and /reload-plugins inside Claude
Code. See the Bifröst cache-verification steps.
When do I need to rebuild my Codespace?
A rebuild tears down the Codespace and creates a new one. It’s slow — a few minutes. Most things don’t need one.
| What you did | Rebuild? | What instead |
|---|---|---|
Added or changed files in .devcontainer/ |
Yes | The .devcontainer/ files only take effect when the Codespace is built. Command Palette → “Codespaces: Rebuild Container”. |
Ran ravenclaude update (or rc) |
No | Skills read live from disk. Inside Copilot, type /skills reload. |
Added a new plugin with --with-plugin |
No | Inside Copilot, type /skills reload (or quit and re-run rc). |
| Changed settings on the dashboard | No | Dashboard’s Save & apply updates .claude/settings.json immediately. The engine reads it on each command. |
| Changed hooks or MCP servers | No, but relaunch | Hooks and MCP servers load when Copilot starts. Press Ctrl+C twice to quit, then type rc again. |
| Just opened the Codespace after pausing it | No | That’s a resume, not a build. The dashboard auto-launch fires on resume too. |
Common problems
“rc: command not found”
Your shell hasn’t loaded the new rc alias yet. Reload it:
source ~/.bashrc
If you use zsh (most Macs), use source ~/.zshrc instead. Or just close and reopen your terminal.
“gh: command not found” during the clone step
GitHub CLI isn’t installed. In a Codespace, it’s already there — if you see this, you’re probably on a local computer. Install it:
- Mac:
brew install gh - Ubuntu/Debian: see github.com/cli/cli
- Windows:
winget install --id GitHub.cli
After installing: gh auth login.
Copilot says it doesn’t know about an agent
Either Copilot was launched without --plugin-dir (the rc alias
handles this for you), or you need to reload skills. Inside Copilot, type
/skills reload. If that doesn’t work, press Ctrl+C twice to quit
Copilot, then type rc again.
Dashboard didn’t open automatically in my Codespace
Open the Ports panel in VS Code (View menu → Ports), find port 8000 labeled “RavenClaude dashboard”, right-click → Open in Browser. Don’t use the VS Code Simple Browser — it blocks parts of the dashboard.
I want to check what’s wired in my project
bash ~/RavenClaude/scripts/ravenclaude status --project .
Prints what’s in .claude/skills, .github/hooks, and
~/.copilot/mcp-config.json.
Under the hood: RavenClaude reads everything live from disk. The plugin
loads via --plugin-dir, skills from .claude/skills, hooks from
.github/hooks, MCP from ~/.copilot/mcp-config.json. So
ravenclaude update is just a git pull on the marketplace clone —
no re-install, ever. There’s no plugin cache to invalidate, no version registry to update.
The hooks land at repo level (not plugin level) as a workaround for
copilot-cli#2540 — plugin-level
preToolUse hooks don’t fire in Copilot today.
Commands
Copy any of these and run them in your checkout. They work everywhere, even when this page is opened from GitHub Pages or a file.
bash scripts/ravenclaude setupbash scripts/ravenclaude installcopilot --plugin-dir plugins/ravenclaude-core/copilotbash scripts/ravenclaude updatebash scripts/ravenclaude statusalias rc='bash scripts/ravenclaude update && copilot --plugin-dir plugins/ravenclaude-core/copilot'One-click run
● live
Run python3 scripts/serve-dashboards.py for one-click, or use the copy
buttons above.
Bridge status
Click Status to check which pieces (skills, hooks, MCP, package) are wired. Needs the local server.
Codex CLI & other agents — what is wired, and what is not
Two lanes above cover Claude Code and Copilot CLI. This is the rest of the world, stated honestly. OpenAI Codex CLI is supported: run bash <marketplace>/scripts/ravenclaude install --host codex --project <your-repo>. It wires the skills into .agents/skills and the guardrails into .codex/hooks.json — Codex speaks the same hook contract as Claude Code, so there is no adapter — and it projects your posture onto Codex’s own OS sandbox. One thing you must do there and nowhere else: run /hooks inside Codex to trust them, and again after every update, because Codex tracks hook trust by hash and silently skips anything it does not recognise. Cursor and Gemini CLI have guardrail hooks wired (shell commands are screened in-loop) but no skills mechanism; Aider and Windsurf / Devin Desktop have no hooks at all, so CI is the only gate there. Cursor, Gemini CLI and Aider still read the projected instruction files, so the discipline travels even where enforcement does not — a gap, not a hidden feature; the per-component truth is in knowledge/host-support.json, and the first-five-minutes ritual for any of them is the external-agent-onboarding skill.
Commands — the marketplace slash-command catalog
Plugin variables
Pick a plugin to edit its variables. Most plugins expose no curated knobs — for those, the free-form values you enter are saved to .ravenclaude/plugins/<plugin>.yaml but are not currently read by any hook (153 of 167 plugins are free-form only). For the full reference — agents, scenarios, skills, hooks, templates, best-practices — read the plugin's own directory under plugins/<name>/, or browse the marketplace repo's portal if you have a clone of it. (Corrected 2026-07-29, audit MH-22: this used to say “open the plugin in the portal’s Marketplace section” — but the portal is index.html at the MARKETPLACE repo root, and a consumer who installs the plugin and runs the dashboard gets this page and no portal at all. It pointed at something you do not have.) Deep-link: Plugin variables.
Setting
What this controls
Examples
Recommended level
When to relax or tighten
Pattern
What this is
Why it's here
How layers merge
Claude Code reads three settings files and merges them at runtime. The strictest rule across all three always wins — a personal “allow” cannot loosen a team “ask” or “deny”.
~/.claude/settings.json — applies to every project on your machine. Only you see it; it is never committed to git. Use it for personal preferences that apply everywhere.
.claude/settings.local.json — project-specific but gitignored. Stays on your machine. Use it for project-level tweaks you do not want to share with teammates.
.claude/settings.json — committed to the repo and shared with the whole team. Whatever you set here becomes the team baseline. A personal “allow” at User or Local cannot soften it.
Merge rule
deny > ask > allow. For any permission pattern, Claude Code takes the strictest bucket it finds across all three files. Setting “inherit” at a layer means that layer emits no rule — Claude Code falls back to its built-in default for that pattern.
Dashboard convention
Presets set the Local layer — your personal default for this project. The User layer is for cross-project preferences; the Project layer is for team-wide policy. Rows set to “inherit” are omitted from the emitted YAML.