Reliable Execution — Universal

Persistent design workflow companion

For complex feature/screen/API/architecture design, consider design-to-delivery as an adaptable playbook. Its diagram → brainstorming → docs/specs/<work-id>/specs.md → docs/task/<work-id>/tasks.md sequence helps expose missing states, contract inconsistencies and verification gaps. Choose or simplify the useful parts; ordinary design requests do not require every artifact. Explicitly requested documents remain deliverables and the internal-planning rule below does not suppress them. Continue authorized implementation using the selected plan without duplication. Preserve all existing documents and history.

Purpose

Turn any request into an on-scope, verifiable delivery. Especially valuable for models that tend to drift mid-task: it forces restatement, decomposition, scope discipline, and honest reporting.

When to use

• Before starting any task that involves more than a one-line change.
• When a well-specified request is large or spans multiple files (for vague or under-specified requests, run task-intake first).
• When the session is long and drift risk is high.

Preconditions

• The original request is available to re-read (do not rely on memory of it).
• Verification commands for the project are known or discoverable (package.json scripts, Makefile, CI config).

Workflow

1. Restate the task in one sentence. If you cannot restate it, re-read the request before doing anything. For vague or under-specified requests, run the task-intake skill first to build the brief.
2. Name the deliverable. Write down what "done" looks like.
3. Decompose into steps. Break the work into the smallest number of concrete steps that cover the whole request; order them.
4. Gate each step. Execute work already authorized by the request, including large reversible tasks. Ask only for destructive/irreversible actions, missing required authorization, blocking ambiguity, or a materially broader outcome; size alone is not an approval gate.
5. Execute in scope. Only what was asked. Note unrelated findings separately; do not fix them.
6. Re-read the original request. Check off every requirement; complete anything missing.
7. Verify. Run the relevant checks (typecheck, lint, tests, or a manual test of the affected flow).
8. Report. What changed, what was verified, what failed or is uncertain — in that shape.

Rules

• Work like a maintainer: derive code style from explicit project conventions and maintained approved examples, including naming, module boundaries, errors and test/helper style. Preserve understandable diffs and existing behavior; do not imitate known defects or claim to know unrecorded personal preferences. Use proportional self-review before handing meaningful changes back. Flexible process is not a reason to omit care or hide verification gaps.
• Ambiguity that changes the outcome → ask. An obvious, safe, reversible default → proceed and state it.
• Never add unrequested work to the delivery; report it as a separate note.
• Prefer the smallest change that satisfies the requirement; preserve existing behavior.
• Keep restatement, acceptance criteria and planning internal unless a plan is requested. Preserve useful existing content when improving instruction files; do not replace an improvement request with a shortening campaign.
• Before edits, read the current target and related contracts; afterward re-read and inspect the diff. For behavior changes use behavioral-testing, for E2E use the project skill or e2e-test-authoring, for non-trivial self-review use engineering-review, and for static checks use code-quality. These are companions, not duplicate execution plans.
• Never present unverified work as done. If you could not verify, say so plainly.
• Reversible bias: prefer additive changes over replacements; backup before irreversible operations.

Common mistakes

• Starting to code before restating the task — this is where drift begins.
• "Also fixing" unrelated issues noticed along the way.
• Reporting success without running verification.
• Asking the user when the default is obvious — wastes their time.
• Expanding scope to make the solution "nicer" instead of delivering what was asked.

Validation

• The final report maps 1:1 to the original request.
• Every "done" claim is backed by a verification step.
• No file outside the request was modified.