Flash DSM

Design systems were built for designers and developers. A Design Genome is built for agents. The tools changed, and so did the way we design. When Claude writes the UI, it needs your design language, not a generic look. Flash DSM serves one product's design system to Claude as a Design Genome: the colour roles, the type and spacing scales, the components, the composition rules, and how they connect. **What Claude does with it** - Reads the roles, scales and rules before it builds, and uses the components your system defines instead of making a new button every time. - Runs `check_violations` on the code it wrote and gets a Genome score from 0 to 100. It names hand-built components, colours from outside the system, hardcoded values that already have a token, and text that fails WCAG AA contrast, each with the fix. - Tells you the score and what it changed to reach it. **Access** On Flash's consent screen you pick the design system and the access. Read only gives Claude the read tools and nothing else. Read and propose adds tools that file token and change proposals, which wait on the Sync page until a person in Flash accepts them, record syncs from a codebase or a Figma file, and create a new design system from a code scan. One tool, `apply_code_scan`, brings code changes from a repository linked through Flash Genome straight into the system without a review card. Nothing is ever deleted. Claude calls Flash's own API at flashdsm.com.