v1.0.15 to v1.0.16

5 added, 5 removed. Audit B to B.

---

name: task_audit

description: Audit one implemented or finished task against the actual codebase. Use when verifying a believed-done task, checking claimed completion against the code, or running a drift check before close-out. Inspect code and tests, run verification, stamp audited only on clean implemented work, and report gaps otherwise.

- version: 1.0.15

+ version: 1.0.16

author: Andreas F. Hoffmann

license: MIT

---

# task_audit

<task_audit_skill>

<role>

- task_audit verifies whether a task's *claimed* completion is *real*, by checking the codebase rather than the prose. It reads one task, reads the actual implemented code and tests, walks every body item and `## Acceptance` check, runs the suite the task names, and reports a verdict: clean, or a list of gaps with fixes. It is a gate with one allowed lifecycle mutation: on a clean, complete verdict over a current `implemented` task, it stamps `status: audited` and bumps `updated`; a clean re-check of an archived `finished` task leaves it `finished`, and any gap leaves the status as it is. It answers "is this task genuinely done?"; `task_finish` answers "now close it." On a clean pass it hands the close-out to `task_finish`; on gaps it hands the remaining work on an `implemented` task to `task_implement` and the gaps on an `audited` or archived task to a new follow-up task.

+ task_audit verifies whether a task's *claimed* completion is *real*, by checking the codebase rather than the prose. It reads one task, reads the actual implemented code and tests, walks every body item and `## Acceptance` check, runs the suite the task names, and reports a verdict: clean, or a list of gaps with fixes. It is a gate with two allowed lifecycle mutations: on a clean, complete verdict over a current `implemented` task, it stamps `status: audited` and bumps `updated`, and on a gap verdict over an `audited` task, it re-opens the task to `status: implemented` and bumps `updated`, the base `<status_discipline>` re-audit re-open. A clean re-check of an archived `finished` task leaves it `finished`, and a gap on an `implemented` or archived task leaves the status as it is. It answers "is this task genuinely done?"; `task_finish` answers "now close it." On a clean pass it hands the close-out to `task_finish`; on gaps it hands the remaining work on an `implemented` or re-opened task to `task_implement`, and the gaps on an archived task to a new task under the base `<status_discipline>` follow-up rule.

</role>

<when_to_activate>

Activate when the user wants a task's done-ness checked against reality:

- "Is `<task>` actually done?" / "audit this task" / "verify the work is really implemented."

- "Check `<task>` against the code before I close it."

- "Re-check this archived task. Did the codebase drift from it?"

Audit only a task whose work is *claimed complete*: a live `implemented` or `audited` task under verification, or an archived `finished` task re-checked for drift. Decline a task whose body is still a plan.

Route elsewhere when the user wants to assess a task's 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`), close and archive a task (`task_finish`), or audit the whole tree's lint health (`task_fix`).

</when_to_activate>

The base `task` skill's `SKILL.md` is the source of truth for the task-file shape; read it and use its `<discover>` step to locate `tasks/` and its `<file_format>` / `<body>` sections to read the task under audit. The task being audited names its own checks in `## Acceptance`, and the repo's suite (`make lint`, the bundled `lint.py`, the matching `tests/<skill>/script_tests`) is the verification surface. Run what the task and repo name under the base `<verification_economy>` rule: run fresh wherever this session holds no citable prior run, and accept a recorded expensive-surface result only when it postdates every artifact under test.

</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>

- Run in order. Change no code and change the task only for the clean-verdict `audited`/`updated` stamp described here.

+ Run in order. Change no code, and change the task only for the two status stamps the **Stamp the verdict.** step describes, each with its `updated` bump.

1. **Read the task end-to-end.** Understand the desired behaviour, the `## Approach`, the scope and any Out of scope block, and every `## Acceptance` item. This is the contract you audit against.

2. **Understand what is actually built.** Read the implemented code and the existing tests around the work to establish what is really in place, not what the task claims.

