emdesign

Infer a design system's tokens + voice from a brand reference (screenshots or a URL) — vision-assisted. Use for /mds:system:create --mode extract, feeding the design-system-author skill.

Reason about color on-system — pick/adjust accent, surfaces, and status colors within a design system's palette, check contrast/accessibility, and propose token changes (not raw hex). Adapted from open-design's color-expert. Use for color decisions during build, review, or system edits.

Build a reusable, on-system React+Tailwind component from an intent. Use when creating or editing a component in emdesign. Composes design-system primitives from "@ds", references token roles only, emits a CSF story, and feeds the verify loop.

Author or maintain a design system's DESIGN.md + tokens.css (the contract). Use when fixing the SYSTEM rather than a component — adding tokens, tightening anti-patterns, or capturing visual rules. Adapted from open-design's design-md (Google Labs / Stitch).

Designer-who-codes visual audit + fix. Use to tighten a component before shipping — run the four-source critique, then make atomic, on-system fixes with before/after screenshots. Adapted from open-design's design-review (gstack) to emdesign's code-first loop.

Create or update a design system to the emdesign quality bar — author the 9-section DESIGN.md + tokens.css + base primitives. Use for the System flow (/mds:system:create | :update). Knows the four sources: brief, blank, import, extract.

Master skill for design taste — embeds deliberate, opinionated design decisions into every agent interaction. Use at the START of any task to replace generic AI output with intentional design. Adapted from taste-skill (Leonxlnx) for emdesign's design system pipeline.

Compile a design system's tokens into TypeScript types and a consumable npm package. Use when the design system is stable and ready for production consumption by other packages/screens.

Manage per-design-system lint rule presets, severities, and exemptions. Use when a design system needs different lint strictness (e.g. fintech needs strict contrast, editorial relaxes accent-overuse).

Methodology for building a large page by progressive decomposition — turn a page brief into a component tree, decide reuse-vs-author per leaf against the graph, build leaves first, and compose upward into an on-system page. Use for /mds:craft:view.

Automate the build-verify-capture cycle for multiple components. Use when you have several components to build, verify, and promote, or want continuous iteration until quality gates pass.

Discover, import, and customize design systems from remote sources — awesome-design-md (74 brands), vendor bases (13 systems), and git repositories.

Build screens and views by composing existing components and blueprints. Use when you need to turn a multi-component layout into a screen with routing.

Single authoritative testing skill for emdesign. Covers the complete 7-level testing pyramid that replaces human verification — from design system foundation through visual taste and quality gate. Every level uses TDD (RED/GREEN with vitest). Use at the START of any testing task.

Meta-router for emdesign's design loop. Use at the START of any design/build/fix task to pick the right skill + /mds command + feedback sources, and to follow the non-negotiable operating behaviors. Maps each phase (analyze → intent → build → verify → ship) to its tools.

Deep visual and spatial analysis of rendered components. Use when a component looks wrong but lint passes, or for deterministic geometry checks (overlaps, alignment, contrast).

Component testing skill. Tests a component across all relevant levels: render probe → lint → states → spatial → behavior → doctor. Use when verifying a component after build or edit. Writes a .test.ts file and runs vitest.

Master testing skill for emdesign. Defines the 7-level testing pyramid (DOM, Lint, Visual, Component, Page, Behavior, Gate), the RED/GREEN agent loop with vitest, and scenario-based testing strategies. Use at the START of any testing task to select the right scenario template, write a .test.ts file, and drive vitest to GREEN.

Page and screen testing skill. Tests that composed pages have correct layout structure (header, main, footer, nav), all required sections are present, responsive metadata exists, and token binding is consistent. Use when verifying a composed view or screen. Writes a .test.ts file and runs vitest.

Visual regression testing skill. Compares HTML documents across pixel, structure, and computed CSS layers. Use when verifying a component change didn't break appearance, comparing overview pages to reference preview HTML, or validating cross-DS equivalence. Writes a .test.ts file and runs vitest.

Breaks work into ordered tasks (MeKnow-adapted onto OpenSpec). Use when you have an OpenSpec proposal or clear requirements and need to fill the change's design.md and tasks.md with implementable, verifiable units. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

Creates specs before coding (MeKnow-adapted onto OpenSpec). Use when starting a new feature or significant change and no OpenSpec change exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Maps SPECIFY/PLAN/TASKS/IMPLEMENT onto /opsx:propose, design.md, tasks.md, and /opsx:ship (ship-plan → ship-code) — former RFCs now live as capability specs (rationale in docs/design/); do not invent a competing PRD file.

