Google stitch extract frontend design system
Skill host452b/polish/skills/google-stitch-extract-frontend-design-system
Claude Code skill/plugin that rewrites a raw question into a high-performing LLM prompt by auto-selecting research-backed prompt-engineering strategies.
npx -y skills add host452b/polish --skill google-stitch-extract-frontend-design-systemAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 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
Use when an existing frontend repository needs its visual language, design tokens, styling inconsistencies, component patterns, or responsive rules documented directly from source code, including when the application cannot build or run.
SKILL.md
2.9 KB, as published. Nobody here has run it
Extract Frontend Design System
Overview
Reverse-engineer the design system from source without requiring a working build. Produce an evidence-backed DESIGN.md that another agent can use without rereading the repository.
Workflow
- Map coverage. Identify frameworks, styling systems, package boundaries, entry points, global styles, theme files, shared components, and representative pages. Record what was inspected and what was unavailable.
- Load the relevant reference. Read only the matching guide: React/Tailwind, Vue, Svelte, Angular, or plain CSS/Sass/Less. Use multiple guides only for a mixed stack.
- Collect evidence. Extract declared and actually used colors, type styles, spacing, radii, borders, elevation, breakpoints, layout primitives, imagery, motion, and component states. Cite file paths, selectors, token names, or components.
- Normalize carefully. Separate aliases from duplicates, declared tokens from one-off values, and global rules from component exceptions. Flag near-duplicates and contradictions; do not silently choose a winner.
- Explain intent. Label each conclusion as Observed, Inferred, or Unknown. Infer atmosphere and hierarchy only from repeated evidence. Never invent missing fonts, breakpoints, states, or brand rationale.
- Write the contract. Create or update root-level
DESIGN.mdusing design-md-template.md. Preserve coherent existing conventions and list proposed normalization separately. - Verify coverage. Confirm the document covers tokens, typography, components and states, layout, responsiveness, motion, accessibility-relevant styling, inconsistencies, and implementation guidance.
Quick Reference
| Evidence | What to capture |
|---|---|
| Theme/config | canonical token names, aliases, modes |
| Global CSS | resets, variables, base typography, breakpoints |
| Shared components | variants, states, composition rules |
| Representative pages | grid, density, hierarchy, exceptions |
| Inline or arbitrary values | drift, intentional exceptions, migration candidates |
Common Mistakes
- Running or repairing the application when source inspection is sufficient.
- Listing values without semantic roles or provenance.
- Treating every declared token as used.
- Collapsing close colors or spacing values without evidence.
- Describing one page as the whole product.
- Mixing current facts with redesign recommendations.