Matrix design skill for AI agents

Overview

Matrix is a cyber-slick, dark-only design system skill file that instructs AI coding assistants to generate interfaces inspired by terminal software, order-book exchanges, command centers, and minimalist high-tech fashion. Its aesthetic is sharp, dense, monochromatic, and precise: one continuous deep dark surface, Space Mono typography everywhere, hairline borders, near-square 2px corners, compact layouts, mono numerics, and a single brand-green accent that drives every meaningful interaction.

Where many dark themes rely on gradients, glass panels, neon glows, colorful charts, or cinematic effects, Matrix is more restrained. It should feel technical, controlled, and operational. The interface should look like a premium terminal layer for serious data, trading, analytics, security, automation, AI operations, developer tools, or high-density dashboards.

When you feed this skill file to an AI assistant, every generated component — buttons, cards, navigation, tables, forms, modals, alerts, charts, command palettes, dashboards, settings screens, loading states, and empty states — should adopt the Matrix visual posture: dark-only surfaces, thin grid-like separators, green interactive accents, terminal-style typography, dense spacing, precise states, and sharp rectangular geometry.

The result is a UI system that feels futuristic, minimal, technical, and confident without becoming gimmicky or visually noisy.

Design Tokens

Color Palette

Matrix uses a narrow dark palette anchored by a deep monochromatic background and a single brand-green accent. The system should feel like one continuous dark interface, not a collection of differently colored sections.

The most important rule is that Matrix is dark-only. The secondary color #0B0C14 is the product environment. It should be used across the entire app, including the page background, dashboard background, section background, and primary surface layer.

The primary green #2DB58A is the only brand accent. It should appear in links, active states, selected rows, command prompts, focus rings, primary buttons, status indicators, graph highlights, and system feedback. It should not be replaced with arbitrary blues, purples, or neon gradients.

The provided surface and text tokens are inherited defaults from the universal foundation. In a Matrix implementation, they should be wrapped by dark-mode semantic tokens rather than used directly as white cards or dark text.

Recommended Dark Semantic Tokens

Because Matrix is a dark-only system, implementations should define dark semantic tokens explicitly.

Use these semantic roles instead of raw values. A Matrix interface should not accumulate random dark grays, arbitrary border opacities, or one-off green tints.

Color Usage Principles

Matrix color usage follows five rules:

1. Dark surface is continuous — every section lives on the same deep dark canvas.
2. Green drives interaction — use primary for active, selected, focused, live, and actionable states.
3. White is not a surface — avoid white cards, white sections, and light modals.
4. Semantic colors remain semantic — success, warning, and danger communicate real state only.
5. Contrast is functional — use brightness, border, and typography to separate layers, not decorative color.

Avoid colorful dashboards where every metric gets a different hue. Matrix should feel like a controlled terminal interface with one deliberate signal color.

Typography

Matrix uses Space Mono for primary, display, and monospace roles. Typography is not just a content layer in this system. It is the visual identity.

Font Families

Using Space Mono across all roles creates a unified terminal-like feel. It also supports tabular rhythm, technical density, and precise alignment.

Do not mix in soft sans-serif fonts for body copy unless there is a strong accessibility or product-specific reason. The Matrix personality depends on monospaced typography carrying the entire interface.

Type Scale

Matrix uses a compact type scale:

Because Space Mono is wide, dense interfaces need careful line length and wrapping rules. A 16px monospace paragraph can feel large and slow to scan if it spans too wide. Use compact blocks, short labels, and clear alignment.

Weight

Available font weights range from 100 through 900, but Matrix should use a disciplined set.

Recommended usage:

• 400 for body text, data values, and standard table cells
• 500 for buttons, labels, and navigation
• 600 for panel headers and section titles
• 700 for major headings, active values, and command emphasis
• 800–900 only for rare display moments

Avoid ultra-light weights. Thin monospaced text on dark backgrounds can become fragile and hard to read. Avoid excessive bold text in dense data screens because it can destroy scanning rhythm.

