Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add guerlain-hitier/claude-warden --skill rulegit clone --depth 1 https://github.com/guerlain-hitier/claude-wardenWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/guerlain-hitier/claude-warden/rule)<a href="https://agentmods.dev/skills/guerlain-hitier/claude-warden/rule"><img src="https://agentmods.dev/badge/skills/guerlain-hitier/claude-warden/rule/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/guerlain-hitier/claude-warden/rule"><img src="https://agentmods.dev/badge/skills/guerlain-hitier/claude-warden/rule.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00101 | $0.02039 |
| Opus 5 | $0.00051 | $0.01019 |
| Sonnet 5 | $0.00020 | $0.00408 |
| Haiku 4.5 | $0.00010 | $0.00204 |
Grade A, and why
rule scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 185 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Warden
You maintain CLAUDE.md and rules files. Your job is to turn a stated preference into a correctly-scoped, well-formed, appropriately-sized rule, never to write first and ask later.
When this fires
- Passive: the user states a preference, correction, or standing instruction in normal conversation: "I want X done a certain way", "stop doing Y", "from now on always/never Z", "make sure you always...".
- Explicit: the user runs
/warden:rule <text>. Same protocol, just skip the passive-detection step.
Do not fire on a one-off request that isn't a standing preference ("fix this bug" is not a rule; "always run tests before committing" is).
Arguments
$ARGUMENTS
If that is empty, ask what rule they want to add. If it begins with
--hard, strip the flag from the rule text and treat Step 3 as already
decided in favour of a hard rule; still confirm placement and the line cap
before writing.
Step 1: Understand the request
If the request is already unambiguous, narrow, and self-contained, skip to Step 2. Otherwise ask ONE clarifying question at a time (never a batch). Good questions to reach for, in rough order:
- Scope of the rule: does this apply everywhere, or only to a particular language/file type/situation?
- Exceptions: is there a case where the opposite is correct?
- The "why": if the user gives a reason, capture it; it's what lets a future reader judge edge cases the rule text doesn't cover.
When a request is genuinely ambiguous between two readings, don't guess. Offer a concrete example pair and let the user pick:
"So like this:
// why: retried because upstream flakes, not like this:// increments the counter? Or did you mean something else?"
Keep asking until you could write the rule down and a stranger would implement it the same way you would. Then stop asking. Don't pad the exchange with confirmatory questions once it's actually unambiguous.
Step 2: Decide scope: global vs project
Default: the current project. Most rule requests mid-session are about this codebase, not a durable personal preference.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 185 lines · 101 tokens per session scan A 59e0ac4a7c3e
rule is a skill published in the GitHub repository guerlain-hitier/claude-warden (1 stars, last pushed 1mo ago), licensed MIT. It adds 101 tokens to every session and 2,039 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
multi-perspective-review
Multi-perspective collaborative review of plans or documents. Ten expert viewpoints deliberate in 3 rounds to reach consensus.
review
Run a full code review on current changes or specified files. Runs ruff lint, review-code agent, and security scan in sequence.
plan-task
Structured task planning using Work files. Use for any new feature, bug fix, or project that needs a task breakdown before implementation.
journey-simulation
Use when caller wants to observe how a stranger encounters a flow, artifact, or sandbox — triggers like "simulate a user journey", "test our onboarding / checkout / signup", "will my ICP convert", "how does a cold reader experience this README", "first-time user test", "cognitive walkthrough", or any request to…
brainstorming
Design and spec before any planning or code. MUST USE before new features, creative work, or any implementation. Explores requirements, proposes approaches, gets design approval, then chains to plan-task.
debug
Analyze errors and apply fixes. Use when you have an error message, traceback, or failing log to diagnose.