coverage-redo

Name: coverage-redo
Author: livlign

18stars1forks

How to install coverage-redo?

livlign/claude-skills/coverage-redo

$npx -y skills add livlign/claude-skills --skill coverage-redo

Installs into the current project.

Summary

Re-audit and reconcile a repo that was already onboarded with an OLDER version of this kit. 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 classification rule

Files · 1

View on GitHub

SKILL.md

1	# coverage-redo
2
3	Reconcile a repo that an EARLIER kit version already onboarded. It re-runs the classification
4	against today's rules, corrects the existing manifest rather than replacing it, migrates it to
5	the current schema, fills only the gaps in test coverage, and regenerates the report. It is the
6	idempotent successor to `coverage-init` for repos that already have a manifest, tests, and a
7	report.
8
9	Use `coverage-init` instead when there is NO manifest yet (greenfield). Use this skill when a
10	manifest exists and may be stale, because the classification rules have improved since it was
11	written (for example: a constructor-injected `DbContext` is now a testable seam, not an
12	`integration-scope` exclusion; mixed files must be per-file structured carve-outs, not one
13	folder glob).
14
15	## Non-negotiables
16
17	These are what make a redo safe to run on a live repo:
18
19	1. Existing tests are kept intact and reused. Never delete, rewrite, or "regenerate" a test
20	that already exists and passes. The backfill only ADDS tests for spots that are newly in
21	scope and not already covered. A reclassification that would orphan an existing test is
22	reported for a human to resolve, never actioned by deleting the test.
23	2. Correct the manifest, do not rewrite it. Preserve the human-curated content: the
24	`baseline`, the `gate` thresholds, intentional gray-zone exclusions, and every carve-out that
25	is still valid. Produce a reviewable DIFF of changes with a reason each, not a fresh file.
26	3. Migrate the schema. Convert legacy `CARVE-OUT:` prose to structured `carve_outs:`, split
27	any carve-out-bearing folder glob or multi-file pattern into per-file entries (the gate warns
28	on these), and recategorize stale `cannot_test` entries to the canonical natures, adding the
29	now-required `mitigation`.
30	4. Never silently move the ratchet. Bringing newly-found testable code into scope grows the
31	Adjusted denominator and can lower the recorded coverage. The re-baseline decision is explicit
32	and human-gated (step 8). Lowering the floor is a reviewed change, never automatic.
33	5. Stop for human confirmation of the corrected manifest BEFORE generating any test (step 6).
34	Generating tests off an unreviewed reclassification is exactly the mistake this skill exists
35	to fix.
36
37	## Preconditions
38
39	Same as `coverage-init`: run on the production branch (master), fast-forwarded to the remote,
40	with a clean working tree. Additionally:
41
42	- A manifest must already exist at `.claude/coverage/refs/coverage-manifest.yml`. If not,
43	stop and tell the user to run `coverage-init` instead.
44	- The existing suite must be green. Run it first. A reconciliation built on a red suite is
45	untrustworthy, and you cannot tell a real gap from a pre-existing failure. If red, stop and
46	report the failures.
47	- Refresh the installed kit files. Copy the current `scripts/` (`coverage-gate.py`,
48	`run-coverage.sh`, `report.sh`) and `templates/coverage.runsettings` into
49	`.claude/coverage/tools/` and `refs/` if they differ from the kit, so the gate and report use
50	the corrected logic. Do not touch the repo-owned `coverage-manifest.yml` or `unit-testing.md`
51	here; those are reconciled in step 5.
52
53	## Steps
54
55	1. Detect the prior state. Record what exists: the manifest (and any `schema_version`), the
56	test projects and roughly how many tests, the last report, and, if discoverable, which kit
57	version produced them. Note whether the manifest uses legacy prose `CARVE-OUT:` (a v1 signal)
58	and whether any exclusion is a folder glob carrying carve-outs (an ambiguity the current gate
59	flags).
60
61	2. Re-sweep the whole repo. Run the classification sweep EXACTLY as `coverage-init` step 4:
62	enumerate every source file, clear `coverage/sweep/`, write `files.json`, and run the
63	`coverage-sweep` workflow at a user-chosen parallelism with the CURRENT rubric (the table in
64	`coverage-init`, including the exclusion-signal principle and the DbContext-seam note). This
65	is what surfaces the misclassifications the old manifest baked in. The sweep is read-only on
66	source.
67
68	3. Diff the sweep against the existing manifest (single, at main). Read the o

