Improve Code Quality
Vibe-coded prototype → production-ready code
Takes you 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. It orchestrates nine skills phase by phase, asking you the decision questions at every step and recording every result in your project's docs/ folder so the journey resumes across sessions.
npx skills add wondelai/skills/improve-code-quality --global - 01
Can I change this code without breaking it unknowingly? gate
Legacy Code → docs/TESTING.md + docs/TECH-DEBT.md - 02
Is this readable to the next person (and agent)?
Clean Code → docs/TECH-DEBT.md - 03
Can I reshape structure without changing behavior?
Refactoring → docs/TECH-DEBT.md - 04
Is complexity hidden behind deep modules?
Software Design → docs/TECH-DEBT.md - 05
Do business rules depend on the framework, or vice versa?
Clean Architecture → docs/ARCHITECTURE.md - 06
What habits keep it clean after we stop?
Pragmatic Programmer → docs/TECH-DEBT.md - 07
Will it survive a hostile production?
Release It! → docs/RELIABILITY.md - 08
Is it sized for the load we actually have?
System Design → docs/ARCHITECTURE.md + docs/RELIABILITY.md - 09
Is the data layer correct and durable under concurrency?
Data-Intensive Apps → docs/ARCHITECTURE.md
Each phase asks the question, then writes the answer before the next one starts.
The long read behind the phases: From Vibe-Coded Prototype to Production-Ready Product
02 What it is
What is the Improve Code Quality journey?
Prototypes that work are not products that survive. Nine phases take vibe-coded code to production: characterization tests first, then readability, structure, deep modules, a business-rules boundary, sustaining habits, production hardening, honest sizing and a durable data layer — with each decision recorded in docs/ so the work spans sessions.
03 In practice
Take a Vibe-Coded Prototype to Production
The demo works. The code was written by vibes.Launch is in six weeks.
This repo is a working prototype built fast and untested. Run the improve-code-quality journey: safety net first, then readability, structure, production hardening, and honest scaling decisions. Structural and behavioral changes in separate commits.
Use improve-code-quality skill.
Written to your repo
- docs/TESTING.md
- docs/TECH-DEBT.md
- docs/ARCHITECTURE.md
- docs/RELIABILITY.md
- docs/IMPROVE-CODE-QUALITY-PLAN.md journey tracker
Stop anytime. The tracker records which phases are done and which decision is next, so a new session opens at the unanswered question.
04 Prompts
Say it like this.
Name the journey at the end of a prompt and it takes over from phase one. Say it again in a later session and it resumes at the unanswered question.
I vibe-coded this app in a weekend — make it production-ready. using improve-code-quality skill
Run the code-quality journey on this repo, safety net first. using improve-code-quality skill
Resume hardening this codebase from the tracker. using improve-code-quality skill
05 Fit
One prompt runs it.
Every phase asks before it acts, and every decision lands in your project's docs/ folder as a living document.
Reach for it when
Take an AI-generated or hackathon prototype to production
Put untested code under characterization tests before touching it
Raise code quality without mixing refactors and behavior changes
Add timeouts, circuit breakers, and health checks before launch
Make honest scaling and data-layer decisions
Reach for something else when
The codebase is large, old and team-owned rather than a weekend build. Remove Technical Debt paces the work differently.
Nothing is written yet and the question is structure. Design Code Architecture decides boundaries before any code exists.
You just want naming and function length fixed in one module. Clean Code alone is the lighter tool.
The complaint is about the product’s experience, not its internals. Improve an App is the journey for that.
07 Questions
Before you install.
How do I install the Improve Code Quality journey?
Run npx skills add wondelai/skills/improve-code-quality --global. It takes about 30 seconds and needs no account. The Improve Code Quality skill then works in Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw and Hermes Agent — anything that reads the open agentskills.io format — and your agent loads it on its own when a task calls for it. It is free and MIT-licensed, and the source is at https://github.com/wondelai/skills.
Which skills does the Improve Code Quality journey run, and what does it produce?
It orchestrates 9 skills across 9 phases — Legacy Code, Clean Code, Refactoring, Software Design, Clean Architecture, Pragmatic Programmer, Release It!, System Design, Data-Intensive Apps — asking you one decision question per phase. Each answer is written to your project's docs/ folder (docs/TESTING.md, docs/TECH-DEBT.md, docs/ARCHITECTURE.md, docs/RELIABILITY.md, docs/IMPROVE-CODE-QUALITY-PLAN.md), so the journey survives across sessions and you keep the reasoning, not just the output.
What does the safety-net gate mean in practice?
Phase one will not let the journey change the shape of anything until the code you intend to touch is pinned by characterization tests — tests that record what it does today, bugs included, rather than what it should do. The result goes to docs/TESTING.md, with the still-unpinned regions listed in docs/TECH-DEBT.md. Refactoring without that net is how a working prototype becomes a broken one.
Nine phases is a lot. Where does most of the value land?
Usually in the first three and in Release It!. Legacy Code buys you the ability to change anything at all; Clean Code and Refactoring make the next month cheaper; Release It! is what stands between a demo and a hostile production — timeouts, circuit breakers, bulkheads, health checks. The Data-Intensive Apps phase matters most if you hold money, counters, or anything two users can write at once.
Should structural and behavioural changes go in the same commit?
No, and the journey is strict about it. Every refactoring phase separates the two: one commit reshapes structure with the tests green and behaviour unchanged, a different commit changes what the code does. That discipline is what makes review possible and lets you revert a mistake without unpicking a week of work. The rule sits in docs/TECH-DEBT.md next to the debt ledger.
My prototype is six months old and has real users. Is this still right?
Check the size first. This journey assumes a codebase small enough that nine phases can sweep most of it — a weekend build, a hackathon repo, an agent-generated MVP that found traction. If it has grown into something several people are afraid to touch, Remove Technical Debt is built for that: the same safety-net gate, but worked module by module while the team keeps shipping.
Nine skills, one deliberate order.
Run the whole journey with one prompt.
npx skills add wondelai/skills/improve-code-quality --global MIT licensed · Claude, Claude Code, Codex, Cursor, OpenClaw, Hermes · No account