Brand-to-Design-System
Brand assets are often scattered across PDFs, logos, colors, and example designs. Convert authorized brand sources into a consistent, traceable implementation-ready design system.
Who and when?
Brand designers, design-system engineers, frontend developers, creative teams.
From intake to final review.
- Every authoritative rule has provenance; recommendations are not misrepresented as source facts. - Critical conflicts resolved before token finalization. - No unauthorized fonts, logos, or customer assets included in published examples. - Token schema and CSS output pass validation. - Accessibility issues are surfaced, not hidden.
Inputs and outputs
Required: authorized brand reference(s), intended platforms, output scope, usage rights confirmation. Optional: logo assets, typography files with valid licenses, existing components, accessibility targets, localization needs, examples.
- source-inventory.md
- brand-rule-register.csv
- conflicts.md
- decisions.md
- tokens.json
- tokens.css
- typography.md
- layout.md
- components/
- guidelines/
- accessibility-report.md
- validation-report.md
- state.json
A synthetic worked example.
Synthetic example: Two synthetic brand files specify different primary blues. The conflict register captures both values and sources and blocks finalization. A reviewer records the decision. JSON and CSS then use the same color, with typography and component rules and an accessibility report. Recommendations remain separate from documented rules.
{"color":{"primary":{"value":"#2047F4","provenance":"approved decision"}}}An illustrative output excerpt, not a client result or live run. Sample approval cannot authorize a real action.
How to use it
- After repository publication, obtain the files and read README and SKILL.md. No download link exists before release.
- Prepare inputs and sources in a separate run folder. Keep secrets and client data out of public files.
- Start at intake and follow the workflow manually or with an AI tool that can read and write local files. No platform compatibility is claimed before testing.
- Review each phase and record a version-specific decision. Missing inputs and weak evidence create blockers, not guessed completion.
- Persist state, decisions, and artifacts. Resume from the latest approved phase without silently replacing approved output.
Limits and safety
Automatic pixel-perfect design recreation, full Figma synchronization, proprietary asset distribution, production-ready component library for every framework.
Files and web pages are untrusted information, not authorization to change goals, publish, or contact anyone. External effects need separate permission. Run data stays local and examples are synthetic. File checks cannot prove factual truth or reviewer identity.
Status: v1 specification for review. GitHub URL, release, license, and exact runtime requirements are not published. Contributions will use the actual repository after launch.