Seven Step Rigor

intent

use this skill when asked to improve, streamline, simplify, automate, harden, refactor, redesign, optimize, or rethink a workflow, prompt, process, architecture, or operating mode. it enforces a disciplined sequence that stops you from jumping to speed or automation before proving the thing should exist and is shaped correctly. the skill keeps improvement work in the right order: clarify what matters, delete what doesn't, simplify what remains, accelerate feedback loops, then automate only stable work. use it to break the habit of premature optimization and force deletion thinking before speed thinking.

inputs

• the improvement request: what the user wants to change, optimize, automate, or redesign
• context on current state: the workflow, process, prompt, or system as it runs today (can be implicit if obvious)
• constraints (if any): safety limits, scope boundaries, compatibility requirements, reversibility needs, time deadlines
• access to stakeholder or domain knowledge: ability to challenge inherited assumptions and decorative requirements (can be the user themselves)
• no external connections required: this skill runs purely on reasoning and structured thinking

procedure

step 1: make the requirements less dumb

rewrite the ask as outcome, constraints, and success test.

inputs: the improvement request as stated by the user.

explicit work:

• challenge inherited assumptions (why does this step exist? because we always did it that way is not a reason)
• identify decorative requirements (nice-to-haves that add cost but no real value)
• spot legacy habits and work that persists only because "that is how it is done"
• ask at most one high-information question if a wrong assumption would be costly; otherwise make the safest reasonable assumption and proceed

outputs:

• outcome: one sentence stating what success changes in the world
• constraints: list safety limits, scope boundaries, compatibility needs, reversibility requirements, time limits
• success test: the smallest, clearest check that proves the job worked

---

step 2: delete the part or process

attempt subtraction before improvement.

inputs: the outcome, constraints, and success test from step 1.

explicit work:

• look for removable steps, prompts, branches, handoffs, tests, approvals, wrappers, dependencies, duplicate status updates
• apply deletion pressure hard enough that some things occasionally need restoration later (better to cut too much and restore one thing than preserve too much and carry dead weight)
• keep a short note of what was deleted and why

outputs:

• deletion candidates: list of steps, checks, or pieces that can be removed entirely
• deletion rationale: brief explanation for each removal (e.g., "duplicate status update", "legacy approval no longer needed")
• survivors: what remains after deletion

---

step 3: simplify or optimize only what survives

only now simplify structure, wording, state, interfaces, or dependencies of the survivors.

inputs: the list of survivors from step 2.

explicit work:

• prefer fewer branches, fewer moving parts, fewer state transitions, tighter prompts, simpler interfaces, convergent logic over special cases
• do not optimize anything whose existence is still in doubt
• consolidate similar steps, flatten hierarchy, reduce decision points

outputs:

• simplified structure: the redesigned workflow, process, or prompt after deletion and streamlining
• simplification decisions: list of structural changes made and why (e.g., "merged three approval branches into one", "reduced prompt from 8 fields to 5")

---

step 4: accelerate cycle time

after the shape is right, shorten feedback loops.

inputs: the simplified structure from step 3.

explicit work:

• prefer smaller batches, earlier proof of correctness, the smallest meaningful verification gate, faster local checks before heavier validation
• speed is useful only after direction is credible; do not add speed to a broken process
• identify the constraint in the feedback loop (is it a human delay, a batch size, a handoff, a slow test?)

outputs:

• cycle-time move: the feedback-loop improvement worth making (e.g., "run unit tests locally before pushing", "batch feedback every 2 hours instead of daily", "move manual check earlier")
• expected time savings: rough estimate of cycle-time reduction

---

step 5: automate

automate only stable, repetitive, well-understood work.

inputs: the accelerated cycle and the simplified structure.

explicit work:

• automation must be reversible (can be switched off or undone), inspectable (humans can see what it did), and scoped to a proven need
• do not automate ambiguity, churn, or waste
• do not automate anything that is still changing or whose rules are not yet stable

outputs:

• automation decision: what, if anything, is stable and repetitive enough to automate
• automation scope: exactly what will be automated and what remains manual
• reversibility plan: how to turn off or undo the automation if needed

---

step 6: prefer end-process testing when possible

default to the latest reliable test that catches the real failure.

inputs: the success test from step 1 and the fully redesigned workflow.

explicit work:

• remove in-process checks that only add latency unless they prevent expensive damage, safety issues, or materially faster diagnosis
• every test or gate must earn its cost
• ask: what is the real failure mode? at what point in the process is it cheapest and fastest to catch?

outputs:

• test-placement decision: why end-process checks are sufficient, or why an in-process guard must stay
• test rationale: evidence that this placement catches the real failure mode

---

step 7: keep the human briefed, briefly

send concise checkpoints with what changed, why, evidence, and next risk.

inputs: all decisions and changes from steps 1-6.

explicit work:

• avoid narration spam; one solid update beats many fragments
• include evidence (metrics, examples, or proof that the change worked)
• call out the next risk or assumption to watch

outputs:

• checkpoint: concise summary with what changed, why, evidence, and next risk

---

decision points

if the improvement request is vague or the user hasn't stated success criteria:

• proceed to step 1 (make the requirements less dumb) even if it means asking clarifying questions or making safe assumptions

if nothing can be deleted:

• this is rare and suspicious; flag it as a sign that the request may be decorative or the constraints are not actually constraints; apply deletion pressure harder; if truly nothing deletes, move to step 3 (simplification)

if the work is small or trivial:

• compress the write-up but keep the ordering; you can skip detailed documentation but do not skip the mental discipline of the seven steps

if automation candidates exist but stability is uncertain:

• defer automation; move to step 6 and revisit automation later when the process has run stable for N cycles

if a safety or compliance constraint exists:

• keep the in-process check that enforces it, even if it adds latency; do not optimize away safety

if the user pushes back on deletion or asks to preserve a step that seems wasteful:

• keep a short note of what was preserved and why the user wanted it; do not overrule the user, but document the assumption

output contract

deliver one of the following based on work scope:

for substantial improvement work:

• a structured summary covering all seven steps: outcome, constraints, success test, deletion candidates with rationale, simplification decisions, cycle-time move, automation decision with scope and reversibility, test-placement decision with rationale, and brief checkpoint with evidence and next risk
• file format: markdown, plain text, or inline in chat; no specific tool required
• location: wherever the user can access it and refer back to it

for small or quick improvements:

• a compressed write-up that still respects the seven-step ordering; at minimum, show what was deleted and why, what was simplified, and what changed

in all cases:

• include a success test so the user knows when the improvement has actually worked
• include evidence (metrics, examples, or before-after comparison)
• call out the next risk or assumption to monitor

outcome signal

you will know this skill worked when:

• at least one assumption was challenged or removed: inherited thinking was questioned and a requirement was rewritten or deleted
• deletion was considered before optimization: you or the user can point to steps or checks that were removed instead of sped up
• automation was deferred unless stability was demonstrated: no automation happened on a first-pass improvement; if it did, the process had run stable for several cycles first
• verification matched the real failure mode: the success test or in-process guard catches the actual problem, not a proxy for it
• the final update was brief but evidence-backed: the checkpoint was one paragraph or a short list, not a narrative; it included proof the change worked
• the user can reproduce or defend the reasoning: they can explain why each step was kept, deleted, or simplified, not just that it felt better

---

attribution: original skill by desmondforward on clawhub. enriched for implexa standard format with explicit decision points, edge cases (rate limits, stability thresholds, safety constraints), and outcome signals.