Prompting Changed. Most of Our Instructions Didn't.

The models got smarter. Our prompt stacks got older. It is time to replace the instruction museum with a small map, clear boundaries, and a finish line.

A few days ago, I discovered something slightly uncomfortable:

Almost all my prompts, instruction files, rules, and skills were outdated.

Not completely useless. Just written for another generation of models.

The prompt stacks that helped older models behave can make GPT-5.6, Claude Fable 5, Claude Opus 5, Grok 4.5, and coding tools such as Cursor more rigid, more expensive, and sometimes simply worse.

This is not my latest prompt religion. Anthropic explicitly warns that skills written for previous models can be too prescriptive for Fable 5 and may degrade output quality. OpenAI recommends leaner prompts, fewer repeated instructions, and simpler tool descriptions.

That was slightly embarrassing to read.

Since summer 2025, I have written more than 100,000 prompts. That's roughly Elon Musk's lifetime tweet count, only with fewer rockets and more failing test suites.

My logs contain around 15 million model messages, including assistant messages, tool calls, subagents, and workflow events. Until March 26, the total was about seven million. Another eight million arrived within three months, largely because of the subagent and workflow explosion around newer coding models.

So I thought I knew how to write instructions.

Then I read the new documentation and realized that much of what I had learned had quietly turned into technical debt.

How Prompt Debt Is Created

My old approach was simple:

• The model made a mistake, so I added a rule.
• It asked an unnecessary question, so I added another rule.
• It missed an edge case, so I added three examples.

Every addition looked reasonable on its own. After a year, the instruction file resembled that kitchen drawer where you keep twelve old cables because one of them might still belong to something important.

The result was a growing collection of:

• duplicated instructions
• negative examples
• conflicting rules
• old model workarounds
• excessive verification steps
• detailed procedures that applied to only one task
• examples created to fix failures that no longer existed

Older models often needed this scaffolding. Newer models follow instructions more strongly and infer intent more reliably. That means they also take our old baggage more seriously.

We built smarter engines and then filled the trunk with bricks.

High-contrast black and white headshot of a young blonde woman in a dark turtleneck, minimalist studio setting. Subtle rim lighting separates her silhouette from a soft gray backdrop, enhancing dimensionality. The mood is introspective yet strong, embodying timeless realism. Hasselblad X2D digital medium format clarity, inspired by 20th-century photojournalism.

The New Principle: Say Less, Mean More

The answer is not to write tiny prompts and blindly trust the model.

A short but ambiguous prompt is still a bad prompt.

The goal is a high-information prompt in which every instruction earns its place.

My current rules are:

• State each instruction once.
• Remove repetitions across system prompts, project files, skills, tool descriptions, and task prompts.
• Prefer a clear description of the desired behavior over a collection of failure cases.
• Keep negative constraints when they protect a real boundary, but stop writing museums of everything the model must never do.

For example, instead of this:

Do not refactor unrelated code. Do not rename files. Do not change APIs. Do not add abstractions. Do not clean up nearby modules.

Better:

Keep the change limited to the affected login flow. Preserve existing API contracts and surrounding architecture. Prefer the smallest correct fix.

Same boundary. Less noise. More room for judgment.

In one internal coding-agent evaluation sample, OpenAI found that leaner system prompts improved scores by roughly 10 to 15 percent while reducing token usage by 41 to 66 percent and cost by 33 to 67 percent. OpenAI also makes clear that these numbers are directional and must be validated on your own workload.

In other words, deleting instructions can improve both quality and the invoice. That is a rare and beautiful combination.

Your Global Instruction File Should Be Boring

The global files at ~/.claude/CLAUDE.md and ~/.codex/AGENTS.md should contain only instructions that apply to every project and every task.

For me, as a German native speaker, that includes things such as:

1Use English for all code, comments, documentation, examples,
2tests, configuration, and commit messages.
3
4Prefer inclusive terminology such as allowlist/blocklist,
5primary/replica, placeholder/example, main branch,
6conflict-free, and concurrent/parallel.

