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 prototypesSDTK-CODE handoff

> 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.
docs/design/DESIGN_SYSTEM.md
Step 4Static prototype
A working HTML/CSS prototype you can open in your browser.
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 — but the AI coder needs a visual contract or it will guess. Run sdtk-design prototype, open docs/design/prototype/index.html in your browser, click through, decide what to keep. By dinner you have a static MVP screen set 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.

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

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/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.
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.

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.

Source-of-truth docs

Canonical usage guide

products/sdtk-design/governance/SDTK_DESIGN_USAGE_GUIDE.md

Install, initialize, start, prototype, 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, 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