02 — ORGANIZE AND APPLY VARIABLES

Create a coherent variable system and replace suitable raw values with verified bindings while preserving the design.

Copy everything between BEGIN PROMPT and END PROMPT into your agent.

BEGIN PROMPT

Audit and improve how variables are organized and used throughout my Webflow project, with a verified pilot before broad changes.

HOW TO WORK WITH ME
Act as an experienced Webflow developer and a thoughtful partner. Inspect what you can discover before asking me questions. Explain technical choices plainly, recommend a sensible option, and ask three to five focused questions at a time. Skip questions already answered by reliable project evidence or our conversation. Do not ask me for IDs, mappings, or technical details you can retrieve yourself.

Keep four categories distinct: observed facts, my confirmed decisions, your recommendations, and unresolved assumptions. A pattern on the site is not automatically an approved convention. Record my answers as specific decisions. Do not turn an unanswered question into a permanent rule. Continue independent work while waiting for an answer; pause only the work that depends on it.

First identify the intended project and verify its hostname. Distinguish production, staging, and demo copies. Discover MCP Router for Webflow before concluding Webflow access is unavailable. When present, use list_projects, prepare_project to load all enabled rules and relevant skills, and get_project_operations to discover permitted actions and schemas. Briefly state which instructions you loaded. Refresh preparation or changed instructions before dependent writes.

With a direct Webflow MCP connection, discover and read all enabled rules and relevant skills through its instruction tools. Do not use the browser Instructions panel for this when MCP access is available. If instructions cannot be accessed, explain the limitation and continue read-only investigation. Missing direct tools alone is not an authentication failure; inspect tool discovery and registration. Recommend reauthorization only when a tool explicitly reports an authentication failure.

Prefer supported MCP operations. Use the browser for necessary visual checks or a capability genuinely absent from the available tools, within the same authorized scope. Do not bypass denied permissions using another connection or browser. Router controls apply to routed operations, not automatically to browser actions. Never extract credentials or put secrets in reports, prompts, or saved instructions.

This prompt authorizes inspection, questions, and a concrete proposal. If I have already authorized an implementation scope, proceed within it. Otherwise, make the proposed changes reviewable before asking me to authorize that scope. Offer a small pilot and the intended rollout together so I can authorize both if appropriate. Once authorized, do not ask for approval for every routine operation. A failed pilot, material scope change, or newly discovered shared impact needs a focused decision. Never treat elapsed time or silence as approval.

Preserve appearance, responsive behavior, content, and functionality unless I explicitly request a change. Do not publish, delete resources, change URLs, or migrate shared structures without the relevant authorization. Flag actions that can affect live content/settings without a separate publish step. Prefer an inspectable draft or agreed test area; do not publish merely to get a preview.


PRELIMINARY STYLE TRIAGE
Before rebinding styles, reuse or create a concise keep/merge/retire/unknown map for the affected classes. Inspect usage and dependencies, identify the intended surviving classes, and distinguish approved decisions from tentative candidates. This is a targeted review, not a requirement to finish the full style cleanup first.

Bind variables to retained styles and verified consolidation targets. Avoid spending time migrating styles that can safely be retired or remapped first within authorized scope. When a small verified consolidation prevents substantial duplicate work, propose or perform that prerequisite within the agreed scope, then apply variables to the survivor. Do not choose a survivor or merge semantic roles just because values match.

A class with live consumers remains active until those consumers have been remapped and checked. If consolidation is deferred or uncertain, either preserve its current behavior and record its variable migration as pending, or include it where necessary for a complete authorized pilot. Do not report skipped active styles as migrated. Track prerequisites, variable bindings, and remaining style cleanup separately. Once variable changes pass their checks, hand the updated map to Prompt 3 for the remaining framework, naming, consolidation, and orphan cleanup.

INSPECT THE CURRENT SYSTEM
Read variable collections, names, types, values, aliases and modes where supported, and their actual use in styles and components. Inspect representative colors, typography, spacing, sizing, radii, and other supported reusable values. Include responsive differences and relevant interaction states. Expand inventories enough to support the claimed scope; report unknown bindings rather than guessing.

Identify existing variables to reuse; repeated raw values that represent a common design decision; inconsistent names for the same role; duplicate variables; unused candidates; and intentional one-off values. Equal numeric/color values are not proof of identical meaning. A border color and body-text color can intentionally share a current value while needing different future control.

TARGETED INTERVIEW
- Which brand/design guidelines and existing pages are authoritative?
- Which apparent differences are deliberate versus accidental?
- Which decisions should change together across the site, and which need independent control?
- Are there themes, brand variants, modes, locales, or responsive requirements to preserve or support?
- Does the team already have naming conventions or a design-system source of truth?
- Is this strictly a visual-preservation cleanup, or are particular visual changes also requested?
- Which shared consumers can be included in the pilot and later rollout?
Recommend a concrete naming/organization approach based on the actual site. Do not ask the user to choose every token name or raw value.

PROPOSE THE TARGET SYSTEM
Prefer a small understandable system over unnecessary abstraction. Reuse existing collections and roles when coherent. Use semantic names where they communicate intent; preserve a useful primitive layer when the site already has one or the need is clear. Do not add layers or modes speculatively.

Provide a table: source value or variable; semantic purpose; proposed existing/new variable; verified value; type; collection/mode; affected consumers; and exceptions. Distinguish adding a variable from binding styles to it. A newly created palette alone does not mean the site uses variables.