Numeric and Data Typography

Matrix is strongly influenced by order-book exchanges and terminal interfaces, so numeric alignment matters.

Data typography rules:

• Use tabular numerics where supported.
• Right-align numeric columns.
• Align decimals consistently.
• Use JetBrains-style or terminal-style formatting patterns only if Space Mono cannot handle the use case.
• Keep timestamps compact.
• Use monospace spacing intentionally; do not manually pad strings with spaces in UI code.
• Use semantic color only when a number represents a state or directional change.

Example numeric treatments:

Text Case and Labels

Matrix can use uppercase for compact labels, badges, tabs, and terminal-like headers.

Recommended rules:

• Use uppercase for short labels only.
• Add letter spacing for small uppercase text.
• Keep body copy sentence case.
• Avoid long all-caps paragraphs.
• Use concise system labels.

Example:

.matrix-label {
  font-family: var(--font-primary);
  font-size: 12px;
  font-weight: 600;
  letter-spacing: 0.06em;
  text-transform: uppercase;
}

Spacing

Matrix uses a 4px-based spacing scale:

Matrix is intentionally dense, but it should not be cramped. The goal is operational density, not clutter.

Use smaller spacing for:

• Tables
• Logs
• Order-book rows
• Command menus
• Sidebars
• Metadata groups

Use larger spacing for:

• Page headers
• Modal content
• Dashboard regions
• Empty states
• Onboarding or explanation screens

Spacing should feel grid-like and consistent. A Matrix layout becomes messy quickly when arbitrary gaps are introduced.

The Matrix Look

Matrix has a specific visual identity: dark, precise, high-tech, monochrome, and terminal-influenced.

Dark-Only Surface

The entire interface must remain dark. This is the most important brand rule.

Do:

• Use #0B0C14 as the global canvas.
• Keep all sections on the same dark surface family.
• Use subtle dark variations only for component separation.
• Use green for interaction and system signal.
• Use hairline dividers for structure.

Do not:

• Add white cards.
• Alternate between dark and light sections.
• Use light modals.
• Use pale gray page backgrounds.
• Use decorative color-blocked sections.
• Treat dark mode as optional.

Matrix is not a light theme with dark cards. It is a fully dark operational environment.

Single Brand-Green Accent

The green #2DB58A is the system’s signal color. It should feel like live terminal output, active trading data, selected commands, and high-tech interaction.

Use green for:

• Primary CTAs
• Focus rings
• Active navigation
• Selected rows
• Live status indicators
• Command prompts
• Progress highlights
• Data highlights
• Interactive hover states
• Chart focus lines

Do not use green for every icon, divider, border, and background. The accent is powerful because it is controlled.

Hairline Borders and Digital Grids

Matrix uses hairline borders to create structure. Borders should be thin, precise, and low-noise.

Recommended border rules:

• Use 1px borders for most panels, tables, inputs, and dividers.
• Use border-hairline for subtle separation.
• Use border-strong for selected or focused containers.
• Avoid thick decorative borders.
• Avoid soft shadows as a separation method.
• Use grid lines sparingly in dense data tables.

The interface should feel like a technical instrument panel, not a boxed card layout.

Near-Square 2px Corners

Matrix uses very small radius. Corners should be almost square.

Recommended radius roles:

The default component radius should be 2px. Avoid large rounded corners, pills, blobs, and soft SaaS geometry.

Flat Surface, No Decorative Depth

Matrix is flat. It should not rely on cinematic glow, glassmorphism, or floating shadows.

Avoid:

• Drop shadows
• Soft elevation
• Glass panels
• Background blur
• Heavy neon glow
• Gradients as UI surfaces
• Decorative 3D effects
• Large rounded cards
• Colorful illustration
• Random sci-fi ornament

Subtle luminous effects may be used only when they improve state recognition and pass accessibility requirements, but the default should remain flat and precise.

High-Density Layouts

Matrix is suited to dense operational screens. It can support many numbers, logs, controls, and status signals at once.

Dense layout rules:

