---
name: Auditing Progress
slug: auditing-progress
category: Quality
description: "Auditing Progress checks evidence quality after an iteration using three tiers: current stories, impacted scenarios, and sentinel regressions. Use it when you need to verify that behavior proof is durable before moving to the next iteration."
github: "https://github.com/prime-radiant-inc/iterative-development/tree/main/skills/auditing-progress"
language: Python
stars: 179
forks: 17
install: "npx degit https://github.com/prime-radiant-inc/iterative-development/tree/main/skills/auditing-progress ~/.claude/skills/auditing-progress"
installs_to: ~/.claude/skills/auditing-progress
source_path: skills/auditing-progress/SKILL.md
collection_size: 6
category_size: 1817
collection_url: "https://dirskills.com/collections/prime-radiant-inc/iterative-development"
added: 2026-09-07T05:20:43.794Z
last_synced: 2026-09-07T05:20:43.794Z
canonical_url: "https://dirskills.com/skills/auditing-progress"
---

# Auditing Progress

Auditing Progress checks evidence quality after an iteration using three tiers: current stories, impacted scenarios, and sentinel regressions. Use it when you need to verify that behavior proof is durable before moving to the next iteration.

**Install:**

```bash
npx degit https://github.com/prime-radiant-inc/iterative-development/tree/main/skills/auditing-progress ~/.claude/skills/auditing-progress
```

## README

# Auditing Progress

## Overview

Runs after every iteration as part of the planning cycle. Verifies behavior evidence quality in three tiers using **parallel adversarial review (PAR)** — two paired auditor subagents evaluate the same work in parallel with competitive framing.

The audit answers: "Does durable, reusable evidence exist at the correct seam for every externally observable behavior this iteration touched?"

## When to Use

Invoked by `iterative-development` after every `running-an-iteration` call, before picking the next iteration.

## Audit Process

### 1. Partition the audit into three tiers

Read the per-epic requirement files in `docs/superpowers/iterations/requirements/`, `docs/superpowers/iterations/behavior-scenarios.md`, and `docs/superpowers/iterations/behavior-corpus.md`:

- **Tier 1 — Deep evidence:** stories marked `done:ITER-<current>` and scenarios added or updated in this iteration. Audit every AC and its proof obligation thoroughly.
- **Tier 2 — Impacted behavior:** all existing scenarios whose owning stories had code changes in this iteration (even if those stories were completed in earlier iterations). Verify the scenarios still pass.
- **Tier 3 — Sentinel corpus:** all scenarios with run cadence `sentinel` in the behavior corpus. Compare against the pre-iteration baseline from `running-an-iteration` step 3.

### 2. Dispatch paired auditor subagents (PAR)

Following the PAR methodology in `skills/shared/parallel-adversarial-review.md`:

1. Build the auditor prompt using `auditor-subagent-prompt.md`. Include ALL THREE tiers:
   - Tier 1: full story cards with proof obligations + new/changed scenario cards
   - Tier 2: impacted scenario cards + their current test results
   - Tier 3: sentinel scenario IDs + baseline results + current results
2. Wrap in competitive framing from `skills/shared/par-reviewer-wrapper.md`
3. Dispatch TWO auditor subagents in parallel
4. Wait for both to return

### 3. Aggregate findings

Following PAR aggregation rules:
- Same finding from both auditors → one finding, high confidence
- Finding from only one auditor → separate finding, still actionable
- Severity disagreement → take the more severe assessment, always fix it

### 4. Process results

- **If gaps found** (any AC fails, evidence is too weak, sentinel regression detected):
  - For AC failures: append gap stories to `requirements/` (status `pending`) or flip existing stories back from `done` to `pending`
  - For weak evidence: create evidence-improvement stories (add scenario, strengthen seam)
  - For sentinel regressions: create regression-fix stories with CRITICAL priority
  - Revise `roadmap.md` to add a follow-up iteration for the gaps
- **If clean** (all tiers pass, evidence is adequate):
  - The iteration is confirmed done
  - Return clean signal to the orchestrator

### 5. Return control

Return the audit result (clean or gaps) to the orchestrator. The orchestrator decides whether to loop or terminate.

## Quick Reference

| Tier | What it checks | Failure means |
|---|---|---|
| Deep evidence | Every AC + proof obligation for current iteration | Story not done, evidence too weak |
| Impacted behavior | Scenarios whose surfaces were touched | Stale or broken scenario |
| Sentinel corpus | High-value journey scenarios | Regression in previously-working behavior |

| Reads | Writes | Dispatches |
|---|---|---|
| `requirements/`, `behavior-scenarios.md`, `behavior-corpus.md`, product code/tests | `requirements/` (gaps), `roadmap.md` (new iteration) if gaps, `behavior-scenarios.md` (stale flags) | **Two** auditor subagents in parallel (PAR) |

## References

- `skills/shared/parallel-adversarial-review.md` — PAR methodology
- `skills/shared/par-reviewer-wrapper.md` — competitive framing wrapper
- `skills/shared/behavior-evidence-formats.md` — scenario and proof obligation formats
- `auditor-subagent-prompt.md` — auditor-specific prompt template