five-step-optimizer

name	five-step-optimizer
description	Apply Elon Musk's Five-Step Algorithm to systematically optimize any process, system, or workflow through questioning, elimination, optimization, acceleration, and automation in strict sequence. Use when discussing process improvement, workflow optimization, system simplification, or eliminating unnecessary complexity. Loop-compatible: multi-pass runs converge via Loop Mode. Trigger keywords: five-step, five step optimizer, Musk algorithm, requirements less dumb, delete then optimize, simplify process, optimize workflow, loop the optimizer, optimization convergence.
license	MIT
metadata	{"version":"3.6.0","author":"ngpestelos","hermes":{"tags":["Optimization","Methodology","Process","Workflow","Refactoring"]}}

Five-Step Optimizer

Optimize processes, systems, and workflows. Key insight: most people work this backwards — optimizing and automating things that shouldn't exist. Execute in strict sequence.

Scope Gate (before any deletion)

• Optimize only artifacts you own or were explicitly asked to optimize. For anything else — or when ownership is unclear — present proposed deletions and get confirmation first.
• Ensure recovery exists before cutting: version control or a saved copy. No history and no backup → preserve a copy first.
• A requirement with no reachable owner and no stated rationale is [Questionable], not deletable — escalate it. The fence stays up until someone who knows why it exists says otherwise.
• Steps 4–5 can be structurally N/A (a static document has nothing to accelerate or automate). Say "N/A" and move on — do not invent automation to fill the step.

Step 1: Make Requirements Less Dumb

Ask: "Is this requirement actually necessary? Why does it exist? Is it still valid?"

Question every requirement. Mark each [Validated] or [Questionable] with rationale. [Questionable] items are Step 2 candidates, not automatic deletions: in unattended or non-owned contexts, get owner/user confirmation before cutting them; when the owner invoked you on their own artifact and your diff will be reviewed before commit, proceed and flag each [Questionable] cut in the output. The Scope Gate's escalation rule still applies to requirements the invoking owner didn't author.

Step 2: Delete

Ask: "Can we eliminate this entirely?"

Remove components/steps rather than optimizing unnecessary elements. Delete aggressively — the calibration signal is the add-back rate: roughly 10% of deletions should later prove needed and come back; if nothing ever comes back, you weren't deleting enough. In a single pass there is no add-back signal yet, so the check is Verify Before Closing below, not a quota — never delete a [Validated] requirement to hit a number. (In multi-pass runs this heuristic is suspended entirely — see Loop Mode.)

On document targets, run three mechanical sweeps before judging any category:

• Dangling intra-document pointers — every "(below)", "(above)", "see
  " must resolve inside the file; a pointer whose referent is missing is a finding (cut it, or repair it in Step 3). (Origin: 2026-07-11 five-step-optimizer calibration — premium caught one in a skill's lifecycle bullet; Sonnet 5 and Haiku 4.5 cold runs both missed it while making category-driven cuts.)
• Verbatim duplication between a fenced template/example and its surrounding prose — where both carry the same wording, at most one copy survives: keep the copy consumers parse (usually the fenced one) plus any extra specificity the prose adds, and cut the duplicated wording from the other. (Origin: 2026-07-11 same round — a clause duplicated 15 lines from its template copy; premium caught it, both cold tiers missed.)
• Inline date-stamp accretion in multi-revision documents — a doc revised over multiple sessions collects inline (added YYYY-MM-DD) / (reconciled YYYY-MM-DD) stamps that duplicate its own revision-log/changelog section. Strip the chronology-only stamps (the log owns the dates); keep only stamps carrying authority the log doesn't — adjudication or decision provenance like "user-adjudicated ". Precondition: the doc must HAVE a revision log; with no log, the inline stamps are the only provenance and stay. (Origin: 2026-07-19 design-doc pass — 10 stamps accreted across two days of multi-agent revisions, every date already recorded in the doc's Notes section.)

Step 3: Optimize

Ask: "How can we improve what remains?"

Only optimize what survived Steps 1-2.

Step 4: Accelerate

Ask: "How can we speed this up?"

Acceleration amplifies whatever exists — good or bad.

Step 5: Automate

Ask: "What can we automate?"

Automation comes LAST. Automating a flawed process locks in the flaws.

Verify Before Closing

Before reporting the optimization complete:

• For code: grep for every deleted identifier. If any call site remains, the deletion is incomplete — fix it or restore the identifier.
• For documents: re-read the optimized file top-to-bottom. Any reference to removed sections or variables is a bug.
• For anything executed or consumed by others: run the tests or exercise the behavior and compare against the pre-optimization result; check known consumers of any deleted output format. Grep proves references, not behavior — a clean re-read with changed behavior is a regression, not an optimization.
• Bare syntax checks (ast.parse) do NOT catch undefined references. Static analyzers (pyflakes F821, eslint no-undef, compilers) catch many — run them when available; execution or grep catches the rest.
• Red-team the deletions: for each Step 2 cut, argue the case for keeping it — what depends on it, what edge case it covered, who would notice it's gone. A cut that survives its own defense stays; one that doesn't gets restored, not merely footnoted. For a high-stakes or shared artifact, dispatch this as an actual adversarial pass (e.g. the red-team skill or a fresh subagent) rather than self-critiquing in the same pass that made the cuts.
• Open escalations: list any [Questionable] items still awaiting an owner answer in the completion report. An escalation that vanishes from the report is a silently dropped question.

Loop Mode (multi-pass runs only)

Bare invocation is single-pass: everything above, once. Loop Mode applies only when a loop harness (e.g. /loop) or an explicit request drives repeated passes over the same artifact; pipelines that invoke this skill once per run are unaffected.

