ariadne:closeout

Ariadne Closeout

Overview

Use this skill at the end of a meaningful work unit, or at a checkpoint inside a larger chat, to decide what should survive in the vault and whether the chat can safely close or continue.

Closeout is a thin orchestration skill. It decides whether to use existing Ariadne skills, what artifact shape fits the work, and what safety gates apply. It does not create new default folders, templates, or board systems by itself.

Modes

• Assess only: read-only. Determine completion state, likely vault/scope, recommended artifacts, follow-ups, and safe-to-close status. Do not write, stage, commit, push, or run mutating cleanup.
• Lightweight closeout: for small but meaningful work. Prefer one existing-note update, one board card update, or one short output.
• Full closeout: for incidents, production behavior changes, releases, evaluations, significant feature work, architecture/product decisions, or durable planning.
• Checkpoint: for a completed work unit inside a longer chat. Update the same durable docs when the work belongs to the same thread; create new docs only for a distinct decision, evidence source, verification event, incident, release, or follow-up stream.

Handoff is an output flag, not a mode. Include a handoff or team update when another person, agent, or future session needs a concise current-state message.

Start

1. Classify the request mode and whether a handoff output is needed.
2. Reconstruct the completed work: goal, actions, changed files or PRs, decisions, verification, evidence, unresolved risks, and next actions.
3. Decide whether durable capture is warranted. If not, explain why and end with a closeout verdict.
4. Use registered vault discovery when the target vault is not explicit.
5. In a multi-scope vault, require a current-turn explicit target before the first write-producing closeout. A target is explicit only when the current prompt names the scope, domain, customer, project, or workstream, or the user confirms one after being asked.
6. For later checkpoints in the same chat, reuse the previously confirmed target only when you restate the vault/scope and the new work still belongs to the same thread. Any scope, vault, artifact class, or workstream drift re-triggers confirmation.
7. Read the selected vault and scope entrypoints: root AGENTS.md, root index, agent navigation, task routing matrix, local AGENTS.md, local hub, and relevant existing notes. For repeat checkpoints, cheaply re-verify the cached route unless the target changed.
8. Read every applicable ancestor scope instruction and state an explicit allowed_write_set before writing. Include each artifact and any individually named parent/root navigation file; defer all other paths.