8Dionysus/aoa-session-donor-harvest

aoa-session-donor-harvest

Intent

Use this skill to metabolize a reviewed session artifact into a bounded HARVEST_PACKET that names reusable units, routes each one to the right AoA owner layer, and drafts the next honest artifact without forcing promotion.

Trigger boundary

Use this skill when:

• a session transcript, compaction note, review packet, or bounded recap exists and must be distilled into reusable donor units
• the work is post-session and reviewable rather than live execution
• candidate outputs may belong in technique canon, aoa-skills, aoa-playbooks, aoa-evals, aoa-memo, aoa-agents, or a hold/quest lane
• a repeated manual route may also need an explicit automation-readiness seam instead of staying vague donor residue
• the session may also have produced decision forks, diagnosis clues, repair candidates, progression evidence, or quest residue that should be made explicit rather than buried in recap prose
• the question is not merely "what happened?" but "what reusable object, if any, emerged here?"

Do not use this skill when:

• the session is still active or unreviewed
• the task is raw session capture, transcript export, or local indexing; those are history techniques, not this skill
• the result is clearly one bounded repeated quest unit that only needs the narrower final promotion verdict from aoa-quest-harvest
• the material is only a progress log, emotional recap, or theme cloud with no bounded reusable unit
• the intended first destination is aoa-routing or aoa-kag; those are derivative layers and should not receive source-owned meaning first

Inputs

• reviewed session artifact
• session goal and closure state
• candidate repeat signals or reuse signals
• touched repos or AoA layers
• explicit uncertainty and boundary risks
• desired output posture: classify-only, draft-stub, or patch-ready proposal

Outputs

• one bounded HARVEST_PACKET
• named candidates, each with:
  • candidate ref minted only after reviewed harvest
  • source cluster ref when the reviewed input carried one
  • reusable unit name
  • unit kind: pattern, mechanic, utility, law, proof, recall, or route
  • owner shape: technique, skill, playbook, eval, memo, agent, or hold
  • owner hypothesis and owner repo recommendation
  • one chosen next artifact
  • one rejected nearest-wrong target
  • status posture plus any supersedes, merged-into, or drop-reason carry
  • evidence anchors from the session artifact
• one short list of items to defer, drop, or keep as quest residue
• one optional automation_candidate extract when a repeated manual route is stable enough to deserve explicit automation-readiness classification
• one optional handoff list to aoa-automation-opportunity-scan, aoa-session-route-forks, aoa-session-self-diagnose, aoa-session-self-repair, aoa-session-progression-lift, or aoa-quest-harvest
• one HARVEST_PACKET_RECEIPT using references/stats-event-envelope.md and references/harvest-packet-receipt-schema.yaml
• one CORE_SKILL_APPLICATION_RECEIPT using references/core-skill-application-receipt-schema.yaml

Procedure

1. start from a reviewed session artifact rather than transient chat memory
2. extract candidate reusable units, not topics; prefer explicit moves, laws, checklists, structures, routes, or proof patterns
3. split merged candidates until each unit has one honest owner shape
4. classify each kept candidate twice:
   • by reuse kind: pattern, mechanic, utility, law, proof, recall, or route
   • by owner shape: technique, skill, playbook, eval, memo, agent, or hold
5. mint candidate_ref only after the reviewed unit is bounded and the owner hypothesis plus nearest-wrong target are explicit
6. mark automation_candidate only when a repeated manual route is stable enough to name the current inputs, outputs, and risk posture, but the surviving question is still automation readiness rather than owner canon
7. reject theme-only repetition, aesthetic resonance, and broad "good idea" residue unless a bounded reusable unit exists
8. route reusable practice meaning to technique canon first
9. route bounded executable leaf workflows to aoa-skills
10. route multi-step recurring scenario methods to aoa-playbooks
11. route rubrics, verdict postures, and proof surfaces to aoa-evals
12. route recall, writeback, recurrence, and memory-support patterns to aoa-memo
13. route role law, orchestrator class law, handoff law, and actor-boundary rules to aoa-agents
14. keep aoa-routing and aoa-kag out of first-authoring unless the source-owned object already exists elsewhere and the session only discovered a derivative bridge update
15. preserve quest residue without forcing promotion when the reviewed session is still mixed, early, or weakly repeated
16. hand off to aoa-automation-opportunity-scan when the main surviving question is whether a repeated manual route is honestly automation-ready
17. hand off to aoa-session-route-forks when the main post-session need is explicit next-route choice rather than donor extraction itself
18. hand off to aoa-session-self-diagnose when the dominant surviving object is drift, contradiction, proof gap, or ownership confusion
19. hand off to aoa-session-progression-lift when the main surviving object is evidence-backed progression reflection rather than owner placement
20. when the candidate is a repeated reviewed quest unit and the remaining ambiguity is specifically the final promotion target among quest, skill, playbook, agent, eval, or memo, hand off to aoa-quest-harvest
21. draft the smallest next artifact for each accepted candidate, such as TECHNIQUE.md, SKILL.md, PLAYBOOK.md, EVAL.md, memory object seed, or agent/orchestrator surface note
22. keep cluster_ref, owner_hypothesis, owner_shape, nearest_wrong_target, status_posture, evidence_refs, supersedes, merged_into, and drop_reason on each accepted candidate when that carry exists or becomes explicit during reviewed harvest
23. emit one HARVEST_PACKET_RECEIPT when the packet is complete, using the shared event envelope and a bounded receipt payload instead of duplicating the full donor packet
24. when the finish path is complete, emit one CORE_SKILL_APPLICATION_RECEIPT that points back to the bounded detail receipt, keeps application_stage=finish, and stays generic enough to act as project-core kernel telemetry rather than a second donor packet
25. record one clear reason for the chosen owner and one clear reason against the nearest wrong owner

