parallel-hardening-loop

If you were dispatched as a subagent to execute a specific task, skip this skill entirely.

Parallel Hardening Loop

Use this skill for "review hard, then fix hard" work.

It is optimized for requests like:

• "Do a crazy parallel review"
• "What is broken?"
• "What is not world class yet?"
• "What is preventing this from being a world-class OSS project?"
• "Now fix it in priority order"
• "Review the last week / this PR / this branch / the working tree"

Core Contract

1. Review first, do not guess.
2. Read before judging.
3. Verify before claiming.
4. Findings come before summary.
5. Split confirmed bugs from quality gaps and OSS maturity blockers.
6. If the user wants fixes, convert the findings into a remediation loop instead of stopping at analysis.
7. Use as many parallel agents as the current session and user permission allow. If delegation is not allowed, run the same loop locally.
8. Treat any late local coordinator patch after review findings as a fix wave that requires another adversarial review.
9. Do not report from a stale pre-build snapshot. Final status must come after the last build, pack, benchmark, artifact refresh, or readiness check.
10. Leave a short run-log digest for repeat loops so the skill improves from actual failures instead of memory.

Scope First

Anchor the review before launching agents:

• working tree: inspect git status --short and git diff --stat
• recent changes: inspect git log --since='7 days ago' --name-only --stat
• branch diff: inspect git diff --name-only <base>...HEAD
• PR review: inspect changed files and PR metadata first

Prefer exact files and dates over vague scope. If the user says "past week", treat that as a bounded recent-change review and use concrete git history to define the slice.

Loop

1. Baseline locally

Do the immediate blocker work yourself before delegating:

• identify the review window
• list touched files
• spot obvious subsystems and risk clusters
• run the cheapest relevant validation commands if they establish ground truth
• check .claude/reports/ for an existing same-day or same-branch deep-audit-YYYY-MM-DD.md. If one exists and the touched files overlap the audited scope, reuse its verified Tier 1-4 findings instead of re-reviewing. This is the canonical input to step 4.

2. Launch the review wave

The review phase is owned by the deep-audit skill. Do not reinvent its reading + verification waves. Choose one of:

• Full repo / large recent-change scope — invoke deep-audit end to end. It runs Phase 0 preflight (scripts/preflight.sh → .audit/preflight/findings.json), canary-gated readers, telemetry-injected verifiers, blind judges, and writes .claude/reports/deep-audit-YYYY-MM-DD.md. Use this as the queue.
• Bounded scope (PR, branch diff, working tree) — run deep-audit with the slice list narrowed to touched files. Keep its discipline: preflight first, canary reader, mandatory Bug Verifier, file:line evidence on every confirmed finding, persistent report file. Do not skip Phase 0 — bounded scopes still benefit from deterministic ground truth.
• Same-day report already exists — skip review entirely; load the existing report and jump to step 3.

The fix-wave topology in references/agent-topology.md applies to remediation only. Review topology is deep-audit's.

Keep the critical path local. Do not delegate the very next blocking action.

3. Report findings

Use the output contract in references/report-format.md. When deep-audit ran, prefer citing its tiered findings and scorecard verbatim — do not paraphrase verified evidence.

Rules:

• findings first, ordered by severity
• include file references (every confirmed finding has file:line and quoted code, per deep-audit's contract)
• state the real failure mode or trust gap
• distinguish:
  • confirmed bugs (deep-audit Tier 1)
  • correctness risks (deep-audit Tier 2)
  • "not world class yet" gaps (deep-audit Tier 3)
  • blockers to world-class OSS trust (deep-audit Tier 4)
• carry forward deep-audit's scorecard so "what is not world class yet" is answered with per-dimension evidence, not prose

4. Convert findings into action

If the user asks what to do next, produce a priority-ordered plan. When deep-audit produced a .claude/reports/deep-audit-YYYY-MM-DD.md, its Tier 1 → Tier 4 ordering is the queue. Otherwise:

1. destructive or user-harming bugs
2. correctness and truthfulness gaps
3. concurrency and recovery hazards
4. test and validation gaps
5. docs, UX, discoverability, and OSS maturity gaps

Always include:

• risk if left unfixed
• likely implementation cost
• logic change required
• user or maintainer benefit

5. Run the remediation loop

If the user wants implementation, switch immediately into the hardening loop in references/remediation-loop.md.

Key rules:

• assign disjoint write scopes to worker agents
• keep integration and final judgment local
• add regression coverage for every confirmed bug
• rerun the narrow lane first, then the broader lane
• do one final adversarial review sweep before calling the work done
• if the final sweep times out or the preferred reviewer is unavailable, run a substitute read-only review or report that as a blocker
• if a validation command rebuilds or mutates generated artifacts, rerun artifact drift and readiness checks after that command
• inspect recent logs before final sign-off and record any missed guardrails, retries, and process fixes

Practical Defaults

• Prefer 8-16 parallel review lanes when the session budget allows it.
• Prefer 3-6 fix lanes only after the review has converged.
• Use explorers for bounded codebase questions.
• Use workers for owned implementation slices.
• Reuse existing agent results instead of re-reading the same area twice.

Done Criteria

Do not stop at "here are some ideas." The loop is done only when one of these is true:

• the user explicitly wants analysis only
• the confirmed findings are fixed and validated
• a blocker remains and you can state exactly what prevents the next step

If the repo is still not world-class after the first pass, say what remains and start the next highest-leverage loop instead of pretending the job is finished.