aoa-automation-opportunity-scan

Intent

Use this skill to detect where repeated project work is ripe for automation and to package that finding into a bounded AUTOMATION_OPPORTUNITY_PACKET.

The goal is not to automate by reflex. The goal is to notice when a process has become repetitive, stable, legible, and evidence-backed enough that automation or semi-automation becomes an honest next move.

Automation can honestly mean many modes: keep manual, assistant draft, dry-run preview, human-approved execution, or a future scheduler seed. The packet must name that mode instead of letting seed_ready imply unattended execution.

Trigger boundary

Use this skill when:

• a reviewed session or repeated project slice reveals a recurring manual route
• the same audit, report, hygiene pass, or triage loop keeps coming back
• a session-harvest packet includes an automation_candidate
• an operator wants to know whether a recurring route should stay manual, become a bounded skill, or become a playbook automation seed
• repeated friction suggests a good automation opportunity but authority and risk still need classification

Do not use this skill when:

• the work happened only once and still looks exploratory
• the route is primarily creative synthesis with no stable trigger or output
• the task is asking for live scheduling or hidden background execution authority
• the route would mutate important system surfaces without checkpoint posture
• the work still needs basic donor harvest or source-of-truth clarification first

Inputs

• reviewed session artifact, harvest packet, or recurring project slice
• evidence of repeated manual work
• known current manual route
• known triggers, inputs, outputs, or their current ambiguity
• current risk, approval, rollback, and proof posture if known

Outputs

• AUTOMATION_OPPORTUNITY_PACKET
• one or more AUTOMATION_CANDIDATE cards
• seed_ready or not_now verdict for each candidate
• automation_mode_posture for the highest honest mode the candidate may claim now
• checkpoint_required flag when the route crosses self-change or approval-sensitive boundaries
• next-artifact suggestion such as skill, playbook_seed, technique_candidate, repair_quest, quest, or defer
• one AUTOMATION_CANDIDATE_RECEIPT using

references/stats-event-envelope.md and references/automation-candidate-receipt-schema.yaml

• one CORE_SKILL_APPLICATION_RECEIPT using

references/core-skill-application-receipt-schema.yaml

Procedure

1. start from reviewed evidence, not from vague enthusiasm
2. isolate the current manual route as actually practiced
3. classify repeat signal, friction, determinism, input clarity, output clarity, proof surface, reversibility, secret coupling, and approval sensitivity
4. name the automation_mode_posture: manual_only, assistant_draft,

dry_run_preview, human_approved_execution, or scheduler_seed_candidate

1. decide whether the first honest landing is a bounded skill, a playbook automation seed candidate, a technique candidate, a repair quest, or a defer verdict
2. mark checkpoint_required when the route would cross into self-change, hidden authority, or important mutation
3. emit seed_ready only when the process is stable enough to name inputs, outputs, bounded prompts or activation hints, a likely owner surface, and a conservative automation mode
4. state the nearest wrong target so promotion pressure stays honest
5. when classification pressure is high, use references/automation-fit-matrix.md, references/session-harvest-integration.md, references/playbook-seed-bridge.md, references/checkpoint-boundary.md, and references/automation-opportunity-packet-schema.yaml
6. emit one AUTOMATION_CANDIDATE_RECEIPT when the packet closes, keeping the

receipt detector-shaped rather than scheduler-shaped

1. when the finish path closes, emit one CORE_SKILL_APPLICATION_RECEIPT

that records the finished kernel-skill run, points back to the bounded detail receipt, and stays separate from scheduler or mutation authority

Contracts

• this skill detects and packages automation opportunities; it does not create live automation authority
• schedule hints remain hints, not runtime truth
• automation_mode_posture is a boundary statement, not permission to execute
• recurring scenario candidates belong in aoa-playbooks as seed candidates rather than hidden playbooks inside a skill
• self-changing or approval-heavy candidates must surface checkpoint posture explicitly
• unresolved candidates may become repair quests instead of fake-ready automations
• handoffs to aoa-session-self-diagnose, aoa-session-self-repair, or

aoa-quest-harvest must stay explicit rather than being smuggled in as silent policy

• candidate receipts stay subordinate to the packet and never grant live

schedule, mutation, or approval authority

• generic core receipts stay subordinate to the candidate receipt and never

replace automation classification meaning

• receipt corrections use supersedes rather than silent overwrite

Risks and anti-patterns

• treating one exciting session as proof of repeatability
• treating seed_ready as a synonym for unattended execution
• automating unstable, under-specified, or secret-heavy work too early
• confusing a bounded skill with a recurring scenario seed
• using automation desire to bypass approval, rollback, or post-change health checks
• writing authored meaning first into derived routing or KAG surfaces
• inventing fake confidence about gains while hiding costs or risks
• reading an automation-candidate receipt as if it were a scheduler verdict

Verification

• confirm each candidate names the current manual route
• confirm evidence refs justify the repeat signal
• confirm stable input and output posture is assessed explicitly
• confirm seed_ready or not_now is explicit for each candidate
• confirm automation_mode_posture names the highest honest mode without granting extra authority
• confirm a first owner layer and next artifact are named
• confirm the nearest wrong target is rejected when classification pressure exists
• confirm checkpoint posture appears for self-changing or approval-heavy routes
• confirm any emitted receipt stays detector-shaped, evidence-linked, and non-authoritative
• confirm any emitted CORE_SKILL_APPLICATION_RECEIPT points back to the

detail receipt and does not claim more than one finished kernel-skill run

Technique traceability

Manifest-backed techniques:

• AOA-T-0086 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/governance/automation-readiness/automation-fit-matrix/TECHNIQUE.md and sections: Intent, Inputs, Outputs, Core procedure, Risks, Validation
• AOA-T-0087 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/governance/automation-readiness/human-loop-to-first-landing/TECHNIQUE.md and sections: Intent, When to use, Outputs, Core procedure, Contracts, Validation
• AOA-T-0088 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/governance/automation-readiness/approval-sensitivity-check/TECHNIQUE.md and sections: Intent, Inputs, Outputs, Contracts, Risks, Validation

Adaptation points

• project overlays may add local execution modes, trigger classes, or schedule vocabularies
• project overlays may add local approval classes or environment-risk labels
• project overlays may add local candidate examples tied to recurring repo rituals