agentsclimarketplace

Design system extractor

Skill SylphxAI/skills/skills/design-system-extractor

Public agent skills from SylphxAI — standards, product procedures, and one-command sync for Codex, Claude Code, and Grok Build

Install
npx -y skills add SylphxAI/skills --skill design-system-extractor

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Extract and reconcile an existing product design system from authorized screenshots, design files, tokens, stylesheets, components, and shipped flows, preserving provenance, confidence, states, responsive rules, accessibility, exceptions, and migration impact. Use when the deliverable is an evidence-backed as-is system map or consolidation plan. Do not use to invent a greenfield visual direction, critique one flow, implement a supplied design, or imitate a third-party product.

SKILL.md

4.2 KB, as published. Nobody here has run it

Design System Extractor

Recover the system the product actually uses. Keep observed facts, inference, and proposed normalization visibly separate.

Workflow

  1. Confirm source ownership/authorization, target product versions, platforms, themes, locales, viewport classes, source recency, and intended consumers.
  2. Read references/design-system-extraction-systems.md.
  3. Build a source and coverage ledger before naming tokens. Capture code/design locators, visible state, viewport, platform, theme, locale, frequency, and confidence for every observation.
  4. Extract the dependency graph: raw values -> primitives -> semantic tokens -> component anatomy/variants/states -> compositions -> complete workflows.
  5. Reconcile contradictions using source authority, shipped usage, recency, accessibility, and product intent. Label each decision observed, inferred, proposed, intentional_exception, or unresolved.
  6. Model responsive constraints, density, content stress, input modality, platform conventions, motion/reduced motion, localization, and non-happy states rather than cataloguing default screenshots only.
  7. Identify duplicate values/components, semantic collisions, missing states, inaccessible patterns, and migrations. Preserve intentional variants with rationale instead of flattening every difference.
  8. Validate by reconstructing or auditing representative flows against the extracted system, including at least one dense, error, loading, empty, localized, keyboard, and narrow-screen case where applicable.
  9. Produce the provenance ledger, token graph, component contracts, exception register, confidence gaps, representative-flow validation, and migration map.

When not to use

  • For a new product or greenfield redesign, use interface-craft and treat any existing-system extraction as an input, not the final design direction.
  • For a one-flow usability or visual critique, use interface-craft.
  • For implementation from an already authoritative system, hand off the exact component contract and acceptance states to the implementation owner.
  • Do not extract a clone from an unrelated third-party product. Use external products for high-level comparative research, not source copying.
  • Do not claim Figma, code, screenshots, or production are universally canonical; record conflicts and the authority chosen for this extraction.

Guardrails

  • Never invent missing values or states and report them as extracted.
  • Never collapse platform, theme, density, locale, accessibility, or product variants merely because their raw styles are similar.
  • Never treat frequency as authority when the frequent pattern is deprecated, inaccessible, or an accidental fork.
  • Never output raw style tokens without semantic roles, provenance, confidence, and consumers.
  • Never log private customer content or proprietary third-party assets in the reusable system artifact.

Output

Scope and source authority:
- product/version/platform/theme/locale/viewport / source order / exclusions

Source and coverage ledger:
| Observation ID | Source locator | Surface/state | Raw fact | Status | Confidence |
| --- | --- | --- | --- | --- | --- |

System graph:
- primitive -> semantic token -> component contract -> composition -> workflow

Component and pattern contracts:
| Item | Anatomy | Variants | States | Responsive/content rules | A11y/input | Provenance |
| --- | --- | --- | --- | --- | --- | --- |

Exceptions and unresolved conflicts:
- observation / competing evidence / decision or open question / owner

Validation and migration:
- representative flow / mismatches / proposed canonical change / blast radius

Gives 0 of the 12 instructions most design systems skills give

Counted across 528 of the 534 authors here whose files we hold, read 2026-08-06

  • create a custom theme if neededin 54 of 528, across 10 files
  • read the corresponding theme filein 54 of 528, across 10 files
  • ask which theme to applyin 53 of 528, across 9 files
  • show the theme showcasein 53 of 528, across 9 files
  • maintain visual identity across all slidesin 50 of 528, across 6 files
  • apply the specified colors and fontsin 47 of 528, across 3 files
  • get explicit confirmationin 45 of 528, across 1 file
  • Generate a design system before codingin 19 of 528, across 6 files
  • Maintain at least 4.5:1 color contrast ratioin 19 of 528, across 8 files
  • Describe component shapes, colors, shadows, and interaction statesin 18 of 528, across 4 files
  • Check Python installation and install if missingin 17 of 528, across 4 files
  • Default to html-tailwind if stack is unspecifiedin 17 of 528, across 4 files

Said here and by no other author read

  • separate observed facts from inference and proposals
  • confirm authorization scope and intended consumers
  • build a source and coverage ledger before naming tokens
  • extract the dependency graph from raw values to complete workflows
  • reconcile contradictions using source authority
  • model responsive constraints accessibility and non-happy states

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.