Audit
Claude Code plugin: tech-lead interview -> multi-file execution plan -> sprint-by-sprint execution -> zero-trust audit -> handoff. Guarded against both lazy shortcuts and over-engineering.
npx -y skills add Zhen-Bo/request-devflow-plan --skill auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 27 days oldThe repository was created 27 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Independent acceptance audit of a completed DevFlow plan — zero trust, re-measures every metric itself, audits without fixing. Produces a PASS / PASS WITH FINDINGS / FAIL report. Must run in a fresh session (no executor history) and only after all sprints claim completion.
SKILL.md
5.1 KB, as published. Nobody here has run it
request-devflow-plan:audit
Independent acceptance audit. Run in a fresh session only — never in the same session as any execution. $ARGUMENTS optionally names the plan folder.
Flow
Step 1 — Locate and read
Locate the plan folder (as in kickoff), then read every plan document in README order — including audit-log.md for the round history (it informs; it never substitutes for your own re-measurement). Cross-agent auditing is encouraged: a different agent than the last round's is a feature, and the log is your shared memory.
Step 2 — Core audit
Per the plan's final-audit doc and 00-iron-rules:
Part 1 — Independent re-run
- Re-measure every metric in the final-audit table yourself; trust nothing recorded in PROGRESS
- Run the full gate suite twice back to back (any mismatch between runs = major defect)
- Every conclusion carries its command, exit code, and output
Part 2 — Anti-cheat (the plan's final-audit doc is authoritative when its list differs)
- Changed expectations: scan
git log -pover the test tree for assertion changes; check each against its sprint-doc authorization - Scope shrink: every sprint's acceptance criteria against PROGRESS evidence, row by row
- Skip audit: integration skips = 0 unless each new skip has a recorded reason
- Commit discipline: sample 15 commits and check their diffs against the declared concern
- Report honesty: do the phase reports cover every deviation in implementation-notes §4?
Part 3 — Out-of-plan scan ≥30 minutes of your own judgment. Answer: "where will the person inheriting this in six months still hurt?" Then run EVERY finding (from all three parts) through the plan's blocking test (final-audit §3b — the five fixed tests): record the first test it hits plus evidence, or "none of the five". A finding without this record is an incomplete audit, not a non-blocking finding.
Step 3 — Report
Write the audit report to the location the plan's final-audit doc names (default docs/phase-reports/final-acceptance-audit.html). Re-audits never overwrite earlier reports — suffix subsequent runs (-r2, -r3, …):
- Verdict: PASS / PASS WITH FINDINGS / FAIL (+ the shortest repair path)
- Metric table, one row per metric: measured value / command / verdict
- Defect list: severity / location / suggested owning sprint
- Out-of-plan findings
- The three most important conclusions for the maintainer
Step 4 — Summarize and route
Verdict + defect summary in the conversation. Append this round to audit-log.md (verdict, defect counts, route, consecutive-FAIL count, your identity, a note to the next auditor) and record the verdict entry in the acceptance unit's PROGRESS section — these two appends are the only plan-folder writes an auditor makes.
The verdict is computed from the blocking-test records, never felt:
- PASS → all metrics green, zero findings → suggest handoff.
- PASS WITH FINDINGS → all metrics green AND every finding recorded as hitting none of the five blocking tests → ask the maintainer where to record the findings: GitHub issues (when the repo uses them) or the plan's
issue-handoff.md(IH-entry format in the plan templates). Then suggest handoff. Never loop on non-blocking findings. - FAIL → any metric miss, or any finding hitting a blocking test → hand the defect list to remediation planning (
planskill, remediation mode): all blocking defects — regardless of size — become one remediation unit (full lifecycle) plus a paired re-acceptance unit. From the 2nd consecutive FAIL, remediation mode opens with a root-cause interview. Loop until a round passes; no defect is fixed off the books.
End with the Next steps block — full copy-paste command lines with actual values (shorthand and unfilled placeholders are violations), recommended line first. Commands that need a fresh context get the advisory line "Run /clear (or open a new session) first" printed before them:
- PASS →
/request-devflow-plan:handoff - PASS WITH FINDINGS → offer to file the findings right now (issues or issue-handoff.md), then print
/request-devflow-plan:handoff - FAIL → print all three, in order, computing the remediation unit number as the plan's last unit + 1:
/request-devflow-plan:plan— remediation mode picks this report up automatically/request-devflow-plan:kickoff sprint <computed number>— fresh session, after the plan lands/request-devflow-plan:audit— fresh session, after the remediation unit is signed off
Principles
- Zero trust, audit only, evidence first
- The audit session and any execution session must be fully separate
- On FAIL, fix nothing (environment repairs excepted)
Never
- Fix anything (environment excepted)
- Pass because "most of it passed" — one miss is FAIL
- Treat "the ledger says done" as done