Why: a delete-biased procedure has no natural fixed point. Re-read on every pass, the add-back heuristic ("if nothing ever comes back, you didn't delete enough") becomes an instruction to keep cutting forever. Loop Mode inverts the success signal — a zero-delta pass is convergence, not under-deletion — and suspends that heuristic entirely.

Per-pass procedure: read the carried state (below), run Steps 1–3, run Verify Before Closing, then end the pass with the updated carried-state block followed by the status line as the very last line. Steps 4–5 do not run per pass — they run once, inside the pass that reaches CONVERGED (see status semantics). Automating earlier just makes pass N's automation pass N+1's deletion candidate; deferring them to convergence is the strict-sequence rule applied across the loop's lifetime.

Carried state — emitted at the end of every pass, immediately before the status line; the next pass reads it before Step 1. The loop state is this block plus the status line that follows it — it persists through the loop transcript, and if each pass starts a fresh context, the harness must feed both back in (state file, artifact frontmatter, or prompt); a carried block without its status line breaks the absorbing rule below. No channel for it → Loop Mode is unusable; fall back to single-pass. Carry every item forward, updating only the counters:

Quiet passes: <n>      # consecutive zero-delta (Steps 1–3) passes; any Steps 1–3 delta resets to 0
Do-not-reapply:        # add-backs, owner-declined cuts, reverted optimizations
- <item>
Open escalations:      # proposed-but-unexecuted cuts awaiting an answer
- <item> (proposed <k> passes)

• Do-not-reapply items are excluded from Steps 2–3 — cutting or reworking one again is the oscillation this list exists to prevent. Entries are permanent tombstones and never block convergence. Text an owner restored between passes counts as an owner-declined cut. Under version control, history shows previously deleted content back in place — add it here instead of re-cutting. Without version control (saved-copy recovery only), comparison cannot distinguish a restore from never-cut, so record each executed cut here at cut time (- <item> (cut pass <n>)); a listed item that reappears is then already tombstoned.
• Open escalations holds every proposed-but-unexecuted cut: [Questionable] items and Scope-Gate confirm-first proposals alike. An answered item is executed (approved) or moved to Do-not-reapply (declined) on the next pass, quoting the answer. Unanswered items carry forward with their counter incremented — they do not re-surface as new findings and do not block convergence; they appear in the final report per Verify Before Closing.

Status line — the last line of every pass: STATUS: CONVERGED | STATUS: CONTINUE | STATUS: ESCALATE. Distinct whole tokens; anything reading the status matches the full value, never a substring. Driver rule, for the model reading the output (the harness itself parses nothing): re-run on CONTINUE; stop on CONVERGED or ESCALATE.

• CONVERGED — this pass made zero deletions, zero optimizations, and found nothing new, AND Quiet passes already stood at 1 or more (two consecutive quiet passes; a single quiet pass is run-to-run noise, not a fixed point). Then, still inside this pass: run Steps 4–5 once, run Verify Before Closing over their output, and end with carried state + status line as usual. Quiet passes is computed from the Steps 1–3 result only — the converged pass's own Steps 4–5 output does not reset it.
• ESCALATE — an Open escalations counter reaches 3 passes unanswered, or a pass cannot honor a Do-not-reapply exclusion (e.g. a consistency edit elsewhere would force rewording a tombstoned section). The persistent disagreement is the signal to surface, not something to grind on. If a pass qualifies for both CONVERGED and ESCALATE, ESCALATE wins — never run Steps 4–5 in the same pass that qualifies for ESCALATE; automating a question that just aged out closes it silently.
• Absorbing rule: a pass whose predecessor emitted CONVERGED or ESCALATE re-emits that status verbatim and does nothing else. Re-optimizing the artifact later is a deliberate fresh invocation with fresh state, not a continuation.

Unattended rule: with no owner reachable mid-loop, [Questionable] items are never cut — record on Open escalations and carry. This overrides Step 1's owner-invoked proceed-and-flag clause for the duration of the loop: that clause assumes a human reviews the diff per invocation, and nobody reviews a diff between unattended passes. Other deletions proceed only when the owner launched the loop on their own artifact and will review the accumulated diff afterward; otherwise every cut is propose-only. The Scope Gate is not relaxed by looping.

Common Step 2 Deletions (Coaching/Framework Skills)

These categories apply to agent-skill and methodology documents specifically — do not pattern-match them onto contracts, runbooks, or other domains. They are a floor, not the search space: a category-matched cut (e.g. a history section) does not complete Step 2 — artifact-specific defects no list names outrank category hits. (Origin: 2026-07-11 calibration — 6/6 cold reports cut the history section while missing every artifact-specific defect the premium caught.)

• Decorative quotes — literary/philosophical attributions that don't change execution
• Generic advice the agent already knows — "search before creating," "use evidence not self-perception." Safety and verification caveats are never "generic" — keep them.
• Output templates — the agent generates structured output naturally; delete only after checking consumers — a format parsed by another tool or agent is a contract, not a template.
• Key Rules that restate the steps — if a rule says the same thing as a step, it's redundant
• Example lists — static examples anchor instead of inspire; the agent generates better contextual ones
• "When to use" sections — duplicates frontmatter trigger keywords
• allowed-tools and similar permission frontmatter — intentional scoping, NOT an artificial restriction. Preserve it unless the skill's owner explicitly widens scope; harnesses that don't support it ignore it, while deleting it silently grants the full tool set.
• Optimization History / Changelog sections — inline history never informs behavior; version-control history records it with better discipline. Strip when history exists; otherwise preserve the content elsewhere first.