Skills / Engineering

audit-to-backlog

Runs parallel specialist reviews of a repository, keeps only findings backed by file-and-line evidence, removes duplicates, and writes a backlog that is ready to implement.

Group

Engineering

Kind

Action

Writes

Backlog files and the Backlog: line

Asks before

Creating the backlog files: which paths to use

When it runs

When you invoke it by name, or ask for a broad codebase audit that should end in a task backlog. It takes an optional path or --diff <ref> and a --perspectives list.

• audit this repo
• audit the code
• scan the repo and build a backlog

What it does

1. Establishes scope. It resolves the path or diff and the perspectives, detects the stack, the package manager from the lockfile and the real validation commands. It finds the backlog from a Backlog: <todo path>, <done path> line in AGENTS.md or CLAUDE.md, otherwise TODO.md and TODO-done.md, and reads it so no finding is duplicated or brought back from the done file. Before creating the files it asks which paths to use and records them as a Backlog: line; a git-ignored path gets a warning that worktrees cannot see its claims, and needs your confirmation. Project-specific reviewer agents are preferred when the repository defines any.
2. Delegates the perspectives in parallel. Security goes to developer-os:security-auditor, performance to developer-os:performance-engineer, tests to developer-os:qa-expert (assessment only, it writes nothing) and correctness to developer-os:code-reviewer; types, architecture and dead code, UI and accessibility run inline or in a general-purpose agent. Each reviewer returns every P0 and P1 plus at most 15 P2/P3 findings, each with an ID, file:line, severity, evidence from the current code, a fix, a size, a Done when criterion and a runnable Check command. Unsupported claims are rejected, and every report must open with a final status (DONE, REVIEW, BLOCKED or CONTINUING).
3. Verifies blocking findings. Every P0 and P1 goes to a fresh verifier that did not produce it (Codex when the Codex plugin is installed, otherwise the read-only verifier agent, which also takes over when Codex errors or returns nothing), given only the claim and asked to disprove it. Confirmed findings stay, undecided ones are marked unverified, refuted ones are left out and listed under Disputed with the verifier's evidence. While reviewers run, a short state card in docs/plans/.devos-state.md lets the session pick up after a compaction.
4. Merges the backlog. Items go into P0–P3 sections followed by implementation sessions of five to seven related tasks, never mixing P0 and P3. Duplicates are merged by file and root cause, keeping the higher severity; IDs continue the existing numbering and are never reused. A Done when is never edited, only amended with your approval.
5. Validates and reports. It checks that every item is evidence-backed, actionable, unique and absent from the done file, then reports the counts per priority and the three highest-impact findings, using only measured metrics.

Severity: P0 is an exploitable security defect, data loss or production down; P1 is wrong behavior on a common path; P2 an edge-case defect or real maintainability risk; P3 minor or cleanup.

Example output

- [ ] SEC-03 · P1 · Retry webhook deliveries with backoff
  - Where: `src/webhooks/deliver.ts:40`
  - Problem: a failed delivery is dropped without a retry.
  - Evidence: `deliver()` returns after the first non-2xx response (`src/webhooks/deliver.ts:52`).
  - Fix: retry with exponential backoff, then mark the delivery failed.
  - Size: S
  - Done when: a failed delivery is retried 3 times with exponential backoff, then marked failed.
  - Check: `pnpm vitest run src/webhooks/deliver.test.ts`
  - Blocked by: SEC-01

Boundaries

Related

• implement-backlog works through the backlog in small, reviewed batches.
• plan-status counts what is open, done and blocked.
• The backlog item format.
• The reviewer agents it delegates to.