한국어 · English
A global design command center for AI coding agents.
제품 철학을 먼저 읽고, 필요한 디자인 지식만 골라 쓰고, 실제 화면으로 검증하는 전역 디자인 총괄팀.
One command. One design team. Product truth first.
디자인팀, 이 화면을 제품 철학에 맞춰 수정해줘.
Design Pattern Lab, or DPL, is not a component dump and not another giant style library.
It is a product-first orchestration layer currently packaged and documented for Codex. The architecture is portable to other coding agents, but those integrations are not yet documented or verified. DPL reads the active product, decides what kind of design help is actually needed, selectively routes to relevant specialists, implements the smallest coherent change, and verifies the rendered result.
AI-generated products often start to look alike when the model is given lots of components but no clear design authority.
DPL reverses that order.
Generic style library
↓
product
becomes:
Product philosophy
↓
Current UX / tokens / behavior
↓
Design Team
↓
Only the design knowledge actually needed
↓
Implementation
↓
Rendered evidence
The product decides the design. The library does not.
User
↓
"디자인팀"
↓
Inspect active product
↓
Find the actual design problem
↓
Choose built-in capabilities + optional specialist sources
↓
Synthesize one direction
↓
Implement in the active repository
↓
Visual Release Review
↓
PASS / PASS_WITH_WARNING / FAIL / NOT_VERIFIED
The user should not have to choose between five overlapping design agents.
Design Team is the front door. Specialist tools are contributors, not competing decision makers.
DPL now uses a Philosophy-to-Design Contract for substantial or identity-sensitive work.
It translates authoritative product sources into:
Product philosophy
↓
explicit / inferred principles with provenance
↓
structure implications
visual-language implications
interaction implications
content implications
↓
derived product profile
↓
Exploration + Pattern Selector
↓
implementation decisions traced back to principle IDs
The contract prevents adjectives such as “premium”, “technical”, or “minimal” from being converted directly into trendy visual styles without product evidence.
tools/dpl/intent_guard.py validates traceability, flags inferred must-rules, unresolved tensions, unknown principle references, and ungrounded design decisions.
→ Philosophy-to-Design Contract
For substantial new design work, DPL can now explore multiple structurally different directions before implementation instead of jumping to the first plausible answer.
- minor repair → usually no exploration
- new surface → 2 directions
- major redesign → 3 directions
- brand-defining work → 3 directions plus lightweight prototypes when useful
DPL also includes a deterministic Pattern Selector that ranks inspected pattern libraries by platform, product type, needs, and product traits. The ranking narrows what to inspect; it never decides product identity.
→ Design Exploration Board
→ Pattern Selector
DPL deliberately keeps its internal capability set small.
| Capability | What it does |
|---|---|
| Component State Auditor | Checks relevant default, focus, loading, error, empty, overflow, responsive, keyboard and touch states |
| Design System Ingestor | Reads external DESIGN.md or style systems and classifies guidance as KEEP / ADAPT / REJECT |
| Interaction Physics | Makes motion explain causality, continuity, direct manipulation and feedback instead of decorating the screen |
| Accessibility Gate | Reviews semantics, focus, contrast, reflow, target size, reduced motion and platform accessibility concerns |
| Visual Release Review | Inspects the actual rendered result and reports PASS / PASS_WITH_WARNING / FAIL / NOT_VERIFIED with evidence |
These are built into Design Team. They are not five more skills to install or invoke.
→ Read the core capability spec
DPL can now use an optional structured verification path that turns parts of the product philosophy into checks, records rendered evidence, tracks which engines actually ran, and computes the strongest verdict the evidence supports.
The important distinction is simple:
- human-rendered evidence still counts — real browser/simulator/device output inspected by Design Team remains valid and can be recorded as
review_mode: human_renderwith reviewer, environment, viewport, reviewed capture IDs, reviewed areas, and any unverified areas; - structured verification is stronger when available — it can catch overclaims, incomparable Before/After data, missing evidence, false engine-use claims, and scope violations;
- NOT_VERIFIED means there is not enough rendered evidence to judge the visual result. It does not mean a verification tool was merely unavailable.
- Harness mode without philosophy checks is capped at
PASS_WITH_WARNING(NO_PHILOSOPHY_CHECKS), while a completehuman_renderreview can still reachPASS. - Stale philosophy checks are detected through source-document hashes and cap the result at
PASS_WITH_WARNING(CHECKS_STALE).
Internal tools live under tools/dpl/. They are part of Design Team, not new user-facing skills.
→ Evidence and verdict contract
→ Philosophy checks guide
DPL uses this authority order:
- User instruction
- Approved product philosophy and decisions
- Current routes, behavior, tokens, components and content
- Design Team synthesis
- Specialist design engines and references
- Generic design defaults
A mature product should not be restyled just because a new design library was discovered.
When an external design system is useful, DPL translates it into the current product rather than replacing the product with it.
DPL can selectively consult external tools and references when they materially improve the task.
| Source | Role |
|---|---|
| Huashu Design | Expressive visual direction and concept exploration |
| UI UX Pro Max | Design-system and stack-aware guidance |
| Hallmark-inspired checks | Web quality and anti-generic review |
| Infographic tooling | Dense information, comparison and process visualization |
| visual-inspiration-research | Free/public visual-reference research before substantial redesign work |
| Component Gallery | Component-state, semantics and mature design-system comparison |
| 21st.dev | Optional React/Tailwind implementation reference after design direction is approved |
| MengTo Web Pattern Pack | Curated runnable web layout, visual-style, motion, proof, and capture patterns used only after product direction is set |
| Native / SwiftUI Pattern Pack | Apple HIG authority + SwiftUI correctness, adaptive layout, accessibility, and native visual-direction routing |
| Product-local design docs | Highest-value source when the product already has a defined philosophy |
Using several engines is not the goal.
For a small hierarchy problem, DPL may use no external design engine at all. For a larger redesign, it may combine several. The Design Team owns the final synthesis.
Purpose: demonstrate the current DPL pipeline with identical Before/After data and fully visible hierarchy.
Result: PASS for the controlled showcase scope.
Important: these are deterministic vector fixtures, not production-app screenshots.
Product philosophy
→ Philosophy-to-Design Contract
→ Design Exploration Board
→ Native Pattern Selector
→ goal-led native hierarchy
→ controlled rendered evidence
The same fixture is used on both sides:
- 24.0 km
- 5 activities
- 2h 41m
- Sub-4 marathon goal
- 4:12:00 projection
- 12-minute goal gap
- Easy aerobic 45 min
- Safety status: Normal
| Before · summary-first | After · product-intent driven |
|---|---|
 |
 |
