Integration

GitHub

The code is where your design system actually is, whatever the documentation says. Onefold reads it through a GitHub App with read-only permissions, on the repositories you pick.

How access works

Onefold uses a GitHub App, not your personal OAuth session. You install it on the organisation and choose repositories during installation, which means access is scoped by GitHub itself rather than by us promising to behave. Revoking the installation revokes everything, immediately, from GitHub's side.

The app requests read access to repository contents and metadata. It does not ask for write access, and it will not until there is a feature that genuinely needs it. When pull request checks ship, that will be a separate, visible permission change you approve.

Analysis runs against short-lived installation tokens, in a background job rather than inside a web request. Tokens are never logged and never leave the server.

What the parsers extract

Components
Component files, exported symbols, props and their types, variants, defaults, composition, and the doc comments attached to them.
Tokens
CSS custom properties, Tailwind configuration, token JSON, Style Dictionary output and theme files. No assumption that you use one token technology.
Stories
Storybook configuration, stories, meta, args and controls. Covered separately on Storybook.
Documentation
READMEs, component docs, Markdown and MDX, contribution guidance, and any AGENTS.md or CLAUDE.md already committed. If you have written rules for agents, Onefold reads them rather than replacing them.
Structure
Framework and package detection, export paths, and the dependency relationships between components. React and Next.js are supported first.

What leaves your repository

May be sent, per question

  • One component's signature and doc comment, to classify its purpose
  • Two component names and their variants, to judge a mapping
  • A description, to check whether it distinguishes the component

Never sent to a model

  • Your repository as a whole
  • Files unrelated to the design system
  • Secrets, environment files or credentials
  • Git history and author information
  • Anything at all, unless a specific analysis question needs it

The asymmetry is the point. Deterministic parsers do the reading; models are asked narrow questions with the minimum context those questions need. Full details on Security.

Keeping up with changes

A design system is a moving target, so analysis is repeatable rather than one-off. Runs can be triggered manually, and webhooks keep the graph current as the repository changes. Each run records what it found and what changed, so a readiness score moving is always traceable to something specific.

You do not need to configure the repository. No manifest to add, no annotations to write, no build step to install. If a component is discoverable by an agent, Onefold can find it. If Onefold cannot find it, that is itself the finding.

Point it at your design system repository

One installation, read-only, the repositories you choose. The first report comes back with your component inventory and eight readiness dimensions.

Request early access