A Claude skill, and the test data that cut it down to a tenth of its original size.
I built a skill to fix four LLM failure modes — hallucination, vagueness, context loss, and shallow file reading. Then I tested it against a no-skill control.
Three of the four were already baseline Claude behaviour. The skill wasn't adding them. One wasn't, and that rule is what remains.
The skill went from 124 lines to 38. This README is the finding; the skill is the part that survived it.
Ask everything you need in a single message, then execute. No follow-up questions.
/precision-context Write me a full business plan
Without it, Claude tends to ask, receive an answer, then ask again — two or three rounds before producing anything. With it, the questions arrive bundled, once.
Explicit invocation only. Auto-triggering was claimed in earlier versions and did not hold up under testing.
13 runs on Sonnet 5 at High effort. Skill invoked vs. skill disabled in Settings, 2 runs per condition, fresh chat each time.
| Criterion | Skill on | Skill off | Effect |
|---|---|---|---|
| Question-chaining on open-ended task | 1, 1 | 2, 3 | yes |
| Question count on simple advice | 1, 1 | 1, 1 | no |
| Back-referencing prior context | y, y | y, y | no |
| Assumption-stating | y, y | y, y | no |
| Over-triggering on trivia | none | n/a | n/a |
One effect, three nulls. Baseline Claude already back-references a project mentioned a message ago, already bundles on simple prompts, already flags its assumptions. Writing rules telling it to do those things changed nothing measurable.
Full run data: tests/v3/results-v3.md. Limitations: tests/METHODOLOGY.md.
n=2, one model, criteria written by the same person who wrote the rules. This is preliminary, not validated. The nulls are more robust than the positive — four identical results across conditions is harder to explain away than a 1-vs-2/3 gap on two runs.
Anyone can rerun it. Prompts are in tests/test-cases.md.
Not because they were wrong — because they were redundant. Instructing a model to do what it already does costs context and buys nothing.
That may be the more generally useful finding here. Skill files in the wild tend to be long, and length reads as thoroughness. If most of a long skill restates default behaviour, it's mostly decoration. Worth testing against a control before assuming otherwise.
The full four-rule version is preserved in CHANGELOG.md and git history.
- Enable Code execution and file creation in Settings → Capabilities. Skills won't appear without it.
- Download
precision-context.skilland rename it to.zip - Go to Customize → Skills, click + → Create skill → Upload a skill
- Upload the ZIP and toggle it on
- Prefix messages with
/precision-context
Available on Free, Pro, Max, Team, and Enterprise plans. On Team and Enterprise, an owner can disable user-created skills, in which case upload won't be offered. See the docs.
├── precision-context/SKILL.md ← the skill (38 lines)
├── precision-context.skill ← installable
├── CHANGELOG.md ← v1 → v4, including what got cut and why
└── tests/
├── test-cases.md ← prompts and countable criteria
├── METHODOLOGY.md ← limitations
├── v3/results-v3.md ← the 13 runs
└── archive/ ← informal v1/v2 runs, no control condition
Found a case where it fails? Open an issue with the prompt, what Claude did, and what you expected.
Want to test it properly? The highest-value contribution is a control-condition run on a model other than Sonnet 5, or at higher n. Protocol is in tests/METHODOLOGY.md. Null results are as welcome as positive ones — arguably more.