• Keep row height compact but readable.
• Use consistent columns.
• Align numeric data.
• Group controls tightly but clearly.
• Use sticky headers where useful.
• Use responsive overflow patterns for small screens.
• Avoid hiding important data behind decorative interactions.

The interface can be dense, but every element must still be scannable.

Component Coverage

The Matrix skill file should guide complete interface generation across dashboards, exchanges, terminals, admin tools, AI consoles, monitoring systems, analytics products, and developer-facing applications.

Buttons

Buttons should be compact, technical, and sharp. Primary buttons use the green accent. Secondary buttons remain dark and outlined.

Button variants:

Primary button rules:

• Use primary green as fill or strong border.
• Use high-contrast text.
• Use Space Mono at 14px or 16px.
• Use 2px radius.
• Avoid shadows.
• Avoid gradients.
• Keep padding compact.
• Preserve explicit hover, focus-visible, active, disabled, loading, and error states.

Recommended button state behavior:

Good button labels:

Avoid vague labels like Submit, Click here, or Go.

Cards and Panels

Matrix cards should feel like terminal panes or data modules, not soft elevated cards.

Panel rules:

• Use dark surface colors only.
• Use 1px hairline borders.
• Use 2px radius.
• Avoid shadows.
• Use compact padding.
• Use clear panel headers.
• Use green sparingly for active or live states.
• Use grid alignment for dashboard panels.
• Ensure long content wraps or truncates predictably.

Panel variants:

A Matrix panel should feel like a precise instrument display. Do not use decorative cards with large imagery or soft visual depth.

Forms

Forms should feel like command inputs and configuration controls. They should be compact, readable, and explicit.

Form rules:

• Labels must always be visible.
• Placeholder text must not replace labels.
• Inputs should use dark fills, hairline borders, and 2px radius.
• Input text should use 16px where space allows.
• Use Space Mono for all field text.
• Focus-visible states must be obvious.
• Error messages must be linked to fields programmatically.
• Required fields must be indicated accessibly.
• Disabled fields must remain understandable.
• Long labels and helper text must wrap cleanly.

Recommended input styling:

.input {
  background: var(--surface-inset);
  color: var(--text-primary);
  border: 1px solid var(--border-hairline);
  border-radius: 2px;
  padding: 10px 12px;
  font-family: var(--font-primary);
  font-size: 16px;
}

.input:focus-visible {
  outline: 2px solid var(--focus-ring);
  outline-offset: 2px;
  border-color: var(--primary);
}

Validation should include color, text, and structural cues. Do not rely on red or green alone.

Navigation

Navigation should feel like terminal wayfinding or exchange software: compact, clear, and state-driven.

Navigation rules:

• Use Space Mono at 12px, 14px, or 16px.
• Use uppercase labels for compact nav groups when appropriate.
• Use green for active state.
• Reinforce active state with border, underline, indicator bar, or filled background.
• Keep navigation dark-only.
• Use hairline separators.
• Preserve keyboard navigation.
• Provide visible focus states.
• Avoid large rounded tabs or colorful icon nav.

Navigation patterns may include:

• Left command sidebar
• Top status bar
• Compact tab row
• Segmented command groups
• Breadcrumbs in mono text
• Command palette trigger
• Terminal-style footer/status strip

Active states must use more than color alone.

Tables and Data Grids

Tables are a core Matrix component. They should support dense operational data, numeric alignment, sorting, filtering, and responsive overflow.

Table rules:

• Use dark background only.
• Use 1px hairline dividers.
• Use compact row height.
• Use Space Mono for all values.
• Use tabular numerics.
• Right-align numeric columns.
• Left-align labels and names.
• Keep header rows sticky when useful.
• Use green for active/live/positive indicators only when semantically meaningful.
• Use warning and danger for real caution/error states.
• Do not color every row.
• Provide sorting and filtering states clearly.
• Support horizontal scroll on small screens.

Recommended table states:

Order Books and Live Data

Matrix borrows from order-book exchanges, so live data components should feel precise and scannable.

