execution-rules

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.