That may already be most of the global file.

• Deployment procedures do not belong there.
• Project-specific test commands do not belong there.
• The architecture of one particular repository does not belong there.

Your global instruction file should not know how to deploy a WordPress site, publish an npm package, and restart a production database. That is not versatility. That is confusion with good formatting.

For project-level files, include stable information the model genuinely needs repeatedly: the purpose of the project, important architectural constraints, unusual conventions, and directions to more specialized guidance.

Anthropic now recommends targeting fewer than 200 lines per CLAUDE.md file. Longer files consume more context and can reduce instruction adherence. Its documentation also recommends path-specific rules and on-demand skills when instruction files become too large.

Two hundred lines is not a magical law of nature, but it is an excellent fire alarm.

I would also avoid asking Claude or Codex to rewrite the entire instruction system by itself and accepting the result blindly. I have tried this with almost every new model. They are useful for finding duplication, conflicts, and possible cuts, but they still tend to preserve too much inherited clutter or invent a beautiful new bureaucracy.

Let the model prepare the demolition plan. You should still decide which walls are load-bearing.

Portrait of a poised young woman with blonde hair in a ponytail, rendered in deep black and white tones. Studio-lit with soft but directional light that accentuates facial geometry and natural shadows. Shot through a 120mm lens for gentle compression, evoking a Hasselblad portrait aesthetic with tactile realism and restrained emotion.

Stop Using One File for Every Model

Until recently, I created CLAUDE.md and symlinked AGENTS.md to it.

I no longer do that.

Yes, maintaining two files is annoying. So is maintaining separate browser fixes. We still do it when behavior differs.

The models now have noticeably different defaults.

GPT-5.6 is more concise by default, so a global “be concise” instruction may make some answers too short. Claude Opus 5 tends to produce longer user-facing responses, so a brief instruction about response length can still help. Fable 5 can investigate and plan far beyond what a routine task requires, especially at higher effort settings, so it benefits from clear scope and stopping boundaries. Opus 5 already performs substantial self-verification, which means old “double-check everything” rules can create expensive over-verification.

The shared project facts can still live in common documentation. The top-level behavioral adapter should match the model that reads it.

One universal prompt often becomes the lowest common denominator.

Replace the Master Prompt with On-Demand Guidance

My preferred structure is a small core file plus task-specific documentation and skills.

A project instruction file might contain this:

1Load task-specific guidance only when relevant:
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

Notice the backticks.

In Claude Code, writing @docs/example.md outside a code span imports that file into the context at startup. That is useful when you always need the content, but it is not lazy loading. A plain path lets the agent know where information exists without automatically carrying the entire document into every task.

Skills are even better for repeatable procedures. Their full bodies load only when the skill is used, so a detailed workflow does not consume context while you are fixing an unrelated CSS issue.

A commit skill, for example, can have a narrow trigger:

name: git-commit-conventional

description: Use after code changes to draft or validate commit messages.

The skill can then contain the exact format, allowed types, subject-length rule, body requirements, and output format.

1---
2name: git-commit-conventional
3description: Use for drafting or validating git commit messages after code changes. Do not use for diagnosis-only, planning-only, or review-only tasks.
4---
5
6# Goal
7
8Produce Conventional Commit messages that are short, correct, and review-friendly.
9
10# Rules
11
12- Format: <type>(<scope>): <subject>
13- Types: feat | fix | docs | style | refactor | test | chore | perf
14- Subject: imperative mood, no period, <= 50 chars
15- Small changes: one-line commit
16- Larger changes: add a wrapped body explaining what and why
17- Keep commits atomic and split by concern
18
19# Output
20
21Return 1-3 candidate commit messages, then recommend the best one.

Your main instruction file does not need to carry the entire Conventional Commits constitution into every debugging session.

Did you know that? Claude Code also supports CLAUDE.local.md for personal project-specific settings such as local hostnames, sandbox URLs, preferred test accounts, or machine-specific commands. Add it to .gitignore. It is finally a proper home for information that matters greatly to you and not at all to the rest of your team.

