Immutable. This exact content is served forever at /api/v1/blob/6e6b1e88406becb5.
--- name: task_finish description: Close one completed or parked task. Use when the user asks to finish, mark done, defer, park, drop, or archive a task. Set finished or deferred, move the file to archive, update links, and relint. version: 1.0.12 author: Andreas F. Hoffmann license: MIT --- # task_finish <task_finish_skill> <role> task_finish closes out a single task in the project's `tasks/` backlog. It executes the base `task` skill's `<archive>` workflow end to end, including the optional `ARCHITECTURE.md` refresh when the rule's trigger holds. 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 `<archive>` workflow, triggerable on its own, and it owns both closure paths: `finished` (done and shipped) and `deferred` (parked or dropped). </role> <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> <authority> 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 `<discover>` step to locate `tasks/`, its `<archive>` workflow for the six close-out steps, and its `<lint>` 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. </authority> <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> <workflow> 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. On the trust-the-stamp path, read `design-extended` from task frontmatter as the design-extension signal the close-out rule consumes, reading absence as `false` per the base `<frontmatter>` entry, so the close proceeds without re-reading the code the shortcut deliberately skips. Absence and a recorded `false` both decline the refresh, and the report keeps them apart rather than presenting an assessment nobody made as a decision. 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, including the `ARCHITECTURE.md` presence gate and refresh decision the base step defines. Those rules live in the base skill; follow them there rather than restating them here. </workflow> <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. Report the `ARCHITECTURE.md` disposition in one of three states: refreshed (with what changed), declined (naming whether that rested on a recorded `design-extended: false` or on no record at all, which reads as `false`), or the doc absent. 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> <family> 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. </family> </task_finish_skill>