Contracts

• invocation must remain explicit and post-session
• the skill harvests donor units; it does not treat session history as memory canon or instruction authority
• one candidate must map to one primary owner layer
• candidate_ref appears only after reviewed donor harvest
• usefulness is a reuse signal, not an owner layer by itself
• derivative layers do not become first authoring targets for source-owned meaning
• weak evidence may end in hold or keep_or_open_quest
• the HARVEST_PACKET may carry handoff hints, but it does not become hidden routing authority
• automation_candidate is only a detector hint; it is not schedule or mutation authority
• HARVEST_PACKET_RECEIPT stays subordinate to the packet and never replaces owner-layer or proof meaning
• CORE_SKILL_APPLICATION_RECEIPT stays subordinate to the packet and the detail receipt; it records one finished kernel-skill application and nothing more
• receipt corrections use supersedes rather than silent mutation
• drafting a next artifact is allowed; forcing promotion is not

Risks and anti-patterns

• collapsing technique, skill, and playbook into one generic "good reuse" bucket
• mistaking session themes for reusable units
• routing authored meaning into aoa-routing or aoa-kag first
• turning agent class law into a skill just because an agent repeatedly used a workflow
• promoting memory residue as if it were proof or source meaning
• over-harvesting one session into too many thin objects
• treating a transcript package or session index as the same thing as donor harvest
• stuffing route-forks, diagnosis, repair, or progression meaning into vague donor notes instead of naming the next family seam explicitly
• turning donor harvest into a generic automation detector for every recurring annoyance instead of keeping automation readiness as its own seam
• letting receipt counts masquerade as proof, progression, or routing law

Verification

• confirm the source artifact is reviewed and bounded
• confirm each kept candidate names one reusable unit rather than a topic
• confirm each accepted candidate has one primary owner layer
• confirm the nearest wrong target is rejected explicitly
• confirm candidate_ref was minted only for reviewed bounded units
• confirm any surviving checkpoint cluster_ref stayed linked when available
• confirm no candidate routes source-owned meaning first into derivative layers
• confirm hold and defer outcomes remain available
• confirm the output names the next artifact rather than only abstract categories
• confirm any family handoff hint is explicit rather than smuggled into the packet as hidden policy
• confirm any automation_candidate names the current manual route and still stops short of automation authority
• confirm any emitted receipt stays append-only, evidence-linked, and smaller than the packet it summarizes
• confirm any emitted CORE_SKILL_APPLICATION_RECEIPT points to the matching detail receipt and does not widen beyond one finished kernel-skill run

Technique traceability

Manifest-backed techniques:

• AOA-T-0075 from 8Dionysus/aoa-techniques at 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/session-donor-harvest/TECHNIQUE.md and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Validation
• AOA-T-0076 from 8Dionysus/aoa-techniques at 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/owner-layer-triage/TECHNIQUE.md and sections: Intent, When to use, Outputs, Core procedure, Risks, Validation
• AOA-T-0077 from 8Dionysus/aoa-techniques at 5c6f0496edc3c2e74590baa35627c85fe58ef765 using path techniques/agent-workflows/harvest-packet-contract/TECHNIQUE.md and sections: Inputs, Outputs, Contracts, Validation

Adaptation points

Project overlays may add:

• local session artifact entrypoints
• local review packet templates
• repo-relative destination paths for drafted artifacts
• local stop conditions for when the result must stay hold
• local naming rules for donor packs and quest IDs
• local family handoff preferences when automation scan, route-forks, diagnosis, repair, or progression surfaces exist

This skill assumes the session artifact already exists. Adjacent history techniques such as session capture, transcript packaging, and local indexing remain separate neighbors rather than being reopened here.