Guides the AI through UI/visual design for user-facing OpenSpec changes. Covers wireframes, component trees, UI states, user flows, visual decisions, responsive/accessible design, and connecting UI design to implementation tasks. Use when a change has a visible surface (new screens, component changes, UX improvements) and you need to produce ui.md.

Complete design-engineering workflow using emdesign CLI. From design system creation to screen deployment — all via CLI commands. Use at the START of any project to route through the right commands.

Automates CI/CD pipeline setup, adapted for the Mezon Mentor Bot ("MeKnow") platform. Use when setting up or modifying build and deployment pipelines, the GitHub Actions workflow (.github/workflows/rag-engine.yml), quality gates, or the /opsx:ship verify step. Use when configuring the polyglot test runner (Python/uv, Go, TS/pnpm) with a pgvector service container or debugging CI failures.

Conducts multi-axis code review (MeKnow-adapted, polyglot). Use before merging any change. Use when reviewing code written by yourself, another agent, or a human across Python/Go/TypeScript. Use when you need to assess code quality across correctness, readability, architecture, security, and performance before it enters main. Complements the built-in `/code-review` and `/security-review` slash commands and the `/opsx:address-review` PR-comment loop.

Simplifies code for clarity (MeKnow-adapted, polyglot + OpenSpec). Use when refactoring code for clarity without changing behavior in this repo. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity. Every change keeps the resolver-selected gates (uv/go/pnpm) green and respects the repo's invariants.

Guides systematic root-cause debugging (Mezon Mentor Bot "MeKnow" platform). Use when a toolchain gate fails (`uv ... pytest`, `pyright`, `go test -race`, `pnpm test`), a build breaks, retrieval/runtime behavior doesn't match expectations, a citation is missing or a tenant boundary leaks, or you hit any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.

Records decisions and documentation, adapted for the Mezon Mentor Bot ("MeKnow") platform. Use when making architectural decisions, changing the API contract (OpenAPI) or the BotPolicy/MCP boundary, shipping features, or recording context future engineers and agents need. Notes how OpenSpec design.md files serve as lightweight ADRs, that former RFCs live in docs/design/, and where docs/ lives.

Structures git workflow practices, adapted for the Mezon Mentor Bot ("MeKnow") platform — the platform/ git submodule of funix-mezon-bot. Use when making any code change. Use when committing, branching, resolving conflicts, writing Conventional Commit messages, opening PRs via gh, bumping the superproject gitlink, maintaining CHANGELOG.md, or organizing work across parallel streams.

Delivers changes incrementally (MeKnow-adapted, polyglot + OpenSpec). Use when implementing any feature or change that touches more than one file in this repo. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step. Each slice stays buildable and green under the resolver-selected gates (uv/go/pnpm as applicable + ci-free-gates.sh + openspec validate).

Hardens code against vulnerabilities (MeKnow-adapted, polyglot). Use when handling untrusted documents or webhook payloads, working with tenant isolation or server-side ACL in retrieve_kb, encrypting/decrypting provider credentials, the service JWT between backend and workers, or any answer-producing path. Use when building any feature that accepts untrusted data, manages tokens, or crosses a tenant boundary. Maps the OWASP Top 10 onto this repo's concrete controls (multi-tenant isolation + ACL-cohort cache keys, server-side ACL in retrieve_kb, Fernet credential encryption, HS256 service JWT, HMAC-signed inbound webhooks, citations-mandatory refusal, the compression invariant against KB prompt-injection).

Drives development with tests (polyglot + OpenSpec). Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Red-Green-Refactor with language-appropriate tests, the resolver-selected gates, and the `/opsx:ship` Test(Red) phase. Project specifics (test commands, file patterns, fixtures, invariants) come from `mzspec.config.json` and the project's `tdd` template.

Discovers and invokes agent skills (MeKnow-adapted). Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked, and it routes work onto this repo's mzspec-driven OpenSpec lifecycle (/opsx:propose → /opsx:spec → /opsx:spec-pr → /opsx:ship [ship-plan → ship-code] → /opsx:address-review → /opsx:archive).

Master skill for emdesign — the design-engineering engine. Use at the START of any design, build, review, or system task. Routes to the right playbook based on what you need to do. All MCP tools are available at http://localhost:4321/mcp.

Generate a polished marketing/web section as a reusable React component, on-system.