Hardening codebase
Skill qte77/claude-code-plugins/plugins/codebase-tools/skills/hardening-codebase
A Claude Code plugin marketplace providing skills, rules, and scripts extracted from a production development workflow.
npx -y skills add qte77/claude-code-plugins --skill hardening-codebaseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Audit and tighten codebase quality gates — architecture, lint, types, tests, docs, code review. Use when onboarding a project, before a release, or when validation is too permissive.
SKILL.md
4.3 KB, as published. Nobody here has run it
Harden Codebase
Scope: $ARGUMENTS (default: full)
Systematic quality tightening. Nine phases, each with a clear gate. KISS: tighten one level at a time — never jump to max strictness.
Phase 1: ARCHITECTURE (read-only)
- Identify entry points, module boundaries, and dependency flow
- Map layering: which modules depend on which?
- Flag circular dependencies and boundary violations
- Output module map as indented text tree (plain markdown, no diagrams)
- Note undocumented coupling, god modules, misplaced responsibilities
Gate: Module map + issue list. Present to user before proceeding.
Phase 2: AUDIT (read-only)
- Does
make setup_all(or equivalent) work from scratch? - What lint rules are enabled? Gap vs recommended?
See
references/lint-tightening-checklist.md - Type checker strictness level?
- Do tests pass? Are slow/hardware tests filtered?
- Is check-only gate separate from auto-fix?
Gate: Issue list ranked HIGH/MEDIUM/LOW. Present to user before proceeding.
Phase 3: TIGHTEN (config only — no code changes)
- Enable next-level lint rules (baseline → recommended, not strict)
- Bump type checker one level
- Split auto-fix from check-only gate if missing
- Add test marker filters for slow/hardware/network
- Count new violations — report before fixing
Gate: Config committed. Violation count known.
Phase 4: FIX (mechanical)
- Run auto-fix
- Fix remaining violations manually
- Update tests broken by signature changes
make validatemust pass
Gate: All checks green. Commit fixes.
Phase 5: DOCS QUALITY
- Does README exist and reflect current state?
- Are public APIs documented (docstrings, JSDoc, rustdoc)?
- Are architecture decisions recorded (ADRs or equivalent)?
- Do inline comments explain why, not what?
- Are there stale/misleading docs that contradict the code?
- Enforce KISS in docs — no walls of text, no redundant sections
- Enforce DRY — single source of truth, no copy-pasted explanations
- Enforce YAGNI — remove docs for features that don't exist
Gate: Docs findings list. Present to user before fixing.
Phase 6: TEST OVERHAUL (meaningful tests only)
- Classify every test: behavioral / implementation / trivial
- Rewrite implementation tests as behavioral (assert outcomes, not internals)
- Delete trivial tests that add no value
- Add missing behavioral tests for error recovery, state transitions, edge cases
- Add property-based tests (Hypothesis) for invariants
- Add complexity gate (complexipy, max 15/function)
make validatemust pass with coverage gate
Gate: All tests behavioral. Coverage ≥ 80%. Complexity ≤ 15.
Phase 7: REVIEW (4 parallel agents)
Launch all four from references/review-agents.md:
- Reuse: duplication, missing shared helpers
- Quality: boundary violations, magic strings, abstractions, bugs
- Efficiency: unnecessary work, missed caching
- KISS/DRY/YAGNI: over-engineering, dead code, speculative features, deletion candidates
Gate: Ranked findings presented to user.
Phase 8: REFACTOR (apply findings)
- Fix HIGH and MEDIUM only (80/20)
- Skip LOW unless trivial
make validateafter each fix- Commit by topic
Gate: All checks green. Findings addressed.
Phase 9: SHIP
- Push branch
- Create PR with summary + test plan
Scope shortcuts
arch— Phase 1 only (architecture research + module map)audit— Phase 2 only (read-only report)tighten— Phases 2-4 (config + fix)docs— Phase 5 only (docs quality)tests— Phase 6 only (test overhaul)review— Phase 7 only (4-agent review)fix— Phase 8 only (apply existing findings)full— All phases
References
See references/lint-tightening-checklist.md for language-specific
rule progressions and references/review-agents.md for agent prompts.