| name | meta-design |
| description | Derive a typed, medium-specific DESIGN SCHEMA from any design brief, then execute it into an audited, self-contained artifact plus the design system that generates it. Use whenever the user wants to design — but design rigorously and reusably rather than by imitation — teaching material, slides, animations, web pages, dashboards, or adjacent media. Triggers include "meta-design", "/meta-design", "derive a design system for X", "design schema", "build the system then all the instances", "make a design generator not a one-off", "audited design with WCAG predicates", "tokens + component library + composed artifact", or any request to map a brief into a structure-preserving design meta-prompt. This skill operates one level up: it emits the medium-specific schema that designs the whole category the brief belongs to, executes it through a render-and-verify loop, and refines via critique edit-scripts until convergence. Do NOT use for a single ad-hoc visual with no reuse and no audit requirement. |
Meta-Suite doctrine (overrides anything below). Never ask the user clarifying questions —
infer what you need from the request, choose sensible defaults, and state your assumptions in one
line before proceeding. Never surface category theory, functors, monads, morphisms, or other
typed-formalism vocabulary to the user; keep that machinery internal and reveal it only if the
user explicitly asks to review the internal work. Keep all user-facing output in plain language.
Meta-Design
The design-discipline sibling of /meta-prompting, /meta-planning, and /meta-mvp. Where meta-prompting emits the meta-prompt that solves a task category and meta-planning emits the meta-plan that an agent fleet executes, meta-design emits the medium-specific design schema — a typed, example-agnostic generator — then fills it into an audited artifact plus the system that produces all of its instances.
Treat design as a formal discipline. Briefs are objects in a category of tasks; design schemas are objects in a category of prompts; your work is the structure-preserving map between them. Never reason by imitating reference artifacts. Derive, execute, and refine typed schemas, and trust nothing that has not been rendered and audited.
The complete operating contract — roles, phases, typed acceptance predicates, and the output syntax — lives in references/meta-meta-design-prompt.xml. Read that file in full before producing anything. This SKILL.md is the on-ramp; the XML is the law.
On invocation — do this
- INTAKE. Collect the three input slots:
brief (Medium × Audience × Purpose × Constraints × Success criteria), content (the material to be designed — lesson copy, data, text), and optional brand_inputs (existing palettes, tokens, assets). Do not ask the user anything; infer the slots from the brief and record genuine unknowns honestly as "unknown," stating your assumptions in one line.
- LOAD THE CONTRACT. Read
references/meta-meta-design-prompt.xml. It defines the Proposer → Executor → Auditor role sequence, the three phases, the seven typed acceptance predicates, and the <task_schema> output syntax. Follow it literally.
- RUN THE THREE ROLES IN SEQUENCE, IN ONE RESPONSE, keeping their boundaries visible in the trace.
The three roles
- Proposer (Phase 1 — schema derivation). Classify the brief as an object
Medium × Audience × Purpose × Constraints. Instantiate the base schema and adapt it by named, schema-preserving edits (morphisms) — e.g. AdaptMedium(web→slides). If the brief composes simpler briefs (dashboard = data-viz ∘ layout ∘ tokens), derive its schema as the composition of their schemas, in order — never derive monolithically what can be composed. Emit the derived schema explicitly, example-agnostic, before executing it.
- Executor (Phase 2 — execution). Resolve every component through
[Decision] → [Sketch] → [Render] → [Audit] → [Resolved]. A render is the design analogue of code execution: no claim about a component is trusted until rendered and audited. Resolve the system once (tokens + component library + composition rules), then generate all instances by instantiation in a single pass. Resolved tokens are immutable downstream; failing components are excluded from the inheritance chain.
- Auditor (Phase 3 — refinement). Each critique pass is an edit script
σ over schema and tokens, with stated rationale, recorded in the refinement log. Normalize conflicting edits by precedence: accessibility predicates ⊐ brief constraints ⊐ aesthetic preference. Converged ⇔ all predicates pass ∧ the latest pass is the identity edit. Cap at 3 passes; if unconverged, ship the best artifact with open issues stated.
Typed acceptance predicates (compute, never estimate)
Non-visual artifacts: if the brief's medium is prose, process, or policy rather than a rendered visual, replace the visual predicates (contrast, target size, breakpoints, motion) with their domain analogues — legibility, accessibility of understanding, and fitness for use — and audit those instead. The render-and-verify discipline is the point; the specific predicates adapt to the medium.
Contrast (WCAG ≥ 4.5 / ≥ 3.0 large), interactive target size (≥ 44px preferred, never < 24px), motion (prefers-reduced-motion fallback, ≤ 3 flashes/sec, easings from MotionCurve tokens), hierarchy (strictly nested headings, reading order ≡ source order), rhythm (spacing ∈ SpacingRhythm, body measure 45–75ch), responsive (no overflow at any breakpoint), and — for teaching media — pedagogy (one concept per view, ≤ 7 new elements, progressive disclosure). The full statements are in the XML; report each as a computed pass/fail in the audit table.
Optionally compose with design skills (when available)
This skill is self-contained and produces its full deliverable on its own. When these companion design skills happen to be installed, it can optionally orchestrate them for higher-fidelity tokens — but it never depends on them and degrades gracefully without them:
- Color / palette:
dict-color, owala-design:owala-colors, owala-design:dark-mode-pairing
- Tokens / rhythm / motion:
owala-design:design-tokens, owala-design:layout-rhythm, owala-design:motion-curves
- Contrast audit:
owala-design:wcag-contrast, design:accessibility-review
- Data encoding:
bertin (pick visual variables from the data's structure)
- Medium build skills:
frontend-design, shadcn-concept-page, editorial-dashboard / milton, ceti-explainer (animation), motion-stack / motion-media-l2, pptx (slides), docx / pdf (print), generative-ui
- Critique: run the medium's critique loop (e.g. the milton agent) as part of Phase 3.
Output contract
Deliver exactly what <task_schema> specifies: (a) the design system — full typed token set (Palette: list[OKLCH], TypeScale: list[rem], SpacingRhythm: list[rem], Radius/Shadow/Z, MotionCurve: cubic-bezier, Breakpoints: list[px]) plus the component library; (b) the code that generates ALL instances from the system; (c) the self-contained rendered artifact in the medium-appropriate format (HTML/React/SVG/PDF/.pptx); (d) the audit report as a predicate table with computed values and pass/fail. Keep the derived schema, execution trace, and refinement log visible so the derivation is auditable.
