Build1 publisher3 min readPublished
A capable model acts on both sides of a contradiction in your AGENTS.md
shinpr has taken claude-code-workflows through 133 releases, and the recent ones delete structure the models no longer need. His session reader then found three mandatory steps in his own repository that never ran.
The Engineer · Build desk
What happened
- Older models ignored much of what they were told, so when two skills conflicted the model quietly picked one and the contradiction never surfaced.
- Models that follow instructions follow the contradictory ones too, and shinpr reports it showing up as skills firing with nothing to contribute and mandatory steps blocking work that did not need them.
- Run against a two-turn session, it flagged a CLAUDE.md requiring a task breakdown, a date check and a rule-advisor call marked "required for all work, no exceptions", none of which ran.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Any selection or advisory layer now has to prove it changes what runs; when the agents downstream already load the rules directly, the selector buys a round trip and nothing else.
- constraint Nothing in a normal working loop surfaces a duplicated or misfiring skill, so a skill directory keeps spending tokens on rules nobody has re-read since they were written.
- exposure Two levels of delegation put the user's decisions where they cannot be seen, and undefined ownership plus an undefined finish line loses work between parent and subagent.
- precedent Config written against forgiving models becomes a migration item, but nobody has measured the size of that job, and what there is to go on is one maintainer's runs.
A conflicting pair of instructions used to resolve itself by attrition. The model read both, acted on one, and you never found out which [1]. A rule that said "always produce X" got you X about half the time, which shinpr, who maintains claude-code-workflows, wrote was usually the right amount [2]. Now both sides run, and it shows up in the session as a skill firing when it has nothing to contribute, or a mandatory step blocking work that did not need it [3]. "Contradictions are worse than ambiguity, because a capable model acts on both sides of one," he wrote [4].
The release log tracks the adjustment. claude-code-workflows is at 133 releases since October 2025 [7]. Early ones added structure because the model needed it to stay on task; later ones took the structure back out [8]. The three releases the post itemises are all deletions [19]. v0.23.0 dropped the current-date retrieval step from six agents, and v0.24.0 removed a whole recipe and cut the planning templates down to what implementation actually consumed [9][10]. In v0.26.0 he deleted the rule-advisor agent and the task-analyzer skill outright. The agents that needed those rules already loaded them directly, so the selection step added a round trip without changing what ran [11].
Session Doctor applies the same reading to a single saved Claude Code or Codex session. Three passes run separately, so a hunch from the first does not bias the other two. Each finding names where it happened, what it changed in the run, and the smallest change likely to prevent a repeat [13]. He pointed it at a small two-turn session in one of his own repositories [14]. The first finding was a CLAUDE.md that predates the AGENTS.md standard and requires a task breakdown, a date check, and a rule-advisor call before any work begins, in the words "required for all work, no exceptions" [15]. None of the three ran [15]. The file still asks for rule-advisor, the agent v0.26.0 deleted [20].
For that reading to transfer, two things have to hold in your setup. Your config has to contain rules written against a model that ignored them, and your sessions have to be legible afterwards. shinpr has the second because a workflow run leaves artifacts; ordinary sessions leave a trail too, and it is harder to read [16]. He did not name the models compared or publish failure rates, so the account of older models quietly discarding conflicting instructions rests on his own work across claude-code-workflows and ai-coding-project-boilerplate [21][18].
He does not read the gap as negligence. Creating a skill has an obvious method and an immediate result; improving one does not. Nothing in the loop tells you that a skill you wrote in March duplicates a rule you added in July, or that it triggers on work it cannot help with [17].
The harder half is delegation. Once you manage a main agent that manages subagents, you are two levels from the work. You need to know who owns each decision and what counts as finished, or work gets lost between the levels. shinpr says most setups have none of that written down anywhere the agent can see [6]. His recent releases are about exactly that: what a subagent is told, and what has to come back before the parent can act [12].
What to watch
- Whether Session Doctor's findings hold on sessions from repositories that were never built around workflow artifacts, where the trail is harder to read.
- Whether the next claude-code-workflows releases keep deleting structure or start re-adding it as subagent delegation gets deeper.
- Whether any convention appears for declaring precedence when two live skills instruct an agent differently in the same session.