Rules, Skills, and Guardrails

Documentation tells an agent what the repo is; the index helps it find things. The final layer shapes how it works: rules that steer its judgment, skills that package your standard workflows, and guardrails that catch it when — not if — it deviates. This is where "AI in the repo" stops being a novelty and becomes an engineered system.

Rules: encode judgment, including how to search

Rules files (.clinerules, CLAUDE.md, custom instructions) are standing orders the agent loads every session. The highest-value rules are the ones that encode judgment you'd otherwise repeat daily. A real example — a retrieval policy for a large MVC repo:

• For a specific symbol, route, or file type: grep and read the actual files; follow references (controller → service → view) before answering.
• Use the semantic index only for broad discovery when you don't know the terms.
• Never answer from retrieved snippets without verifying against the source.

In a production repo, adding exactly that policy turned unreliable, slow answers into instant, correct ones — no index changes at all. Rules also carry the non-negotiables: "all new services are registered in DI and interface-first," "never edit the generated Migrations folder," "run the test suite before declaring a task done."

Skills: package the repeatable workflows

A skill (or custom command) is a documented, parameterized procedure the agent can execute on demand: scaffold a controller + service + tests in house style, add an EF migration and apply it, generate the standard PR description. The pattern: write the procedure once — exact steps, naming conventions, verification — and the agent replays it consistently, instead of reinventing (and subtly varying) it each time. Skills are how a repo's standards become executable rather than merely readable. Start with the three workflows your team performs most; those repay the effort immediately.

Guardrails: determinism beats persuasion

No prompt guarantees compliance — models drift, and prompt-pleading ("please follow the standards") is hope, not engineering. The enforcement backstop must be deterministic:

• Build gates — TreatWarningsAsErrors, nullable enabled, Roslyn analyzers and .editorconfig rules that fail the build on standards violations (this course's own repo does exactly this).
• Tests and CI — the agent's work goes through the same pipeline as a human's; green is the definition of done.
• Scoped permissions — what the agent may edit, which commands it may run, review gates for anything touching security or data.

The division of labor is clean: rules and skills make the agent usually right; guardrails make being wrong survivable. That's the same fail-closed philosophy this whole course is built on — probabilistic capability wrapped in deterministic checks — applied to the repository itself.