task_finish

task_finish

<task_finish_skill>

task_finish closes out a single task in the project's `tasks/` backlog. It performs the close-out action — set `status` to `finished` or `deferred`, bump `updated`, `git mv` the file to `archive/`, re-point the cross-references the move touches, and re-lint to a clean tree. It is the *action* counterpart to `task_audit`, the read-only *gate* that answers "is this genuinely done?". task_finish answers "now close it." It is the skill form of the base `task` skill's `` workflow, triggerable on its own, and it owns both closure paths: `finished` (done and shipped) and `deferred` (parked or dropped).

<when_to_activate> Activate when the user wants one task closed out:

• "Finish this task" / "mark <task> done" / "this task is implemented."
• "Defer this" / "park <task>" / "drop this for now."
• "Archive this task."

Route elsewhere when the user wants to create a task (task_create or the base task skill), assess readiness before building (task_check), automatically repair readiness issues before building (task_auto_check), choose what to work on next (task_select), do the implementation work (task_implement), verify a believed-done task against the codebase (task_audit), or list / query / update tasks (the base task skill). </when_to_activate>

The base `task` skill's `SKILL.md` is the single source of truth; keep every shared rule there and follow it rather than copying it. Read that skill and apply its `` step to locate `tasks/`, its `` workflow for the six close-out steps, and its `` step (the bundled `lint.py`) to confirm the result. These assets ship in the same plugin as task_finish, so they are present wherever task_finish is.

<path_resolution> The bundled scripts (discover_tasks.sh, lint.py) ship in scripts/ next to the base task skill's SKILL.md, not next to this one. After reading that base SKILL.md (per <authority>), resolve each script's absolute path by combining the directory you loaded it from with scripts/<script-name> and invoke that absolute path — never a bare scripts/..., which resolves against the current working directory (the target project) rather than the skill, and so finds the project's own scripts/ or nothing. If the first invocation reports a missing file, re-resolve the absolute path once before treating the script as failed. </path_resolution>

Close one task, in order:

1. Identify the target task. Run the base skill's <discover> step to resolve tasks/, and confirm which single task file is being closed. Read it so you know its current status, links, and the work it claims.
2. Decide the outcome. Set finished when the work is done and shipped, or deferred when the task is parked or dropped and not pursued for now. When the user's intent is ambiguous between the two, ask before changing anything.
3. Verify before a finished close when needed. Marking a task finished asserts the work is genuinely done, so make the verification decision from the task's current status: when it is audited, treat the codebase-verification gate as already satisfied and proceed to close-out; when it is implemented or any other non-audited live status being closed as finished, run task_audit (the read-only gate) or carry out its check, and resolve or report any gap before closing. Trust a current audited stamp; when you have concrete evidence the code changed since that audit, re-verify rather than relying on the stamp. A deferred close skips this step, since parking a task makes no claim about completion. Mark a task finished on codebase evidence, not on prose. This trust-the-stamp gate is the lifecycle-scale instance of the base <verification_economy> rule: the audit is the prior run whose evidence stands until an input changes, and code that changed since the audit is that input change — so the stamp is trusted by default and re-verification fires exactly on fresh evidence.
4. Run the base skill's <archive> close-out. Follow the task skill's <archive> workflow end to end — set status, bump updated from date, git mv the file to archive/, re-point every cross-reference the move touches (outbound links inside the moved file, inbound links from anywhere in the tasks tree — open and archived alike), and re-lint once after the move per the base <verification_economy> rule, re-running only after a fix changes the tree, until no blocking finding remains. Those rules live in the base skill; follow them there rather than restating them here.

<output_contract> Report the task's new path under archive/, the status you set, the cross-references you re-pointed, and a clean linter result. When a finished close relied on an existing audited stamp, state that explicitly. Surface any assumption you made about the finished-vs-deferred outcome so the user can correct it. </output_contract>

The `task_*` family — each sibling does one job, then points to the next; the base `task` skill is the hub that can do all of it:

• task_create — write one task file
• task_check — readiness gate before building (read-only)
• task_auto_check — autonomously repair one task until task_check reports ready
• task_explain — explain one task at a high level (read-only)
• task_select — choose and rank the next eligible task/action (read-only)
• task_implement — do the work
• task_audit — verify a believed-done task against the codebase (read-only)
• task_finish — close out: set status, bump updated, archive (this skill)
• task_fix — audit and repair the whole tasks tree

These ship together as a family; any sibling may be absent if a deployment excluded it. The default manual chain is create → check → implement → audit → finish, with task_auto_check as an opt-in readiness repair loop, task_select a read-only chooser for what to work on next, and task_fix maintaining the tree.

</task_finish_skill>