Live data rules:

• Use compact row spacing.
• Use mono numerics.
• Align decimals.
• Avoid excessive animation.
• Flash updates briefly but provide reduced-motion fallback.
• Use green for positive/live states only when meaningful.
• Use danger red for negative or failing states only when meaningful.
• Include accessible text for directional changes.
• Do not rely on color alone to indicate increase or decrease.
• Provide pause or reduced update frequency where rapid updates may overwhelm users.

Example accessible delta text:

+2.4% increase

Do not show only +2.4% in green without a textual or semantic cue.

Command Palette and Terminal Inputs

Command interfaces are a signature Matrix pattern.

Command palette rules:

• Use dark overlay and dark panel.
• Use hairline border.
• Use 2px radius.
• Use Space Mono.
• Use green prompt or active selection.
• Support keyboard navigation.
• Highlight selected command with more than color.
• Show shortcuts with mono badges.
• Keep results dense but readable.
• Return focus to the trigger after close.

Terminal input rules:

• Use clear prompt marker.
• Preserve readable command text.
• Support copy actions.
• Distinguish command input from output.
• Show errors with danger styling and explanatory text.
• Avoid decorative fake terminal effects that reduce usability.

Badges and Status Indicators

Badges should look like compact system labels.

Badge rules:

• Use 2px radius.
• Use uppercase short labels where appropriate.
• Use hairline borders.
• Use green only for active/live/brand states.
• Use semantic colors for real statuses.
• Include text labels, not only colored dots.
• Ensure contrast passes.
• Avoid large pill badges.

Good badge labels:

Alerts and Feedback

Alerts should be restrained, technical, and direct.

Alert rules:

• Use semantic colors only for real feedback.
• Use dark surfaces with border accents.
• Include a clear title or message.
• Include recovery guidance when useful.
• Do not rely on color alone.
• Avoid playful copy.
• Make dismiss controls keyboard accessible.
• Keep layout compact.

Example feedback copy:

Modals and Overlays

Modals should feel like focused dark system panels.

Modal rules:

• Use dark surface only.
• Use hairline border.
• Use 2px radius.
• Avoid shadows or use only a subtle backdrop contrast.
• Keep title clear.
• Use compact body text.
• Use green for the primary action unless destructive.
• Trap focus inside the dialog.
• Close on Escape unless explicit confirmation is required.
• Return focus to the triggering element after close.

Destructive modals must use danger styling and explain consequences.

Charts and Visualizations

Charts should be minimal, dark, and data-first.

Chart rules:

• Use dark background.
• Use green as the primary highlight line or active series.
• Use muted grid lines.
• Avoid rainbow palettes unless the data requires many categories.
• Use semantic colors only for state meaning.
• Label axes clearly.
• Ensure data is not communicated by color alone.
• Provide table or textual alternatives where appropriate.
• Avoid glowing chart lines unless subtle and accessible.
• Support compact tooltips with keyboard access when possible.

For multiple series, use line style, symbols, labels, or patterns in addition to color.

Loading States

Loading states should feel technical and explicit.

Loading patterns may include:

• Skeleton rows
• Terminal-style progress text
• Compact spinners
• Progress bars
• Streaming output indicators
• Queued state badges

Loading rules:

• Preserve layout dimensions.
• Avoid flashing animation.
• Include accessible loading text.
• Respect reduced-motion preferences.
• Avoid theatrical hacker effects that delay comprehension.

Good loading copy:

Empty States

Empty states should be minimal and operational. They should explain what is missing and provide a next action.

Empty state rules:

• Use dark panel or section.
• Use clear heading.
• Include concise explanation.
• Provide one primary action where useful.
• Avoid illustrations.
• Avoid jokes or overly playful language.
• Keep copy direct.

Examples:

Accessibility

Matrix enforces WCAG 2.2 AA as a baseline. Dark, dense, high-tech interfaces can easily become inaccessible if contrast, focus states, spacing, and motion are not carefully managed.

Core Accessibility Requirements

