A green build is the weakest 'done' - and your agent's first choice.
Write the exact verification step into the feature spec your agent loads, so 'done' means the test passed - not that the code compiled.
24 posts tagged #rules.
Write the exact verification step into the feature spec your agent loads, so 'done' means the test passed - not that the code compiled.
Not all code is equally expensive to get wrong. Stop reviewing your agent's output uniformly and spend your scrutiny where a mistake double-charges a customer.
Agent-driven file discovery burns turns and fills the window with wrong guesses. A parameterized priming command loads exactly the right files in one shot.
A single giant root rules file dilutes the agent's attention. Split context into a broad root plus directory-scoped files it loads by what it's touching.
Most AGENTS.md files defend against imagined mistakes. Mine your own transcripts, count what the agent actually gets wrong, and let that decide what to write.
A deterministic check on the agent's output, with one retry, kills a class of wrong answers no prompt rewrite reaches - and gives you a number, not a vibe.
An MCP server exposes resources, tools, and prompts - context the app pulls, actions the model takes, workflows the user invokes. Most teams wire only one.
A git pre-commit hook turns 'the agent should run the tests' into 'the agent cannot commit broken code' - a deterministic gate that ships with every clone.
Scatter gating logic inline and consistency depends on luck. Collapse the policy into one named helper, make calling it a rule, and enforcement is the default.
Asking an agent to review what you say you did grades your spin, not your code. A small MCP server that reads the live diff grades reality instead.
Before you write another anti-hallucination instruction, split each wrong answer into a retrieval failure and a generation failure. They need opposite fixes.
The correction you keep re-typing into the chat is a missing command. Fold the recurring ritual into one parameterized verb backed by a rules file.
Vibe-coding a service you have never touched traps you at the first failure. Point the agent at its docs over MCP and force it to teach you back.
Pairing an isolated subagent with the right tools and a slice of your conventions rebuilds the proven agent loop without dragging tool logs into your thread.
An agent that waits for you to remember to ask it is a toy. Wire a deterministic event to a headless run that reads your rules, and routine work fires itself.
A rules file is write-once and rots; auto-memory saves corrections on its own judgment. Add the human-gated layer between them so corrections compound.
Every failed agent session is a labeled example of where your context falls short. Capture them, cluster them, and fix the top category once in your rules file.
Vague prompting isn't a skill gap you fix with longer prompts. It's a missing shared vocabulary - and the fix is a committed glossary, not a personal habit.
The codebase is your strongest steering signal - stronger than your prompt or your rules. Pay the exploration cost once, freeze it, and feed it to every run.
Hand the agent two committed documents - a requirements doc that fixes the destination, a phased plan that fixes the journey - and a big feature still ships.
Your rules file is necessary but not sufficient. Persistent context degrades as the window fills - move the ignored rule into a hook that fires when it matters.
An autonomous agent isn't a bigger context window. It's a tiny window run many times, where the git log - not chat history - carries decisions between passes.
A million-token window won't fix a long build. Externalize state to a plan file and relay across fresh sessions - quality dies long before the window fills.
Copilot, Cursor, Claude Code, Codex, and OpenCode all converged on the same primitive - a rules file the agent reads on every session. Use it.