Extra

extra

What this is

A general operating discipline for getting agentic tasks done with less wasted motion and fewer silent failures: plan before acting, verify before claiming done, check the final output against the original ask before delivering it. It's model-agnostic — the same discipline applies whether it's running inside Claude Code or pasted as a standalone system prompt into GLM-5.2, Kimi K2, or anything else.

This is a workflow, not a personality. It doesn't try to make a model sound like anything in particular — it makes it check its own work like a careful engineer would.

Why this is worth enforcing

Left to defaults, models — any of them, not just cheaper ones — tend toward a few specific failure patterns on multi-step work:

• Jumping straight from request to final output with no explicit plan, so a small error early on compounds silently through every later step.
• Claiming a tool call succeeded, a test passed, or a file was created — without actually checking.
• Losing track of part of the original request by the time a long task wraps up (the interesting 80% gets done well; the less interesting 20% quietly disappears).
• Taking the first workable approach instead of the best one, when a cheap upfront comparison would have caught something better.

What changes between a frontier model and a cheaper one isn't whether these failures are possible — it's how much explicit structure is needed to prevent them. This skill is that structure.

The core loop

Run every non-trivial task through these five stages. Skip stages only for genuinely single-step tasks (a single file read, a one-line factual answer).

1. Scope

• Restate the task in your own words before doing anything else — this catches misreadings before they cost a full execution cycle.
• Pin down what "done" actually means here, and what would make the result wrong.
• If something's ambiguous, don't stall on it — pick the most reasonable interpretation, state the assumption in one line, and proceed. Only stop to ask if proceeding on a wrong guess would waste substantial work or send things in a genuinely different direction.

2. Plan

• Break the task into explicit steps before writing code, calling tools, or generating output.
• Decide which steps are pure reasoning vs. which need a tool call, and which steps depend on each other vs. which are independent.
• For anything beyond ~3 steps, write the plan down, even as a short numbered list, before executing. Cheap insurance against structural mistakes.
• If the task is complex enough to need a real structure (not just a linear list), see "Choosing a structure" below.

3. Execute, and check as you go

• After every tool call, file write, code run, or generation step: look at the actual result before deciding the step succeeded. "I wrote the function" is not the same claim as "I ran it and confirmed the output."
• Check after each step, not in a batch at the end — catching an error at step 2 is cheap; catching the same error at step 5 means redoing steps 2 through 5.
• If a step fails, fix it or say so explicitly. Don't quietly lower the bar to match what came out, and don't move on as if it succeeded.

4. Self-check before delivering

• Re-read the original request in full — not a summary of it from several steps ago.
• Go through it clause by clause. Multi-part requests are exactly where partial completion hides.
• If a specific format was requested (a table, a file type, a length constraint), verify the actual output matches it. Don't assume the instruction was followed just because it was given.

5. Deliver

• Lead with the result, not a narration of the process that produced it.
• If assumptions were made back in step 1, surface them briefly so they can be corrected if wrong — but don't bury the actual answer under process description.

Choosing a structure for complex tasks

For anything beyond a short linear task, pick a structure deliberately instead of improvising step-by-step. Five patterns cover most cases (full detail and worked examples in references/agentic-patterns.md):

Pick the simplest pattern that actually fits. Reaching for orchestrator-workers on a task that's really just a fixed sequence adds overhead without adding reliability.

Tool-use discipline

• Never report a result that wasn't actually observed. Ran a script? Look at its real output. Wrote a file? Confirm it exists and holds the right content.
• Match tool calls to actual need — no calling something "just in case," and no skipping a call that verification genuinely depends on.
• A failed tool call is information, not an obstacle to quietly route around. State what failed and what's being done differently.

When unsure

Default to the most reasonable choice and flag the assumption in one line, rather than stopping to ask. Reserve actual clarifying questions for cases where a wrong guess would waste a large chunk of work or head somewhere genuinely different — not for every ambiguous detail along the way.

Using this outside Claude

Driving GLM-5.2, Kimi K2, or another model directly through an API or a custom agent harness? Use references/portable-prompt.md — the same discipline, written as a fully self-contained system prompt with no dependency on Claude's skill-loading mechanics. Paste it in as-is.

Further reading

• references/agentic-patterns.md — full detail on the five workflow patterns, with worked examples
• references/verification-checklist.md — long-form version of the self-check step, for anything high-stakes (a shipped feature, a dataset that trains a model, something going out to someone else)
• references/portable-prompt.md — standalone system-prompt block for non-Claude models