SDTK-DESIGN

Turn ideas and specs into reviewable MVP screens before code

SDTK-DESIGN is the public local-first MVP design product in the suite. It creates design briefs, screen maps, design tokens, static prototypes, review reports, and SDTK-CODE-ready handoff artifacts without claiming to replace Figma, v0, Lovable, or production UI engineering.

Public packageLocal-first designStatic prototypesVisual Preview StudioStyle presetsSDTK-CODE handoff

sdtk-design — brief to wireframes

Real capture: brief, screen map, wireframes as reviewable files

> FROM IDEA TO REVIEWABLE PROTOTYPE

A static HTML prototype your AI coder can implement against — generated locally in minutes.

SDTK-DESIGN is the bridge between spec and code. It does not try to replace Figma, v0, or Lovable — it produces concrete, reviewable artifacts your downstream coding AI can read without ambiguity. Every step writes to your repo, not the cloud.

Step 1Raw idea
A one-paragraph MVP brief or an SDTK-SPEC handoff.
--idea "…" or --from-spec .
Step 2Screen map
AI picks core screens, infers navigation, lays out a flow.
docs/design/SCREEN_MAP.md
Step 3Design tokens
Visual style brief: colors, type, spacing, density — driven by a category-oriented style preset.
docs/design/DESIGN_SYSTEM.md
Step 4Static prototype
A working HTML/CSS prototype you can open in your browser and iterate on in the Preview Studio.
docs/design/prototype/index.html
Step 5Handoff to CODE
Bundled review evidence + spec for downstream implementation.
docs/design/DESIGN_HANDOFF.md

When a solo founder reaches for this

Saturday afternoon. SDTK-SPEC has produced a real plan and you know what to build. Run sdtk-design styles to browse the category-oriented presets — pick ecommerce-retail, fintech-trust, or whichever fits — then sdtk-design prototype to generate. Open the Preview Studio (sdtk-design preview), click through screens, drop an annotation, tweak a token slider live. On 'Send to agent' it writes a scoped DESIGN_FEEDBACK file and shows a copy-ready instruction — your open Claude session applies it. If SDTK-WIKI is installed, run sdtk-design open to jump straight to the Design tab in the wiki viewer — same style gallery, same pipeline, same annotate flow, all without leaving the viewer context. By dinner you have a static MVP screen set, scoped feedback applied, and a DESIGN_HANDOFF.md ready for SDTK-CODE.

Product truth

What this toolkit does today

These cards summarize the current shipped or internal surface exactly as it exists in the local source tree.

Idea-to-design workflow

Start from a rough MVP idea, generate the core design package, create a static prototype, review it, and hand it to SDTK-CODE as implementation planning input.

Spec-driven design bridge

When SDTK-SPEC has already produced a project handoff, SDTK-DESIGN can consume that spec context and build screen-level design artifacts before coding begins.

Visual Preview Studio

sdtk-design preview opens a local browser studio. Render prototype screens at desktop/tablet/phone widths, click to annotate elements, live-preview token tweaks on :root CSS variables without writing a file, then queue everything as a scoped DESIGN_FEEDBACK file — the studio never shells out or generates code itself.

Style Gallery

sdtk-design styles opens a read-only gallery of 7 category-oriented presets (SaaS, Dashboard, Marketing, Editorial, E-Commerce, Fintech). Each card shows color swatches, a type sample, and a summary. Click a card to copy the start --style command — no prototype needed.

Design tab in wiki viewer

When SDTK-WIKI is installed, the Design Prototype experience also runs inside the wiki viewer as a 4th tab — alongside Dashboard, Docs, and Graph. Pick a style preset from the gallery, enter a prompt, watch the pipeline stream live, then annotate elements in the embedded prototype. sdtk-design open opens the viewer directly to the Design tab.

Reviewable local artifacts

Human-facing output stays under docs/design while internal state stays under .sdtk/design. The product remains local, inspectable, and bounded.

Current command and workflow surface

Beginner idea flow

sdtk-design init

