# Extra

> Enforces a plan-before-execute, verify-before-done operating discipline for any multi-step task — coding, ML pipelines, hardware/firmware debugging, research, content batches, data work, dataset builds. Use this proactively whenever a task has more than one step, involves tool calls, or produces a deliverable where correctness matters, even if the user didn't explicitly ask for "a plan" or "rigor." Also functions as a portable system-prompt module (see references/portable-prompt.md) for driving non-Claude models — GLM, Kimi, local models, custom agent harnesses — through raw API calls, giving them the same planning and verification discipline without needing Claude's skill-loading system.

- Skill: `rsign1279/extra` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add rsign1279/extra`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rsign1279/extra/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Rsign1279 (https://skillmd.com/u/rsign1279)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/rsign1279/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`):

| Pattern | Use when | Example |
|---|---|---|
| Prompt chaining | Steps are fixed and sequential, each feeding the next | clean data → analyze → write report |
| Routing | The task is one of several distinct types that need different handling | classify a request, then dispatch to the right handling path |
| Parallelization | Subtasks are genuinely independent | generate N variants, run several independent checks |
| Orchestrator–workers | The subtask breakdown can't be fully known upfront | open-ended refactor, broad research question |
| Evaluator–optimizer | There's an explicit, checkable quality bar | polish a draft against stated criteria, tune a description |

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