• Text must meet WCAG 2.2 AA contrast against dark surfaces.
• Every interactive element must be reachable and operable by keyboard.
• Every interactive element must have a visible focus-visible state.
• Color must never be the only indicator of state.
• Form errors must be visually and programmatically associated with fields.
• Semantic HTML must be used before ARIA.
• Touch targets should be large enough for comfortable interaction.
• Motion must respect reduced-motion preferences.
• Dense data must remain readable at supported viewport sizes.
• Live updates must not overwhelm assistive technology users.

Contrast Requirements

Matrix relies on dark surfaces and muted secondary text, so contrast must be tested carefully.

Rules:

• Primary text must use a high-contrast light token.
• Secondary text must still meet contrast requirements for its size.
• Muted metadata must not become unreadable.
• Green text on dark backgrounds must be contrast-tested.
• Warning and danger colors must be tested against dark surfaces.
• Hairline borders may be subtle, but interactive boundaries must remain perceivable.
• Disabled states must remain understandable even when visually muted.

Do not use low-opacity gray text for important labels. Use size, weight, spacing, or grouping instead.

Focus States

Focus states must be highly visible against the dark canvas and hairline border system.

Preferred focus treatments:

• 2px green outline with offset
• Green border plus outline for inputs
• High-contrast underline plus outline for links
• Accent background plus border for selected items
• Visible row or cell focus in tables

Avoid focus states that rely only on a subtle glow, opacity shift, or slight text-color change.

Keyboard Interaction

Keyboard behavior is critical for dense technical interfaces.

Rules:

• Buttons activate with Enter and Space.
• Links activate with Enter.
• Menus and command palettes support arrow-key navigation.
• Tabs support expected keyboard movement.
• Modals trap focus and return focus after close.
• Tables with interactive cells expose reachable controls.
• Search suggestions are keyboard navigable.
• Tooltips must not contain unreachable interactive content.
• Live regions must be used carefully for updates.

Do not create clickable rows, cells, or panels without proper button or link semantics.

Live Region and Streaming Data Accessibility

Matrix may include logs, order books, metrics, and streaming output. These patterns require special care.

Rules:

• Do not announce every rapid live update to screen readers.
• Provide a pause, filter, or reduced update option for fast streams.
• Use polite live regions only for important state changes.
• Provide static summaries for rapidly changing data.
• Ensure users can inspect values without motion or automatic scrolling.
• Do not rely on flashing color to indicate updates.

A trading-style screen may update visually often, but assistive technology should not become unusable.

Motion Accessibility

Motion should be minimal and functional.

Acceptable motion:

• Short hover transitions
• Subtle selected-row update
• Loading indicator
• Compact progress animation
• Optional data flash on update

Motion rules:

• Respect prefers-reduced-motion.
• Avoid rapid flashing.
• Avoid large animated backgrounds.
• Avoid fake code-rain effects behind content.
• Avoid motion that causes layout shift.
• Provide static feedback in addition to animated feedback.

Matrix can feel cyber-slick without animated clutter.

Content and Tone

Matrix uses concise, confident, helpful, clear, and friendly copy. The tone should be technical but not cold. It should feel precise, calm, and operational.

Voice Principles

Matrix copy should be:

• Clear
• Concise
• Technical
• Calm
• Action-oriented
• Specific
• Helpful

Avoid overly playful, dramatic, or cliché hacker language. The interface can feel futuristic without saying things like “Access granted” everywhere.

Good Examples

Avoid

Matrix labels should describe the action, object, or state precisely. In dense interfaces, vague copy becomes expensive.

Technical Content Standards

For technical screens, copy should follow these rules:

• Use consistent terms for the same concept.
• Prefer short labels over sentence-like UI controls.
• Include units for numeric values.
• Include recovery guidance in errors.
• Label destructive actions clearly.
• Avoid unnecessary metaphors.
• Avoid hiding critical meaning in icons alone.

Example:

Deployment failed

The build completed, but the deployment step timed out. Check the network logs and run the deployment again.

