Menu
Use when writing a new galdr skill, editing an existing one, or running the pack's quarterly prune review.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use once a spec is approved and ready to become an executable task list — turns spec requirements into a wave-based plan of write-scoped, testable tasks that waves can dispatch. Invoke via route or explicit command.
Use when a plan already exists and is ready to run — dispatches each wave's tasks, reviews every return before trusting it, and gates advancement on evidence. Invoke via route or explicit command.
Continuation protocol for resuming work after a break, handing off to another session, a subagent, or Codex, and parking fast under a usage limit. Invoke via route or explicit command.
Use once per repo to create or refresh docs/agents/galdr.md — the config verify, waves, review, branches, and route read for gate commands, invariants, models, and smoke details. Slash-command only, not router- or model-invoked.
Use when the user runs /galdr:core to install, uninstall, or check galdr's core rules block on this machine for Claude, Codex, or Antigravity. Run install once per agent to write the marked block into that agent's rules file (or the Claude enabled flag); uninstall to remove it; status to report state without writing.
Use when turning a fuzzy idea, a position to stress-test, or a set of already-clear requirements into a written spec — grill mode tests a position, explore mode is open-ended, synthesis mode drafts straight from clear requirements. Invoke via route or explicit command.
| name | authoring |
| description | Use when writing a new galdr skill, editing an existing one, or running the pack's quarterly prune review. |
| disable-model-invocation | true |
Applies galdr's own build rules to galdr's own skill work — this file included. Every
change to a SKILL.md or a references/ file in this pack goes through the checks
below before it's written.
Before writing a line, ask: does this line change behavior versus not having it? If a model already does this by default, the line is a no-op — cut it, don't soften it. Run this at the sentence level, not just the section level: a file that reads clean can still hide individual no-op sentences.
A discipline skill enforces a rule under pressure (tdd, verify, debug, bootstrap,
route, continue). For these, run the scenario without the skill first, per
testing/protocol.md §1, and record the verbatim rationalization under ## Baseline captures in the scenario file. Every row in the skill's rationalization table must
trace to a captured excuse. A row invented without a capture is a guess, and a guess
misses the loophole the agent actually reaches for — write the baseline run before the
table, not after.
General skills (reference, orchestrator) skip this step; they go straight to the
spot-check in testing/protocol.md §2.
Two different failures need two different fixes, and each form backfires on the other's failure:
| Failure | Right form | Why the other form fails |
|---|---|---|
| Skips or breaks a rule under pressure | Prohibition + rationalization table built from captures | A positive recipe leaves the rule negotiable — the agent complies with the letter, not the discipline |
| Output has the wrong shape (bloated, buried, restated) | Positive recipe: state the output's parts, in order | A prohibition ("don't restate") gives the agent something to argue around instead of a shape to fill |
Prohibition tables are for rule-skipping only. Everywhere else, write the positive recipe.
Every skill spends two separate budgets:
description, loaded whether the skill fires or
not. Keep it to trigger conditions.references/ file — the body stays lean, the reference
loads only when its pointer fires.Before adding a paragraph, name which budget it's charged to. If it's the description, it must be a trigger, not an explanation of mechanics.
The description says when to use the skill, never how it works inside. "Use when reviewing a branch" is a trigger; "runs two parallel review passes and merges them" is a mechanics leak — cut it. A description that summarizes the workflow teaches the agent to act on the summary and skip the body.
A references/ file may hold detail the body doesn't need on every run. It may not
point to a references/ file of its own — one hop from SKILL.md, no deeper. A
reference file that needs its own reference means the skill is doing too much; split
it instead.
Every step or procedure this skill's content prescribes states when it's done — checkable, not "produce a good result." A step with no completion criterion invites stopping early, because nothing says what "done" looks like. Write the criterion before the step that leads to it.
Test cost matches the skill's kind. testing/protocol.md is canonical for both
procedures — the one-line routing rule: discipline skills take the pressure test
(§1: RED baseline, then GREEN with the skill's content pasted inline); every other
skill takes the retrieval spot-check (§2: load the SKILL.md, ask the scenario's probe,
check the answer cites the right section). Everything past that routing lives in
protocol.md alone.
Check before committing:
wc -l skills/<name>/SKILL.md
A budget is a ceiling, not a target — don't pad a skill to reach it. Budget growth is not a rewrite convenience: per spec §12, a discipline skill's budget grows only after it fails its pressure campaign at the current size, and that failure is the justification recorded in the commit. Growing a budget with no failed pressure run to point to is scope creep, not maintenance.
On a quarterly cadence, or whenever the pack feels heavier than it earns:
The ritual is done when every currently-installed skill has a fired/not-fired verdict for the quarter and every "not fired" skill has an explicit keep-or-deprecate decision.