Everyone adds lines to their system prompt when the agent breaks. Almost nobody goes back and deletes them.
One developer did. 400 lines became 162 after 30 days of running 3-4 cron sessions a day. The agent got better, not worse. Response quality went up. Hallucinations on edge cases went down. Token costs dropped meaningfully because the context window wasn’t stuffed with contradictory noise competing for attention.
The unlock wasn’t a better instruction. It was realizing that 240 lines were already default model behavior, just dressed up as custom constraints. Turns out modern frontier models don’t need you to tell them to think carefully or write clean code. They need you to tell them the things only you know, not the things they already do.
The One-Question Audit
Every line in the prompt got tested against a single question: “Did the agent actually get this wrong without this specific line?”
If no, delete it.
Sounds obvious. Almost nobody does it. The reason is psychological: adding a rule after a failure feels like fixing a bug. Deleting a rule feels like taking a risk. So the prompt grows in one direction forever. You end up with a 400-line document that’s half scar tissue and half superstition, and the agent is reading all of it on every single call.
The audit forces you to flip the burden of proof. Instead of asking “is there any reason to keep this?” you ask “is there a specific incident that proves I need this?” That shift alone cuts most prompts by 40% on the first pass.
The Old Way vs. The New Way
The old approach: agent makes a mistake, you add an instruction, you never revisit it. Six months later you have 400 lines, half of which contradict each other, and the agent is more confused, not less. Instructions added in January reference a workflow you retired in February. Rules written for one task bleed into unrelated tasks. The agent is balancing a stack of constraints written by different versions of you, under different pressures, at different times.
The new approach: treat every line like production code. It earns its place with a specific incident, or it gets cut. You wouldn’t leave dead functions in your codebase just because deleting them feels risky. The same logic applies here. Dead instructions aren’t neutral. They consume context, create contradictions, and train you to write more of them.
The 4 Categories That Actually Survived
- 🎯 Identity and scope. Not “be helpful”: that’s default. More like “You own the site/ directory. Never touch infrastructure/ without asking.” This changes which files the agent reaches for without being told. The more specific the boundary, the less you need to supervise the output. A well-scoped agent makes fewer wrong assumptions because it knows exactly where its lane starts and ends.
- 📋 Failure-mode flags with dates and incident tags. “Don’t call endpoint X without the retry header; added 2026-03-19 after silent cron failure, 4 hours of lost data.” The date matters. Without it, you delete the rule six weeks later and get burned again. The incident tag is what makes future-you take the rule seriously instead of treating it like boilerplate someone left behind.
- 📁 File paths and patterns the agent can’t discover on its own. If it’s not obvious from the codebase and the agent would invent the wrong pattern, it stays. Everything else is clutter. The test: could the agent find this by reading the repo? If yes, you don’t need to tell it. If no, write it down precisely, with a real example path.
- 💬 Voice calibration with real examples, not adjectives. Not “write casually.” Instead: “Bad: ‘I’m excited to share today’s update.’ Good: ‘The cron fired at 8:17am and shipped a homepage rewrite.'” Examples are binary. Adjectives are guesses. A good before/after pair communicates tone, rhythm, and word choice in one shot, without leaving the agent to interpret what “casual” means to you specifically.
What Got Deleted
The graveyard of well-intentioned noise:
- “Be concise.” (It already is, or it isn’t. The line changed nothing.)
- “Think step by step.” (It already does. This instruction predates modern reasoning models by three years and never got retired.)
- “Write clean code.” (Meaningless without specifics. Clean by whose standard? For what purpose? The model has no idea what this is asking.)
- “Always verify before acting.” (Gets overridden by task urgency every single time. If you want verification, build it into the task structure, not the system prompt.)
- Duplicate instructions scattered across three sections saying slightly different things about the same behavior, creating genuine ambiguity about which version to follow.
All of it is default model behavior wearing the costume of custom instructions. The model was going to do most of it anyway. The instructions didn’t add capability. They added noise, and noise has a cost.
How to Run This Yourself
- Export your current system prompt and count the lines. If you’ve never done this before, the number is probably higher than you expect. Most people who do this for the first time discover instructions they don’t remember writing.
- For each line, ask the one question: can you point to a specific real run where the agent failed without it? Not “could I imagine it failing” but “did it actually fail?” If you can’t name the incident, delete the line. If you’re not sure, move it to a separate document and test without it for two weeks.
- For every rule that survives, add a date and a short incident tag. “Added 2026-03-19 after X happened.” Future you stops re-learning the same lessons. This also makes the next audit faster because you can see which rules are old enough to question and which ones were added recently enough to leave alone.
- Replace every adjective in your voice instructions with a before/after sentence pair. “Casual tone” is vague. Two sample sentences is binary. Do this once and you’ll never go back to describing tone with adjectives. The difference in output quality is immediate.
Run this once a month. System prompts accumulate debt exactly like codebases do. The difference is nobody has a linter for it yet. Until someone builds one, the audit is manual, and the question is always the same: did it actually fail without this, or did you just get scared and add a line?
What’s the biggest line you deleted that actually made your agent better? Drop it in the comments.
Frequently Asked Questions
Q: How do you know if a system prompt instruction actually works?
The simplest test: delete it. If your agent’s behavior noticeably changes or gets worse, the instruction was doing something. If nothing happens, it was just noise taking up space. This deletion test is how the post went from 400 lines to 162.
Q: What kinds of instructions actually survive the deletion test?
Four keep showing up: (1) identity and scope (“you own this directory, don’t touch infrastructure”), (2) failure-mode flags with incident dates (like “endpoint X needs retry header, added after silent failure on 2026-03-19”), (3) file paths and infrastructure your agent can’t discover on its own, (4) voice examples showing good vs bad (“Bad: ‘excited to share.’ Good: ‘8:17am shipped homepage rewrite.'”). Everything else like “be concise” almost never survives.
Q: Will my system prompt get outdated as the model improves?
Definitely. An instruction you added to fix a bug six months ago might actually hurt things now that the model’s been updated. Tag each instruction with the date and incident it prevents, so you can circle back and test whether the failure mode still exists. If it doesn’t, deleting the instruction might actually make things better.
Q: Should I organize my system prompt by topic or keep it as a flat list?
Organize by concern: identity, failure-modes, infrastructure, voice calibration. When your agent hits a problem, you can jump straight to the relevant section instead of scanning the whole thing. Structure also makes it easier to see what actually matters.
Q: Why don’t vague instructions like “be concise” or “think step by step” work?
Because the model already does these things (or doesn’t, and one more mention in the prompt won’t fix it). The real instructions that survive change which files the agent opens or what patterns it reaches for. Style advice competes with the actual task signal and almost never wins.
What survived in my Claude system prompt after 30 days of daily agent runs (and what got deleted)
by u/Most-Agent-7566 in PromptEngineering