init

When to use it

Run /impeccable init once at the start of a project. It is the onramp. Without it, every other command will produce design that is technically competent but generically toned: stock SaaS voice, safe-default fonts, the AI color palette. With it, every command reads your answers before it generates.

Reach for it when:

• You just installed Impeccable in a new project. First thing to run. Other commands will nudge you toward it if you skip.
• The project’s brand direction has shifted. New positioning, new audience, new voice. Re-run init and the updated context flows through every command.
• Another command said “no design context found” and stopped. That is the signal: run init, then resume.

How it works

One codebase crawl feeds everything init writes:

• PRODUCT.md is the strategic file. Register (brand or product), target users, product purpose, brand personality, anti-references, design principles, accessibility needs. Answers “who, what, why”.
• DESIGN.md is the visual file. Colors, typography, elevation, components, do’s and don’ts. Answers “how it looks”. Written by the delegated /impeccable document command, which init invokes at the end.
• Live mode config. Since the same crawl already knows your framework and entry files, init pre-configures /impeccable live so it opens straight into variant mode with no first-time setup.

The flow scans the codebase first (README, package.json, components, tokens, brand assets) and forms a register hypothesis: brand (landing, marketing, portfolio, where design IS the product) or product (app UI, dashboards, tools, where design SERVES the product). Register is the first question, because it shapes every downstream answer: typography defaults, motion energy, color strategy, the reference set commands like /impeccable typeset pull from. After register, init asks only what it could not infer: users, personality in three real words, references and anti-references, accessibility requirements.

PRODUCT.md is strategic only. No colors, no fonts, no pixel values. Those live in DESIGN.md. Keeping the two files separate is deliberate: strategy can stay stable while the visual system evolves.

It closes by pointing you at the best commands to run next, picked from what the scan turned up: craft or shape for new work, critique or audit for what is already there, live to iterate visually. No guessing where to begin.

Try it

/impeccable init

Expect a 5 to 8 minute interview. The first question is usually about register; the rest are short. Init will quote back what it inferred from your code (“from the routes, this looks like a product surface, match?”) so you are confirming, not starting from scratch.

Along the way it offers to run /impeccable document for you. Say yes unless you have a specific reason to hold off. A real DESIGN.md is what keeps variants, polishes, and audits on-brand.

Pitfalls

• Skipping it to “just try a command quickly”. Every other command will interview you mid-flight instead. Running init first is faster, not slower.
• Giving generic answers. “Modern and clean” is not useful. “Warm, mechanical, opinionated” is. Be specific. Be willing to disagree with safe defaults.
• Treating PRODUCT.md as immutable. The file is yours. If init put something in there that is not quite right, edit it. Every command reads the current file.
• Listing only adjectives for references. Brands, products, printed objects: named, not described. “Klim Type Foundry specimen pages”, not “technical and clean”. Anti-references should be equally specific.