greenloop

Greenloop adversarial challenger (app-audit Phase 4.5). Given a single finding and the code it cites — but NOT the reasoning that produced it — tries to REFUTE it. Use to blind-challenge findings before delivery. Read-only.

Greenloop concurrency reviewer (app-audit Category 5: concurrency and race conditions). Use when app-audit dispatches parallel reviewers. Read-only; emits findings.

Greenloop data-integrity reviewer (app-audit Categories 1 & 2: schema integrity + data flow). Use when app-audit dispatches parallel reviewers. Read-only; emits findings.

Greenloop operational-readiness reviewer (app-audit Categories 8 & 10: operational readiness + diagnosability). Use when app-audit dispatches parallel reviewers. Read-only; emits findings.

Greenloop reliability reviewer (app-audit Categories 4 & 6: error handling + resource bounds/performance). Use when app-audit dispatches parallel reviewers. Read-only; emits findings.

Address findings from a completed app-audit run, in safe order, with per-fix verification. Use whenever the user asks to fix the audit findings, address them, work through them, or run audit-fix. Reads AUDIT_LOG.md; uses cartographer's call graph (stage 4) to order fixes by blast radius — pure-local first, large-blast-radius last, critical severity prioritized within each tier. Runs pre-commit-verification after each fix; reverts and stops on failure. Every fix is graded with a 0–1 truth score against an environment threshold (dev 0.90 / PR 0.95 / release 0.99) — below threshold, evidence is strengthened or the fix rolls back. Proof-tests are authored blind (from the finding + spec, never the fix diff). PR-scoped runs isolate fixes in a git worktree and use Conventional Commits. Closes with a tamper-proof clean-room re-run in a fresh worktree. Refreshes cartographer and re-runs app-audit on the full original scope when done.

Build and maintain a persistent codemap (.codemap/*.json — structure, dependencies, functions, warnings) of any codebase. Function-level extraction runs in four stages — tags, spec_refs, qualified names + git blame default-on; call graph opt-in. Use whenever the user asks to build, refresh, or rebuild the codemap; to map the code; to find duplicate, stale, or unused files; to ask "what's impacted if I change X" (forward/backward impact analysis over the call graph, spec sections joined in); or as part of an audit (app-audit Phase 0.5). Incremental refresh after the first full build. Works on any language.

Use this skill whenever the user asks to verify, test, check, validate, or confirm their repo before committing or pushing — including requests like "do a pre commit verification", "run local tests before push", "deep local verification", "fix everything and test it", "make sure this is ready", or "run the full verification pass". Covers stack-aware test discovery, unit/integration/e2e tests, smoke tests, lint checks, type checks, builds, and a runtime smoke/integration harness (binary-launch, migration idempotency, provider mocks, headless webview + browser verification for web UIs, env probe). Supports a tamper-proof clean-room mode (re-run in a fresh worktree of HEAD so uncommitted state can't rig the verdict), an Ed25519-signed witness manifest for tamper-evident green results, and per-check reliability tracking across runs (pass³) that exposes flaky checks instead of retrying them green. Do NOT use for a single narrow test unless explicitly requested.

Reconstruct a design spec (SPEC.md) for a codebase that doesn't have one — derive observed behavior from the code, interview the user to separate intent from accident, and produce a section-numbered, provenance-marked spec that app-audit can generate its checklist from. Use when the user asks to write or create a design spec, document what the app should do, or formalize requirements for an existing app — and automatically when app-audit Phase 1 finds no spec. Every statement is marked [confirmed] / [observed] / [assumed] so audits know how much to trust each claim. Optional formal surface: EARS-form requirements and Gherkin scenarios (which seed the acceptance map), architectural decisions captured as ADRs, and a C4-style context/container diagram generated from cartographer's codemap.

3 hooks across 3 events