task_audit

task_audit

<task_audit_skill>

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

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

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 status: implemented and route the gaps to task_implement.