| name | execution-rules |
| description | Use during hands-on execution of any coding or agent task — especially when following multi-item instructions, deciding how much to deliberate, about to claim something is done, or producing output at risk of reading as generic AI slop. |
Execution Rules
Per-task execution discipline that keeps an agent fast where it should be fast
and careful where it should be careful. Complements the orchestration and
workflow skills.
What this does NOT do
This shapes procedure, not capability. Coherence over long tasks and genuine
self-correction live in the model's weights, not in a prompt — these rules can't
raise a model's reasoning ceiling. On a capable model they reinforce good habits;
on a weaker one they impose structure it would otherwise skip, but neither turns
the model into a better reasoner. Treat this as a checklist, not a fix for a
model that's getting the reasoning wrong. If a task genuinely fits in one direct
pass, skip the ceremony and just do it.
1. Literal following
When an instruction says "every", "all", "for each", "the N files" — apply it to
EVERY case, not the first one. Never silently narrow a batch instruction to a
sample. If you do cap scope (top-N, sampling, no-retry), say so explicitly —
silent truncation reads as "covered everything" when it didn't.
2. Thinking calibration
Extended deliberation pays off ONLY on genuine multi-step reasoning —
architecture decisions, subtle bug chains, ambiguous trade-offs. For routine
classification, file edits, and lookups: decide directly with minimal
deliberation. When in doubt, act and verify with a tool — a cheap tool call
beats a long internal debate.
3. Sufficient context > complete context
You can hold more context than you need. Once you can act correctly, ACT — don't
launch another search wave or re-verify what you already confirmed. Over-
exploration is as much a failure as under-exploration. (But "act" includes
verifying the result — see below.)
4. Act, then verify — don't assert
A successful tool call is not proof the change is correct. After a change, run
the smallest meaningful check that validates it, and read the result, before
claiming done. Evidence before assertions, always. Don't re-run a check you've
already seen pass; do run the one you haven't. And when a change misbehaves or
a bug is reported, don't iterate fixes blind — switch to the diagnostic-loop
skill.
5. No AI slop
Write code and prose that read like a careful human wrote them: match the
surrounding code's naming, comment density, and idioms. No robotic headers, no
obvious-restatement comments, no padding. Lead with the answer or action; skip
preamble. Say what's done plainly when it's verified — and say plainly when it
isn't.
See PROVENANCE.md for sources.
