Sync Responsive Figma From Web

Treat the latest accepted Web frame as the source of truth for approved visual changes. Refine the existing Pad and Mobile frames in place while preserving valid device-specific structure and interaction.

Load dependencies

Before Figma reads or writes:

1. Load and follow the installed figma-use Skill.
2. Use context-first-design-execution when the request continues an existing design task or uses referential language.
3. Use cross-device-recomposition-spec only when device structure or breakpoint behavior remains unresolved.
4. Use enforce-ui-visual-restraint only when the user also requests general cleanup of spacing, dividers, containers, or surface colors. Track that audit separately from synchronization.

Read responsive-delta-ledger.md when more than one module or delta family is in scope. It is the canonical worksheet for source evidence, Copy/Translate/Recompose/Preserve decisions, exceptions, and parity proof.

Lock the sync contract

Record:

• the authorized Figma file and exact Section;
• the newest accepted Web root frame;
• the existing Pad and Mobile root frames;
• the specific Web edits that must propagate;
• content, media, routes, states, and device-specific structures that must remain;
• shared components and unrelated frames that are out of scope;
• the available recovery point or automatic history limitation.

Interpret “按 Web 调整” as an incremental visual and geometric sync. Preserve valid Pad/Mobile reflow, touch patterns, visible information, and semantic order. Do not scale the Web frame proportionally or regenerate the whole page.

Match semantic modules

Match Web, Pad, and Mobile modules by content and role rather than layer name or canvas position alone.

For every matched module, record a compact delta ledger:

Capture structure and rendered screenshots. Variable bindings or node counts alone cannot prove parity.

Distinguish transfer from recomposition

For each source delta, choose one action:

• Copy — use the same token, color, type style, radius, icon, or component state.
• Translate — preserve the same visual relationship with device-appropriate dimensions.
• Recompose — change columns, order, disclosure, or interaction while preserving hierarchy and meaning.
• Preserve — keep an intentional target-specific treatment that is unaffected by the Web edit.
• Block — stop when the target lacks a safe mapping or the required change exceeds the authorized scope.

Do not treat numeric equality as the goal. A Web two-column module may become a Pad split layout and a Mobile stack while retaining the same hierarchy, emphasis, and component identity.

Sync geometry completely

When an approved Web change affects layout, compare three levels:

1. Inside an item — label-to-value, heading-to-body, icon-to-text, control padding.
2. Inside a module — row gap, card gap, column gap, text-to-media distance.
3. Between modules — section padding, transition gap, long-page rhythm, footer offset.

Apply these rules:

• Translate relationships from the newest Web geometry and approved design-system rhythm; avoid arbitrary values.
• Preserve the relative hierarchy of gaps across target viewports.
• Recompute text width and wrapping before accepting derived row or module heights.
• Recalculate child heights, parent Auto Layout, root-frame height, Section height, and following-frame positions after vertical changes.
• Inspect min/max constraints, fixed heights, clipping, overflow, and invisible placeholders when the target refuses to fit the translated layout.
• Clear only constraints made obsolete by the approved Web change.

If general excessive whitespace exists outside the mapped Web delta, record it for enforce-ui-visual-restraint; do not silently expand the synchronization scope.

Edit in a stable order

For each module, modify in this order:

1. root width, columns, and outer padding;
2. child widths, text wrapping, and responsive order;
3. internal gaps, row heights, and component sizing;
4. fills, strokes, typography, radii, icons, and media treatment changed in Web;
5. module height, page height, Section bounds, and following-frame positions;
6. device-specific states and interactions affected by the source delta.

Reuse approved components, variables, and styles. Preserve component linkage. Do not detach instances or change shared main components unless the user explicitly includes that scope.

Validate a specimen before batching

Choose one difficult Pad module and its Mobile peer for each source-delta family. Prefer long text, dense indexes, forms, media compositions, or sections already called out by the user.

For each specimen:

1. capture the Web source, target before state, and target after state;
2. verify the semantic module match and chosen Copy/Translate/Recompose/Preserve action;
3. compare geometry, typography, component treatment, media behavior, and total module height;
4. inspect the complete target root for clipping, overflow, and long-page continuity;
5. confirm the requested Web delta visually at the same review scale;
6. correct the mapping rule before applying it to sibling frames.

Batch only after the specimen passes. A token match does not authorize propagation when the requested delta also changes geometry or responsive composition.

Run final parity QA

Check every scoped Web/Pad/Mobile group for:

• every requested Web delta mapped to each target or explicitly excepted;
• visual hierarchy, component identity, and media treatment aligned;
• text-box width and wrapping appropriate to the device;
• intentional target-specific order, disclosure, and interaction preserved;
• no clipping, overlap, horizontal overflow, or hidden footer content;
• root and Section heights fitted after the mapped edits;
• content, links, images, data, and states unchanged unless authorized;
• shared components and out-of-scope frames unchanged.

Return Pass, Open, or Blocked for cross-device parity. If enforce-ui-visual-restraint also ran, return its spacing, divider, container, and surface-color status in a separate block.

Handoff

Return:

1. source Web frame and target Section scope;
2. locked content and preserved responsive behaviors;
3. source deltas and their Copy/Translate/Recompose/Preserve mappings;
4. before/after parity proof for each representative module;
5. frame-level Pad/Mobile parity status;
6. shared-component and recovery-history status;
7. explicit exceptions or unresolved mappings;
8. separate visual-restraint results only when that Skill was also in scope.