guardrails — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited guardrails (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Verification gates that block the agent from proceeding until checks pass. The agent already knows what linting, testing, type checking, and security scanning are. This skill doesn't re-teach those concepts. Instead, it specifies:
These are the behaviors a coding agent wouldn't exhibit without being told. Everything else — which linter to use, how to structure a unit test — the agent already knows from training and discovers from the project's existing config.
Bundled resources: references/tool-building.md contains the diagnostic tool and notation catalogs with worked examples. references/language-defaults.md is a lookup table for tool selection by ecosystem. Read these when directed, not proactively.
Not every check applies to every project. The common base applies everywhere: lint, format, types, SAST, dependency audit, secrets scan, dead/duplicate code detection, coverage, unit tests (tool lookup: references/language-defaults.md). Beyond that, add layers by project type:
Scale up as the project matures. A prototype needs the common base. A production system serving users needs the full suite.
Hooks make guardrails real: they block the agent from proceeding until checks pass. A failing check gives concrete, unambiguous feedback; prose alone competes for attention.
The enforcement system needs two commands in the target project — one fast, one full:
Fast check — Runs in seconds. Fires on every agent stop. Covers: format check, lint, type check, unit tests.
Full suite — Runs before every commit. Covers: everything in the fast check plus integration tests, property tests, secrets scan, dead code detection, duplicate code detection, coverage floor.
Discover, don't impose. Every ecosystem has its own convention: npm scripts (npm test, npm run test:unit), Makefile targets (make test, make check), Go commands (go test ./...), pytest (pytest tests/unit), bun scripts, Cargo, etc. During SessionStart, find what the project already uses by inspecting package.json scripts, Makefile targets, CI workflow steps, and README instructions. Adapt to the project's existing runner — don't create a new one alongside it.
If no test runner exists at all, create one using the project's native tooling. Consult references/language-defaults.md for tool selection. The runner must exit non-zero on failure.
Fires when the agent boots up. Discovery and baseline before touching anything.
Identify the project type (Scope section) and determine which checks apply.
mocking, fixtures. Match them.
LESSONS_LEARNED.md if it exists. Apply project-specific lessons.script/agent-tools/. Read the directory and description comments to knowwhat diagnostic tools are available from previous sessions.
Defer to existing conventions. When the project has tooling or patterns in place, follow them — even when they conflict with this skill. Do not switch tools or frameworks without explicit user approval.
Fires every time the agent returns control. Prevents declaring success without verification.
Return a decision with evidence, not just a label:
matching tests, or the circuit breaker was skipped.
production files changed, tests changed or non-production reason, and required next action. A bare "BLOCK" is not enough evidence.
Thrashing circuit breaker. If the fast check fails and the agent has already attempted the same fix twice, it cannot try a third direct fix:
(read references/tool-building.md). Two failed attempts means the agent's model of the problem is wrong — re-reading the same code produces the same wrong model. New information or a different representation breaks the loop.
what's failing, what was tried, what the diagnostic revealed, why it isn't converging.
The breaker resets when the user provides new direction. Persist useful diagnostics to script/agent-tools/.
Completion check. After the fast check passes, check your task list. If planned work items remain and you are not blocked, continue to the next slice — do not hand off. Hand off only when: all items are done, the circuit breaker fired, or context is running low (in which case, commit completed slices and report remaining items).
Work in slices, but finish the job. Verify frequently — a good slice is 1-3 production files plus tests. An agent that writes 15 files then discovers a type error in file 3 has wasted 4-15. But verifying a slice is not completing the task. Do not hand off to the user until all planned work items are done or you are explicitly blocked.
Fires on any git commit, whether from the agent or a human. Same enforcement for both.
Code that passes tests but isn't wired into the application is a deployment gap. Confirm: new modules imported? Routes registered? Migrations included? Entry points updated? If nothing invokes the new code, that's a failure even with passing tests.
fix: prefix or fixinga reported issue), answer three questions before committing:
missing from the verification layer?
test case, type constraint, assertion, or lint rule — not just a prose note.
exist, fix them in this commit or track them explicitly. Block the commit if any question is unanswered.
When direct fixes fail, the agent needs new information or a different problem representation. Read `references/tool-building.md` for the full catalog of diagnostic tools, notations, and three worked examples.
The circuit breaker (Stop hook) mandates reading this reference after 2 failed attempts. But the best use is proactive: recognize the problem shape during planning and build scaffolding before writing code. Common patterns:
Diagnostic tools often graduate into permanent infrastructure — reproduction scripts become test cases, schema checkers become health checks, dependency mappers feed the integration check. Building a diagnostic tool is not a detour; it's often the most direct path to completing the task.
The agent does not edit its own guardrail configuration. An agent under pressure to make tests pass has an incentive to weaken the tests rather than fix the code. Block the agent from modifying: test scripts, lint/format/type config, CI definitions, pre-commit config, and coverage thresholds. If config needs changing, propose it to the user.
Some operations have blast radius beyond the current code change. Even if the user's request implies them, the agent stops and asks because these are irreversible or affect systems beyond the codebase:
Describe the operation and blast radius, then wait for confirmation.
The agent accumulates project-specific knowledge across sessions. Without a persistent record, each session starts from zero and risks repeating the same mistakes.
Maintain LESSONS_LEARNED.md in the project root. Append an entry when encountering: a guardrail failure requiring multiple attempts, a non-obvious project convention, a surprising tool behavior, a deployment gap tests didn't catch, a bug fix retrospective that revealed a detection gap, a thrashing episode, or a diagnostic tool that proved useful.
Entry template:
### YYYY-MM-DD — [short title]
**Context:** What task was being performed.
**What happened:** The surprising behavior or failure.
**Resolution:** How it was resolved.
**Rule:** [One-line directive for future sessions to follow.]Example:
### 2026-02-14 — Custom validation framework
**Context:** Adding input validation to /users endpoint.
**What happened:** Started with express-validator, broke existing tests. Project uses a custom rule-based validator in src/validation/ — not documented anywhere except inline comments in rules.js.
**Resolution:** Rewrote validation using the custom framework (validate() + rules).
**Rule:** Always check src/validation/ for this project's validation pattern before reaching for a third-party library.Commit to version control. If a lesson reveals a missing guardrail, propose adding one — don't just document the workaround.
Behaviors the agent follows because the reasoning is sound, not because a hook enforces them.
Planning: Define completion criteria — what "done" looks like for this task (files changed, tests added, routes wired, etc.). Decide testing layers before writing code. Check problem shape against the proactive table in references/tool-building.md. Assess security relevance.
Code writing: Format and type-check incrementally. If the same type error reappears after one fix, that signals a structural misunderstanding — switch to a notation rather than continuing to guess.
Handoff / PR: Report what was verified, which layers were skipped and why, security findings, and coverage delta. Do not present work as complete if any hook failed.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.