3. **Verify each item against the code.** Walk every body item and every `## Acceptance` check and confirm the codebase covers it. Confirm the `design-extended` signal matches what the built change actually did, reading absence as `false` per the base `<frontmatter>` entry: a recorded `true` needs a design extension to justify it, and a `false` or absent signal needs the change to have genuinely left goals, stack, and design decisions alone. Treat a missing field on a task implement stamped as a recording gap worth naming, while an absent field on a task predating the field is legitimate and draws no finding. Trust the code, not the prose.

4. **Audit the tests as first-class.** When `TESTING.md` exists at the project root, read it for project-specific testing details (stack, runner, layout, thresholds) before judging the test surface. When it is absent, continue with the repo and task context already loaded. Confirm every acceptance check that names or implies a test has a corresponding, *passing* test. A missing or incomplete test is a gap, audited with the same rigour as the feature work, not waved through.

5. **Run the suite and attribute every failure.** Execute the verifications the task and repo name under the base `<verification_economy>` rule, running fresh wherever this session holds no citable prior run (a cross-session audit inherits no run from the session that built the work, so it runs the checks itself), and accepting a recorded expensive-surface result as evidence only when it postdates every artifact under test. Record each failure or warning as evidence. Attribute honestly: a failure your audited work would cause is a gap; a pre-existing failure unrelated to this task is context, named as such rather than counted against the task.

- 6. **Stamp only a clean current implementation.** When every body item, acceptance check, required test, and the `design-extended` signal check is confirmed and the current task status is `implemented`, stamp `status: audited` and bump `updated`. When the task is already archived as `finished`, leave it `finished`. When any gap remains, leave the status as it is. Route the gaps on an `implemented` task to `task_implement`, and the gaps on an `audited` task or an archived `finished` task to a new follow-up task, because after implementation the status only moves forward under the base `<status_discipline>` rule and `task_implement` would write `implemented` over the later status.

+ 6. **Stamp the verdict.** When every body item, acceptance check, required test, and the `design-extended` signal check is confirmed and the current task status is `implemented`, stamp `status: audited` and bump `updated`. A clean verdict over a task already `audited` or archived as `finished` leaves its status as it is. When gaps remain on an `implemented` task, leave the status as it is and route the gaps to `task_implement`. When gaps that `task_implement` should fix remain on an `audited` task, write `status: implemented` and bump `updated`, which is the base `<status_discipline>` re-audit re-open, and route the gaps to `task_implement` on the same task. Route gaps on an archived `finished` task, and any finding the base `<status_discipline>` follow-up rule sends to a new task, to a new task under that rule.

</workflow>

<output_contract>

Report an evidence-based verdict, never on prose alone.

- On full compliance, make the verdict line, on its own line, exactly: `Success: full task compliance confirmed.` That literal is the machine-readable signal, so write it bare (no backticks, no surrounding words on that line). Supporting evidence may precede it and the `task_finish` pointer follows it; the verdict line itself stays exact.

- Otherwise lead with `Gaps:` followed by a numbered list. For each gap give **requirement / expected behaviour / actual behaviour / minimum fix**, ordered by mismatch size (largest coverage or behaviour gap first).

- Make only the clean-verdict `audited`/`updated` stamp described in `<workflow>`. On a clean pass, point at `task_finish` to perform the close-out. On gaps, hand the remaining work to `task_implement` for an `implemented` task, or to a new follow-up task for an `audited` or archived one. Surface any pre-existing, unrelated failure as context separate from the gap list.

+ Make only the status stamps the **Stamp the verdict.** step describes. On a clean pass, point at `task_finish` to perform the close-out. On gaps, hand the remaining work to `task_implement` for an `implemented` task or an `audited` task the gap verdict re-opened, and to a new task for an archived one under the base `<status_discipline>` follow-up rule. Surface any pre-existing, unrelated failure as context separate from the gap list.

</output_contract>

The `task_*` family, in which 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) **(this skill)**

- `task_finish`: close out (set status, bump `updated`, archive)

- `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_audit_skill>