aftercare

name

aftercare

description

Use when the user wants to operate a post-build cleanup queue through natural language: initialize Aftercare in a repo, add/list/show tickets, recommend or start the next task, reorder work, reopen a ticket after failed acceptance, manage mixed fix/test/review/deploy work in one queue, run the queue loop, or sync queue summaries back into project memory. Works well for artifact-heavy build workflows, including roadmap-driven, spec-driven, pipeline-driven, and hybrid projects.

Aftercare

Use this skill when the user wants to work with Aftercare directly through the model instead of manually typing every queue command.

Resolve The Runtime First

Before running any Aftercare operation, resolve the bundled runtime script in this order:

1. ./.agents/skills/aftercare/scripts/aftercare-tools.cjs
2. ./.claude/skills/aftercare/scripts/aftercare-tools.cjs
3. ./.cursor/skills/aftercare/scripts/aftercare-tools.cjs
4. ./.gemini/skills/aftercare/scripts/aftercare-tools.cjs
5. ./.gemini/antigravity/skills/aftercare/scripts/aftercare-tools.cjs
6. ./.codex/skills/aftercare/scripts/aftercare-tools.cjs
7. $CODEX_HOME/skills/aftercare/scripts/aftercare-tools.cjs
8. ~/.codex/skills/aftercare/scripts/aftercare-tools.cjs
9. ~/.claude/skills/aftercare/scripts/aftercare-tools.cjs
10. ~/.cursor/skills/aftercare/scripts/aftercare-tools.cjs
11. ~/.gemini/skills/aftercare/scripts/aftercare-tools.cjs
12. ~/.gemini/antigravity/skills/aftercare/scripts/aftercare-tools.cjs

If none of these paths exist, read references/install.md and tell the user how to install the skill. Do not invent other install locations beyond the supported mainstream hosts: Claude Code, Codex, Cursor, Gemini, and Antigravity.

Read Directly, Mutate Through Runtime

Aftercare is not runtime-only.

Use direct file reads to understand project truth:

• .aftercare/OVERVIEW.md
• .aftercare/STATE.md
• .aftercare/tickets.jsonl
• .aftercare/queue-view.json
• .aftercare/history/events/events.jsonl
• related code, docs, and planning artifacts

Use the runtime script for state mutations and derived writes:

• init-repo
• add-ticket
• start
• force-next
• reopen
• block
• done
• defer
• cancel
• summary
• sync-project
• help
• run-next
• run-loop

If the runtime is missing, read-only analysis can still proceed from files. Only block when the user wants to mutate queue state and the runtime is not installed.

Target Repo Rules

• Default target repo is the current working directory.
• If the user names another repo or path, operate on that path instead.
• If the target repo does not have .aftercare/ yet and the request is operational, run init-repo first.
• If the target repo does not have .aftercare/ yet and the request is only analytical, inspect the repo normally and explain that queue state has not been initialized yet.
• Never write runtime state into the skill install directory.
• All runtime state must stay inside the target repo's .aftercare/.

Natural-Language Routing

Map user intent to the runtime commands:

• "initialize aftercare here" -> init-repo
• "add a ticket", "record this bug" -> add-ticket
• "show queue", "what's pending" -> list
• "show ticket AC-..." -> show
• "what should we do next" -> pick-next
• "start AC-..." or "claim next ticket" -> start
• "force AC-... next", "make this the next one", "put this at the front" -> force-next
• "acceptance failed", "put this back in queue", "retry the same ticket" -> reopen
• "show commands", "aftercare help", "what can aftercare do" -> help
• "mark done", "block", "defer", "cancel" -> matching status command
• "summarize aftercare state" -> summary
• "sync this back to the project" -> sync-project
• "run the next one automatically" -> run-next
• "keep going until the queue is empty" -> run-loop

Use explicit ticket ids whenever available. When the user asks to start the next item, call pick-next first and then start <id>.

Queue Rules

Read references/operating-rules.md when the user asks about queue behavior or when you are about to change ticket state.

The important defaults are:

• the queue is non-preemptive
• only one ticket can be in_progress
• one shared queue can mix fix, test, review, and deploy tickets
• pick-next is read-only
• start <id> is the claim boundary
• force-next <id> makes one queued ticket become the next ticket without interrupting the active one
• reopen <id> is the right move when the same issue failed acceptance and needs another pass
• automatic selection is force_next -> P0 -> P1 -> P2 -> FIFO
• new tickets can be added while another ticket is active
• blocked, deferred, and cancelled do not participate in automatic selection

Operator Style

• Prefer the smallest command that matches the user's request.
• Treat add-ticket -> run-loop as the default user path unless the user wants manual queue control.
• When acceptance fails on the same issue, prefer reopen over creating a brand new ticket.
• Create a new ticket only when the newly discovered issue should be tracked independently.
• After mutating queue state, report the resulting ticket id, status, and next meaningful follow-up.
• Use sync-project when the user asks to recover data, write back summary state, or refresh project memory.
• Use run-next and run-loop only when the user explicitly asks for automatic progression.
• If a queue operation fails because a ticket is already active, explain that the queue is single-active rather than trying to override it silently.