Prompt for Outcomes, Not Choreography

New models generally perform better when they understand the destination and the boundaries, rather than receiving a rigid description of every footstep.

Wherever possible, I replace “first do A, then B, then C” with:

• the required outcome
• the relevant context
• the hard constraints
• the evidence required
• the success criteria
• the approval boundary
• the stopping condition

For example:

1Goal
2
3Fix the failing login flow in the web application.
4
5Context
6
7Focus on `apps/web` and `packages/auth`.
8Use the attached test output as the starting point.
9
10Constraints
11
12Preserve existing API contracts.
13Keep changes limited to the authentication flow.
14Prefer the smallest correct fix.
15Broaden the change only when required for correctness.
16
17Evidence
18
19Run the relevant tests and report their actual results.
20Identify the root cause with references to the affected files.
21
22Done when
23
24The failing login test passes.
25Tests are added or updated when the corrected behavior requires it.
26The final summary explains the cause, the fix, and any remaining risk.
27
28Approval
29
30You may inspect files, edit in-scope code, and run non-destructive tests.
31Ask before destructive actions, database migrations, external writes,
32or a material expansion of scope.
33
34Stop
35
36Stop when the fix is implemented, validated, and summarized.

This gives the agent freedom to solve the problem without permission to renovate the entire house while repairing one door handle. (Use an LLM for generating prompts like this.)

Put Reasoning Effort in the Settings

• "Think harder."
• "Ultra think."
• "Take a deep breath and reason step by step."

These phrases have had a long and distinguished career in prompt engineering. It is time to give many of them a dignified retirement.

Use the model controls.

Set the effort level through /effort, the API, or the relevant configuration. Compare multiple effort levels on representative tasks. Higher is not automatically better.

OpenAI recommends starting GPT-5.6 migrations at the existing effort level and testing one level lower. It also says that prompts for Pro mode should remain focused on the goal, context, constraints, evidence, success criteria, and output format. You do not need to tell the model to “think harder.”

A reasoning parameter is a control.

“Please activate your enormous digital brain” is encouragement from a sports movie.

read image description

ALT

Studio photograph of a sophisticated woman with black wavy hair and a chic headband, dressed in high-waisted leather pants. She sits on a low stool, one knee bent forward, her long legs commanding attention. Sharp detail, pristine white background, and subtle motion in the hair add energy. The overall tone recalls 1990s editorial photography clean, bold, confident.

Autonomy Needs a Fence

Modern coding agents are much more proactive. This is useful until the agent solves three additional problems, creates two abstractions, launches six subagents, and proudly presents an architecture you never requested.

Set the boundaries explicitly.

Define what the agent may do without asking. Define what needs approval. Tell it when to stop.

Also place limits on delegation. Both Opus 5 and Fable 5 are more willing to use parallel subagents. That is powerful for independent investigations, but expensive and slow for small tasks. A twelve-line bug fix does not need a committee meeting.

Codex Goal mode is genuinely excellent. We have used it on a project for four days in one continuous run.

But do not treat a long-running agent like a slow cooker. You cannot add an objective in the morning and assume dinner will be correct four days later.

For our longer runs, we check in every 30 to 60 minutes with something like:

Report the current objective, completed work, verified evidence,

active blockers, next action, and where progress is documented.

Ground every progress claim in actual tool output or repository state.

State clearly what remains unverified.

OpenAI describes Goal mode as suitable for objectives that can run for hours or days and explicitly supports continuing the same session to steer the work or request status updates. Anthropic similarly recommends grounding progress reports in real tool results rather than trusting narrative claims.

Autonomy is not the absence of supervision. It is supervision at a higher level.

Close-up portrait of a goddess illuminated by silver lunar glow, her eyes bright and filled with affection. Her headdress sparkles with tiny galaxies, Klimt-inspired spirals, and celestial patterns. The background is a flat, carefully arranged pastel backdrop with theatrical Andersonian staging, rich textures, and quiet charm.

Refactor Prompts Like Production Code

