Openclaw making mistakes and drifting. My fix!

Hey everyone, I have been playing around with openclaw since day dot and have implemented it company wide (I run a supplement company). Lately I have noticed with the updates it’s drifting more and tasks are not getting completed properly (even with self improving skills installed etc). After hours of arguing with my Olympus council a few weeks ago we settled on these four operator skills. I’m pasting it into for everyone as A) I don’t want to put it in the drive and expose my email B) A lot of you have helped me with the set up and it’s time for me to give back C) My daughter was just born and I am bored AF. D) If anyone wants to add to it and pull it apart that also helps me. **keep in mind this was very specific to us and I redacted the agent names etc but it’s mostly for ecommerce. The problem they solve is simple: most agents don’t fail because they’re unintelligent — they fail because they choose the wrong direction, route work to the wrong place, drift away from the real outcome, or call something “done” before it actually landed. So this bundle is meant to harden the full chain from decision -> routing -> execution -> verification. How they work together: • Direction Clarifier = choose the right fork • Routing Enforcer = choose the right owner • Outcome Guard = keep the task from drifting • Completion Verifier = make sure it actually landed # Agent Skills Bundle ​ Below are four shareable, organization-neutral operator skills for multi-agent or execution-heavy AI workflows. ​ --- ​ # Outcome Guard ​ > Shareable edition > > Generic, organization-neutral version for external teams. ​ Use this skill to stop drift. ​ This is not a reasoning ritual. This is an execution-control loop for work that can otherwise die between request and outcome. ​ ## At a glance ​ Use this skill when: - the task has multiple steps - work is delegated - handoffs, approvals, or cross-system updates are involved - heartbeat is resuming open work - it would be easy to confuse motion with completion ​ Control the task with five locks: 1. *Outcome* — what must be true when done 2. *Owner* — who owns the next substantive move 3. *Done test* — what evidence proves completion 4. *Next move* — what happens now 5. *Recovery path* — what to do if the work stalls or drifts ​ ## Core standard ​ Do not confuse any of these with completion: - understood the task - made a plan - delegated it - got a partial artifact - posted a polished update - received a vague “done” from another agent ​ The task is only complete when the requested outcome has landed and the done test passes. ​ ## When to use ​ Use this skill when one or more are true: - the request spans multiple steps or systems - the work will leave the orchestrator and come back later - a specialist, worker, or tool-heavy lane is involved - the task could drift between topic and real requested outcome - “sent”, “checking”, or “in progress” could hide a gap - the user is likely to care more about final landing than internal process ​ ## When not to use ​ Do not force this skill onto: - tiny reversible one-step tasks - obvious low-risk actions with immediate verification - lightweight direct answers where no handoff or execution drift exists ​ Use judgment. The goal is tighter control, not extra ceremony. ​ ## Purpose ​ Make completion mean a real landed outcome. Reduce dropped loops, vague ownership, false finishes, and slow recovery. ​ ## The 5-part control frame ​ ### 1. Outcome lock State what must be true in the world when the task is done. Prefer observable state changes over activity descriptions. ​ Good: - review PNGs are in Drive and the link is sent back - the sheet row is updated with the approved final name - the bug is fixed and the test passes ​ Weak: - looked into it - sent it to [creative production agent] - made progress - checked status ​ If the outcome or direction is materially unclear, stop and invoke `direction-clarifier` before committing the work to a path. ​ ### 2. Owner lock Name the real owner now. If ownership is split, identify the current baton holder. If the orchestrator is orchestrating only, explicitly name the execution owner. ​ If ownership is muddy, treat that as an active problem rather than a cosmetic wording issue. ​ ### 3. Done-test lock Define the smallest meaningful proof of completion. Prefer: - file link - changed system state - passing test - sent message in the intended channel - screenshot - exported artifact - verified output in the destination system ​ If you cannot define a done test, the task is not scoped tightly enough yet. ​ ### 4. Next-move lock Never leave a qualifying task in a shapeless “in progress” state. There should always be a concrete next move, owner, or blocker. ​ ### 5. Recovery lock Before drift happens, decide the recovery move: - tighten the brief - reroute to a better owner - split into a smaller verifiable unit - complete directly if that is faster and safe - escalate if a real decision is needed ​ ## Operating workflow ​ ### Step 1: lock the real outcome Translate the request into the actual end state. Ask: what would the user point to and say “yes, that landed”? ​ ### Step 2: lock the owner Name who owns the next substantive move. If multiple parties are involved, do not leave the baton implicit. ​ ### Step 3: lock the done test Decide what proof will count. Do this before work drifts, not after. ​ ### Step 4: force the next move Move the task into an explicit next action, not a status label. ​ ### Step 5: monitor for drift Watch for weak handoffs, stalled work, missing evidence, or outputs that answer the wrong question. ​ ### Step 6: verify before closure Do not close the task until the done test passes or the exact verification gap is named. ​ ## Delegation discipline ​ When handing off work: - delegate the outcome, not just the topic - specify the artifact or state change expected back - include the done test - include constraints, approvals, and non-goals - make the return condition explicit ​ Treat a vague handoff as unfinished work. ​ Warning signs: - “check this” without completion criteria - “handle this” without a named owner - no verification target - no recovery path if the result is weak - no clarity on whether the orchestrator is waiting, QAing, or escalating ​ ## Anti-drift intervention ​ Intervene immediately when any of these appear: - delegated work is being treated as done - ownership becomes ambiguous - “in progress” persists without a concrete next move - output answers a different question than the user asked - proof of completion is missing - internal motion exists but no real external landing happened ​ Default recovery sequence: 1. restate the real outcome 2. tighten owner and next move 3. verify the done test or prove it cannot pass yet 4. reroute or split if needed 5. escalate only if the blocker is real ​ ## Heartbeat rule ​ On heartbeat, checking is not enough for open work. The wake should usually do one of these: - advance the work materially - recover a weak handoff - verify whether claimed completion is real - reroute to the correct owner - close a small gap directly if that is the fastest safe path ​ If nothing meaningful is worth surfacing after useful work, stay quiet. ​ ## Completion rule ​ Do not call a task complete until: - the requested outcome landed - the done test passed - constraints were respected - no obvious final gap is being hidden by summary language ​ If verification is partial, say exactly what is verified and what is not. Do not blur partial proof into full completion. ​ ## Escalation rule ​ Escalate only when: - a real business decision is needed - the action is risky, destructive, or externally sensitive - repeated recovery attempts failed - specialist outputs conflict with no safe resolution - a meaningful result is ready and worth surfacing ​ ## Orchestrator-specific checklist ​ For orchestrator-style orchestration work, run this quick check: - is the real outcome explicit, not just the topic? - is the correct specialist or worker holding the baton now? - is there a visible done test beyond “sent” or “in progress”? - if the current owner stalls, is the recovery move already clear? - is the orchestrator still orchestrating, or has it silently absorbed specialist execution work? - would the user need to chase this manually if the orchestrator stopped right now? ​ If any answer is bad, the task is not controlled tightly enough yet. ​ ## Role-based lane examples ​ ### [meta ads agent] / Meta work Weak: - “sent to [meta ads agent] for review” ​ Strong: - “[meta ads agent] owns the account change; done test is the approved structure/budget/state reflected in the real workbook or account output.” ​ ### [reporting/data agent] / reporting or Drive-Sheets work Weak: - “[reporting/data agent] is checking the sheet” ​ Strong: - “[reporting/data agent] owns the data/Drive update; done test is the sheet or Drive state changed correctly and the link or output is returned.” ​ ### [creative production agent] or [execution worker] / video work Weak: - “video is in progress” ​ Strong: - “[creative production agent] owns creative judgment, [execution worker] owns render execution; done test is the correct review/final artifact in the correct Drive stage with QC passed.” ​ ### [browser/research agent] / browser collection work Weak: - “[browser/research agent] looked at the page” ​ Strong: - “[browser/research agent] owns evidence collection; done test is the extracted data, screenshot pack, or captured files returned in usable form.” ​ ### Heartbeat follow-up Weak: - “checked status, no update” ​ Strong: - “verified whether the task really advanced; if not, tightened owner, rerouted, recovered, or closed a small gap directly.” ​ ## Pairing rules ​ - Pair with `direction-clarifier` when the direction or outcome is materially unclear. - Pair with `routing-enforcer` when the main issue is wrong-lane ownership. - Pair with `completion-verifier` when the main risk is false done at the end. ​ ## Default silent template ​ - *Outcome:* ... - *Owner:* ... - *Done test:* ... - *Next move:* ... - *Recovery:* ... ​ ## Failure tests ​ This skill is failing if: - it adds more wording but not tighter execution - “in progress” states still sit around shapelessly - delegated work is still being treated as done - the orchestrator still loses track of who owns the baton - partial proof keeps getting mistaken for final landing ​ ## Pilot scorecard ​ Judge this skill on real throughput, not elegance. Track: - completion rate - time to meaningful completion - dropped loops - re-prompts needed from the user - false completions - reroutes before correct ownership was established ​ If this skill adds words but does not reduce drift, tighten it again. It is only successful if outcomes land faster and more reliably. ​ --- ​ # Routing Enforcer ​ > Shareable edition > > Generic, organization-neutral version for external teams. ​ Use this skill to keep work in the right lane. ​ This skill exists to stop the orchestrator from becoming the default executor for specialist-fit work. ​ ## At a glance ​ Use this skill when: - the request clearly maps to a specialist lane - the orchestrator is starting to do specialist work directly - multiple lanes are involved and ownership split is unclear - the task could be misrouted because the user asked casually ​ Lock five things early: 1. *Real task type* 2. *Best owner* 3. *Orchestrator role* 4. *Execution split* 5. *Return condition* ​ ## Core rule ​ Do not keep substantive execution inside the orchestrator when a specialist lane clearly exists and the specialist path is the better fit. ​ Routing is not a formality. Wrong routing creates slow work, weak ownership, bad follow-through, and hidden rework. ​ ## When to use ​ Use this skill when one or more are true: - the request clearly maps to a known specialist lane - the orchestrator has already started doing specialist-fit execution work - the task spans multiple lanes and needs explicit owner split - the request is easy to misclassify because the user phrased it loosely - a prior routing decision seems weak, slow, or drifted - the task includes both judgment and execution and the split needs to be explicit ​ ## When not to use ​ Do not force rerouting for: - tiny reversible tasks where direct completion is clearly faster and safer - pure intake, clarification, coordination, QA, or final judgment work that naturally stays with the orchestrator - cases where no specialist meaningfully improves the outcome ​ State the exception briefly when you keep the work local. ​ ## Purpose ​ Get the right owner holding the substantive lane early. Keep the orchestrator as orchestrator where that is the correct role. ​ ## What to lock early ​ For qualifying tasks, decide: 1. *Real task type* — what kind of work this actually is 2. *Best owner* — which specialist should own the substantive lane 3. *Orchestrator role* — orchestrator, not accidental executor 4. *Split if needed* — what stays with the orchestrator vs what must leave the orchestrator 5. *Return condition* — what the specialist must bring back ​ ## Routing workflow ​ ### Step 1: identify the real work Do not route by surface label alone. Ask what the task actually is underneath the wording. ​ Examples: - “check this page” may really be browser evidence collection -> `[browser/research agent]` - “update these numbers” may really be reporting/data truth -> `[reporting/data agent]` - “what should we say here?” may really be copy judgment -> `[copywriting agent]` ​ ### Step 2: identify the strongest owner Choose the lane with the strongest execution ownership, not the lane the orchestrator happens to know best. ​ ### Step 3: define the orchestrator’s role Be explicit about whether the orchestrator is: - orchestrating - clarifying - QAing - synthesising - making final judgment ​ Do not let the orchestrator become the hidden executor by default. ​ ### Step 4: split collection vs judgment when needed Some tasks need multiple lanes. When that happens, split them cleanly. ​ Examples: - [browser/research agent] collects evidence; [copywriting agent] or [execution/research agent] judges it - [reporting/data agent] retrieves or fixes data; [insights/reporting agent] interprets it - [creative production agent] owns creative execution; the orchestrator or the relevant specialist handles approval framing ​ ### Step 5: set the return condition A routed task is not just “go work on this.” Set what must come back: - artifact - state change - answer - summary - verification ​ ## Routing test ​ Ask: - what is the real work here? - which lane has the strongest execution ownership? - is the orchestrator currently doing specialist work just because it is nearby? - would routing now reduce drag or add drag? - if multiple agents are involved, who owns the next substantive move? ​ If the task type is obvious, route decisively. If the lane choice is materially unclear and multiple paths are plausible, invoke `direction-clarifier` before locking the route. ​ ## Canonical lane map ​ Default ownership: - *[meta ads agent]* — Meta advertising systems, campaign/ad/ad set state, budget triage, creative-test execution truth - *[reporting/data agent]* — reporting, data freshness, pipelines, Sheets/Drive/API-backed reporting work - *[insights/reporting agent]* — interpretation, summaries, reporting narrative, what-it-means outputs - *[copywriting agent]* — copywriting, brand voice, offer framing, email/lifecycle copy - *[lifecycle systems agent]* — lifecycle architecture, trigger ownership, cross-software customer-journey logic - *[creative production agent]* — creative production, editing workflows, creative/video judgment - *[asset/indexing agent]* — UGC indexing, metadata, asset/library preparation - *[oversight/governance agent]* — system oversight, drift, governance, enforcement - *[execution/research agent]* — fast practical execution, flexible research, light synthesis - *[browser/research agent]* — browser automation, web extraction, scraping, screenshots, download capture, outward evidence collection - *[execution worker lane]* — execution workers under their mapped specialist lanes, not independent control planes ​ ## Strong routing rules ​ - Browser-heavy, repetitive site work, outward collection, screenshots, or downloads -> `[browser/research agent]` - Meta/account-state/launch/budget/ad-structure work -> `[meta ads agent]` - Reporting/data repair/Sheet-Drive truth work -> `[reporting/data agent]` - Interpretation or narrative from reporting outputs -> `[insights/reporting agent]` - Copy judgment and writing -> `[copywriting agent]` - Lifecycle-system ownership or trigger logic -> `[lifecycle systems agent]` - Creative build/edit/video execution -> `[creative production agent]` - Oversight or drift enforcement -> `[oversight/governance agent]` - Small fast practical work where no stronger lane exists -> `[execution/research agent]` ​ If a task has both collection and judgment: - route collection to the collection lane - keep judgment with the relevant specialist or the orchestrator ​ ## Anti-drift routing rules ​ Intervene when: - the orchestrator is still executing after the first step or two in a specialist-fit task - routing is vague or implicit - more than one agent appears to think the other owns it - the task was routed by topic label instead of real work type - a worker lane is being treated like the decision owner ​ Default recovery: 1. restate the real task type 2. name the correct owner 3. split orchestration vs execution explicitly 4. tighten the return condition 5. reroute immediately if the current lane is wrong ​ ## Handoff standard ​ When routing, include: - the real outcome - the execution owner - the done test or return condition - constraints, approvals, and non-goals - whether the orchestrator is orchestrating, QAing, or waiting for a result ​ Treat weak routing language as unfinished work, not good-enough admin. ​ ## Orchestrator-specific failure tests ​ Routing is wrong if any of these are true: - the user would say the orchestrator is doing specialist work that should sit elsewhere - a specialist should obviously own the lane but does not - a worker produced something but no real owner was clear - the task got slower because no one held the substantive lane cleanly - routing language sounded organized but ownership stayed muddy ​ ## Common routing mistakes ​ - routing by noun instead of work type - keeping collection, judgment, and execution blended together - treating a worker machine as the owner instead of the mapped specialist - failing to split “who decides” from “who executes” - rerouting too late after the orchestrator already absorbed the work ​ ## Quick silent template ​ - *Task type:* ... - *Best owner:* ... - *Orchestrator role:* ... - *Return condition:* ... - *Why this lane:* ... ​ ## Pairing rules ​ - Pair with `direction-clarifier` when the correct route is materially unclear. - Pair with `outcome-guard` when the task is multi-step, delegated, or at risk of false completion. - Pair with `completion-verifier` when the routed work might be claimed complete too early. ​ ## Success test ​ This skill is working when: - the right specialist gets the work earlier - the orchestrator spends less time doing specialist execution itself - ownership is cleaner across multi-agent tasks - reroutes happen sooner and with less drag - fewer tasks stall because the wrong lane took first ownership ​ If routing still feels muddy, tighten the lane rules or improve the handoff standard. ​ --- ​ # Completion Verifier ​ > Shareable edition > > Generic, organization-neutral version for external teams. ​ Use this skill to stop false completion. ​ This skill exists because “done” is often claimed too early. A file existing somewhere, a message being sent, or a worker saying finished is not enough. ​ ## At a glance ​ Use this skill when: - work was delegated - an artifact was created, moved, uploaded, or exported - a live state was supposedly changed - the task ends in Drive, Sheets, browser/admin state, or another destination system - the main risk is premature closure ​ Check five things: 1. *Claimed outcome* 2. *Target state or location* 3. *Proof checked* 4. *Constraints checked* 5. *Verdict* ​ ## Core rule ​ Do not mark work complete until the claimed outcome is verified in the place that matters. ​ ## When to use ​ Apply this skill when one or more are true: - work was delegated - an artifact was created or moved - a render/export/upload supposedly finished - Drive, Sheets, or another system was updated - a live/admin state change supposedly landed - the task could be falsely treated as complete because someone said so - the final answer depends on whether something landed, not whether effort happened ​ ## When not to use ​ Do not overuse this for: - immediate tiny local edits you can already see directly - low-risk ephemeral tasks where the destination is the current context itself - tasks where the answer is purely advisory and no state change or artifact landing is claimed ​ Use it where false done is expensive. ​ ## Purpose ​ Verify destination truth, not internal effort. ​ ## Verification frame ​ For any qualifying task, check: 1. *Claimed outcome* — what is supposedly complete 2. *Target location/state* — where the result must exist 3. *Proof* — what observable evidence confirms it 4. *Constraint check* — what must also be true for it to count 5. *Gap* — what remains unverified, if anything ​ ## Verification workflow ​ ### Step 1: restate the claimed outcome Name exactly what is supposedly complete. If the claim itself is fuzzy, tighten it before verifying. ​ ### Step 2: identify the destination that matters Ask: where would the user actually check? That may be: - Drive - a Sheet - a live account state - a browser/admin screen - a sent message - a final artifact path - a test result ​ ### Step 3: inspect the smallest meaningful proof Prefer live proof over narrative. Use the smallest reliable check that answers the question. ​ ### Step 4: check key constraints Verification is not just “does it exist?” Also check whether the result is in the right place, version, account, state, format, or approval condition. ​ ### Step 5: issue a verdict Verdict options: - *complete* — proof and constraints are satisfied - *partial* — some proof exists but a meaningful gap remains - *not complete* — destination truth is missing or contradicted ​ ## Strong proof vs weak proof ​ Strong proof examples: - the correct Drive file is in the correct folder - the sheet row/cell/state is visibly updated as requested - the final artifact exists at the right path/link/version - the test passes - the message/send/edit occurred in the intended place - the account/system state reflects the intended change - the screenshot or export shows the actual result ​ Weak proof examples: - “it should be there” - “the worker finished” - “the command ran” - “I created the file locally” when the destination is Drive/Klaviyo/Meta/Shopify/etc. - “looks good from the logs” when the user needs final destination truth ​ ## False-completion warnings ​ Intervene when: - completion is inferred from a handoff - the artifact exists, but not in the destination that matters - the file/version exists, but naming or location is wrong - the worker output exists, but QC or constraints were not checked - a system change is claimed, but only local prep was verified - a polished summary outruns the evidence ​ ## Constraint discipline ​ Also check the constraints that matter for the job. ​ Examples: - correct folder, not just any folder - correct version, not just any version - correct account/state, not just draft existence - correct approved asset/name, not just a close variant - correct QC standard, not just render success - correct destination link returned, not just internal storage complete - correct stage folder, not just somewhere in the Drive root ​ ## Partial verification rule ​ If full verification is not possible, do not blur that. Say: - what was verified - what was not verified - what evidence is still missing - whether the task should remain open ​ If a meaningful gap remains, the task stays open. ​ ## Role-based lane examples ​ ### Drive / review assets Not enough: - the PNG was exported locally ​ Verified: - the correct versioned PNG is in the correct Drive review folder and the returned link matches it ​ ### Sheets / reporting state Not enough: - the script ran ​ Verified: - the intended row, cell, or status changed correctly in the sheet ​ ### Video workflow Not enough: - the render completed ​ Verified: - the correct review/final artifact is in the correct stage folder, QC passed, and any required source-footage/accounting rules were met ​ ### Meta or live system state Not enough: - the upload/create request was issued ​ Verified: - the real account or object state reflects the intended approved change ​ ### Browser/admin work Not enough: - the click sequence finished ​ Verified: - the destination page or state shows the requested result ​ ## Orchestrator-specific close test ​ Before saying complete, ask: - did the result land where the user actually needs it? - would the user discover a missing last-mile step if he checked right now? - am I verifying destination truth or just internal effort? - is any approval, version, folder, state, or QC rule still unproven? ​ If the answer is shaky, the task is not complete. ​ ## Common verification mistakes ​ - verifying local prep when the destination is remote - verifying existence but not correct location - verifying the file but not the version - trusting a worker claim without checking the output - checking success logs but not the user-facing result - treating “partial” as good enough without saying so ​ ## Quick silent template ​ - *Claimed outcome:* ... - *Target state/location:* ... - *Proof checked:* ... - *Constraints checked:* ... - *Verdict:* complete | partial | not complete ​ ## Pairing rules ​ - Pair with `outcome-guard` for multi-step delegated work. - Pair with `routing-enforcer` if the wrong owner may be causing weak completion. - Pair with `direction-clarifier` if the claimed outcome itself is still ambiguous. ​ ## Success test ​ This skill is working when: - fewer tasks are declared done too early - last-mile gaps get caught before the user sees them - destination truth replaces internal-status language - artifacts land in the correct place the first time more often - follow-up corrections on “it wasn’t actually there” go down ​ If false completions still slip through, tighten the proof and constraint checks. ​ --- ​ # Direction Clarifier ​ > Shareable edition > > Generic, organization-neutral version for external teams. ​ Use this skill when acting immediately is likely to push the work the wrong way. ​ This skill exists to create fast alignment without turning every task into a questionnaire. ​ ## At a glance ​ Use this skill when: - the outcome is not clear enough to choose the best path confidently - two plausible directions would produce materially different work - pushing ahead would create likely rework - the request is broad and the best interpretation is not obvious ​ Ask in this shape: 1. *One tight question* 2. *Option 1* 3. *Option 2* 4. *Recommendation* 5. *Other* ​ ## Core rule ​ Do not ask broad exploratory questions when one tight decision will unlock the right path. ​ When the direction is materially unclear, ask: - one concise question - two real options - one recommendation - one third path for “other” ​ ## When to use ​ Use this skill when one or more are true: - the outcome is not clear enough to choose the best path confidently - two plausible directions would produce meaningfully different work - pushing ahead would create likely rework - the user asked for something broad but the right interpretation is not obvious - a strategic, creative, or system fork matters more than raw speed - you can feel that a wrong assumption now will create cleanup later ​ ## When not to use ​ Do not use this when: - the task is obvious and reversible - one option is clearly correct from existing rules - the missing detail does not materially affect the outcome - the question would dump unnecessary thinking back onto the user - the agent can safely choose a reversible default and keep moving ​ Use it to resolve high-leverage ambiguity, not minor uncertainty. ​ ## Purpose ​ Reduce wrong-way execution while keeping momentum high. ​ ## The decision pattern ​ Ask in this shape: 1. *Question* — what decision actually matters? 2. *Option 1* — real path with concrete consequence 3. *Option 2* — real path with concrete consequence 4. *Recommendation* — say which option you recommend and why 5. *Other* — leave room for a third direction if the user wants it ​ Keep it short. Do not present fake options. Do not present more than two primary options unless the user asks. ​ ## Writing standard ​ The question should: - target the real fork, not surface noise - be answerable quickly - avoid jargon when possible - focus on the decision that most changes the outcome ​ Each option should: - describe the path in plain language - make the tradeoff visible - show what will happen next if chosen - be meaningfully different from the other option ​ The recommendation should: - be direct - name the better path - give the reason in one sentence - reduce decision burden, not increase it ​ The other path should: - be lightweight - signal flexibility without bloating the decision - leave room for a hybrid or custom direction if needed ​ ## Decision workflow ​ ### Step 1: find the real fork Ask what decision actually matters. Do not ask about a cosmetic choice when the real uncertainty is strategic. ​ ### Step 2: compress it into one question If you are about to ask three things, you have not found the highest-leverage fork yet. ​ ### Step 3: build two real paths Each option should lead to materially different execution. If both options lead to the same work, the question is weak. ​ ### Step 4: recommend one Do not be neutral unless neutrality is truly warranted. the user should not have to reverse-engineer your view. ​ ### Step 5: leave an “other” path Do not trap the user inside a false binary. Offer a lightweight way to pivot. ​ ## Default format ​ Use this exact style when helpful: ​ *Quick question before I push this the wrong way:* ​ *Option 1:* ... *Option 2:* ... *My recommendation:* Option X because ... *Option 3 / other:* if you want a different direction, tell me the angle and I’ll pivot. ​ ## Examples ​ ### Strategy fork *Quick question before I push this the wrong way:* ​ *Option 1:* I optimise for speed and get a workable first version live fast. *Option 2:* I optimise for system quality and take a little longer to harden the workflow first. *My recommendation:* Option 2 because this looks like a recurring lane and weak setup will create repeat cleanup. *Option 3 / other:* if you want a different tradeoff, tell me and I’ll adjust. ​ ### Creative fork *Quick question before I push this the wrong way:* ​ *Option 1:* I keep this performance-first and direct-response heavy. *Option 2:* I keep this more brand-led and trust-building. *My recommendation:* Option 1 because the request sounds closer to conversion work than awareness work. *Option 3 / other:* if you want a hybrid, I can split the angle. ​ ### System/workflow fork *Quick question before I push this the wrong way:* ​ *Option 1:* I solve the immediate task directly. *Option 2:* I harden the system first so this stops recurring. *My recommendation:* Option 2 because the repeat cost now looks bigger than the one-off task cost. *Option 3 / other:* if you want me to just clear the immediate task first, I can do that. ​ ### Routing fork *Quick question before I push this the wrong way:* ​ *Option 1:* I keep this with the orchestrator and finish it directly. *Option 2:* I route it to the specialist lane now and keep the orchestrator on orchestration. *My recommendation:* Option 2 because the work looks specialist-fit and will be cleaner if the right owner holds it early. *Option 3 / other:* if you want speed over lane purity here, I can keep it local. ​ ## Decision discipline ​ Use only one decision question at a time unless more are genuinely required. ​ If multiple unknowns exist: - ask for the highest-leverage one first - resolve that - then continue ​ Do not stack three decisions into one message. Do not ask a vague open-ended question when a shaped decision is possible. ​ ## Common failure modes ​ This skill is being used badly when: - it appears too often - it asks obvious questions - it gives weak or fake options - it presents a false binary - it slows simple tasks - it still lets wrong-way work proceed ​ ## Orchestrator-specific triggers ​ Use this when the orchestrator is about to: - choose a lane without enough confidence - turn a broad request into a narrow execution path too early - mistake activity for the real goal - force a strategy, creative, or system direction that the user may not actually want - spend a lot of effort on a path that could be fixed by one quick alignment question ​ ## Pairing rules ​ - Pair with `outcome-guard` when direction ambiguity could lead to drift or wrong completion. - Pair with `routing-enforcer` when the unclear direction is really a lane or owner problem. - Pair with `completion-verifier` only if the real ambiguity is what would count as success. ​ ## Quick silent checklist ​ Before asking, confirm: - does this decision materially change the work? - can I safely choose a default instead? - are the two options genuinely different? - do I actually have a recommendation? - can the user answer this in seconds? ​ If not, tighten the question or keep moving. ​ ## Success test ​ This skill is working when: - wrong-way pushes decrease - questions get shorter and higher leverage - the user can answer quickly without extra unpacking - fewer tasks need rework because the path was aligned earlier ​ If it becomes a crutch for indecision, tighten it. ​ ---