The design decision is traceable to explicit principles:
P-01 Goal gap before supporting statistics
P-02 Today's training and safety stay together
↓
D-01 Goal gap becomes the first card
D-02 Training + safety become one coaching unit
D-03 Monthly totals move to supporting statistics
This showcase fixes the two main evidence weaknesses of the historical case: the data no longer drifts, and the complete intended hierarchy is visible.
Showcase 01 remains available as the original simulator-based evidence case. It is intentionally preserved with its PASS_WITH_WARNING verdict because the Before/After datasets differed and the After viewport did not visually prove the complete Goal → Workout → Month order.
Keeping both cases is deliberate:
- Showcase 01: real historical app evidence with known limitations.
- Showcase 02: controlled, reproducible DPL reasoning and hierarchy evidence with identical data.
In any product repository where Design Team is installed globally:
디자인팀, 이 화면을 제품 철학에 맞춰 수정해줘.
More specific requests are also fine:
디자인팀, 현재 정보 구조는 유지하고
이 화면이 정밀한 분석 도구처럼 느껴지도록 개선해줘.
기능과 데이터 흐름은 바꾸지 말고 실제 렌더까지 검증해줘.
Or ask for review only:
디자인팀, 구현은 하지 말고 이 화면의 UX 문제만 검토해줘.
$repoPath = "$env:USERPROFILE\projects\Design_Pattern_Lab"
if (Test-Path $repoPath) {
Set-Location $repoPath
git pull --ff-only
} else {
git clone https://github.com/ZestfulPulse/Design_Pattern_Lab.git $repoPath
Set-Location $repoPath
}
npx skills add . --skill design-team --global --agent codexrepo_path="$HOME/projects/Design_Pattern_Lab"
if [ -d "$repo_path/.git" ]; then
cd "$repo_path"
git pull --ff-only
else
git clone https://github.com/ZestfulPulse/Design_Pattern_Lab.git "$repo_path"
cd "$repo_path"
fi
npx skills add . --skill design-team --global --agent codexIf Codex edits a Windows-local product, invoke Design Team from that Windows session.
If Windows is only the control surface and the product repository lives on a Mac mini reached through SSH, invoke Design Team from the Mac Codex session.
Same team. Same rules. Different workbench.
DPL uses visual-inspiration-research as the default reference-research replacement for Refero. It does not require a Refero subscription.
npx skills remove refero-design --global --agent codex -y
npx skills add https://github.com/Eldergenix/Codex-Design --skill visual-inspiration-research --global --agent codexDPL should prefer publicly accessible reference sources. Paid or partly paid galleries mentioned by the upstream skill are optional and must not become a dependency.
For Apple-platform work, DPL now has a separate native pack rather than reusing web design patterns.
Product Intent
→ Apple HIG / SDK constraints
→ Native Pattern Selector
→ SwiftUI correctness
→ native visual direction when useful
→ simulator/device verification
Install the curated specialist skills:
Windows
powershell -ExecutionPolicy Bypass -File .\scripts\install-native-pack.ps1Mac / Linux
bash scripts/install-native-pack.shThe installed skills are design-swiftui-interfaces and swift-ui-design. SwiftUI Catalog remains reference-only.
→ Native / SwiftUI Pattern Pack
DPL can selectively route to a curated subset of MengTo/Skills for concrete web implementation patterns. The upstream repository is MIT licensed.
Install the curated pack:
Windows
powershell -ExecutionPolicy Bypass -File .\scripts\install-mengto-pack.ps1Mac / Linux
bash scripts/install-mengto-pack.shThe pack is never allowed to override product philosophy. DPL chooses one direction first, then selects the smallest relevant pattern.
→ MengTo Web Pattern Pack routing
UI UX Pro Max can be installed separately and used when its guidance is actually relevant:
npm install -g ui-ux-pro-max-cli
uipro init --ai universal --globalDPL does not require every specialist tool to be installed.
Design_Pattern_Lab/
├─ README.md
├─ LICENSE
├─ docs/
│ ├─ WINDOWS_SETUP.md
│ └─ MAC_SETUP.md
├─ showcase/
│ ├─ 01-legs-of-steel/
│ └─ 02-legs-of-steel-controlled-native/
├─ tools/dpl/
│ ├─ intent_guard.py
│ ├─ pattern_selector.py
│ ├─ verdict_gate.py
│ └─ checks_runner.py
└─ skills/
└─ design-team/
├─ SKILL.md
├─ agents/
├─ patterns/
│ ├─ web-patterns.json
│ └─ native-patterns.json
├─ references/
│ ├─ PHILOSOPHY_TO_DESIGN.md
│ ├─ DESIGN_EXPLORATION.md
│ ├─ PATTERN_SELECTOR.md
│ ├─ NATIVE_SWIFTUI_PATTERNS.md
│ ├─ MENGTO_WEB_PATTERNS.md
│ └─ CORE_CAPABILITIES.md
├─ schemas/
└─ templates/
Product-specific philosophy, tokens and approved decisions remain in each product repository. DPL should not create a second source of truth.
DPL does not claim ownership of the external design systems, libraries or reference projects it learns from or routes to.
External sources are classified as:
- Tool / engine — actually invoked when installed and useful
- Reference — consulted for patterns or principles
- Inspiration — informed a DPL capability without bundling the upstream project
Examples include Component Gallery, 21st.dev, MengTo/Skills, DESIGNmd, visual-inspiration-research, Huashu Design, UI UX Pro Max, Hallmark, Emil Kowalski's design skills, Addy Osmani's web-quality skills, Impeccable, shadcn/ui and Anime.js.
Available does not mean used. Every showcase must list only the sources actually used.
→ Source attribution and inspiration
DPL is allowed to improve presentation and interaction within the user's requested scope.
It must not silently change:
- backend contracts
- authentication
- business logic
- data structures
- routes
- dependencies
- deployment configuration
- secrets
It also must not claim:
- that an external engine ran when it did not
- that accessibility passed without evidence
- that visual QA passed because build or lint passed
- that an external project's license applies to DPL itself
DPL is deliberately opinionated about a few things:
Use fewer sources, better.
More design engines do not automatically produce better design.
Preserve product identity.
An external style guide is input, not authority.
Motion should explain something.
If removing an animation does not reduce understanding, it may be decoration.
Accessibility is release quality.
Not an optional polish pass.
Rendered evidence beats declarations.
A successful build does not prove a successful design.
DPL v1 baseline
- One global Design Team
- Three P0 creation/orchestration modules: Philosophy-to-Design Contract + Design Exploration Board + Pattern Selector
- Five built-in capabilities
- Selective specialist routing
- Explicit source attribution
- Cross-platform Windows / Mac SSH workflow
- Rendered-evidence verification
- Optional machine-checkable verdict gate and run provenance
- Public case-study structure
Future capabilities should be added only when they close a clearly identified gap without duplicating an existing one.
Current agent support: Codex is the documented and verified installation target. Other coding-agent integrations are architectural possibilities, not current compatibility claims.
Design Pattern Lab is released under the MIT License.
External tools, repositories, services and assets remain subject to their own licenses and terms.