Platform-Side Usage: Commands, Skills, Rules, Hooks, and Agents¶

Which of the 37 platforms supports what? → the Platform Support matrix — per-platform ✅/⚠/❌ for every CRASH component plus MCP and engine tier, with the honest gap list, and per-platform reference pages linked from every row.

Just want the quick version for your platform? → Use gald3r With Your Platform — a short, one-page-per-platform overview (what installing gald3r gives you, by exact product name) that links through to the full matrix and reference pages above.

Everything else in this doc set documents gald3r as a terminal binary. This page is for the other way most people actually meet it: inside an AI IDE or coding agent — Cursor, Claude Code, Kimi Code, Codex, GitHub Copilot, Devin Desktop (formerly Windsurf), and the rest of the supported roster — driving gald3r through slash commands, skills, and agent personas instead of typing gald3r <verb> yourself. That in-IDE layer is called CRASH (Commands, Rules, Agents, Skills, Hooks); see crash.md for the full technical breakdown with real component source. This page is the user-facing companion: what you actually see and do, not how the mechanism is built.

Every command, skill, rule, hook, and agent named below was checked against this repo's own component catalog while writing this page — nothing here is invented or aspirational.

1. The CRASH overlay, in user terms¶

Once gald3r itself is installed, gald3r platform install <platform> (see install.md §3) writes that one platform's overlay into your project — the actual files your IDE reads:

gald3r platform install claude       # writes .claude/ into the current directory
gald3r platform install cursor       # writes .cursor/ into the current directory

For Claude Code that overlay is .claude/commands/, .claude/rules/, .claude/skills/, .claude/agents/, .claude/hooks/, plus .claude/settings.json (hook registration) and a root CLAUDE.md that imports AGENTS.md (Claude Code reads CLAUDE.md, not AGENTS.md, directly). Most other platforms read AGENTS.md as their root instruction file natively — no import needed. Which file goes where, and which one your IDE actually parses, differs by platform; the quick-start matrix below spells it out platform by platform, and crash.md has the mechanism-level detail (including a real trimmed hook source and the gald3r crash-stats activation-count command).

You generally don't hand-edit any of these folders. Every file under them is a flat or recursive copy of this repo's canonical neutral_source/ tree — a fresh gald3r platform install <platform> (safe to re-run) or a future gald3r update overwrites them with the current version. A local edit inside .claude/commands/g-status.md, for instance, does not survive the next install/update; there is no reconciliation step that preserves it. If you're a contributor to gald3r_core itself (not an end user of it), the equivalent for this repo's own IDE copies is gald3r sync --apply — that verb is dev-only and does not apply to your own gald3r-enabled project.

2. The command layer¶

Prefix conventions¶

Platform	How you type a command
Claude Code	`/g-<name>` (e.g. `/g-status`)
Cursor	`@g-<name>` (e.g. `@g-status`)
Most other platforms with a native command/prompt-file surface	`/g-<name>`, using that platform's own slash-command or prompt-file convention

Every command's source file already carries its canonical name (g-status.md, g-task-add.md, ...) — no platform renames it, so the visible command name is the same everywhere; only the invocation punctuation and folder differ. Not every platform has a dedicated command layer today — see the caveats column in the quick-start matrix for the ones where gald3r commands are reached through skills instead.

`-h` / `--help` never mutates state¶

Every gald3r command answers a bare -h, --help, or help argument (exactly one token, nothing else) with a short usage card — its purpose, its documented arguments, and the path to its command file — and stops there. No .gald3r/ write, no task/bug creation, no side effect of any kind. /g-status --help and /g-status are not the same operation; only the second one runs the real status report. This is enforced in every skill's own preamble (the HELP CONTRACT block), not left to an individual command file to remember.

Everyday command tour¶

A cross-section of commands most people reach for day to day (see the Commands reference for the full, current total — this is nowhere near all of them):