[View logs] [Run again]

How to Use with AI Tools

Cursor and Claude Code

Add the Matrix skill file to your project so the assistant can use it as design-system context while generating UI code.

npx typeui.sh matrix

The skill file should be saved as SKILL.md or another project-level instruction file. Once present, ask the assistant to generate components, screens, dashboards, or refactors using the Matrix design system.

Example prompts:

Create a dark-only analytics dashboard using the Matrix design system.

Build an order-book table with mono numerics, green active states, hairline borders, and accessible live updates.

Generate a command palette, terminal input, and log viewer using Matrix component rules.

Refactor this admin panel into a dense cyber-slick Matrix interface with 2px corners and no light surfaces.

Claude

Use the design skill directly in Claude by adding the markdown file as project knowledge or pasting it into the beginning of a conversation.

Then ask for implementation-specific output:

Generate React components for Matrix buttons, inputs, tables, and panels.

Create component rules for command palettes, data grids, status badges, and modals using this skill.

Audit this UI against the Matrix design rules and list required changes.

ChatGPT, Windsurf, Copilot, v0, and Other AI Tools

The file is standard markdown, so it can be used with any AI assistant that accepts context, prompt instructions, or project-level rules.

Useful workflows include:

• Paste the skill into the chat before requesting UI code.
• Add it to a repository-level instruction file.
• Use it as context for dashboards, terminals, admin tools, or developer products.
• Use it to define dense data components and explicit interaction states.
• Use it as a QA checklist during code review.
• Ask the assistant to migrate an existing light UI into the Matrix dark-only system.

The best results come from prompting for concrete implementation details: dark semantic tokens, Space Mono usage, hairline borders, 2px radius, green interaction states, table behavior, live update accessibility, keyboard support, and anti-patterns.

Design Philosophy

Matrix is governed by a few core principles.

1. The Surface Never Turns Light

Matrix is dark-only. The deep dark surface is the world. Every panel, table, modal, and control belongs to that environment.

2. Green Is the Signal

The brand green is the system’s only expressive UI color. It communicates action, focus, liveness, selection, and technical energy.

3. Density Is a Feature

Matrix embraces dense layouts, but density must be structured. Alignment, spacing, borders, and typography must make high information volume scannable.

4. Mono Typography Creates Precision

Space Mono gives the system its terminal intelligence. It supports numeric alignment, technical labeling, and a consistent high-tech tone.

5. Flatness Creates Control

The interface should not feel like floating cards in space. It should feel like a precise digital surface with panes, borders, rows, and command areas.

6. Cyber Does Not Mean Decorative

Avoid cliché hacker visuals, random code rain, gratuitous glow, and neon overload. Matrix should feel premium and operational, not costume-like.

7. Accessibility Is Operational Reliability

A technical interface must work under pressure. Contrast, keyboard support, visible focus, readable data, reduced motion, and accessible live updates are part of the system’s reliability.

Anti-Patterns

Avoid these implementations when generating Matrix-style interfaces:

• Light cards, white modals, or white full-width sections
• Alternating dark and light page backgrounds
• Random neon colors outside the single green accent
• Overuse of green on every border, icon, and label
• Soft rounded SaaS cards
• Pill-shaped controls
• Large border radius beyond the near-square system
• Thick decorative borders instead of hairline dividers
• Soft shadows, glassmorphism, or blurred panels
• Heavy neon glow around text or controls
• Decorative code-rain backgrounds behind readable content
• Low-contrast muted text
• Placeholder-only form labels
• Tables with poorly aligned numbers
• Live updates that rely on color or flashing alone
• Rapid animations that ignore reduced-motion preferences
• Vague labels like Submit, Click here, or Go
• Color-only selected, success, warning, danger, or active states
• One-off spacing values outside the defined scale
• Components missing default, hover, focus-visible, active, disabled, loading, empty, or error states

Matrix should feel cyber-slick and technical, but never inaccessible, chaotic, or theatrical.

Migration Notes

