agentleFS
fusebase-devfusebase-dev/fusebase-flow/.agents/skills/phase-audit/SKILL.md

phase-audit

Skill9 starsChanged 27 days agoMITView on GitHub

Use when a multi-slice phase has been implemented and the operator wants an independent audit of ALL slices before sign-off, or asks to "audit the phase", "review all slices", "independent check". Spawns a fresh sub-agent that examines every slice against the spec. Do NOT use for a single-diff review (use code-review), for security-only review (use security-permissions-review), or before a phase is implemented.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After a phase of multiple slices is implemented, run an independent audit (a fresh sub-agent with no implementation bias) over EVERY slice …

    line 27
  2. Distinctive:

    Before flipping a large spec DRAFT→DONE.

    line 33
  3. Distinctive:

    Cross-slice consistency: Check slices don't contradict each other, duplicate logic, or leave a seam (shared types, interfaces, data shape).

    line 55
  4. Distinctive:

    Ask operator in chat (FR-19) if scope of "the phase" is ambiguous.

    line 78
  5. Very specific:

    Do not write fixes (audit only.

    line 82
  6. Distinctive:

    Do not audit in the implementing session (defeats independence).

    line 83
  7. Distinctive:

    Do not collapse to a single-diff review — every slice in scope.

    line 84
  8. Distinctive:

    Do not pass a phase with unreconciled cross-slice contradictions.

    line 85

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Phase Audit

Style: Mode-B-lite.

Purpose

After a phase of multiple slices is implemented, run an independent audit (a fresh sub-agent with no implementation bias) over EVERY slice — verifying each against the spec/decisions and checking cross-slice consistency — before the phase is signed off. Catches drift that per-slice, in-session review misses.

When to invoke

  • A phase with 2+ slices is implemented and awaiting sign-off.
  • Operator says "audit the phase", "review all slices", "independent audit", "did we miss anything across the phase".
  • Before flipping a large spec DRAFT→DONE.

Do not invoke when

  • Single change / single diff → use code-review.
  • Security-specific concern → use security-permissions-review.
  • Phase not yet implemented (nothing to audit).
  • A trivial one-slice phase (per-slice review suffices).

Required inputs

InputWhere it livesIf missing
Spec + decisionsdocs/specs/<slug>/stop; cannot audit without the target
Slice list + SHAsdocs/specs/<slug>/tasks.mdderive from git log of the phase range
Implemented diffgit diff <phase-start>..HEADstop

Procedure

  1. Scope. Identify the phase's slices and their commit range from tasks.md / git log.
  2. Delegate (independent). Per flow-skills/task-delegation/SKILL.md, spawn a fresh sub-agent (read-only) so the audit is unbiased by the implementing session.
  3. Per-slice audit. For each slice: does the diff satisfy its acceptance criteria; cite file:line; flag gaps, scope creep, TODOs, missing tests.
  4. Cross-slice consistency. Check slices don't contradict each other, duplicate logic, or leave a seam (shared types, interfaces, data shape).
  5. Drift vs spec/North Star. Confirm the phase as a whole still matches the spec/decisions and docs/north-star.md if present.
  6. Consolidate. Produce one report: per-slice verdicts + cross-slice findings, split into blockers vs non-blockers, each with file:line evidence.
  7. Adversarial pass (optional). For high-risk phases, have the sub-agent try to refute its own "looks good" verdicts before reporting.

Output artifacts

ArtifactPath or locationMode
Phase audit reportchat + optional docs/specs/<slug>/phase-audit.mdMode B

Failure cases

Failure modeDetectionResponse
Slice fails its ACstep 3blocker; return to AI Developer
Cross-slice contradictionstep 4blocker; reconcile before sign-off
Audit not independent (same session bias)sub-agent not spawnedre-run via task-delegation

Escalation path

  • Blockers found → return to AI Developer with the per-slice list.
  • Cross-cutting design issue → workflows/architect-escalation.md.
  • Ask operator in chat (FR-19) if scope of "the phase" is ambiguous.

Anti-patterns

  • Do not write fixes (audit only; like code-review, FR-01).
  • Do not audit in the implementing session (defeats independence).
  • Do not collapse to a single-diff review — every slice in scope.
  • Do not pass a phase with unreconciled cross-slice contradictions.

Clean-room note

Original Fusebase Flow content. Designed after reviewing public AI coding workflow patterns; no third-party code, prompts, skill files, or hook scripts are copied. See docs/source-map.md.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.