---
name: stop-doing-elimination-audit
description: 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 / keep) with reasoning for each item. Triggers on requests like "help us figure out what to stop doing," "build a stop-doing list," "our best people are buried in low-value work," or "apply the elimination hierarchy to this."
---

# Stop-Doing Elimination Audit
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:

| Item | Need it served | Still needed? | Hierarchy step | Recommendation (stop now / pilot / keep) + reasoning | Who can authorize the stop | Destination for recovered capacity |
| --- | --- | --- | --- | --- | --- | --- |

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.