sdtk-design start --idea "<your MVP idea>" --style premium-dashboard

sdtk-design prototype --force

sdtk-design review --artifact docs/design/prototype/index.html

sdtk-design handoff

sdtk-design status

Spec-driven flow

sdtk-design start --from-spec . --profile b2b-commerce

sdtk-design prototype --force

sdtk-design review --artifact docs/design/prototype/index.html

sdtk-design handoff

sdtk-design status

Preview & iterate

sdtk-design styles # browse style presets before generating

sdtk-design preview # open Preview Studio after prototyping

sdtk-design open # open wiki viewer at Design tab (requires sdtk-wiki)

docs/design/feedback/ # scoped feedback files written here

Main outputs

docs/design/DESIGN_BRIEF.md

docs/design/SCREEN_MAP.md

docs/design/DESIGN_SYSTEM.md

docs/design/prototype/

docs/design/reviews/

docs/design/feedback/

docs/design/DESIGN_HANDOFF.md

.sdtk/design/

Runtime support

Runtime	Project	User	Notes
CLI	Yes	Package install	Runs locally in the target workspace and writes design artifacts to docs/design plus internal state under .sdtk/design.
Claude	Yes	Guide-aware	Claude can use the generated design briefs, prototype, and handoff as bounded implementation context before coding. The Preview Studio writes a DESIGN_FEEDBACK file and a copy-ready instruction — the user's open Claude session applies it.
Codex	Yes	Guide-aware	Codex can consume the design handoff and review evidence before SDTK-CODE planning and implementation.

Validated truth

The shipped public package is sdtk-design-kit with the sdtk-design CLI.
The core beginner path is init, start, prototype, review, handoff, and status.
Human-facing design output belongs in docs/design; .sdtk/design is internal state.
The prototype is static review evidence and planning input, not production application code.
The preview command starts a local Preview Studio on 127.0.0.1 only; it annotates elements and live-previews token tweaks in the browser but never writes files other than DESIGN_FEEDBACK under docs/design/feedback/.
The styles command opens a read-only style gallery; it copies a start command to the clipboard and writes nothing to the project.
The open command opens the SDTK-WIKI viewer directly to the Design tab when sdtk-wiki-kit is installed.
When the wiki viewer Design tab is active, it exposes the full loop (style gallery → generate pipeline → annotate) without running the standalone Preview Studio.

Boundaries and honest limits

SDTK-DESIGN does not replace SDTK-SPEC for requirements, formal architecture, traceability, or release gates.
SDTK-DESIGN does not replace SDTK-CODE; implementation, tests, and ship readiness remain downstream coding work.
SDTK-DESIGN does not replace Figma, v0, Lovable, or a full app builder.
URL, browser, screenshot, vision, and DOM review are not claimed as default local product behavior.
SDTK-DESIGN must not create or mutate .sdtk/atlas or SDTK-WIKI output.
The Preview Studio never calls an AI agent itself — it writes a scoped DESIGN_FEEDBACK file and shows a copy-ready instruction; the user's agent session applies it.

Source-of-truth docs

Canonical usage guide

products/sdtk-design/governance/SDTK_DESIGN_USAGE_GUIDE.md

Install, initialize, start, prototype, preview, styles, review, handoff, and status guidance for SDTK-DESIGN.

Package README

products/sdtk-design/distribution/sdtk-design-kit/README.md

npm-facing package truth for sdtk-design-kit and the current public command surface.

Generated output

docs/design

Human-facing design briefs, screen maps, design system, prototype, reviews, feedback, and handoff artifacts.

Position in the SDTK control plane

Where SDTK-DESIGN sits in the chain

SDTK-DESIGN is the bridge between ARCH (spec) and DEV (code). It turns design intent into a static reviewable artifact before a single line of feature code.

Orch—
PM—
BA—
ARCHuses
DEVuses
QA—

Highlighted owners actively use SDTK-DESIGN as their execution pack.

Family links

Move across the SDTK suite without losing context

These product pages map the current suite boundaries so users can move from specification to coding to operations deliberately.

Governance