Design Continuity Guard

Design Continuity Guard

Purpose

Keep new UI work native to the current page. Before changing styles, recover the site's existing color language, section rhythm, component grammar, and brand constraints; then reuse or extend them conservatively.

This skill is a guardrail, not a generic design generator. It should reduce random new colors, one-off gradients, mismatched components, and section backgrounds that break the page.

Fast Path

For a small style or content change:

1. Read local memory and design notes if present: AGENTS.md, agents.md, DESIGN.md, design.md.
2. Inspect the target section plus the previous and next visible sections.
3. Inspect the CSS/SCSS/Tailwind tokens that already style those sections.
4. Reuse existing variables, classes, gradients, and text colors whenever they fit.
5. Verify the changed area in desktop and mobile if layout or contrast could change.

Do not invent a new palette for a localized change.

Visual Audit

Before adding a new section or changing a background:

• Identify the page sequence: hero, proof, features, catalog, cases, FAQ, CTA, contacts, footer, etc.
• Record each nearby section's background, heading color, text color, card surface, CTA style, and visual weight.
• Determine the page rhythm: light/dark alternation, neutral/accent cadence, gradient placement, image-led sections, card density.
• Find brand tokens: CSS custom properties, Tailwind theme values, repeated hex/rgb/hsl colors, named utility classes, button classes.
• Check whether the target slot needs contrast, rest, or emphasis.

If the system is unclear, run the palette extractor:

bashCopy code
python3 /path/to/design-continuity-guard/scripts/extract_visual_palette.py --root .

Use its output as evidence, not as the only source of truth.

Decision Rules

• Prefer existing CSS variables and reusable classes over new raw color values.
• Add a new color only when no existing token covers the needed role and the user asked for a new visual direction.
• Do not add a new gradient if the page already has a recognizable gradient language; reuse or adapt the existing gradient.
• Do not make every new section accent-heavy. Preserve alternation between high-emphasis, neutral, and rest sections.
• Avoid placing two visually heavy sections next to each other unless the current page already uses that pattern.
• If a new section sits between two similar backgrounds, choose a compatible contrast layer or a subtle divider rather than a random accent.
• If it sits between a neutral section and a CTA/accent section, usually keep the new section calmer than the CTA.
• Maintain heading hierarchy: use existing heading colors, accent spans, eyebrow labels, and max-width patterns.
• Maintain card grammar: border radius, border color, shadow, surface, icon background, and hover states should match nearby cards.
• Check contrast when changing foreground/background. If contrast is uncertain, choose the more conservative existing pair.

Section Recommendation

When proposing or implementing a new section, decide these fields before editing:

textCopy code
Position:
Neighboring sections:
Section role: neutral / proof / feature / CTA / transition / content-heavy
Background:
Heading color:
Text color:
Accent:
Cards:
CTA:
Reusable classes/tokens:
What not to add:
Verification:

Keep this internal for implementation tasks unless the user asks for a recommendation first.

When To Read References

• Read references/section-rhythm.md when adding, reordering, or moving a section.
• Read references/color-audit.md when brand colors/tokens are unclear or CSS is large.
• Read references/decision-rules.md when choosing between several plausible backgrounds or accent styles.

Verification

For visual changes:

• Run the project's build or syntax check when available.
• Use browser screenshots or inspection for desktop and mobile when section layout, background, heading color, or CTA changes.
• Check the target section together with its previous and next sections, not in isolation.
• If screenshots show a new block looking detached from the page, revise colors/classes before finalizing.

Memory Boundary

Follow the project's own AGENTS.md/agents.md rules for memory updates. Add or update design memory only when a stable visual rule was discovered, such as a canonical brand token, section rhythm rule, or deprecated color pattern. Do not save one-off experiments.