coverage-redolisted

Re-audit and reconcile a repo that was already onboarded with an OLDER version of this kit, and apply every kit update since. Use when a repo already has a coverage-manifest.yml, generated tests, and a report, and you want to redo/re-run/recheck/reconcile/upgrade/migrate it against the current rules, or to pull in new kit features (latent-bug backlog, vendored-path scoping, baseline scope_lines, dated reports, structured carve-outs): works out the version delta from MIGRATIONS.md and applies it, re-sweeps to spot misclassifications (false exclusions such as DbContext-injected services wrongly frozen, mixed folders collapsed to one glob), corrects the manifest in place, migrates it to the current schema, generates tests only for the newly-found gaps while keeping existing tests intact, and writes a fresh report. Triggers: 'the new dotnet-coverage-kit has new updates, review and apply it to this repo', 'apply the kit updates to this repo', 'the kit was updated', 'upgrade the kit here', 'redo coverage', 're-run
livlign/claude-skills · ★ 18 · Testing & QA · score 76

Install: claude install-skill livlign/claude-skills

# coverage-redo Reconcile a repo that an EARLIER kit version already onboarded. It re-runs the classification against today's rules, corrects the existing manifest rather than replacing it, migrates it to the current schema, fills only the gaps in test coverage, and regenerates the report. It is the idempotent successor to `coverage-init` for repos that already have a manifest, tests, and a report. It is also the **kit-upgrade entry point**. "The kit has new updates, review and apply them to this repo" is this skill, run as a version delta: step 1 works out which kit changes this repo has not picked up (from `MIGRATIONS.md`) and the rest of the steps apply them. There is no separate upgrade command and no per-feature request to make: every change since the repo's recorded `kit_version:` is in scope for one run. Use `coverage-init` instead when there is NO manifest yet (greenfield). Use this skill when a manifest exists and may be stale, because the classification rules have improved since it was written (for example: a constructor-injected `DbContext` is now a testable seam, not an `integration-scope` exclusion; mixed files must be per-file structured carve-outs, not one folder glob). ## Non-negotiables These are what make a redo safe to run on a live repo: 1. **Existing tests are kept intact and reused.** Never delete, rewrite, or "regenerate" a test that already exists and passes. The backfill only ADDS tests for spots that are newly in scope and not already cov