Command	What it does for you
`/g-status`	Project status at a glance — task/bug counts, completion %, what's blocked and why, what's waiting on you.
`/g-task-add`	Create a tracked task — gets an ID, a complexity score, and a `TASKS.md` row, all in one call.
`/g-bug-add`	Log a defect the moment you spot it (`BUG-NNN`) so it never quietly disappears in a chat transcript.
`/g-go`	Two-phase pipeline: implement whatever's next on the queue, then automatically hand off to a fresh reviewer session — you get an implemented-and-reviewed result back, not just code.
`/g-go-code`	Same implementation phase as `/g-go`, but stops at "awaiting review" — use this when you want to review it yourself, or batch several tasks before reviewing any of them.
`/g-go-review`	Independently verify tasks/bugs sitting in "awaiting review" — pass/fail scored, never self-reviewed, commits the verdict.
`/g-go-go`	Autopilot: rolling implement-then-review cycles across your whole queue until the backlog's clear or a hard stop hits.
`/g-medic`	Health check and repair for `.gald3r/` itself — broken links, stale indexes, drifted files, auto-fixing what's safe to fix.
`/g-report`	A backlog status report: last commit, what's available/in-progress/blocked, and a recommendation of what to do next.
`/g-code-review`	Depth-scaled code review (quick/standard/comprehensive) on specific files, a PR, or your recent changes.
`/g-git-commit`	A structured commit with a task-aware message and staging-safety checks, instead of hand-writing one.
`/g-idea-capture`	Drop an idea into `IDEA_BOARD.md` without derailing whatever you're doing right now.
`/g-plan`	Walk through creating or updating `PLAN.md`, `PROJECT.md`, and `SUBSYSTEMS.md`.

For the complete command catalog — one usage card per command (purpose, when to use, arguments, a /g-/@g- example, related commands) — see the generated Commands reference. It is produced straight from each command's own frontmatter, so it regenerates every release and cannot drift from what actually ships. verbs.md documents the equivalent bare-CLI verbs these commands dispatch to, if you want the binary-verb side instead — the command and the CLI verb run the same underlying logic either way.

3. Skills: the instructions behind the commands¶

A skill (SKILL.md) is the actual instruction package a command hands off to — commands themselves are thin dispatchers (see the real g-wpac-notify example on crash.md). A skill loads in one of two ways:

Command-invoked — running /g-status loads g-skl-status.
Judgment-invoked — your agent decides a skill is relevant on its own, based on that skill's frontmatter description: field, without you typing a slash command at all.

See the Skills reference for the full, current skill count and a usage card per skill — purpose, when to use, and which commands (if any) dispatch to it, regenerated from source so it can never go stale. As with commands, you don't hand-edit skills — they're regenerated verbatim by platform install/update. If a skill's behavior needs to change, that happens upstream in the source tree, not by patching your local copy.

4. Rules: always-apply, every session¶

Rules (g-rl-*.md, e.g. .claude/rules/g-rl-33-enforcement_catchall.md) load automatically at the start of every session — no command needed. They encode standing constraints a project should never have to restate: for example, one of this repo's own rules mandates gald3r search over raw grep for anything that might touch a gitignored tree, because a plain ripgrep search silently skips gitignored directories. See the generated Rules reference for the full, current set and what each one does.

Rules are framework-managed, not user-managed: they load as plain optional context (how strictly an IDE enforces "always apply" varies by platform — see the Rules column in the quick-start matrix), and updates arrive the same way commands and skills do — by re-running gald3r platform install <platform>, never by hand edit.

5. Hooks: the one CRASH type that is real, executing code¶

Hooks are plain Python scripts wired into your IDE's lifecycle events by a platform-specific registration file — .claude/settings.json's "hooks" key for Claude Code, .cursor/hooks.json for Cursor, and so on (copying the script alone does nothing; the registration file is what makes it fire). Common events: session start (g-hk-session-start.py — checks/heals .gald3r/, assembles a context banner), pre-tool-call (guards that can refuse a risky edit before it happens), and stop/agent-complete (session wrap-up, logging).

What you see when a hook blocks something. A blocking hook exits with a non-zero status and writes its reason to stderr — that's the contract your IDE surfaces to you as a denial, not a crash. A real example, from g-hk-pre-tool-call-gald3r-guard.py (this repo's own hook, guarding direct edits to .gald3r/):

# exit 2 is Claude Code's "blocking error" contract -- the reason MUST be
# written to STDERR, not stdout, or the IDE has nothing to surface as a denial.
sys.stderr.write(msg + f" Target path: {path}\n")
return 2

The message itself (also real) tells you exactly what to do instead: "Direct Edit/Write to .gald3r/ refused ... Route the change through the appropriate gald3r agent (g-task-manager / g-qa-engineer / g-planner / ...)". That's the pattern across every gald3r hook: a block always comes with a stated reason and a next step, never a bare failure. If you instead see a traceback, an unhandled exception, or output with no stated reason, that's a genuine error — worth reporting, not a hook doing its job. See the generated Hooks reference for what each hook does and which lifecycle event fires it.

6. Agents: the `@g-agnt-*` roster¶

An agent definition narrows a whole session to one job. Invoke one directly with @g-agnt-<name> when you specifically want that narrower framing (for example, forcing a fresh, unbiased verification pass); otherwise, let commands route to the right skill on their own — most day-to-day work never needs a direct agent invocation.

