Inherited code
Iterating on existing design.
You have an existing project. The design has accumulated over time — some of it works, some of it drifted, some of it never got the attention it needed. You want Spruce to help you see what's there and improve it without starting over.
Install Spruce alongside your project.
Run npx spruce-skill add from your project root. Spruce installs as a skill in your AI tool (Claude Code today; more harnesses coming). No code changes to your project — Spruce reads your codebase to reason, but doesn’t require you to restructure anything first.
When the install completes, you have access to all 25 commands across 5 tiers from your AI conversation interface.
› $ npx spruce-skill add
Installed Spruce skill. 25 commands available across 5 tiers (setup, discovery, generative, diagnostic, corrective). Run /spruce-up to set up project context, or run /detect to scan what's already in the codebase.
Set or import context.
If your project doesn’t already have a .spruce.md, run /spruce-up to create one. Even on existing codebases, the context file is what calibrates everything else — Spruce needs to know what the product is trying to be before it can tell you whether the existing design is on or off character.
If a context file exists, every command will read it automatically.
Bring in any existing user research.
Inherited codebases often come with prior research — interview notes, usability findings, persona documents the previous team wrote, survey data sitting in a Notion doc. Don’t leave it on the shelf. Run /personas and pick Mode B (structure your research) when it asks. Spruce accepts research in whatever shape you have it — paste transcripts, point at documents, describe findings — and structures whatever you provide into .personas.md. Each claim is labelled with its source: research-grounded, context-derived, or assumed.
Run /jtbd and /journey the same way for jobs and journey artifacts. If a previous team produced a finished persona file or journey map, pick Mode C (pressure-test) — Spruce reads it and challenges its assumptions against your .spruce.md context.
With Discovery artifacts in place, the diagnostics in the next beat get sharper — /audit becomes available, framing findings against named personas and the jobs they’re hiring the product to do rather than against general principles.
Assess what's there.
With context in place, run a diagnostic. The right starting lens depends on what you want to learn:
/detect— Fast scan for named anti-patterns and accessibility blockers. Best for triage — what's clearly broken or generic./survey— Comprehensive review with severity tiers. Best for shipping prep or full-project assessment./critique— Design-director read. Best when something feels off but you can't name it./audit— HCD-grounded findings tied to named personas and the jobs they're doing. Available once .personas.md and .jtbd.md exist.
Address from the outside in.
Reviews surface findings; the corrective tier addresses each layer. With existing code, the order matters: visible layers first (typography, color), then structural (spacing, components), then content (voice, state coverage).
The point isn’t to fix everything at once. Pick the highest-impact findings from the review, run the relevant corrective, review again to see what changed.
Iterate, then ship.
After the first round of correctives, re-review with the same diagnostic to see what changed and what remains. Refine again. The loop converges as findings drop in severity.
When you’re ready to deploy a milestone, run /finish for the final polish pass and a ship-readiness verdict.