audit-plan-implementation

Audit plan implementation

Use this skill for findings-first verification after implementation work. The default action is audit only; fixes require an explicit remediation request or a controller policy that allows bounded in-scope remediation.

Inputs

Read the frozen developer overview, plan manifest, lock, task packet, write-set contract, acceptance criteria, evidence rules, task result, implementation diff, and previous reviews. In final mode, read all accepted task results, reviews, evidence receipts, and the workflow state.

When the installed CLI exposes the implementation audit facade, use it as the typed evidence producer:

agent-lifecycle audit implementation \
  --manifest work/plans/package/plan.manifest.json \
  --state run.state.json \
  --task WS-01 \
  --result work/WS-01/attempt-1/task-result.json \
  --review work/WS-01/attempt-1/task-review.json \
  --review-mesh-quorum work/review-mesh/implementation-quorum.json \
  --out work/WS-01/attempt-1/implementation-audit.json

agent-lifecycle audit final-implementation \
  --manifest work/plans/package/plan.manifest.json \
  --state run.state.json \
  --report work/WS-01/attempt-1/implementation-audit.json \
  --out final/final-implementation-audit.json

The command output is the machine-readable source for acceptance gates. The skill still supplies semantic review guidance when a human or host reviewer must interpret findings.

Use --review-mesh-quorum only when the frozen plan requires Review Mesh for the audited phase. Missing or failed quorum evidence is a blocking audit finding; optional Review Mesh output remains advisory. For operator-facing audit setup, point beginners to docs/guides/lifecycle-cookbook.md#audit-implementation-evidence and keep this skill focused on findings-first semantic verification plus typed audit receipts.

Task audit

For each planned item, verify:

• expected behavior and acceptance criteria;
• actual changed files and their owner;
• forbidden-write and read-only-path compliance;
• tests, command receipts, artifact ids, hashes, and freshness;
• evidence limits and budget use;
• architecture, security, performance, release, and adapter constraints;
• task result identity bound to run, task, attempt, packet, plan, source, and reviewer.
• task result file set and content digests recomputed from the current Git worktree and frozen source revision; caller-provided path lists are comparison inputs, not freshness authority.