AIRDS

Feature catalogue

Everything AIRDS will do

AIRDS is on v0.6, build slice 6, in progress — v0.1 through v0.5 have shipped. This catalogue is the full feature set from docs/FEATURES.md, organized the same way, cross-referenced against docs/RELEASES.md so each section shows the release it's scheduled for — and whether that work has shipped, is in progress, or is still planned.

B1from the original product-vision briefB2from the Figma-plugin build briefNEWintroduced in this project's own plan

A. Bootstrap & Brand

plannedv0.1 · v0.7

Where a design system begins: one logo, one palette, and a record of which tools the team actually uses.

  1. A.1Select brand/logo frame in Figma, detect valid selectionB1B2
  2. A.2Product surface multi-select (Web / iOS / Android / Marketing / …) at project start, replacing single-platform Product DNANEW
  3. A.3Product DNA fields — type, complexity, density, a11y target, theme, interaction type, navigation modelB1
  4. A.4Smart recommendations from Product DNA — spacing, type scale, density, radius, breakpointsB1
  5. A.5Brand extraction — dominant/secondary color, neutral temperature, personality, shape language, contrast profile, all editable before generationB1B2
  6. A.6Brand Kit pipeline — favicon set, apple-touch-icon, PWA manifest icons, iOS AppIcon set, Android adaptive icons, OG/social card, logo lockups, versioned and re-runnableNEW
  7. A.7Change brand mid-project — one action re-cascades every derived asset through the same PR-reviewed sync flowNEW
  8. A.8Tooling DNA — select which design tools (Figma / Stitch / Claude / code-first) and dev tools (Claude Code / Cursor / Copilot / none) the team usesNEW
  9. A.9Recommended Structure review screen — shows exactly what will be scaffolded, before anything is generatedNEW
  10. A.10Tooling DNA is revisitable any time; adding a tool later generates only the missing adapter, idempotentlyNEW

B. Tokens

plannedv0.1 · v0.2 · v0.7

Three tiers, Material's own naming: primitive values, semantic roles that alias them, and component tokens that alias those.

  1. B.1Three-tier token architecture — ref (primitive) → sys (semantic) → comp (component)B1B2NEW
  2. B.2Real Figma Variable Collections with alias binding — semantic references primitive, never a copied valueB2
  3. B.3Light/dark (and future) modes per collectionB1B2
  4. B.4Token categories — color, typography, spacing, sizing, radius, border, elevation, opacity, motion, breakpoints, layoutB1
  5. B.5Token dependency graph — primitive → semantic → component → pattern → screenB1
  6. B.6Color Engine — 6 HCT-derived palettes across 13 canonical tone stops; the 28 Material color roles resolved for light and dark from the documented role table, not a contrast-curve guessNEW
  7. B.7Governance rule enforced in Check and CI — a primitive color with no palette/tone lineage is a hard fail, not a warningNEW
  8. B.8Component tokens (comp tier) — per-component, per-part, aliasing a semantic token so one component can be re-skinned aloneNEW
  9. B.9Typography Engine — Material's real 15-role type scale, sizes from a configurable modular-scale ratioNEW
  10. B.10Ratio configurator — named modular-scale presets, recommended from product density, always overridableNEW
  11. B.11Type outputs gated by product.surfaces[] — adding a surface later fills in just that platform's columnNEW
  12. B.12DTCG-compliant JSON export, re-importable by standard token toolingB2
  13. B.13Multi-platform token build — CSS custom properties, JS, iOS constants, Android XML, one source many outputsNEW

C. Foundations & Documentation

shippedv0.1 · v0.2

The system's own reference pages, generated from live state and never hand-maintained.

  1. C.1Generated Foundations page — brand, colors, typography, spacing, radius, elevation, grid, motion, icons, a11y — bound to live VariablesB1B2
  2. C.2Idempotent re-generation — updates in place, never duplicatesB2
  3. C.3Type scale generation driven by Product DNAB1
  4. C.4Generated markdown docs — foundations.md, components.md, patterns.md, written from live stateB2

D. Components

shippedv0.2

From native Figma component sets to a documented, versioned API contract.

  1. D.1Scan file for ComponentNode / ComponentSetNode + instance usage countsB2
  2. D.2Pull native Figma component properties — variants, booleans, text, instance-swap — as a contract starting pointB2
  3. D.3Near-duplicate clustering — fuzzy name + structural similarity — with confirm/reject UIB1B2
  4. D.4API contract editor — behaviorNotes, a11yNotes, codeMapping (package/export/Storybook id)B2
  5. D.5Component metadata model — maturity, version, tokenDependencies, accessibility, usageRules, codeMappingB1
  6. D.6Naming convention linting — warns, never blocksB2
  7. D.7Component library seeded by Product DNA — base set plus an enterprise/data set for data-heavy productsB1

E. Patterns & Templates

in progressv0.6

Repeated compositions, confirmed by evidence and promoted only by a person.

  1. E.1Pattern = confirmed repeated composition of components across screensB1B2
  2. E.2Pattern candidate detection — structural similarity, composition, ordering, frequency, cross-screen usage, confidence score, human approval mandatoryB1
  3. E.3Pattern metadata — purpose, components used, allowed variants, behavior, responsive rules, a11y rules, when to use / not useB1
  4. E.4Template factory — page recipes (List, Detail, Form, Dashboard) composed from patterns and componentsB1

