/gridgeist

name: gridgeist
description: Use when creating, redesigning, or reviewing web interfaces that need product-specific structure, clear hierarchy, responsive composition, accessible interaction, or relief from generic AI-generated SaaS aesthetics. Adapt grid, typography, imagery, motion, and product evidence to the established brand—including technical, editorial, image-led, warm, playful, and utilitarian directions—across React, Next.js, Tailwind CSS, HTML/CSS, landing pages, dashboards, documentation, portfolios, and interactive tools.

Gridgeist

Overview

Craft distinctive, product-native interfaces from audience, content, behavior, and brand intent. Use grid as structural logic; make it visible only when it serves the product.

Select a mode

| Intent and authorization | Mode | Start with | |---|---|---| | Build an interface without an existing design | Create | Audience, primary task, content, and evidence | | Change an existing interface with permission to edit | Redesign | Preserved behavior, brand signals, and state inventory | | Diagnose without changing files | Review | Prioritized findings grounded in rendered evidence |

Let user authorization determine whether files change. Permission to redesign does not authorize choosing among materially different visual theses. Derive direction from explicit user intent or established brand evidence; audience, task, product category, and content may inform hierarchy but do not alone confirm a visual thesis. Use the alignment gate below whenever thesis-level ambiguity remains.

Workflow

1. **Inspect** — Understand the audience, primary tasks, brand signals, content, product evidence, routes, components, tokens, and rendered desktop/mobile UI. Inspect existing design-system sources, including `DESIGN.md` when present, and reconcile them with the implementation and rendered evidence rather than assuming they agree. Inventory important interaction states and constraints. Do not invent customers, metrics, outcomes, research, or compliance.

• **Align direction before editing** — Classify the direction as **user-confirmed**, **brand-derived**, or **provisional**. Treat a coherent user direction as confirmed even when it leaves implementation choices open; variations within the same thesis are not material ambiguity. Classify a direction as brand-derived only when existing visual implementation, assets, documented rules, or repeated brand conventions converge on one thesis; product subject matter or copy alone is not enough. When a broad Create or Redesign still supports materially different theses that would change core brand expression, hierarchy, imagery, color, or motion, offer two or three evidence-grounded directions with trade-offs and a recommendation, then ask the user to choose or authorize the recommendation. While the direction is provisional, do not define the replacement system or edit implementation files. Proceed without redundant questions when intent or coherent brand evidence is clear. Do not block Review or narrow repairs; label an unconfirmed Review replacement direction provisional.
• **Hard stop for provisional broad work** — A provisional direction is not an implementable direction. End the turn after the options, trade-offs, recommendation, and alignment question. Do not set a thesis, read the system contract, create tokens, edit files, start implementation, or verify a redesign until the user selects a direction or explicitly authorizes the recommendation.

2. **Set a thesis** — Write one governing sentence combining audience, primary task, structural logic, brand expression, and a product-native motif. Read [design-language.md](references/design-language.md) before choosing the direction, especially for image-led, warm, playful, or otherwise nontechnical brands. 3. **Define the system** — Read [system-contract.md](references/system-contract.md) before making new or changed system decisions. Establish the relevant color, typography, layout, spacing, shape, surface, component, state, media, motion, and responsive rules as one compact contract. Decide whether the grid should be visible, quiet, or invisible. Reuse semantic tokens and existing primitives; keep narrow repairs proportional and do not create a persistent design artifact unless authorized. 4. **Compose** — Build hierarchy before detail. Make one area dominant, align related content, vary sections within shared logic, and let the most authentic material—product UI, data, prose, imagery, artwork, code, or the primary tool—carry visual weight. 5. **Implement** — Preserve required behavior and states. Follow repository conventions, semantic HTML, keyboard and touch behavior, and existing primitives. Recompose mobile layouts rather than shrinking desktop. Avoid dependencies for simple CSS effects. 6. **Verify** — Use [review-checklist.md](references/review-checklist.md). Render representative widths and exercise primary flows, states, focus behavior, reduced motion, overflow, and dynamic content. Fix clarity and hierarchy before polish. Report what was observed separately from what remains inferred or untested.

For interactive products, inventory at least default, loading, empty, error, success, disabled, and destructive states when applicable. Preserve privacy, safety, data, and platform constraints as product behavior, not optional polish.

Coordinate companions

• Keep Gridgeist as the sole owner of product and visual direction. Do not automatically combine it with another broad frontend-design or art-direction skill. If the user explicitly requests both, establish one direction owner before editing instead of silently blending their defaults.
• **Explicit overlap gate** — When the user requests Gridgeist plus another broad visual-design skill, state the overlap and recommend one direction owner before selecting a thesis or editing; use Gridgeist by default for product-native, brand-adaptive work. Do not silently ignore the requested co