Agent	Use it for
`@g-agnt-task-manager`	Task lifecycle — create, update, complete.
`@g-agnt-project`	Feature writing, planning, `PROJECT.md`, `CONSTRAINTS.md`.
`@g-agnt-qa-engineer`	Bug tracking and quality assurance.
`@g-agnt-code-reviewer`	Code quality and security review.
`@g-agnt-infrastructure`	File organization, scope boundaries, `SUBSYSTEMS.md`.
`@g-agnt-ideas-goals`	Idea capture, `IDEA_BOARD.md`, goal management.
`@g-agnt-verifier`	Verifying work you did not implement yourself — a structural fresh-eyes check, not just a suggestion.
`@g-agnt-project-initializer`	First-time gald3r project setup.
`@g-agnt-test`	Fast/comprehensive/regression test-plan creation and maintenance.
`@g-agnt-platformer`	Cross-platform IDE/agent integration upkeep — this is the agent that maintains the very overlay this page documents.
`@g-agnt-marketing`	Marketing voice and copy — launch posts, announcements, landing copy.
`@g-agnt-workspace-manager`	Workspace-Control manifest init/validate, member add/remove.
`@g-agnt-wpac-coordinator`	Cross-project coordination — topology, inbox triage, broadcasts, syncs.

See the generated Agents reference for a fuller usage card per agent, including the Claude Code Task-tool invocation form.

7. Per-platform quick-start matrix¶

Sourced from what platform install actually writes and each platform's own native capability truth — not guessed. Where a platform's convention is a known gap rather than a real capability, it's called out rather than glossed over. See the Platform Support matrix for the full 37-platform capability grid; these six are the ones named most often.

Platform	Prefix / invocation	Overlay location	Root instructions file	Caveats
Claude Code	`/g-<name>`	`.claude/{commands,rules,skills,agents,hooks}/`	`CLAUDE.md` (imports `@AGENTS.md`)	Hooks register via `.claude/settings.json`'s `"hooks"` key, not a `hooks.json` file — see Troubleshooting → Windows dual-exe note if a command returns instantly with no output on Windows.
Cursor (reference platform)	`@g-<name>`	`.cursor/{commands,rules,skills,agents,hooks}/`	`AGENTS.md` (native)	Rules use `.mdc` (not plain `.md`); hooks register via `.cursor/hooks.json`. All other platforms' overlays are derived from Cursor's.
Kimi Code	(no dedicated command layer yet — known gap)	`.kimi/skills/` + `.kimi/.mcp.json` only	`AGENTS.md` (native)	Today's install ships Skills + MCP + `AGENTS.md` only — no `commands/`, `rules/`, `hooks/`, or `agents/` overlay is generated for Kimi yet, even though Kimi Code natively supports all of those. Invoke gald3r skills directly by name (e.g. `g-skl-status`) using Kimi's own skill-invocation syntax until the command layer lands.
OpenAI Codex	`/g-<name>` (via `.codex/prompts/*.md`, OpenAI's now-deprecated-but-functional "Custom Prompts" mechanism)	`.codex/{prompts,hooks}/` + `.agents/skills/`	`AGENTS.md` (native)	Hooks register via `.codex/hooks.json`; no dedicated `rules/`/`agents/` overlay path in today's generator — rely on `AGENTS.md` + skills.
GitHub Copilot	`/g-<name>` (VS Code Copilot Chat only — prompt files are not read by the Copilot CLI)	`.github/prompts/*.prompt.md`, `.github/hooks/`, `.github/agents/`, `.claude/skills/`	`copilot-instructions.md` (concatenated from gald3r rules) + reads `AGENTS.md`	Capability support is fragmented per surface (VS Code vs. CLI vs. JetBrains vs. cloud agent) — check which surface you're on before assuming a feature is available.
Devin Desktop (formerly Windsurf; Cascade IDE)	`/g-<name>` (Workflows)	`.windsurf/{workflows,hooks,skills}/`	`AGENTS.md` (native)	Hooks register via `.windsurf/hooks.json`; no dedicated `rules/`/`agents/` overlay path in today's generator — rely on `AGENTS.md` + skills.

Where next¶

The generated CRASH reference — one usage card per item, regenerated every release from neutral_source/ frontmatter (never hand-maintained, so it cannot drift from what ships): Commands, Rules, Agents, Skills, Hooks.
install.md §3 — the exact platform install mechanics, real output, and the .claude/settings.json non-destructive merge behavior.
crash.md — CRASH internals: a real command file, a real hook docstring, and gald3r crash-stats in action.
verbs.md — every bare-CLI verb these commands dispatch to.
task-bug-workflow.md — the full task/bug lifecycle these commands drive.
Troubleshooting → Windows dual-exe note — relevant if a hook-invoked gald3r call ever seems to vanish with no output on Windows.