F. Screen Analysis — "Check"

shippedv0.4

A compliance pass over any frame, with fixes that only ever touch what they're sure of.

  1. F.1Analyze selected frame — colors, typography, spacing, radius, components, detached components, repeated structures, a11y, hardcoded values, token usageB1
  2. F.2Compliance scoring — weighted across tokens, components, pattern reuse, a11y, typography, spacing consistency; configurable weightsB1
  3. F.3Issue severity tiers — Critical / Warning / RecommendationB1
  4. F.4Safe Auto-Fix — high-confidence token/component remaps only, grouped preview, undo support, never an ambiguous structural change without approvalB1
  5. F.5Safe Auto-Fix color matching — a hardcoded hex resolves to the nearest {palette, tone} by hue distance, deterministic because the token system is HCT-basedNEW
  6. F.6Deterministic contrast checking — WCAG contrast computed from tone deltas directly, without renderingNEW
  7. F.7Jump-to-node from any flagged issueB2

G. Growth Engine

shippedv0.4

The retention feature — the system stays accurate as screens are added, without a re-bootstrap.

  1. G.1New-frame diffing against a scannedFrameIds set — no full re-bootstrap neededB2
  2. G.2Screen registration — template, components, patterns, tokenUsage, complianceScoreB1B2
  3. G.3File-wide / per-page compliance score, trended over multiple scansB1B2
  4. G.4Automatic changelog generation as a side effect of every mutating action — no manual logging stepB2
  5. G.5Drift detection — is product-system alignment improving or worsening, most common deviation categoriesB1
  6. G.6Token gap detection — repeated deviations suggest a missing token, surfaced as a recommendation, never auto-createdB1

H. Evolution & Governance

in progressv0.6 · v1.0

How a token, component, or pattern earns its way from local experiment to system-wide status.

  1. H.1Maturity lifecycle — local → candidate → pattern → system → deprecated, with explicit Promote / Reject / Merge / Keep Local / Deprecate actionsB1
  2. H.2Promotion evidence — usage count, screen count, consistency, similar existing assets, token compliance, a11yB1
  3. H.3Governance dashboard — system health score, component/pattern/token counts, adoption %, activity feed, attention listB1
  4. H.4Dependency graph queries — "what uses this token?", "where is this component used?"B1
  5. H.5Change impact analysis before propagating a change — affected components/patterns/screens/instances, risk tier: Minor / Major / BreakingB1
  6. H.6Versioning — semver for the design system, structured changelogB1
  7. H.7Deprecation management — mark deprecated, propose replacement, migrate safe instancesB1
  8. H.8Design review workflow — Draft → Review → Approved → Development Ready, with compliance/a11y/reuse summaryB1

I. Sync — Figma ↔ GitHub ↔ Code ↔ AI tools

shippedv0.3 · v0.5

Every path — Figma or code — reduces to the same reviewable pull request against one repo.

  1. I.1GitHub design-system repo as sole source of truth — not a branch of any product app repoNEW
  2. I.2Figma plugin Sync action opens a design-sync/* branch + PR with a generated diff/impact summaryNEW
  3. I.3CLI + Claude Code/Cursor skill for developers — scans code the way the plugin scans Figma, opens dev-sync/* PRsNEW
  4. I.4Published versioned packages — @org/design-tokens, @org/design-assets, later @org/ui — consumed, never edited downstreamNEW
  5. I.5Canonical rules.json rendered into AGENTS.md, CLAUDE.md, .cursor/rules/, copilot-instructions.md — gated by Tooling DNANEW
  6. I.6Frame intake / code intake as the two universal entry points — any design tool's output is handled by which shape it producesNEW
  7. I.7Prompt Seed export — rules.json rendered as a natural-language design brief for Stitch or a Claude chat before generatingNEW
  8. I.8Code-to-design bridge — a code-first screen can be pushed into Figma as real frames, re-entering the frame-intake pipelineNEW
  9. I.9Screen → structured implementation context ("Copy Claude Context") — template, patterns, components, behavior, responsive rulesB1
  10. I.10Component → code snippet using mapped real components, never raw CSS when a mapping existsB1
  11. I.11Design-system global search across tokens/components/patterns/templates/rulesB1
  12. I.12Intelligent design assistant, answers scoped to the current systemB1

J. Roles & Access

plannedv1.0

GitHub's own permission model, not a bespoke backend.

  1. J.1Role model mapped onto GitHub permissions — Viewer / Designer / Developer / Maintainer / OwnerB1
  2. J.2Manager-facing Govern dashboard is strictly read-only over existing stateB1B2

K. Cross-cutting

shippedapplies to every release

The constraints that hold regardless of which feature above is running.

  1. K.1Idempotency — every file-mutating action is safe to re-runB2
  2. K.2No silent mutations — Figma-file-changing or repo-changing actions are explicit and user-confirmedB1B2
  3. K.3Single authoritative DesignSystemState — the UI is a thin view, never parallel stateB2
  4. K.4Schema versioning (schemaVersion) for future migrationsB1
  5. K.5AI may recommend, analyze, classify, detect, compare, propose — AI may never autonomously promote, delete, introduce breaking tokens, or publish a versionB1