improve-code-quality

What it does

Guided journey from a working-but-untested vibe-coded prototype to a production-ready product with tests, clean structure, a business-rules boundary, and resilience at scale. Orchestrates nine skills phase by phase and records results in the project docs/ folder (TESTING.md, TECH-DEBT.md, RELIABILITY.md, IMPROVE-CODE-QUALITY-PLAN.md) so the journey resumes across sessions. Use when the user wants to harden an AI-generated prototype, add tests before refactoring, make code safe to change, or says ''this works on my machine but I am scared to touch it''. For a large aged codebase, use remove-technical-debt; to decide structure before building, use design-code-architecture; for a product and UX pass, use improve-app. For one framework in isolation, invoke that skill directly.

How it works

• The skill defines a nine-phase journey where each phase is handled by a specific sub-skill (e.g., working-with-legacy-code, clean-code, refactoring-patterns, etc.).
• Before each phase, it asks the user to decide entry points and confirms the phase plan, resuming from an existing tracker if available.
• Phase 1 creates docs/TESTING.md and docs/TECH-DEBT.md as safety nets; subsequent phases extend docs files (e.g., docs/TECH-DEBT.md, docs/ARCHITECTURE.md, docs/RELIABILITY.md) with phase-specific artifacts.
• Phase invocation follows the slug of the phase (e.g., invoke working-with-legacy-code, clean-code, refactoring-patterns, etc.). If a phase tool is unavailable, the user can install it via npx skills add wondelai/skills/<slug> --global.
• Each phase requires decisions to be recorded in a tracker with Key Decisions and Next Actions, and a draft artifact is presented for sign-off before writing.
• Phase 1 is a gate; changes to code absent from the Safety Net Map are not allowed. Commits are single-purpose per phase, especially during refactors with tests green.

When to use it

• When the user wants to harden an AI-generated prototype, add tests before refactoring, make code safe to change, or address fear around touching working code.
• For a large aged codebase, use remove-technical-debt; to decide structure before building, use design-code-architecture; for a product and UX pass, use improve-app. For a single framework in isolation, invoke that skill directly.

What it can touch

• The skill references creating and extending docs/ files: TESTING.md, TECH-DEBT.md, ARCHITECTURE.md, RELIABILITY.md, IMPROVE-CODE-QUALITY-PLAN.md, and possibly others under docs/.
• It invokes phase-specific skills by slug (e.g., working-with-legacy-code, clean-code, refactoring-patterns, software-design-philosophy, clean-architecture, pragmatic-programmer, release-it, system-design, ddia-systems).

Caveats

• Requires tracker existence to resume; intake creates IMPROVE-CODE-QUALITY-PLAN.md with phase statuses.
• Phase progress depends on user decisions; skipping or deferring follows defined rules. Phase 1 must pin behavior before later phases touch code.
• Artifacts are created or extended in docs/ with uppercase section headings per artifact templates; each phase adheres to single-purpose commits when possible.