8Dionysus/aoa-automation-opportunity-scan

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.

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
• 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. 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
5. mark checkpoint_required when the route would cross into self-change, hidden authority, or important mutation
6. emit seed_ready only when the process is stable enough to name inputs, outputs, bounded prompts or activation hints, and a likely owner surface
7. state the nearest wrong target so promotion pressure stays honest
8. 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
9. emit one AUTOMATION_CANDIDATE_RECEIPT when the packet closes, keeping the receipt detector-shaped rather than scheduler-shaped
10. 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
• 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
• 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 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 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/automation-fit-matrix/TECHNIQUE.md and sections: Intent, Inputs, Outputs, Core procedure, Risks, Validation
• AOA-T-0087 from 8Dionysus/aoa-techniques at 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/human-loop-to-seed-lift/TECHNIQUE.md and sections: Intent, When to use, Outputs, Core procedure, Contracts, Validation
• AOA-T-0088 from 8Dionysus/aoa-techniques at 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/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