Fundamentals
What is DZINE?
Who the product is for, why design contracts exist, how the three layers fit together, and how to use the CLI in your own app.
Who this is for
DZINE is for builders and teams who ship UI with AI agents — product engineers, design-minded founders, agency devs, and agent authors who are tired of generic SaaS output.
You should use it if you:
- Want design decisions written down before Claude, Codex, or Cursor touch your components
- Need a repeatable pack (contract, route, tokens, scorecard) you can commit beside application code
- Want to score a dev URL against explicit clauses instead of asking “does this look okay?”
You do not need to know the maintainers or work inside this repository day to day. Clone once, run the CLI from your app directory, and treat the output like any other build artifact.
The problem DZINE solves
AI coding agents are good at generating UI quickly — but they default to the same patterns: gradient heroes, three equal CTAs, decorative dashboard mockups, and vague copy. That happens because the agent is guessing product strategy while it writes components.
DZINE separates design decisions from implementation. You compile a brief into a DesignContract v1 pack first. The agent implements from that pack. You score the result against explicit gates — not vibes.
What DZINE is (and is not)
| DZINE is | DZINE is not |
|---|---|
| A public design skill OS (MIT) | A private toolkit or hosted design product |
| A CLI + file pack workflow | A chat-only prompt library |
| Route intelligence + contracts + scorecards | A component UI kit you paste without context |
| Agent-agnostic (Claude, Codex, Cursor, v0…) | Locked to one editor or model |
Three layers
1 · Route intelligence
Maps your brief to a product-aware page type — SaaS landing, docs system, trust center, marketplace, dashboard, and 50+ style routes in the corpus.
2 · DesignContract v1
Produces design-contract.json plus rendered DESIGN.md, route.json, tokens.css, and scorecard.md — one source of truth for humans and agents.
3 · Score and repair
Checks a live URL against contract paths (structure, proof, primary action). Failed rows become a repair prompt your agent can run on the next pass.
End-to-end workflow
- 01
Clone the public repo
One-time setup. The CLI resolves the corpus from the clone automatically.git clone https://github.com/chasesdavis/DZINE.git && cd DZINE - 02
Write a product brief
Include audience, product type, proof requirements, tone, and primary action — not “make it modern.” - 03
Compile a build pack in your app
From your project directory, point at the cloned CLI. Output lands in ./build-pack/.npx dzine-skill run "public docs site for a design-contract CLI" --write-build-pack - 04
Hand off to your agent
Commit the pack or pin it in project rules. The agent implements from DESIGN.md and route.json. - 05
Score and repair
Run score against your dev URL, then repair only failed clauses.npx dzine-skill score --contract build-pack/contract/design-contract.json --url http://localhost:3003
Repository layout (for contributors)
If you are exploring or contributing to DZINE itself, the monorepo is organized as:
| Path | Purpose |
|---|---|
| skills/dzine/ | Router skill, validation, self-improvement scripts |
| style-systems/dzine-taste-framework/ | Routes, templates, tokens, snippets |
| packages/dzine-skill/ | CLI package (published to npm when ready) |
| contracts/ | DesignContract v1 schema + golden brief fixtures |
| site/ | This documentation and marketing site |
| examples/ | Reference microsites and visual proof |