Stop-Doing Elimination Audit

Use this skill when the user wants to free up their team's time and attention by identifying recurring work — meetings, reports, approvals, custom systems, features — that no longer earns its cost, and getting a stated recommendation (stop now / pilot /…

This skill is Labor as Code™ for Chasing Native Alpha's "Stop Work That Does Not Improve Outcomes" chapter. It runs the book's elimination hierarchy against the reader's own actual list of recurring work — it does not retell the book's weekly-operating-report example. For every candidate it names which hierarchy step applies and why, and states whether the evidence favors stopping it now, testing a reversible pilot first, or keeping it - with the reasoning behind that lean. What it does not do is unilaterally execute the stop: the people who depend on each piece of work haven't been consulted by this skill, and only the named authorizer holds the organizational standing to actually act. A stated recommendation is not a substitute for that consultation or that authority - it's what the authorizer acts from.

Before running

Confirm with the user before starting:

1. The actual list of recurring work to examine — meetings, reports, approvals, custom systems, tasks, or features, with who currently consumes them and who produces them. Ask for real items, not a general sense that "there's too much going on."
2. Who can authorize stopping each item. The book's method assigns a specific person to authorize each stop — this skill can nominate candidates and structure the case, but it cannot authorize removing anything itself, and it should say so rather than implying a recommendation is a decision.
3. What scarce judgment is currently displaced by this work — the people whose attention is most expensive and most needed elsewhere. The audit is about protecting that attention, not eliminating work for its own sake.

Step 1: Find candidates that meet all three conditions

For each item on the list, test it against all three of these. An item only qualifies as a strong candidate for elimination, delegation, standardization, or automation if it meets all three — not just one:

• It occurs repeatedly.
• It consumes someone with scarce judgment.
• It produces an output that does not itself require that judgment.

Step 2: For each candidate, ask what need it actually serves

Do not just look at the task — look at what would happen if the task vanished. Stopping a task and leaving the underlying need unaddressed usually means the need regenerates in a different form (a cancelled meeting becomes a flood of status messages; an automated report gets more fields requested for it).

For each candidate, record:

• The need it originally served — visibility, risk control, coordination, accountability.
• Whether that need still exists, and whether it changed since the work was created (the book's example: an approval added after a specific incident, still running years later after the underlying risk was addressed a different way).
• A safer replacement for meeting that need, if one exists — a shared instrument instead of a weekly performance, explicit decision rights instead of three approvals, clear ownership instead of more communication.
• Who consumes the current output, and whether they can name a recent decision it changed. If report consumers or meeting attendees can't point to a decision from the last several instances, that's strong evidence the work has drifted from decision-support into habit.

Step 3: Apply the elimination hierarchy, in this exact order

Do not skip ahead to automation before testing the earlier steps — this is the book's central discipline for this chapter, and skipping it (automating a report nobody reads instead of asking why it exists) is the specific failure mode the chapter names.

1. Eliminate work whose outcome no longer matters.
2. Simplify work that serves a real need, but badly.
3. Delegate work to the role that should actually own it.
4. Automate work that remains repeatable and valuable after the first three steps have been genuinely tried.
5. Apply scarce human judgment only where consequence or ambiguity actually requires it.

For every candidate, record which step of the hierarchy applies and why the earlier steps in the order don't.

Step 4: Weigh the cost of stopping against the cost of continuing

Low-value work often survives because continuing feels safer than stopping — the harm of continuation is distributed across many people and hard to see, while the harm of stopping might get a name attached to it. Make this tradeoff explicit rather than letting inertia win by default:

• What is the visible risk of stopping this?
• What is the (usually larger, usually invisible) ongoing cost of continuing it — the higher-value work the same time and attention could have gone to instead?
• Is there a reversible way to test the stop before committing fully (a trial period, a smaller pilot group, an opt-out rather than an opt-in)?

Once these are answered, state this skill's own lean - stop now, pilot first, or keep - and name which of the two costs is doing the work in that lean. Where the visible risk and the invisible cost are genuinely close in magnitude, say so and recommend the reversible pilot as the option that resolves the tie with evidence instead of guessing which cost is larger.

Step 5: Name the destination for recovered capacity

For every item recommended for elimination, simplification, delegation, or automation, name the specific higher-value work — the specific Native Alpha — that will receive the freed time. A stop without a named destination tends to get reabsorbed into more low-value activity rather than redirected, which is the book's own warning about automation savings in general.

Step 6: Produce the stop-doing portfolio, and require at least one real stop

Assemble the results into one table:

A stop-doing portfolio that never actually stops anything has become another report — the exact failure mode the chapter describes. If the user is running this for real, push for at least one item to actually be stopped within a defined, short window, not merely logged.

What this skill does not do

This skill nominates candidates, applies the elimination hierarchy, weighs the cost of stopping against continuing, and states a recommendation with its reasoning for every candidate - it does not execute the stop itself, and it does not claim the people who depend on each piece of work have been consulted when they haven't. The named authorizer still has to actually make the call, informed by this skill's recommendation and by consulting the people affected, not overridden by either. Where the evidence for whether a need still exists is missing, the correct output is "ask the consumers of this work before deciding, here's what to ask them" - not a confident stop/keep recommendation invented to finish the table.