closeout

Name: closeout
Author: pariyar07

18stars2forks

How to install closeout?

pariyar07/ariadne/closeout

$npx -y skills add pariyar07/ariadne --skill closeout

Installs into the current project.

Summary

Close or checkpoint meaningful completed work in an agent-maintained Markdown knowledge vault. Use when the user asks to run Ariadne closeout, make work durable, close the loop, checkpoint this work, capture the outcome, decide whether a chat can close, draft a handoff, or update

Files · 1

View on GitHub

SKILL.md

1	# Ariadne Closeout
2
3	## Overview
4
5	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.
6
7	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.
8
9	## Modes
10
11	- 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.
12	- Lightweight closeout: for small but meaningful work. Prefer one existing-note update, one board card update, or one short output.
13	- Full closeout: for incidents, production behavior changes, releases, evaluations, significant feature work, architecture/product decisions, or durable planning.
14	- 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.
15
16	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.
17
18	## Start
19
20	1. Classify the request mode and whether a handoff output is needed.
21	2. Reconstruct the completed work: goal, actions, changed files or PRs, decisions, verification, evidence, unresolved risks, and next actions.
22	3. Decide whether durable capture is warranted. If not, explain why and end with a closeout verdict.
23	4. Use registered vault discovery when the target vault is not explicit.
24	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.
25	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.
26	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.
27	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.
28
29	Do not scan the whole vault by default. Prefer hubs, indexes, decisions, boards, and synthesis notes over raw sources.
30
31	## Artifact Decision Tree
32
33	Choose artifacts from the shape of the completed work, not from a fixed checklist.
34
35	Use artifact count discipline:
36
37	1. Prefer no durable capture when nothing reusable was created.
38	2. Prefer updating one existing canonical note over creating a new note.
39	3. Prefer one new note over multiple notes.
40	4. Use multiple artifacts only when each has a distinct job.
41	5. More than three artifacts requires briefly stating why each earns its existence.
42
43	Common choices:
44
45	- No durable capture: use for trivial, self-contained work with no decision, reusable learning, follow-up, or verification burden. If the user explicitly asks to capture the outcome, use the lightest durable form.
46	- Existing note update: use when the work advances an existing decision, product plan, release, incident thread, or workstream note.
47	- Decision note: use for accepted product, architecture, process, scope, naming, release, safety, or implementation commitments. Separate context, options, rationale, consequences, and evidence links.
48	- RCA or incident content: use for failures, outages, regressions, production-relevant errors, security concerns, production/preprod issues, data drift, or substantial debugging lessons. Capture symptom, cause, impact, fix, verification, prevention, and follow-ups inside the nearest existing local convention.
49	- Verification content: use for manual QA, preprod/prod validation, migrations, dry-runs, evals, or environment-specific proof. Capture what was checked, where, when, result, evidence pointer, and residual risk. Create a standalone note only when the scope already has that convention or the proof nee

People who liked this also viewed

6 picks

Type

closeout

18stars2forks

View on GitHub

How to install closeout?

pariyar07/ariadne/closeout

$npx -y skills add pariyar07/ariadne --skill closeout

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Ariadne Closeout
2
3	## Overview
4
5	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.
6
7	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.
8
9	## Modes
10
11	- 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.
12	- Lightweight closeout: for small but meaningful work. Prefer one existing-note update, one board card update, or one short output.
13	- Full closeout: for incidents, production behavior changes, releases, evaluations, significant feature work, architecture/product decisions, or durable planning.
14	- 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.
15
16	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.
17
18	## Start
19
20	1. Classify the request mode and whether a handoff output is needed.
21	2. Reconstruct the completed work: goal, actions, changed files or PRs, decisions, verification, evidence, unresolved risks, and next actions.
22	3. Decide whether durable capture is warranted. If not, explain why and end with a closeout verdict.
23	4. Use registered vault discovery when the target vault is not explicit.
24	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.
25	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.
26	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.
27	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.
28
29	Do not scan the whole vault by default. Prefer hubs, indexes, decisions, boards, and synthesis notes over raw sources.
30
31	## Artifact Decision Tree
32
33	Choose artifacts from the shape of the completed work, not from a fixed checklist.
34
35	Use artifact count discipline:
36
37	1. Prefer no durable capture when nothing reusable was created.
38	2. Prefer updating one existing canonical note over creating a new note.
39	3. Prefer one new note over multiple notes.
40	4. Use multiple artifacts only when each has a distinct job.
41	5. More than three artifacts requires briefly stating why each earns its existence.
42
43	Common choices:
44
45	- No durable capture: use for trivial, self-contained work with no decision, reusable learning, follow-up, or verification burden. If the user explicitly asks to capture the outcome, use the lightest durable form.
46	- Existing note update: use when the work advances an existing decision, product plan, release, incident thread, or workstream note.
47	- Decision note: use for accepted product, architecture, process, scope, naming, release, safety, or implementation commitments. Separate context, options, rationale, consequences, and evidence links.
48	- RCA or incident content: use for failures, outages, regressions, production-relevant errors, security concerns, production/preprod issues, data drift, or substantial debugging lessons. Capture symptom, cause, impact, fix, verification, prevention, and follow-ups inside the nearest existing local convention.
49	- Verification content: use for manual QA, preprod/prod validation, migrations, dry-runs, evals, or environment-specific proof. Capture what was checked, where, when, result, evidence pointer, and residual risk. Create a standalone note only when the scope already has that convention or the proof nee

People who liked this also viewed

6 picks

Type