aoa-automation-opportunity-scan

name	aoa-automation-opportunity-scan
description	Detect reviewed or repeated project processes that are candidates for automation, classify whether they are candidate-ready, and route them to the right owner layer without granting schedule or mutation authority. Use when a reviewed session or repeated project slice reveals a recurring manual route and the honest question is whether it should stay manual, become a bounded skill, or become a playbook automation candidate. Do not use for one-off exploratory work, creative synthesis with no stable trigger or output, live scheduling requests, or hidden self-change.
license	Apache-2.0
compatibility	Designed for Codex or similar coding agents with repository file access and an interactive shell. Network access is optional and only needed when repository validation or referenced workflows require it.
metadata	{"aoa_scope":"core","aoa_status":"evaluated","aoa_invocation_mode":"explicit-only","aoa_source_skill_path":"skills/core/session-growth/aoa-automation-opportunity-scan/SKILL.md","aoa_source_repo":"8Dionysus/aoa-skills","aoa_technique_dependencies":"AOA-T-0086,AOA-T-0087,AOA-T-0088","aoa_portable_profile":"codex-facing-context"}

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 candidate. The packet must name that mode instead of letting candidate_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 candidate
• 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
• candidate_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_candidate, 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_candidate
5. decide whether the first honest landing is a bounded skill, a playbook automation candidate, a technique candidate, a repair quest, or a defer verdict
6. mark checkpoint_required when the route would cross into self-change, hidden authority, or important mutation
7. emit candidate_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
8. state the nearest wrong target so promotion pressure stays honest
9. when classification pressure is high, use references/automation-fit-matrix.md, references/session-harvest-integration.md, references/playbook-candidate-bridge.md, references/checkpoint-boundary.md, and references/automation-opportunity-packet-schema.yaml
10. emit one AUTOMATION_CANDIDATE_RECEIPT when the packet closes, keeping the receipt detector-shaped rather than scheduler-shaped
11. 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 automation 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 candidate_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 candidate
• 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 candidate_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