agent-guardrails

When to Use

Use on every coding task involving implementation, tests, or code review, including fixes after a review and dispatching a fresh-context reviewer. Compose with project rules and specialized skills; written project conventions and explicit user requirements still bind.

Procedure

1. Before acting, identify the agreed task, written rules/conventions, real callers, inputs, environment, and any genuine security boundary. Priority: agreed feature, correctness, then proven risk. Written convention violations are must-fix; unwritten reviewer taste does not block. Prefer the smallest safe change. For new non-trivial behavior, one failing test first when practical; use existing focused checks when sufficient. New dependencies and abstractions need a job today.
2. Only report or accept a finding that names the violated requirement or written rule, shows this change caused or worsened it, demonstrates a reachable scenario in real use, explains material impact, and offers a proportionate response. Do not hide an actual defect because it is security-related or out of scope: flag a proven large/out-of-scope issue to the human.
3. Security findings require a touched boundary (untrusted or external input through files, queries or network; credentials; auth; dependency changes), a named asset, a realistic attacker, and a working attack path through real callers, inputs, and environment. Do not invent stolen-secret, broken-TLS, malicious-admin or generic hardening stories. If no boundary is touched, say 'security: n/a'. If a genuine security task lacks facts, mark the criterion unverified and ask rather than inventing a threat model. Apply written safety rules even if they are not security findings.
4. A request for a test or check is a finding: name the reachable scenario, the material failure it protects, and the regression it would catch. Apply the evidence rules below: default to zero new tests when applicable coverage already exists, otherwise add one focused test per uncovered behavior. Coverage percentage or unreachable states alone do not justify new tests; run relevant existing checks and report what they actually prove.
5. When dispatching a fresh reviewer, put the complete dispatch contract below IN the prompt with the specific criteria, written conventions and real-use context. A path or link to this skill is not enough. Reviewer only returns findings and a pass/fix-first verdict; the parent alone decides fixes and re-reviews.
6. Before repairing reviewer feedback, disposition each finding: fails a gate -> reject in one line; passes with a small in-scope fix -> fix; passes but the right fix is large/out of scope -> hand back to the human in one sentence. Never treat reviewer opinion as authority over the approved task.
7. A review ends once agreed criteria, real risks and written rules are covered. After a fix, re-review ONLY the fix and the behavior it changes. One fix pass and one delta recheck; if the same finding survives an honest fix, stop and ask the human rather than starting round three.
8. After each coding task, restate the approved task in one sentence, compare the result, and choose accept / fix / hand back / ask. Record extra ideas in one line, not code. Do not create evidence ledgers or sign-off artifacts for this process.

Lean verification and evidence