Examples
Everything on this page is unedited output of the shipped SDTK CLIs — generated with the exact command shown next to it.
> SDTK-DESIGN
Each style preset turns an MVP idea into a design brief, screen map, wireframes, and a token-level design system — reviewable files, not a canvas you can't diff.
Clean solo-founder SaaS default with practical hierarchy, quiet surfaces, and low-decoration components.
System UI sans, 32/24/18/15/13px hierarchy
Dashboard-first MVP style with stronger density, metrics, cards, tables, and command surfaces.
Inter-like sans with tabular numerals, 34/24/18/14/12px
Trust-forward financial style with dense data surfaces, tabular numerals, a restrained palette, and strong status semantics.
Precise system sans, tabular numerals everywhere numbers appear
Product-forward storefront style with photography-led cards, a single confident accent for CTA and price, and a sticky cart/checkout rail.
Friendly geometric sans, price and CTA weight forward
Generated with sdtk-design-kit — artifact links open the raw, unedited files. A clickable HTML prototype step exists behind the spec-handoff input contract and will join this gallery once a full spec-fed example is published.
> SDTK-SPEC
sdtk-spec generate verified all 17 scaffold files itself — product, specs, architecture, API, database, design, dev plan, and QA gates.
docs/
├── product/
│ ├── PROJECT_INITIATION_SHOPEASE.md
│ ├── PRD_SHOPEASE.md
│ └── BACKLOG_SHOPEASE.md
├── specs/
│ ├── BA_SPEC_SHOPEASE.md
│ └── SHOPEASE_FLOW_ACTION_SPEC.md
├── architecture/
│ └── ARCH_DESIGN_SHOPEASE.md
├── api/
│ ├── ShopEaseMVP_API.yaml
│ ├── SHOPEASE_ENDPOINTS.md
│ ├── SHOPEASE_API_DESIGN_DETAIL.md
│ └── shopease_api_flow_list.txt
├── database/
│ └── DATABASE_SPEC_SHOPEASE.md
├── design/
│ └── DESIGN_LAYOUT_SHOPEASE.md
├── dev/
│ └── FEATURE_IMPL_PLAN_SHOPEASE.md
└── qa/
├── SHOPEASE_TEST_CASE.md
├── QA_RELEASE_REPORT_SHOPEASE.md
└── CONTROLLER_ACCEPTANCE_SHOPEASE.md
+ SHARED_PLANNING.md · QUALITY_CHECKLIST.md (shared state)docs/product/PRD_SHOPEASE.md — as generated
# PRD: SHOPEASE (ShopEase MVP) **Document ID:** PRD_SHOPEASE **Version:** 1.0.0 **Author:** PM Agent **Status:** DRAFT - Ready for ARCH Review **Source:** BA_SPEC_SHOPEASE.md ## 1. EXECUTIVE SUMMARY ## 2. GOALS & SUCCESS METRICS | Goal ID | Goal | Success Metric | Target | |---------|------|----------------|--------| | G-01 | TBD | TBD | TBD |
The scaffold ships structure and gates; your PM/BA/ARCH skills (or you) fill the content. Traceability is the point — every later phase references these IDs.
> SDTK-AGENT
This is the same run shown in the homepage video: it paused at a human gate, was approved, completed, and rendered this report from the on-disk ledger.
The ledger lives at .sdtk/agent-runtime/runs/<run_id>/ — state, events, approvals, and evidence are files in your repo, inspectable without rerun.
# Run Report **run_id:** run_mr8rcw2y_249a15 **workflow_id:** shopease-demo **feature_key:** SHOPEASE **goal:** Verify docs, gate on owner review **status:** completed ## Task Status | Stage | Type | Status | |----------------|------------|-------------| | verify_docs | task | ✓ completed | | owner_review | human_gate | ✓ completed | | summarize_tree | task | ✓ completed | | final_report | report | ✓ completed | ## Artifacts - [final_report] reports/final_report.md *Generated by sdtk-agent. Evidence is persisted on disk and inspectable without rerun.*
> SDTK-CODE + SDTK-WIKI
The readiness score explains itself and says NO first; the local Atlas graph makes the scaffold queryable.
Ship Readiness: 0/85 — FAIL
Components:
SPEC 0/15 CODE handoff not found
CODE_VERIFY 0/30 non-pass gates: spec, quality, evidence
GUARDRAIL 0/15 unresolved deny event(s)
FILE_SCOPE 0/10 file-scope verdict: absent
OPS 0/15 OPS handoff evidence absent
Blockers:
[FAIL] CODE verification evidence missing or failed.
[FAIL] Unresolved guardrail deny events.> SCENARIO PACKS
Four worked scenario families ship in the package examples/ directory and install with the toolkit.
Full upstream artifact chain: BA, architecture, API contract, database, screen layout, flow-action, DEV planning, QA gating.
Backend-heavy delivery: UI artifacts intentionally reduced, API contract discipline stays explicit.
UI-heavy scenario: DESIGN_LAYOUT, FLOW_ACTION_SPEC, action mapping, and cross-screen process clarity.
Shortened documentation path for bugfixes while keeping verification, handoff, and QA release discipline.
Install the suite and run the same commands — every artifact above lands as files in your project, locally.