compact-dev-environment

Consolidate invariants, specs, tests, and feedback in a plugin development repository.

Updated Jul 13, 2026
One-click install
npx skills add https://github.com/docktermj/senzing-bootcamp-claude-plugin-development --skill compact-dev-environment-docktermj
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: compact-dev-environment
Source: https://github.com/docktermj/senzing-bootcamp-claude-plugin-development/tree/main/.claude/skills/compact-dev-environment
Command: npx skills add https://github.com/docktermj/senzing-bootcamp-claude-plugin-development --skill compact-dev-environment-docktermj

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Maintainer documentation for a Claude Code plugin accumulates overlapping invariants, stale specs, redundant test traversals, and stale feedback over time, and cleaning it up naively breaks thousands of cross-references. This Skill compacts those four asset classes without losing the reasoning future development depends on. ## Core Features & Use Cases - Citation census and referential integrity: Runs citations.py census and verify to map every INV-NNN citation across plugin text, specs, tests, and skills before any change is proposed. - Invariant triage: Sorts each invariant into load-bearing, mergeable, superseded, unenforced, or not-an-invariant, merging duplicates into new IDs while keeping old citations resolvable. - Spec, test, and feedback assessment: Archives misleading specs without deleting provenance, merges test traversals without merging assertions, and prunes feedback archives only when the append-only ledger stays intact. - Use Case: A maintainer notices INVARIANTS.md has grown unwieldy and asks to tidy the dev environment; the Skill produces a report-first plan with before/after citation counts, then executes only the confirmed mechanical changes. ## Quick Start Ask the assistant to compact the Senzing Bootcamp plugin development environment and consolidate the invariants.

Frequently Asked Questions about compact-dev-environment

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I consolidate duplicate invariants without breaking citations?▼

Merge the duplicates into one new invariant at the next free ID and mark both originals as superseded. Every existing citation still resolves to something true, and the file gets shorter without renumbering.

How do I check referential integrity before cleaning up specs?▼

Run citations.py census to see what cites what, then citations.py verify to confirm every cited invariant exists, every Source spec resolves, and every feedback archive is in the ledger. Re-run verify after every change.

Why should invariant IDs never be renumbered?▼

Hundreds of INV-NNN citations live in immutable git commit messages. After a renumber those citations silently resolve to different real invariants, which is worse than dangling references because nobody notices the misdirection.

Can I delete old spec files to reduce clutter?▼

Deleting specs is almost never warranted because IMPLEMENTED.md is the actual reading burden and specs are read one at a time. Archive misleading specs with a dated supersession note; only never-implemented specs are delete candidates.

When should test files be consolidated?▼

Consolidate only when one file genuinely re-reads the corpus for checks that belong together, never for speed. Combine the traversal into one walk with independent subTest assertions so failure messages still name which check failed on which file.

Is the feedback ledger safe to prune?▼

PROCESSED.jsonl is append-only and never pruned because dropping a line makes old feedback re-processable. Archived markdown files may be pruned once every entry they carry has a disposition in the ledger.