Fixing Opus 5 with one system prompt: what disler's repo actually changes
Lean how ONE system prompt turns Opus 5 from a 'load-bearing' smartass into a precise CRACKED senior engineering partner.
At a glance
- What is it?
- The repository ships a single markdown file appended to every Opus 5 session to strip verbal tics, scope creep and co-author credits. It is a prompt-engineering artifact, not a tool, and its value depends on whether you already run Claude Code or a comparable harness.
- Who is it for?
- Adopt it if you already run Claude Code or Pi on Opus 5 and want one file to govern tone, scope and commit hygiene across every session; the justfile gives you an immediate A/B against the unmodified model. Do not adopt it if you cannot append a system prompt to your harness, or if you want the model to refactor adjacent code without being asked, because section 3 explicitly forbids that.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly Just, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: an expensive communication channel, not a broken model
The README is blunt about the premise: "The model is not broken. The communication channel is, and the system prompt is where you fix it." Opus 5, in this account, buries answers under six headers, spends more output tokens than earlier models, and attaches Anthropic co-author credit to commits. Each of those is a cost you pay per turn, and per turn is the operative unit.
The target reader is narrow and stated: mid to senior engineers running frontier coding agents, specifically Claude Code, Pi, or any harness with an appendable system prompt. If you use a chat window with no system-prompt slot, nothing here applies to you. The repository is a single markdown file plus a justfile that launches the agent with that file appended, so the whole proposition rests on the assumption that your harness lets you inject persistent instructions.
The diagnosis matters more than the fix. Most engineers, the README argues, respond to a verbose model by rewriting individual user prompts task by task. That is described as the low-leverage move, because a user prompt is scoped to one task while the system prompt is present on every turn of every session. Whether or not you accept the framing, the asymmetry is real: a phrase banned in the system prompt is banned everywhere at once.
What is actually inside sr_opus_5_system_prompt.md
The file is one document with a purpose statement, four numbered instruction sections and a set of examples. Section 1 holds two explicit lists, behaviors to replicate and words or patterns to avoid, with the banned phrases named directly: load-bearing, worth stating plainly, flattery, and em dash chains. Section 2 defines reference codes the agent attaches to its own output, F1 for findings, D1 for decisions, O1 for options, R1 for risks, Q1 for questions and A1 for actions. Section 3 is a scope boundary: unrequested refactors, adjacent cleanup, completion claims without evidence and co-author credits are all excluded. Section 4 defines four aliases, scr, eli, foc and ref, each expanding into a full instruction.
The reference-code section is the most interesting design choice and the one most likely to divide readers. It creates a shared index into the conversation so a follow-up can be three tokens long. The README gives the example keep D1, reject O2, answer Q1 and notes there is no re-quoting or re-explaining. That works only if the model labels consistently and you keep the labels straight in your head; a long session with dozens of codes becomes its own bookkeeping problem. The README does not say what happens when the model mislabels or skips a code.
The examples section is described as training data you author. The README suggests taking a response you liked, tightening it and pasting it as a To do, and taking a bloated response and turning it into a do-not. That is a maintenance obligation disguised as a feature. The file is useful out of the box, but the repository's own framing implies it gets better as you add your own pairs, which means someone has to keep adding them.
Installing it and running a first session
There is no build step, no dependency graph and no configuration file. The system prompt is plain markdown passed to the CLI through --append-system-prompt-file. You need just and claude at minimum; herdr and jq are for the side-by-side comparison, and pi is optional for the mirror recipes.
The clone and toolchain step, as the README lists it:
git clone <REPO_URL> && cd sr-opus-5
brew install just herdr jq
npm install -g @mariozechner/pi
justThe README states that just with no argument lists the recipes, so run that first to confirm the toolchain resolves. The pi install is marked optional in the README and only matters if you want the Pi mirror recipes.
To boot Opus 5 with the prompt appended, the justfile recipe is:
just sr-opusThat recipe runs claude --dangerously-skip-permissions --model "opus" --append-system-prompt-file with the path to sr_opus_5_system_prompt.md resolved from the justfile directory. What you should see is a Claude Code session on Opus 5 where the first response is short, unheaded and free of the banned phrases. If the response still opens with a bolded takeaway, the file is not being picked up, and the path resolution in the recipe is the first thing to check.
The repository also has an agentic install path:
just installThis runs the /install slash command, which lives at .claude/commands/install.md. The README says it verifies just, claude, herdr, jq and pi, auto-installs what it can, and confirms the compare loop is ready. Note that both launch recipes pass --dangerously-skip-permissions, so the agent runs without permission prompts. That is a deliberate choice for this workflow and a real risk if you point it at a repository you do not trust.
The compare recipe is the honest part of the repository
The justfile does not just launch the modified model; it launches both. The smart-ass-opus recipe starts Claude Code on Opus 5 with no custom instructions. The compare recipe creates a herdr workspace, splits it into two panes, renames them smart-ass-opus-5 and sr-opus-5, and runs the same prompt in each. The prompt used is a fixed document in the repository, ai_docs/zuck-thefutureisforeveryone.md, so the comparison is reproducible rather than anecdotal.
Before opening the panes, the recipe lists existing herdr workspaces, filters for a label matching compare-<name>, and closes any it finds. That means rerunning the comparison cleans up the previous one instead of accumulating panes. It is a small detail, but it tells you the author ran this loop repeatedly.
The recipe requires jq because it parses herdr's JSON output for workspace and pane identifiers, and it requires herdr itself. If you only want the prompt file, you can skip both and pass the file to your own harness. The comparison machinery is the part of this repository that is genuinely reusable beyond Claude Code, because the idea of running raw and modified side by side applies to any model with an appendable system prompt. The README does not publish results from that comparison, so you are expected to run it yourself and judge.
Where this breaks down
The first limitation is structural: the whole approach assumes your harness accepts an appended system prompt. A web chat interface, an IDE plugin without a system-prompt setting, or an API wrapper that hardcodes its own system message will not take the file. The README names Claude Code, Pi and "any harness with an appendable system prompt" as the targets, and that phrase is doing the work. Everything outside it is out of scope.
The second is that boundaries written as prohibitions trade one failure for another. Section 3 blocks unrequested refactors and adjacent cleanup. If you are the kind of engineer who wants the agent to notice a broken import two files over and fix it while it is there, this prompt will suppress exactly that behavior. You can edit the file, but then you are maintaining a fork of a prompt whose value comes partly from being opinionated.
The third is that a banned-phrase list is a moving target. The README pins specific tics, including load-bearing and em dash chaining. Model behavior changes across versions and across harnesses, and the README does not document a process for auditing whether the banned phrases still match what the model actually emits. The examples section is the intended answer to that drift, since you author new do and do-not pairs, but nothing in the repository automates the check.
Finally, the README does not document rollback, versioning of the prompt file, or how to tell whether a regression came from the prompt or from a model update. The compare recipe is the closest thing to a test, and it is a manual visual comparison, not an assertion.
The alternative: keep tuning user prompts, or use a harness-level config
The obvious alternative is the one the README argues against: leave the system prompt alone and keep tightening user prompts per task. The difference in approach is scope. A user prompt is a work order for one task; the system prompt is an operating contract present on every turn. If your complaints are task-specific, such as an answer that missed a detail in one file, prompt tuning is the right tool and this repository will not help. If your complaints recur every session, such as the model opening with a bolded takeaway regardless of the question, the system prompt is the only place that scales.
A second alternative is harness-level configuration. Some agents let you set output style, verbosity or commit attribution through their own settings rather than a markdown file. That is more structured than a prompt and survives model changes better, but it is also less portable: settings for one agent do not transfer to another, while a markdown file passed via --append-system-prompt-file moves between harnesses that accept the flag. The repository's compare recipe leans on this portability, since the same file is used for both the Claude Code and Pi recipes.
A third option is to write your own system prompt from scratch. The honest case for this repository over that approach is the examples section and the specific banned-phrase list, which encode someone else's iteration on the same problem. The honest case against it is that a prompt written for someone else's tolerance for verbosity may not match yours. Reading sr_opus_5_system_prompt.md before adopting it costs a few minutes and tells you which side you are on.
Licence, maintenance and what upgrading costs you
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is not legal advice, and if you plan to redistribute a modified prompt inside a product, read the LICENSE file at the repository root rather than relying on the label.
The last push to the default branch was on 2026-08-16, which is recent enough that the project has not gone quiet, but the repository has no releases listed. That means there is no versioned artifact to pin. You consume the prompt file from main, and an update is a git pull away from changing the behavior of every session you launch. If you care about reproducibility, copy sr_opus_5_system_prompt.md into your own repository at a commit you have reviewed, and point --append-system-prompt-file at your copy.
The upgrade cost is low in mechanical terms and non-trivial in attention terms. The file is markdown with no build step, so applying an upstream change is a diff. But the file is also the thing you are supposed to extend with your own examples, which means every upstream change risks a merge conflict in the section you have been curating. The justfile is small enough to read in full, and the recipes are short, so the launch path is unlikely to be the source of a surprise. The prompt content is where the churn will land.
Editorial conclusion
Adopt it if you already run Claude Code or Pi on Opus 5 and want one file to govern tone, scope and commit hygiene across every session; the justfile gives you an immediate A/B against the unmodified model. Do not adopt it if you cannot append a system prompt to your harness, or if you want the model to refactor adjacent code without being asked, because section 3 explicitly forbids that. Before relying on it, read sr_opus_5_system_prompt.md end to end, then run just compare with a document you know well and check whether the reference codes and the banned-phrase list survive contact with your own workload.
Frequently asked questions
Why do people dislike Opus 5?
The repository's stated complaints are verbosity and verbal tics: answers buried under six headers, repeated phrases such as load-bearing and worth stating plainly, em dash chaining, flattery, and Anthropic co-author credit on commits. It also notes the model burns more output tokens than earlier models, which the README frames as a direct cost.
Has Opus 5 gotten worse?
The repository does not claim the model degraded. Its position is that the model is not broken and the communication channel is, with the fix applied through a system prompt rather than a model change.
Is Opus 5 good for coding?
The README calls it one of the smartest models ever shipped while also calling it exhausting to work with, and it targets mid to senior engineers running frontier coding agents. The repository's aim is to make it a precise senior engineering partner, not to argue about raw coding ability.
Is Opus 5 down?
The repository does not address service availability, outages or status. It covers prompt behavior in a local agent session and ships no monitoring or status tooling.
Community notes