Reverse-engineering a Sketch file (or Figma export with similar shape) into pixel-perfect React + CSS — the iteration mental model, tree reconstruction, layout inference algorithms, geometry math, visual-regression diffing, and the style/typography/path conversions that make "improvement without regression" enforceable. Trigger even if the user doesn't explicitly mention "algorithms" but is converting a design source into web code, building a design-to-code pipeline, or struggling to make incremental fidelity improvements without breaking previously-converted output.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Reverse-engineering a Sketch file (or Figma export with similar shape) into pixel-perfect React + CSS — the iteration mental model, tree reconstruction, layout inference algorithms, geometry math, visual-regression diffing, and the style/typography/path conversions that make "improvement without regression" enforceable. Trigger even if the user doesn't explicitly mention "algorithms" but is converting a design source into web code, building a design-to-code pipeline, or struggling to make incremental fidelity improvements without breaking previously-converted output.
dot-skills Design-to-React Conversion Best Practices
The reverse-engineering pipeline that converts Sketch files into pixel-perfect React + CSS, with regression-safe iteration as the load-bearing constraint. The skill is organized around the cascade effect of design-to-code conversion: a wrong call in stage N corrupts every output from stage N+1 onward, so categories are ordered by how much downstream they own.
The user's primary requirement — "each improvement doesn't cause regressions" — is enforceable only if the iteration loop, the layer tree, and the layout solver are correct before you start polishing styles. Read the rules in priority order.
When to Apply
Building a converter that ingests a .sketch file (or equivalent design source) and emits React + CSS
Iterating on an existing converter where each improvement risks breaking other components
Diagnosing why a converted component "almost matches" the design but visual-regression fails
Designing the snapshot-gate / baseline strategy for a design-to-code pipeline
Choosing between flexbox vs grid vs absolute positioning when the source is freeform geometry
Translating Sketch-specific primitives (MSImmutableFlexGroupLayout, attributedString, curvePoint, MSImmutableStyleCorners) into idiomatic CSS
Rule Categories by Priority
The ordering is the cascade — fix earlier stages first; later-stage fixes are wasted if the upstream tree is wrong.
Start with the iteration strategy (iter-*) — without the regression gate, every other rule is just techniques
Then tree (tree-*) and layout (layout-*) — these are the load-bearing structural decisions
Then geometry (geom-*) and diff (diff-*) — these are the precision and validation layers
Style, type, and path are the polish layer — high fidelity but mostly local impact
For a brand-new converter, follow the rules in priority order. For an existing converter, identify which stage owns the regression you're seeing (use [[diff-subtree-bisection-to-localize-regression]] + [[diff-perceptual-hash-for-wrong-component-detection]] to triage) and fix at the highest stage that owns it.
