titan-closeout

Intent

Use this skill at the end of a Titan service-cohort session to close the local receipt without claiming final owner truth.

Trigger boundary

Use this skill when:

• a Titan receipt is ready to close
• Atlas, Sentinel, and Mneme posture needs one summary
• Forge or Delta gates were used and need visible closeout

Do not use this skill when:

• the session has no receipt
• closeout would replace owner-repo validation
• memory candidates are being promoted without owner confirmation

Inputs

• receipt path
• operator summary
• gates used
• validation evidence
• memory candidates and owner-route hints

Outputs

• closed receipt or closeout packet
• role and boundary summary
• gate summary
• verification status
• next owner-repo action

Procedure

1. load the active receipt, gate, ledger, console, and memory-candidate refs
2. summarize Atlas route, Sentinel risk, and Mneme provenance state
3. separate completed validation from remaining owner-repo review
4. record whether Forge or Delta ever crossed their gates and with what evidence
5. emit the next-owner summary without promoting candidate memory or proof claims

Contracts

• The skill is explicit-only and must not be invoked as hidden background behavior.
• Titan role, helper/control-plane, runtime implementation, memory, proof, and public-runbook authority stays in owner repositories: aoa-agents, aoa-sdk, abyss-stack, aoa-memo, aoa-evals, and 8Dionysus.
• Receipts, bridge ledgers, console state, replay artifacts, approval records, and memory records are witnesses or candidates, not final owner truth.
• Forge mutation and Delta judgment gates must remain distinct, operator-visible, and receipt-linked.
• Missing source refs, missing approval, missing validation, or unclear owner route must be named as stop conditions.

Risks and anti-patterns

• treating Titan vocabulary as permission to widen authority
• letting receipt, replay, console, or bridge state replace owner-repo evidence
• auto-approving Forge or Delta because a plan looks plausible
• promoting candidate memory, approvals, replay, or receipts into canon without owner review
• using the skill for an ordinary repo task that has no explicit Titan route

Verification

• confirm direct skill invocation or explicit Titan service-cohort request is present
• confirm lane, gate, source refs, and owner surface are named when relevant
• confirm Forge or Delta locked or allowed state matches recorded approval evidence
• confirm generated artifacts are marked witness, candidate, derived, or advisory rather than final truth
• confirm next validation, replay, repair, or owner-route follow-up is named before continuation

Technique traceability

Manifest-backed techniques:

• AOA-T-0058 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/continuity/handoff-continuation/receipt-confirmed-handoff-packet/TECHNIQUE.md and sections: Intent, Inputs, Outputs, Core procedure, Contracts, Risks, Validation
• AOA-T-0076 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/governance/decision-routing/owner-layer-triage/TECHNIQUE.md and sections: Intent, Inputs, Outputs, Core procedure, Contracts, Risks, Validation
• AOA-T-0045 from 8Dionysus/aoa-techniques at 3b1d5d623569aa4920b87280d0db0e911d2e29d5 using path techniques/history/history-artifacts/witness-trace-as-reviewable-artifact/TECHNIQUE.md and sections: Intent, Inputs, Outputs, Core procedure, Contracts, Risks, Validation

Adaptation points

• Extract a Titan-specific reusable technique into aoa-techniques only after repeated reviewed evidence exists; do not add pending IDs as placeholders.
• Keep repo-local command examples in owner docs or examples rather than hard-coding them into skill law.
• If a Titan surface graduates from scaffold to reviewed or evaluated, add review evidence before changing status.