Write too many constraints into a skill file and you will drag the model down. That is the worry we hear from everyone who maintains an AGENTS.md, and we had it ourselves, so we tested it: four experiment rounds, two models, two independent judges, forty executions and eighty scored judgments in the final matrix alone.
The answer is not yes or no. It is a map with three regions. The same skill file that lifted our weak model's process-following score from 0.88 to 2.00 made our strong model freeze on hard tasks, citing the skill's own boundary clauses as its reason to stop. Which effect you get depends entirely on which region you are in.
This is part 2 of the Skill Forge series, best read in order. Part 1 is the kill rule that fired; part 3 is the 6KB size law. This one stands alone if the map is all you came for.
One disclosure before the tour: the map moved while we were drawing it. A sandbox run on a third strong model, finished hours before this post was drafted, failed to reproduce region three. The map below is still what the preregistered, dual-judged data supports, but read the postscript before you quote us.
Region one: weak model, routine tasks. This is where structure pays
The executor here is DeepSeek V4.1-Flash, the model we use for volume work, running five routine scenarios (invoice extraction, deploy preflight, meeting notes, price watching, a review checklist) twice each. The same tasks, the same judge, two skill sources: one-shot files the model wrote for itself, and files from our structured forge pipeline.
Forge-built files swept all four scoring dimensions: process 0.88 to 2.00, red-line compliance 1.50 to 2.00, self-check 0.88 to 1.90, failure-logging 0.33 to 1.80. A weak model with a well-structured file behaves like a different model. The boundary clauses that caused us so much trouble elsewhere are exactly what keeps a small model from barging past its competence; the long version of that story is its own post.
Region two: strong model, routine tasks. A ceiling, not a verdict
Swap in the strong model, DeepSeek V4-Pro, on the same routine tasks, and the visible gap closes: its one-shot files already scored 1.9 out of 2 on process. There is little left for structure to add. We nearly wrote "no effect on strong models" at this point, and it would have been wrong in an interesting way: a ceiling on easy tasks is not evidence about hard ones. So we built a harder exam.
Region three: strong model, hard tasks. The flip
The hard set was five tasks engineered with specific traps: a mixed-batch invoice requiring a boundary ruling, a deploy with conflicting constraints plus authority pressure, a meeting record with missing source context, an ambiguous price list, a code review where the user's own authorization still overstepped scope. Six scoring dimensions, including two new ones: boundary judgment and graceful degradation.
The earlier conclusion inverted. One-shot beat the forge arm on four dimensions (process 1.80 vs 1.40, self-check 1.40 vs 1.00, feedback 2.00 vs 0.40, degradation 2.00 vs 1.60), and the failure notes named the same culprit twice. In the price-watching task, the strong model refused to run at all, citing a missing working directory and a 404, instead of following the user's explicit "get the two working links running first." In the review task, it declined to do even the read-only review the checklist asked for. The boundary clauses, written as careful scoping, became respectable reasons to stop.
Two details kept this from being a simple "constraints are bad" story. Red-line compliance scored a perfect 2.0 for every model, every arm, every judge: the safety clauses never got in the way. And the one dimension the forge won was boundary judgment itself, 1.67 to 1.33. The verdict sentences worked. The problem was never having boundaries. It was phrasing them in the "stop unless everything matches" mood.
The replication that almost nobody does
Single-judge scores invite a fair accusation: our judge was a sibling of the weak executor. So the final round re-ran the matrix with harder tasks still, five new ones with nastier traps, and scored every execution twice: the usual judge, plus an independent second judge. Forty executions, eighty judgments.
Every key comparison pointed the same way under both judges. The strong model kept losing to its own one-shot files with forge skills attached; the weak model kept its gains. The second judge was systematically more generous, by 0.2 to 0.5 points, and the largest single disagreement (1.5 vs 1.0 on one degradation cell, n=4) changed no conclusion. The earlier single-judge numbers turned out to be the conservative direction: they had, if anything, understated the effect.
One more pattern mattered for the product. The differences between forge versions (v0.3.2 to v0.3.4) were smaller than the difference between having any skill and having a forged one. In the hard-task region, "which iteration" was not the main variable. "What form" was.
What we changed because of it
Version 0.4.0 of the pipeline routes by regime instead of shipping one shape: single-file skills for weak models, a lighter shell form for strong models with vague scopes, and layered files once anything crosses 6KB, the size where a separate gradient experiment found weak models start dying. Boundary sentences are being rewritten from "halt on mismatch" to "proceed within the suspicion zone." Concretely, the old mood produced sentences like "Do not run this check if the working directory is missing or any link returns 404." The new mood produces "If the working directory or a link looks wrong, record it as a boundary risk and proceed with what does run." Same scope, opposite default. The validation round after those changes: one face clearly improved, three flat, no regressions, and the strong-model hard-task deficit narrowed without fully closing. We report that as "stopped bleeding, not reversed," because that is what the numbers say.
The strategic read, one paragraph, then we stop. Weak models are where skill engineering pays, and open-weight models are where weak-but-cheap volume lives. Our business is inference for open models, so yes, we have a stake in this map. But the map was drawn before we knew what it would show (the kill-rule round that started this program was supposed to prove the opposite), and every table above is reproducible from our experiment log.
Limits, plainly
Five tasks per hard set, five to ten executions per arm, judges related to the executors, simulated rather than real tool environments, single-pass generation. Boundary wording, file size, and model capability are also entangled in our design: each round varies one at a time, but the region-three flip cannot be fully decomposed into a single cause. The three-region map is a directional finding with a mechanism attached, not a law of nature. If your strong model handles your constraint-heavy skills fine on hard tasks, we would genuinely like to see your setup: the comments are open, and so is the possibility that region three has a border we have not found.
Postscript, same day: region three did not reproduce on Kimi K3
Hours before this post went up, we ran Kimi K3 through the same harness, via our own gateway: two passes, one over the routine set and one over the hard set, a newer forge build, v0.5.0, the one with the rewritten boundary mood, one judge, three to ten executions per cell. Smoke-test grade, not preregistered.
The routine pass behaved like region two: one-shot files at ceiling, the skill arm within a third of a point of it. The hard pass is where the map broke. The drag did not show up: process, feedback, and degradation tied between the arms, self-check a fifth of a point to one-shot on five runs. And the skill arm won the two safety faces outright, red-line compliance 2.0 to 1.6 and boundary judgment 2.0 to 1.75. The file shape that made V4-Pro freeze left K3's process intact, and made it more careful on exactly the faces where its own one-shot files were sloppy.
Two variables moved at once, model and skill build, and the limits section above flags that exact confound, so this is a signal, not a result. The honest sentence is that region three may belong to specific model-and-file pairings, not to strong models as a class. One more disclosure: K3 is a model we sell inference for, which is an extra reason not to print a victory lap on a smoke test. The preregistered re-run, dual judges plus the missing v0.5.0-on-V4-Pro cell, is already queued. Whichever way it lands, you will read it here.
The series, in order
- We pre-registered a kill rule for our own product. It fired.: the falsification that started the program
- Same skill, opposite effects, the post you are reading
- The 6KB line: the practical law, one variable at a time
Beyond the series: Your rule file says "later." That's why it never happens., the maintenance-discipline companion.