Scope the review step before you price the automation

---
name: scope-automation-opportunity
description: Scope one recurring workflow into an evidence-based automate, assist, discovery, or stop decision with human review, acceptance criteria, and illustrative economics.
---

# Scope an automation opportunity

Produce a bounded decision and pilot brief before recommending a build. This skill works from supplied evidence and authorized research; it does not inspect a customer's systems or implement an automation by itself.

## Map the actual work

Ask for or extract the triggering event, eligible inputs, decisions, current tools, human handoffs, output destination, operating owner, and failure path. Walk one ordinary example and one difficult example. Check whether an existing approved feature, deterministic import, or simpler manual improvement already solves the problem.

Separate observed counts/timings from estimates. Define the observation window and include checking, corrections, exception handling, reconciliation, and review in the baseline. Do not multiply a best-case demonstration into a savings claim.

## Decide what is ready

Record the evidence for an accountable owner, approved data/tool path, representative examples, review capacity, output specification, and manual fallback. An unknown necessary approval is a hold. Avoid a composite score that hides a failed essential condition.

Choose and explain one posture:

- **Automate:** sufficiently bounded steps can run under agreed authority and exception controls.
- **Assist:** the system prepares work while a named person makes the consequential decision.
- **Discovery:** important feasibility or baseline evidence is missing; specify the narrow investigation that would resolve it.
- **Stop or use the existing process:** the need, economics, permission, or operational support does not justify a build.

## Make a testable scope

Specify included inputs, excluded inputs, destination schema, review/approval behavior, exception queue, retry limits appropriate to the workflow, and the recovery path. Do not import a previous project's document limits or numerical thresholds as universal requirements.

Propose acceptance measures before testing: representative cases, difficult cases, independent expected results, candidate version, pass/fail rules, all-case reporting, reviewer effort, and a teach-back/fallback drill. Keep raw system performance separate from corrected output. A demo, an accepted deliverable, and production activation are different decisions.

## Estimate conservatively

Use only supplied or explicitly approved economic assumptions. Show manual burden, proposed ordinary processing/review burden, exception burden, ongoing oversight, software cost, and implementation cost separately. Model downside as well as the base case. Capacity value is not cash savings unless there is an actual avoidable expense. Leave fees and contractual terms unresolved where the necessary inputs are missing.

If compatible planning tools are already available, they may help calculate or compare scenarios. Preserve their assumptions and guardrails; never imply the tool inspected systems or guaranteed payback. Do not require any particular vendor or connector.

Return the current map, recommendation with reasons, bounded pilot scope, acceptance proposal, assumptions/economics, unresolved decisions with owners, and the next authorized step. Do not book, contract, purchase, deploy, or contact people from a planning request alone.

## Illustrative request

“Use scope-automation-opportunity on our invoice intake notes and timing log. Decide whether to assist, automate, investigate, or stop. Keep payment approval human and propose a finite acceptance plan. Label all unmeasured economics.”

This instruction package is a draft and has not been tested in Claude. A complete planning kit is not evidence of a completed client implementation or measured savings.