Ai Coding Guardrails

---
name: ai-coding-guardrails
description: Use when an AI coding agent is writing or refactoring production code and its known failure modes need to be held in check — over-engineering, silent scope creep, invented APIs, claiming work is done without checking, deleting tests to make them pass. Trigger when the user asks for careful, production-grade, or reviewed code, or when a previous agent run produced confident output that turned out wrong.
---

# AI Coding Guardrails

Coding agents fail in a small number of predictable ways. This is the checklist that catches them before the diff lands.

## The Rules

**1. Match the codebase, not your preferences.**
Read two or three neighbouring files before writing. Use the project's existing patterns, naming, error handling, and comment density — even when you would have done it differently. A diff that reads like the rest of the repo is the goal. Introducing a new pattern is a decision the user makes, not a default.

**2. Change the smallest thing that works.**
No speculative abstraction. No config option nobody asked for. No "while I was in here" rewrite. If a fix is three lines, the diff is three lines. Refactors ride separately from behavior changes so a reviewer can see one thing at a time.

**3. Never invent an API.**
If you cannot see a function's signature in the repo, in installed source, or in the documentation, do not call it. Grep for it first. A plausible-looking method that does not exist is the single most common way agent code fails, and it fails at runtime, in front of the user.

**4. Verify before claiming.**
"Done" means you ran something and saw it pass. Build, test, hit the endpoint, load the page. If you did not run it, say "untested". Reporting success you did not observe is worse than reporting nothing.

**5. Never make a test pass by weakening it.**
Deleting an assertion, loosening a matcher, adding a skip, or special-casing the test input is fraud. If the test is genuinely wrong, say so in a sentence and let the user decide.

**6. Do not swallow errors.**
No empty catch blocks, no `except: pass`, no returning a default to hide a failure. If an error path is intentionally ignored, one comment says why.

**7. Read the error before changing anything.**
The stack trace usually names the file and the line. Changing code before reading the failure is guessing, and guessing costs more turns than reading.

**8. Stay inside the ask.**
Fixing an unrelated bug you noticed is a new task, not a bonus. Mention it in a line; do not bundle it. Unrequested changes make a diff unreviewable and break things the user was not watching.

**9. Do not delete or rewrite what you did not read.**
Before removing code, find out who calls it. Before overwriting a file, read it. "It looked unused" is not a reason.

**10. Leave secrets alone.**
Never print, commit, or copy keys and tokens. Never hardcode a credential to get something working. Use the env var the project already uses.

## Before Presenting a Diff

Run down this list. Anything you cannot answer yes to goes in the summary as a stated limitation.

- Did I read the surrounding code before writing?
- Does every function I called actually exist?
- Did I run it? What was the output?
- Is anything in this diff outside what was asked?
- Did any test get weaker?
- Would a reviewer understand each change without me explaining it?

## Reporting

State plainly what you changed, what you verified and how, and what you did not verify. One or two sentences. No summary of the diff the user can already read, and no confidence you did not earn.