People who liked this also viewed

6 picks

Type

coverage-redo

18stars1forks

View on GitHub

How to install coverage-redo?

livlign/claude-skills/coverage-redo

$npx -y skills add livlign/claude-skills --skill coverage-redo

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# coverage-redo
2
3	Reconcile a repo that an EARLIER kit version already onboarded. It re-runs the classification
4	against today's rules, corrects the existing manifest rather than replacing it, migrates it to
5	the current schema, fills only the gaps in test coverage, and regenerates the report. It is the
6	idempotent successor to `coverage-init` for repos that already have a manifest, tests, and a
7	report.
8
9	Use `coverage-init` instead when there is NO manifest yet (greenfield). Use this skill when a
10	manifest exists and may be stale, because the classification rules have improved since it was
11	written (for example: a constructor-injected `DbContext` is now a testable seam, not an
12	`integration-scope` exclusion; mixed files must be per-file structured carve-outs, not one
13	folder glob).
14
15	## Non-negotiables
16
17	These are what make a redo safe to run on a live repo:
18
19	1. Existing tests are kept intact and reused. Never delete, rewrite, or "regenerate" a test
20	that already exists and passes. The backfill only ADDS tests for spots that are newly in
21	scope and not already covered. A reclassification that would orphan an existing test is
22	reported for a human to resolve, never actioned by deleting the test.
23	2. Correct the manifest, do not rewrite it. Preserve the human-curated content: the
24	`baseline`, the `gate` thresholds, intentional gray-zone exclusions, and every carve-out that
25	is still valid. Produce a reviewable DIFF of changes with a reason each, not a fresh file.
26	3. Migrate the schema. Convert legacy `CARVE-OUT:` prose to structured `carve_outs:`, split
27	any carve-out-bearing folder glob or multi-file pattern into per-file entries (the gate warns
28	on these), and recategorize stale `cannot_test` entries to the canonical natures, adding the
29	now-required `mitigation`.
30	4. Never silently move the ratchet. Bringing newly-found testable code into scope grows the
31	Adjusted denominator and can lower the recorded coverage. The re-baseline decision is explicit
32	and human-gated (step 8). Lowering the floor is a reviewed change, never automatic.
33	5. Stop for human confirmation of the corrected manifest BEFORE generating any test (step 6).
34	Generating tests off an unreviewed reclassification is exactly the mistake this skill exists
35	to fix.
36
37	## Preconditions
38
39	Same as `coverage-init`: run on the production branch (master), fast-forwarded to the remote,
40	with a clean working tree. Additionally:
41
42	- A manifest must already exist at `.claude/coverage/refs/coverage-manifest.yml`. If not,
43	stop and tell the user to run `coverage-init` instead.
44	- The existing suite must be green. Run it first. A reconciliation built on a red suite is
45	untrustworthy, and you cannot tell a real gap from a pre-existing failure. If red, stop and
46	report the failures.
47	- Refresh the installed kit files. Copy the current `scripts/` (`coverage-gate.py`,
48	`run-coverage.sh`, `report.sh`) and `templates/coverage.runsettings` into
49	`.claude/coverage/tools/` and `refs/` if they differ from the kit, so the gate and report use
50	the corrected logic. Do not touch the repo-owned `coverage-manifest.yml` or `unit-testing.md`
51	here; those are reconciled in step 5.
52
53	## Steps
54
55	1. Detect the prior state. Record what exists: the manifest (and any `schema_version`), the
56	test projects and roughly how many tests, the last report, and, if discoverable, which kit
57	version produced them. Note whether the manifest uses legacy prose `CARVE-OUT:` (a v1 signal)
58	and whether any exclusion is a folder glob carrying carve-outs (an ambiguity the current gate
59	flags).
60
61	2. Re-sweep the whole repo. Run the classification sweep EXACTLY as `coverage-init` step 4:
62	enumerate every source file, clear `coverage/sweep/`, write `files.json`, and run the
63	`coverage-sweep` workflow at a user-chosen parallelism with the CURRENT rubric (the table in
64	`coverage-init`, including the exclusion-signal principle and the DbContext-seam note). This
65	is what surfaces the misclassifications the old manifest baked in. The sweep is read-only on
66	source.
67
68	3. Diff the sweep against the existing manifest (single, at main). Read the o

People who liked this also viewed

6 picks

Type