Borrowing it
Nothing to install: this file belongs to ForgeyClap/claude-forge. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/ForgeyClap/claude-forge/main/.claude/skills/forge-guardian/SKILL.mdgit clone --depth 1 https://github.com/ForgeyClap/claude-forgeWrote 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/forgeyclap/claude-forge/forge-guardian)<a href="https://agentmods.dev/skills/forgeyclap/claude-forge/forge-guardian"><img src="https://agentmods.dev/badge/skills/forgeyclap/claude-forge/forge-guardian.svg" alt="Measured on agentmods" 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.00040 | $0.01650 |
| Opus 5 | $0.00020 | $0.00825 |
| Sonnet 5 | $0.00008 | $0.00330 |
| Haiku 4.5 | $0.00004 | $0.00165 |
Grade A, and why
forge-guardian 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 7d 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 — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Forge playbook — Guardian (deploy -> monitor -> reproduce -> self-heal -> redeploy)
STATUS: SCAFFOLD. Nothing in this file is wired to any live production system in this project. No
forge-bin/ tool currently deploys, monitors a live endpoint, or redeploys anything — this skill exists
so the design is available and reviewable, not because the capability is running. Do not report Guardian
as "active" or "monitoring" anything unless the owner has supplied real production access AND approved a
live circuit-breaker for that specific environment. Absent both, Guardian stays exactly what it is here: a
documented design.
Do not duplicate existing tools — defer to: forge-actiongate.cjs (the ONE hard-gate classifier every
deploy/redeploy step below MUST route through — never a parallel gate), forge-checkpoint.cjs (idempotency
for any redeploy/rollback action so a retry never double-deploys), forge-briefing.cjs (surfacing an
incident as a real "decision needed" item, the same evidenced pattern forge-nightshift uses), and this
project's existing "no mandatory security gates but hard-gates always stop" governance
(CLAUDE.md + config/orchestration/hard-gates.json).
The loop this doctrine describes
- Deploy — an explicit, owner-approved release to a named environment. Always classified through
forge-actiongate.cjs::classify()(gate iddeploy,prod-activate, or equivalent) BEFORE it happens; never a Guardian-internal deploy path that bypasses the existing gate. - Monitor — after a real deploy, watch the environment's own real signals (health checks, error rate, latency, a smoke test) — never fabricated or assumed-passing telemetry. If no real monitoring source is wired for an environment, Guardian has nothing to watch and says so honestly, rather than inventing a "healthy" status.
- Reproduce — when a real signal indicates a regression, reproduce it with an actual failing
check/test BEFORE attempting any fix (mirrors this project's
forge-debugskill: reproduce → isolate → root-cause, never a guessed patch). A "fix" with no reproduction is not a fix, it's a guess. - Self-heal — propose (and, ONLY with the circuit-breaker below open, apply) the smallest correct fix for the reproduced regression: a code fix + regression test, a config rollback, or a redeploy of the last known-good artifact. Every one of these is itself a write/deploy action and is gated exactly like step 1.
- Redeploy — the fixed/rolled-back artifact goes out through the SAME
deploygate as step 1. There is no separate, lower-scrutiny "redeploy" path — a redeploy is a deploy.
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.
- 7d ago First seen · 93 lines · 40 tokens per session scan A c0a914918b46
forge-guardian is a skill published in the GitHub repository ForgeyClap/claude-forge (2 stars, last pushed 1mo ago), licensed MIT. It adds 40 tokens to every session and 1,650 once invoked, about $0.0002 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
browser-edge-cases
SOP for debugging browser automation failures on complex websites. Use when browser tools fail on specific sites like LinkedIn, Twitter/X, SPAs, or sites with Shadow DOM.
triage-issue
Analyze a GitHub issue, verify claims against the codebase, and close invalid issues with a technical response.
hive.error-recovery
Follow a structured recovery decision tree when tool calls fail instead of blindly retrying or giving up.
manage-skills
A maintenance workflow for checking whether project verification skills still cover the code and rules that changed during a session.
review-loop
Run the adversarial verification loop — implement, then hand the change to a fresh checker that did not write it, fix what it finds, and re-dispatch until APPROVE. Use before claiming any behavioural change is done, and on requests like "review loop", "adversarial review", "independent review", "get this verified"…
ai-slop-cleaner
Post-implementation cleanup that removes AI-generated bloat while preserving functionality. Runs pass-by-pass with test verification after each pass. Activate after kraken/spark complete a feature, or when a codebase needs hygiene work.