8Dionysus/aoa-quest-harvest

aoa-quest-harvest

Intent

Use this skill to decide whether a repeated, reviewed quest-shaped pattern should remain a quest or be promoted into the next honest owner surface.

Trigger boundary

Use this skill when:

• a bounded work pattern has repeated and now needs an explicit promotion decision
• reviewed evidence exists, but the correct destination is still unclear
• the decision must distinguish between skill, playbook, orchestrator surface, proof surface, memo surface, or staying a quest
• the route needs a compact final promotion triage rather than another free-form discussion

Do not use this skill when:

• the route is still active and the evidence has not been reviewed yet
• there is only one anecdotal occurrence with no honest repeat signal
• the task is to invent net-new doctrine rather than classify a repeated pattern
• the route is already clearly scenario-shaped and only needs playbook authoring
• the source is a reviewed session artifact with multiple candidate donor units that still need owner-layer routing first; use aoa-session-donor-harvest
• the source still needs explicit automation-readiness classification for a repeated manual route; use aoa-automation-opportunity-scan
• the source still needs explicit route forks, diagnosis, repair, or progression reflection from the wider session-harvest family before final promotion triage

Inputs

• source quest or quest family
• reviewed run summary or harvest pack
• repeat count and repeat shape
• owner layer and touched surfaces
• difficulty, risk, and control posture
• residual ambiguity or reasons to defer promotion

Outputs

• promotion verdict
• owner repo and follow-up surface
• explicit reason for promotion or non-promotion
• named next artifact or next quest action
• concise note on what boundary must remain intact
• one QUEST_PROMOTION_RECEIPT using references/stats-event-envelope.md and references/quest-promotion-receipt-schema.yaml
• one CORE_SKILL_APPLICATION_RECEIPT using references/core-skill-application-receipt-schema.yaml

Procedure

1. collect a bounded reviewed harvest pack rather than raw runtime state
2. name what actually repeated: leaf workflow, route, proof pattern, recall pattern, or boundary law
3. reject theme-only repetition; only repeatable work or repeatable law counts
4. if the repeated unit is a bounded leaf workflow, consider promotion to a skill
5. if the repeated unit is a multi-step scenario route, consider promotion to a playbook
6. if the repeated unit is orchestrator boundary law, read order, or allowed outputs, promote toward orchestrator class surfaces in aoa-agents
7. if the repeated unit is proof posture, promote toward aoa-evals
8. if the repeated unit is recall, writeback, or recurrence posture, promote toward aoa-memo
9. if repetition is still weak, owner is unclear, or boundary risk is high, keep or open a quest instead of forcing promotion
10. record the verdict with one clear reason for promotion and one clear reason against the nearest wrong target
11. emit one QUEST_PROMOTION_RECEIPT when the triage closes, keeping the receipt smaller than the promotion packet itself
12. when the finish path closes, emit one CORE_SKILL_APPLICATION_RECEIPT that points back to the bounded promotion receipt and records one finished kernel-skill application

Contracts

• invocation must remain explicit and post-session
• orchestrator class identity must not be promoted into a skill
• a skill promotion must stay leaf-workflow-shaped
• a playbook promotion must stay route-shaped
• proof and memory promotions must stay in their owner layers
• one good run is not enough to justify promotion by itself
• active quest state must not be copied into memo canon as if it were settled truth
• QUEST_PROMOTION_RECEIPT is verdict telemetry, not promotion authority
• CORE_SKILL_APPLICATION_RECEIPT is generic kernel telemetry, not promotion authority and not a replacement for the verdict receipt
• receipt corrections use supersedes rather than silent overwrite

Risks and anti-patterns

• promoting a theme instead of a repeatable workflow
• collapsing orchestrator class law into the skill layer
• collapsing recurring route method into a single skill
• treating proof debt as skill meaning
• treating memo writeback as active quest ownership
• forcing promotion just because the repeated work feels important

Verification

• confirm the harvest pack is reviewed and bounded
• confirm the repeated unit is named explicitly
• confirm the chosen promotion target matches the owner layer
• confirm the nearest wrong target is explicitly rejected
• confirm class identity is not being defined by quest metadata
• confirm the result is one of the allowed outcomes: keep or open quest, skill, playbook, orchestrator surface, proof surface, or memo surface
• confirm any emitted receipt stays evidence-linked and subordinate to the closed triage
• confirm any emitted CORE_SKILL_APPLICATION_RECEIPT points to the promotion detail receipt and stays finish-only

Technique traceability

Manifest-backed techniques:

• AOA-T-0089 from 8Dionysus/aoa-techniques at 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/quest-unit-promotion-review/TECHNIQUE.md and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Validation
• AOA-T-0090 from 8Dionysus/aoa-techniques at 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/nearest-wrong-target-rejection/TECHNIQUE.md and sections: Intent, When to use, Outputs, Core procedure, Risks, Validation

Adaptation points

Project overlays may add:

• local quest IDs and harvest entrypoints
• local owner-repo route maps
• local review packet or acceptance surfaces
• local memo and eval references
• local stop conditions for when promotion must remain deferred