Do not delete half a system prompt, run one task, and declare the migration successful.

OpenAI recommends removing one group of instructions, examples, or tools at a time, then rerunning the same evaluations. That is exactly how prompt refactoring should work.

Measure:

• task success
• completeness
• correctness
• required evidence
• token usage
• latency
• cost
• unnecessary tool calls
• unnecessary changes

Use representative tasks, including awkward real-world cases, not one friendly demo that already worked before the migration.

Prompt cleanup without evaluation is still guessing. It is merely guessing in a cleaner shirt.

Generated Code Still Contains Bugs

The models have improved enormously. They have not repealed software defects.

In our work, a rough rule of thumb is still around one issue for every 300 lines of generated source code. This is not a scientific benchmark, and I do not count repetitive HTML templates in the same way. But it is reliable enough that when an agent generates 1,500 lines of real application code, I assume several bugs are hiding inside, at least 5.

I do not ask whether there are bugs.

I ask where the five bugs are.

Occasionally, I add:

Find the five bugs, or you will be replaced by Codex, Claude, or Grok.

Threat-based development is not an official methodology, but it can be strangely motivating. ;-)

More seriously, use a fresh review pass for large changes. Run the relevant tests. Inspect the diff. Test actual behavior, not only compilation.

And watch the tests carefully. Models still sometimes prefer to “repair” a failing test rather than fix the production code that caused it.

A useful instruction is:

1Treat existing tests as the expected behavior unless the evidence shows
2that a test is incorrect.
3
4When a test fails, investigate the production code first.
5
6Before changing an existing test, explain why its expectation is wrong,
7what the correct behavior should be, and what evidence supports that change.

For large, long-running tasks, a fresh-context verifier can be useful. For a small change, spawning several agents only to confirm one another usually burns time and tokens. Verification should match the size and risk of the task.

What You Should Not Delete

The lesson is not “write tiny prompts and trust the machine.”

• Keep security and safety boundaries.
• Keep legal and compliance requirements.
• Keep exact output schemas.
• Keep product-specific behavior.
• Keep domain knowledge the model cannot infer.
• Keep approval requirements for consequential actions.
• Keep citation and evidence requirements.
• Keep test criteria and definitions of done.
• Keep examples that correct a measured, reproducible failure.
• The goal is not the shortest possible prompt.
• The goal is a prompt where every instruction still carries useful information.

One Final Bonus

OpenAI provides an official Docs skill that can inspect a project and apply its GPT-5.6 migration guidance:

1$openai-docs migrate this project to the GPT-5.6 model family

That is a useful first pass. It is not the final review.

Let Codex identify outdated parameters, duplicated instructions, and migration opportunities. Then inspect every change yourself. A migration agent is a very fast junior engineer, not a constitutional court.

The Bottom Line

• Treat your prompt stack like production code.
• Remove dead instructions.
• Delete duplication.
• Separate global preferences from project rules.
• Move procedures into on-demand skills.
• Describe outcomes instead of scripting every step.
• Set clear scope, approval boundaries, evidence requirements, and stopping conditions.
• Control effort through model settings.
• Limit subagents.
• Evaluate every meaningful change.
• The newest models need less micromanagement, but they still need direction.
• A good prompt is no longer a giant instruction manual.

It is a small map, a solid fence, and a clearly marked finish line.

Have you already started migrating your prompts and skills? What did you remove, and what unexpectedly became better?

Links

Open AI GPT 5.6 best practise:

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 best practise

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 best practise:

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

Official open ai skills / plugins:

https://github.com/openai/plugins

Credits: Image created with Midjourney. Research and hands-on testing by me. Edited with help from OpenAI, Claude, and Grammarly.

Image prompt of the main image:

1
2Close-up black-and-white portrait of a serene blonde woman, hair tied back, wearing a black turtleneck sweater. The chiaroscuro effect shapes her face with striking definition, merging soft ambient light and bold shadow. Medium format style with fine film grain and moody tonal gradation. Evokes authenticity and strength.

PS: I love @Midjourney :-)