From scratch
Starting from scratch.
You arrive with a new product idea. The codebase is empty or has barely begun. You want Spruce to help shape what you build, from the first decision onward — not as a styling layer applied later, but as design reasoning threaded through the whole project.
Set the context.
Run /spruce-up. Spruce asks five questions about your product — what it does, who uses it, what character it should have, how dense it should feel, what voice it should speak in. The answers compile into .spruce.md at the root of your project. Every command from this point reads it.
This is the only command that has to come first. Without context, the rest of Spruce’s reasoning has nothing to calibrate against.
› /spruce-up
What does this product do, and what's the core experience you want users to have?
› A short-session meditation app for parents — five-minute practices designed to fit into the gaps of a busy day.
Got it. Next: who uses it? What do you know about them?
Ground the work in users.
Optional but recommended. Run /personas to capture who the product is for; then /jtbd to articulate the jobs they’re hiring it to do. Spruce drafts both from your .spruce.md context — no research required. Every persona and job is labelled context-derived so downstream commands know to weight them as structured assumptions rather than research-grounded findings.
You can extend the Discovery tier as you go — /journey maps a specific persona doing a specific job through real touchpoints; /scenarios anchors decisions in concrete moments. Or skip them and add them later when a flow gets contested.
The Discovery artifacts live in .personas.md, .jtbd.md, and friends — sibling files alongside .spruce.md. From here, every generative and diagnostic command can ground its decisions in named users.
Establish the foundations.
With context (and optionally personas) in place, run /foundations. Spruce reads .spruce.md and generates the design tokens every other command will compose within: a type system calibrated to the character you described, a palette with the right temperature and accent strategy, a spacing scale, a small set of composed primitives.
The output is a specimen sheet you wire into your project’s CSS or design tokens. From here, the rest of the loop has a system to draw from.
Make the first call.
Foundations established. Time to design something. Spruce gives you three commitment levels for the work itself:
/decide <surface>— Spruce walks you through the significant decisions before generating./design <surface>— Spruce makes the calls and ships a first pass with notes on what was decided./remix <surface>— Spruce produces three distinct directions for the same brief.
Review what you made.
You have a designed surface. Now review it. Spruce offers four lenses, each with a different depth and a different question:
/detect— Fast anti-pattern scan. Names what's wrong, points to the corrective./survey— Comprehensive findings with severity tiers and an action plan./uxreview— UX substrate specifically — IA, feedback, forms, state coverage./critique— Design-director feedback at the level of feel and direction.
Refine through the loop.
Reviews surface what to address; the corrective tier handles each layer. /typeface for typography, /colorgrade for color, /arrange for spacing, and so on through the corrective tier.
The corrective and review tiers loop with each other. Refine based on what review surfaced; review again to see what changed; refine more. The loop runs as many times as the work needs.
Ship with a verdict.
When the loop has converged, run /finish. It runs a final polish pass — straight quotes to smart quotes, balance on headlines, focus-ring offsets — and produces an honest verdict on ship-readiness.
The verdict is the differentiator. Other commands produce work; /finish produces a call.
Ready to ship. With minor items noted.