8Dionysus/aoa-session-route-forks

aoa-session-route-forks

Intent

Use this skill to author FORK_CARDS from a reviewed session.

The goal is not prediction theater. The goal is legible choice architecture: what routes exist, why each route matters, what each one likely costs, and where each route probably lands first.

Trigger boundary

Use this skill when:

• a reviewed session ended with multiple plausible next moves
• the operator or local coding agent needs explicit branch choices instead of a buried recommendation
• the next route may change owner repo, risk posture, or difficulty posture
• the choice may include staying manual, becoming a bounded skill, becoming a playbook automation seed candidate, or waiting for prerequisite repair
• the session needs quest-board legibility without pretending to be runtime state

Do not use this skill when:

• there is only one obvious next bounded move
• one bounded child route is already chosen, anchored, and output-named; use aoa-summon for the launch gate instead
• the session still needs first-pass donor harvest
• the question is final promotion of a repeated quest unit
• the route needs scenario canon immediately rather than branch analysis

Inputs

• reviewed session artifact or harvest packet
• candidate next routes
• known risks, dependencies, and blockers
• desired control mode or approval posture
• operator preference if already named

Outputs

• FORK_CARDS with likely gain, cost, risk, owner repo, and stop conditions
• one suggested default route if evidence is strong enough
• one explicit hold or defer option when honest uncertainty remains
• optional automation and non-automation branches side by side when that choice is real
• optional quest hooks or campaign hints without runtime authority
• one DECISION_FORK_RECEIPT using references/stats-event-envelope.md and references/decision-fork-receipt-schema.yaml
• one CORE_SKILL_APPLICATION_RECEIPT using references/core-skill-application-receipt-schema.yaml

Procedure

1. start from reviewed evidence rather than free speculation
2. separate materially different branches instead of cosmetic variants
3. name the likely first owner repo for each branch
4. state likely gains, likely costs, likely risks, and stop conditions
5. attach a small route passport with difficulty, risk, control mode, and delegate tier
6. allow automation and non-automation branches to appear side by side when the reviewed evidence supports a real choice between them
7. when one branch becomes an anchored child-route candidate, stop at fork evidence and hand the launch gate to aoa-summon
8. preserve a hold or reanchor path where uncertainty or risk remains meaningful
9. emit quest-board-readable language only as adjunct reflection
10. emit one DECISION_FORK_RECEIPT when the fork set closes, keeping the receipt smaller than the branch cards themselves
11. when the finish path closes, emit one CORE_SKILL_APPLICATION_RECEIPT that points back to the bounded fork receipt and records one finished kernel-skill application only

Contracts

• branch cards do not become routing authority
• fork analysis must stay evidence-backed
• confidence should be named when weak
• stop conditions are first-class, not footnotes
• a fork card may recommend but must not hide alternatives
• automation-shaped branches must not be read as schedule authority
• child-route-shaped branches must not launch from fork analysis; aoa-summon owns that gate after anchor, outputs, and passport are clear
• DECISION_FORK_RECEIPT is descriptive branch telemetry, not routing policy
• CORE_SKILL_APPLICATION_RECEIPT is generic kernel telemetry, not branch policy or route choice authority
• receipt corrections use supersedes rather than silent overwrite

Risks and anti-patterns

• fake certainty about future routes
• using fork cards as hidden routing policy
• collapsing all branches into one generic recommendation
• confusing playbook outline with branch analysis
• confusing an automation seed candidate with a live scheduler or background job
• treating quest-board cards as runtime state
• treating branch receipts as if they already chose the route

Verification

• confirm each branch differs materially
• confirm likely owner repo is named
• confirm at least one cost or risk is explicit
• confirm stop conditions exist for risky branches
• confirm hold or defer remains possible when uncertainty is real
• confirm selected child-route work is routed to aoa-summon rather than launched from fork cards
• confirm any emitted receipt stays evidence-linked and subordinate to the fork cards
• confirm any emitted CORE_SKILL_APPLICATION_RECEIPT points to the fork detail receipt and stays finish-only

Technique traceability

Manifest-backed techniques:

• AOA-T-0078 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/governance/decision-routing/decision-fork-cards/TECHNIQUE.md and sections: Intent, Inputs, Outputs, Core procedure, Validation
• AOA-T-0079 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/governance/decision-routing/risk-passport-lift/TECHNIQUE.md and sections: Outputs, Contracts, Risks, Validation

Adaptation points

Project overlays may add:

• local control-mode labels
• local delegate tiers or approval classes
• repo-specific route passports