stitch-to-react
Stitch to React
Convert Google Stitch exports (Tailwind HTML + PNG) into React components with full design system integration.
Core Philosophy: Decompose Stitch screens into composable React components while respecting established patterns.
Quick Start
0. Verify Exports Exist (Mandatory)
Before any conversion, verify Stitch exports are available:
# Check for HTML/PNG pairs in the expected location
Glob: design-intent/google-stitch/{feature}/exports/*.html
Glob: design-intent/google-stitch/{feature}/exports/*.png
If exports found: Proceed to Step 1.
If exports NOT found:
- Check if user specified wrong path - ask for correct location
- Suggest running
/stitch-generatefirst to create exports - Fall back to design docs: Check
/design-intent/patterns/for established patterns or project directories for screenshots - If no design assets exist, inform user and offer to help create them
Report findings:
Export Check: [PASSED/MISSING]
- HTML files: [count] found
- PNG files: [count] found
- Location: design-intent/google-stitch/{feature}/exports/
1. Load Project Context (Mandatory)
Before any conversion:
- Read
/design-intent/memory/constitution.mdfor project principles - Read
/design-intent/patterns/for established patterns - Detect project design system (Fluent UI, Material UI, custom, etc.)
- Report: "Existing patterns to consider: [list]"
2. Scan Stitch Exports
Stitch exports are located at:
design-intent/google-stitch/{feature}/exports/
├── 01-layout-{name}.html # Tailwind CSS + HTML
├── 01-layout-{name}.png # Visual reference
├── 02-component-{name}.html
├── 02-component-{name}.png
└── ...
From each HTML file, extract:
- Inline
tailwind.config(colors, fonts, spacing) - Custom
<style>blocks (animations, keyframes) - DOM structure for component hierarchy
- Material Symbols icons usage
3. Map to Project Design System
For each Stitch element:
- Check existing patterns - Can we reuse established components?
- Map Tailwind tokens - Convert to project design tokens
- Decompose into composable parts - Break screens into smaller, reusable components
- Flag conflicts - Note when Stitch output differs from patterns
4. Generate React Components
Output structure:
src/components/{feature}/
├── {ComponentName}.tsx # Main component
├── {SubComponent}.tsx # Decomposed smaller components
├── tokens.ts # Design tokens from Stitch config
├── types.ts # TypeScript interfaces
└── index.ts # Re-exports
Component Selection Priority
Per constitution principles:
- Existing project components from
/design-intent/patterns/ - Framework components (Fluent UI, project design system)
- Custom components (document with header comment)
Conflict Resolution
When Stitch output conflicts with patterns:
## Design Conflict Detected
**Element**: Button border-radius
**Stitch Output**: 4px
**Existing Pattern**: 8px (button-styling.md)
### Options
1. Follow Stitch output - Use 4px
2. Use existing pattern - Use 8px
3. Update pattern - Make 4px the new standard
Which approach?
Custom Component Documentation
/**
* CUSTOM COMPONENT: ComponentName
* Source: Stitch screen name
* Base: @fluentui/react-components/ComponentType (if applicable)
* Reason: Why custom implementation was needed
* Created: YYYY-MM-DD
*
* Original Reference: design-intent/google-stitch/{feature}/exports/{screen}.png
*/
Reference Documentation
- Detailed workflow: See WORKFLOW.md
- Usage examples: See EXAMPLES.md
- Common issues: See TROUBLESHOOTING.md
Invocation
Triggered by:
- User references
design-intent/google-stitch/exports - "Convert Stitch output to React"
- "Stitch to React" requests
- Processing directories with HTML + PNG pairs from Stitch
More from joaquimscosta/arkhe-claude-plugins
skill-validator
Validate skills against Anthropic best practices for frontmatter, structure, content, file organization, hooks, MCP, and security (62 rules in 8 categories). Use when creating new skills, updating existing skills, before publishing skills, reviewing skill quality, or when user mentions "validate skill", "check skill", "skill best practices", "skill review", or "lint skill".
30domain-driven-design
Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls.
26code-explanation
Explains complex code through clear narratives, visual diagrams, and step-by-step breakdowns. Use when user asks to explain code, understand algorithms, analyze design patterns, wants code walkthroughs, or mentions "explain this code", "how does this work", "code breakdown", or "understand this function".
22generating-changelog
Analyzes git commit history and generates professional changelogs with semantic versioning, conventional commit support, and multiple output formats (Keep a Changelog, Conventional, GitHub). Use when editing CHANGELOG.md, CHANGELOG.txt, or HISTORY.md files, preparing release notes, creating releases, bumping versions, updating changelog, documenting changes, writing release notes, tracking changes, version bump, tag release, or when user mentions "changelog", "release notes", "version history", "release", "semantic versioning", or "conventional commits".
21workflow-orchestration
>
19deep-research
>
18