---
name: ai-automation-triage
description: Use this skill when the user wants to decide which tasks or capabilities their team should automate with AI, which need human review or decision rights, and which AI is quietly eroding versus strengthening as a real advantage. Triggers on requests like "what should we automate with AI," "where is AI actually helping versus just producing more output," "classify our tasks for automation," or "is AI eroding our advantage here."
---

# AI Automation Triage
This skill is Labor as Code™ for *Chasing Native Alpha*'s "Test Whether
AI Erodes or Strengthens the Advantage" chapter. It runs the book's
task-classification method and its erosion/amplification matrix
against the reader's own actual task or capability list — it does not
retell the book's care-management-dashboard example, and it does not
decide, by itself, that a given task is safe to automate. It produces
a classified list and a set of questions still open for a human to
answer.

Two of this book's central terms apply directly: this skill helps a reader find which of their own
team's tasks might be ready to become **Labor as Code** — durable,
inspectable, versioned execution of a method — by first testing
whether **Native Alpha** is actually present in the task's current
form, or whether it's a task any competent alternative already
performs.

## Before running

Confirm with the user before starting:

1. **The actual list of tasks or capabilities to classify**, and who
   currently does them. A vague "everything we do" produces a useless
   triage — ask for a real, bounded list (the book's own exercise caps
   it at the important capabilities consuming the most attention).
2. **What quality or outcome baseline already exists**, if any — cost,
   error rate, cycle time, customer-visible result — versus what will
   have to be estimated. Flag every estimate as an estimate.
3. **Who has authority to change where AI is or isn't used.** This
   skill produces a classification and recommended actions; it does
   not implement automation, change access controls, or remove a human
   checkpoint. That is always a decision for the named owner of the
   work.

## Step 1: Classify by context, consequence, evaluability, and frequency

For each task, ask the four questions below and place it in the
matching row. Do this per task — do not classify a whole department or
workflow at once, since different steps inside the same workflow often
land in different rows.

| Task characteristics | Recommended approach |
| --- | --- |
| Low context, low consequence, easily evaluated | Move toward automation quickly |
| High context, easily evaluated | Benefits from retrieval and specialized agents |
| High consequence, strong evaluation | Allow automation inside strict gates |
| High consequence, weak evaluation | Needs decision support, not autonomous action |

- **Context**: does this task need only public or generic knowledge
  (low), or does it depend on this organization's own conventions,
  architecture, customer commitments, risk tolerances, and operating
  history (high)?
- **Consequence**: what happens if the output is wrong — a clinical
  recommendation, a security decision, a financial commitment, a
  production change (high), or something easily caught and cheaply
  corrected (low)?
- **Evaluability**: can a correct or acceptable output actually be
  checked, cheaply and reliably, before it does damage? If nobody can
  say what "good" looks like for this task, evaluation is weak — treat
  it as weak even if the task feels routine.
- **Frequency**: does this task recur often enough that the investment
  in automating or building an evaluation harness pays for itself?

This is not a one-time policy. Note the date of this classification —
the book is explicit that the boundary moves as models, context
systems, and evaluation improve, and the classification should be
revisited, not frozen.

## Step 2: Classify each capability's AI effect

For each of the same tasks, or for a broader capability the tasks roll
up into, classify the effect AI is actually having — not the effect a
demo suggested it should have:

| Effect | Question | Likely action |
| --- | --- | --- |
| Erodes | Can others now reproduce the output cheaply? | Reduce protection; move up the value chain |
| Amplifies | Does AI compound scarce context, data, trust, or judgment this organization actually has? | Invest and measure the combined outcome |
| Releases | Can AI remove work that was blocking a capable person from their highest-value work? | Automate, then verify the freed time actually moved to higher-value work |
| Exposes | Does AI reveal that this capability never produced real differentiation to begin with? | Run a replacement test (see the `false-alpha-hearing` skill) |
| Uncertain | Is reliability too uneven, or consequences too high, to classify yet? | Time-box an evaluated pilot rather than guessing |

For every row, require:

- The mechanism — what, specifically, does AI change here?
- A benchmark — better than what reasonable alternative?
- Confidence and missing evidence — say plainly what's assumed versus
  observed.
- A failure mode and leading signal that would show the classification
  is wrong.
- A thirty-day test where the classification is genuinely uncertain.

**Do not count tool adoption as the outcome.** The book's own warning:
a dashboard that's entirely green on usage and output volume can still
be hiding a bottleneck that moved downstream (their care-coordination
example: adoption and message volume rose while patient follow-through
did not improve). Ask for the business or customer-facing result the
combination actually produced, not the amount of AI-generated output.

## Step 3: Decide what stays a human checkpoint

Before recommending automation for anything in the "high consequence"
rows, ask explicitly why the current human check exists:

- Does it prevent a cheap action from becoming an expensive mistake?
- Does it force accountability, conflict detection, or an irreversible
  tradeoff into view before it happens?

State which of the two this is, with the reasoning: if the friction
exists only because information is hard to assemble, name it a
removal candidate and recommend fixing the information flow rather
than removing the check itself. If the friction exists to force a
human decision on genuine ambiguity or consequence, say so and
recommend it stay. Either way, this skill states the classification
and its reasoning - actually removing a checkpoint is the accountable
owner's act, not this skill's, and the recommendation is what they act
from, not a decision already made on their behalf.

## Step 4: Name what happens to the freed capacity

For anything recommended for automation or release, do not let the
recommendation stop at "this saves time." Ask: which specific
higher-value work — whose Native Alpha — will the recovered time go
to? Automation without a named destination tends to get reabsorbed
into more low-value activity, not redirected.

## What this skill does not do

This skill classifies and recommends, with reasoning traced to the
mechanism, benchmark, and evidence behind each call - it does not flip
the switch. Stating that a checkpoint looks like a removal candidate is
this skill's job when the evidence supports it; actually removing it is
the accountable owner's act, informed by this skill's reasoning and by
their own weighing of consequence and reversibility, not overridden by
either. Where the evidence is thin (uneven reliability, untested
consequence, no real baseline), the correct output is "uncertain —
pilot this," not a confident automate/don't-automate verdict
manufactured to close out the list.