The run, end to end
01
Connect the sources
Install the GitHub App, pick the repositories that hold your system, and optionally connect the Figma libraries that describe it. Selection is per repository, permissions are read-only, and nothing is analysed until you say so.
02
Discover what is there
A background run walks the repository and parses it: components and their props, variants, tokens and theme files, Storybook stories, READMEs, MDX and any agent instructions already committed. Parsers do this work, not a model, so the result is the same every time.
Components84 foundButtonexportedDateRangePickerexportedModalno docsStatusPillnot found03
Reconcile design with code
Figma components, component sets, variants and variables are matched against the implementations that realise them. Names, variant structure and descriptions produce candidate mappings, each with a confidence value and the evidence behind it.
MappingFigma to codeButtonButtonconfirmedDialogModallikelyTooltipno matchunmapped04
Score, and show the evidence
The eight readiness dimensions are calculated from what was found. Every number decomposes into findings, and every finding links to the file, story or Figma node that produced it.
Evidence98% confidenceButtonFigma / Core / Button- Identical component name
- 5 of 5 variants match
- Description describes the same purpose
- Confirmed by a maintainer
05
Hand it to the agents
The parts of your system that are ready become retrieval-oriented context, exposed over MCP so Claude Code, Codex and Cursor can query it directly instead of guessing from a component name.
search_componentsMCPintent: “let someone pick a date range”
DateRangePicker0.97
avoid DatePicker
DatePicker selects a single date only.
What a run produces
- A component inventory
- Every component Onefold could find, where it lives, what it exports, its props and variants, the stories that exercise it and the documentation that mentions it.
- A system graph
- The components, tokens, stories and documents as nodes, with typed relationships between them: implements, uses token, has variant, documented by, composed of.
- A readiness assessment
- Eight dimensions, each with its own evidence, combined into one score. The model is documented in full on AI Readiness.
- A findings list
- The specific gaps, ordered by how much they cost you: components with no usage guidance, no negative guidance, no examples, literal values instead of tokens, ambiguous neighbours.
- A run record
- What was analysed, when, how long it took, what was discovered and what failed. Analysis is observable rather than magic.
Parsers first, models second
The order matters more than it sounds. Discovery is deterministic: an AST walk finds exports, props and token references, and it finds the same ones tomorrow. Models are used where judgement is genuinely required, such as deciding whether two similarly named components mean the same thing, and they are given the minimum context that specific question needs.
This is the difference between a tool you can trust with a hundred-component system and a demo that works on ten. It also means your repository is not shipped wholesale to a model provider, which is covered in detail on Security.
Provenance is not optional. Every assertion records whether it came from a source fact, a deterministic derivation, a model inference or a human confirmation, along with its evidence and confidence. Ask why a mapping exists and you get a list you can check. A human confirmation always outranks a model inference.
What Onefold is not
- Not a component library. It hosts nothing and becomes no part of your build.
- Not a documentation site. Your docs stay where they are. Onefold reads them.
- Not a Figma replacement. Design stays in Figma.
- Not a chatbot on top of your design system. The intelligence sits in the product and in what agents can query, not in a chat window.
Run it against a real repository
Early access begins with GitHub. Connect the repository that holds your design system and read the first report.
Request early access