Preserve units, inheritance, computed behavior, breakpoint overrides, and modes. Replacing a responsive or relative value with a fixed value is not a cleanup. Avoid collapsing roles purely because their current values match. Keep deliberate one-offs where variable abstraction brings no benefit; document the reason. “Variables throughout” means appropriate reuse across the agreed site scope, not converting every literal indiscriminately.

IMPLEMENT A REPRESENTATIVE PILOT
Choose one component or section that exercises several roles, including a responsive or state variation if relevant. Verify the current values and dependencies; create only the missing variables and bind the intended styles. Do not change global values to make an unrelated component match. Compare actual appearance and behavior before and after.

Check relevant themes/modes and breakpoints, text wrapping, spacing, contrast preservation, and interactive states. Investigate differences instead of masking them with new overrides. Record which consumers were migrated and which still use raw values.

ROLLOUT AND CLEANUP
After a passing pilot, migrate the authorized scope in batches. Refresh shared styles before edits and verify consumers. Track variable creation, binding migration, and verification separately. Consolidate duplicate variables only after checking semantic meaning and all known references. Rebind consumers before retiring a duplicate. Delete unused variables only with verified absence of required consumers and applicable authorization; otherwise list candidates.

DELIVER A MAINTAINABLE RESULT
Report the final organization, actual binding coverage within the inspected scope, justified raw-value exceptions, unmigrated consumers, and unverified areas. Supply concise conventions for when to reuse a variable and when to introduce one. These decisions should become verified references in Prompt 6, not a static list of values copied forever into rules.


EXECUTION AND VERIFICATION
Before implementation, capture the relevant starting state and establish a supported recovery approach proportional to the change. Inspect dependencies and refresh mutable records before updating them so you preserve concurrent human edits. Do not promise an automatic rollback you have not verified is available.

Start with one representative example in the agreed scope. Read back the changed data and inspect the affected page/component at relevant desktop and mobile widths. Check states, links, content, and interactions appropriate to the task. A successful tool response is not sufficient evidence of a correct result. If you cannot perform a check, state that limitation explicitly.

After the pilot passes, expand within the authorized rollout scope in bounded batches. For shared changes, check representative affected consumers, not only the page used for the pilot. Stop and resolve regressions before expanding. Maintain a concise change ledger containing stable identities, intended action, previous/new state or recovery reference, and verification status. Inspect current state after an ambiguous write before retrying.

For substantial repetitive work, discover bulk capabilities, reuse paginated inventories and ID maps, measure a small batch, and improve the workflow if projected runtime is excessive. Batch independent-resource work with cautious bounded concurrency; serialize shared definitions and dependent changes. Respect throttling. Save resumable checkpoints atomically at batch boundaries, with completed, unverified, pending, and blocked work separated. Do not log credentials or signed upload fields.

Finish with the result links, decisions applied, changes completed, checks actually performed, remaining work, and the next useful action. Separate observed fixes from hypotheses. Do not claim conversion uplift, ranking improvement, complete accessibility compliance, or complete site coverage without evidence. Finish with the concrete Webflow instruction recommendation described below.

CAPTURE THE LEARNING IN WEBFLOW
At the end of this audit or implementation, explicitly recommend whether to create or update instructions on the Webflow project so future agents can use what we learned. Do not postpone all documentation until Prompt 6. If existing instructions already cover the verified outcome, say so and avoid unnecessary additions.

Inspect the current instruction inventory again before proposing changes. Prefer a targeted update to an existing rule, skill, or shared reference over another overlapping document. Use short rules for standing expectations, a focused skill for a repeatable procedure, and shared references for detailed project context. Only create a new skill when there is a useful recurring workflow to describe.

Capture variable semantics, naming, collections/modes, reuse and creation criteria, verified bindings, and justified exceptions. Reference actual variables and relevant styles instead of copying mutable values into permanent prose.

Separate observed facts, user-confirmed intent, verified implementation outcomes, and unresolved recommendations. Only confirmed intent and verified current behavior should become operative guidance. An audit-only engagement may still justify guidance describing established conventions, but proposed future improvements must remain clearly marked as proposals. Do not encode accidental inconsistencies as policy or present unperformed checks as passed.

Provide a concrete instruction proposal: target rule/skill/reference, create or update, reason, complete proposed wording or exact revision, verified resource references, and intended enabled status. Use supported Webflow dynamic references for components, classes/styles, variables, CMS resources, and other relevant resources. Discover the actual supported types and syntax; never invent tokens or treat a typed resource name as a binding. Explain each referenced resource's intended use.

If installation or maintenance of instructions is already authorized, make the relevant updates within that scope. Otherwise finish the draft first and offer a clear next action such as “Save these proposed instructions to this Webflow project.” Do not treat that suggested reply as authorization already given. Avoid an extra approval step for updates already authorized.

After writing, read back the content, verify dynamic references resolve to the intended resources, and check enabled status. Report proposed, saved, enabled, and tested separately. If permissions or tooling prevent installation, provide the exact draft and limitation. Keep secrets, transient logs, full audit dumps, and unresolved assumptions out of operative instructions. Carry this instruction map forward to Prompt 6 for consolidation and a broader workflow test.


Start by inspecting variables and representative style bindings. Return the current structure, a proposed mapping for a small pilot, and the questions needed to settle intent.

END PROMPT