When adapting an existing interface to Matrix, migrate in this order:

1. Replace all page and section backgrounds with the dark secondary canvas.
2. Remove white cards, light modals, gray app shells, and tinted sections.
3. Define dark semantic tokens for text, borders, panels, inputs, and focus states.
4. Replace mixed accent colors with the single green primary accent.
5. Convert all typography to Space Mono.
6. Normalize type sizes to the 12 / 14 / 16 / 20 / 24 / 32px scale.
7. Normalize spacing to the 4 / 8 / 12 / 16 / 24 / 32px scale.
8. Replace soft shadows with hairline borders and surface contrast.
9. Reduce border radius to 2px for most components.
10. Compact dense layouts while preserving readable row height.
11. Align numeric data and enable tabular numerics.
12. Add explicit hover, focus-visible, active, disabled, loading, empty, and error states.
13. Review tables, logs, and live data for accessibility.
14. Replace vague labels with precise technical copy.
15. Test contrast across all dark surfaces.
16. Run the QA checklist before shipping.

Do not migrate by simply applying a dark background and green buttons. Matrix depends on the full system: dark-only continuity, Space Mono typography, dense grid logic, hairline borders, 2px corners, restrained green interaction, and accessibility-first data behavior.

QA Checklist

Use this checklist when reviewing generated UI against the Matrix design skill.

Visual System

• The interface is dark-only.
• The deep dark #0B0C14 surface is used across every section.
• There are no white cards, light modals, or light page sections.
• The green #2DB58A accent is used for meaningful interaction and system signal.
• Random accent colors are avoided.
• Hairline borders structure panels, tables, and controls.
• Radius is near-square, usually 2px.
• Shadows, glassmorphism, and heavy glows are avoided.
• The interface feels high-tech and operational, not decorative.
• Dense layouts remain structured and scannable.

Typography

• Space Mono is used for primary, display, and mono typography.
• Type sizes come from the 12 / 14 / 16 / 20 / 24 / 32px scale.
• Font weights are used consistently.
• Numeric data is aligned and easy to scan.
• Timestamps, IDs, logs, and code-like values use compact mono treatment.
• Uppercase labels remain short and readable.
• Long labels and headings wrap cleanly.
• Muted text remains accessible.

Components

• Buttons have clear primary, secondary, tertiary, destructive, disabled, and loading variants.
• Inputs use dark fills, hairline borders, and visible focus states.
• Panels use dark surfaces, hairline borders, and compact padding.
• Navigation has clear active states using more than color.
• Tables support sorting, filtering, selection, loading, empty, and error states.
• Order-book or live data components align numerics and support reduced-motion behavior.
• Command palettes are keyboard accessible.
• Modals trap focus and return focus after closing.
• Alerts use semantic colors plus text or structural cues.
• Empty states include clear explanation and one next action where useful.

Accessibility

• Text contrast meets WCAG 2.2 AA on dark surfaces.
• Green, warning, danger, and muted text colors are contrast-tested.
• Keyboard navigation works across all interactive elements.
• Focus-visible states are obvious against the dark interface.
• Color is never the only indicator of state.
• Form errors are linked to fields programmatically.
• Semantic HTML is used before ARIA.
• Touch targets remain comfortable despite dense layouts.
• Motion respects reduced-motion preferences.
• Live updates do not overwhelm screen readers.
• Rapid data changes have pause, reduced update, or inspection options where needed.

Content

• CTA labels are specific and action-oriented.
• Technical labels are consistent across the interface.
• Error messages explain what happened and how to recover.
• Empty states explain what is missing.
• Destructive actions clearly state consequences.
• Loading states describe the current operation.
• Tone remains concise, confident, helpful, clear, and friendly.
• Vague labels like Submit, Click here, and Go are avoided.

Matrix is a disciplined design system for interfaces that should feel dark-only, cyber-slick, dense, technical, and operational. Its strength comes from a single dark surface, Space Mono typography, hairline grid structure, near-square geometry, mono numerics, and one controlled green signal color.