03 — STANDARDIZE AND CLEAN UP STYLES

Identify the existing framework, improve naming, consolidate genuine duplicates, and remove verified orphan styles without visual or functional regression.

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

BEGIN PROMPT

Audit and improve my Webflow styling framework and clean up poorly named, duplicate, and genuinely orphaned styles.

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.


USE THE PRELIMINARY MAP AND VARIABLE WORK
Read the audit's keep/merge/retire/unknown map and the verified outcomes of Prompt 2 if available. Refresh live state rather than repeating the whole investigation. Complete the remaining cleanup while preserving the established variable semantics and bindings. When consolidating, compare bindings and intended roles as well as current appearance. Recheck resource references after renaming or retiring styles.

If this prompt is run first, do not block useful inspection. Settle the surviving class structure, perform only authorized prerequisites that prevent wasted binding work, and recommend Prompt 2 before a broad cleanup that depends on unresolved variable conventions. Return to this prompt afterward. Do not run two competing migrations against the same shared styles at once.

ESTABLISH THE EXISTING FRAMEWORK
Inspect classes, utilities, custom classes, combo classes, wrapper structure, variables, breakpoints, states, and representative component/page usage. Determine whether the site follows Client-First, another coherent framework, mixed conventions, or no clear system. Identify the actual version/conventions when possible; do not infer full compliance from a few familiar names.

If a coherent framework exists, preserve it and recommend targeted improvements. If there is no coherent framework, propose Client-First as a candidate, explain how it would help this team, and agree scope before migration. Consult current primary Finsweet documentation for the conventions you intend to apply. Do not force Client-First onto a sound alternative or promise that renaming classes alone converts a site to a framework.

TARGETED INTERVIEW
- Is the observed framework intentional, and who maintains it?
- Which pages/components represent the desired standard? Which are legacy or exempt?
- Are there established naming rules or vocabulary to preserve?
- Are external scripts, analytics events, integrations, tests, or third-party services coupled to class names? What exists outside the project that inspection cannot reveal?
- Must every change preserve visual and functional behavior, or are specific exceptions requested?
- Should the pilot be limited to one component/page, and which shared resources may the rollout affect?
- May verified orphan classes be deleted, or should they first be delivered as a review list?
Use inspection to avoid asking questions already answered. Do not assume the user knows all dependencies; state what you verified and what remains uncertain.

CLASSIFY CLEANUP CANDIDATES
1. Naming: unclear autogenerated names, inconsistent terminology, misleading purpose, or deviations from the agreed convention. Propose understandable names and map old to new.
2. Duplicates: classes that may have equivalent responsibilities and behavior. Compare their complete declarations, inheritance, combo relationships, breakpoints, states, variable bindings, and relevant dependencies. Similar current appearance is insufficient evidence.
3. Orphans: styles with no required consumers after comprehensive relevant usage/dependency checks. A class absent from one page or the currently rendered DOM is only an unused candidate.
4. Framework gaps: inconsistent wrappers/utilities, unnecessary overrides, style responsibilities in the wrong layer, or conflicting conventions. Keep structural adjustments distinct from simple renames.

DEPENDENCIES TO INSPECT
Check static pages, component definitions and instances, CMS templates and bound content, hidden/conditional elements, relevant locales, combo/base relationships, interactions, embeds, custom scripts/styles, and any known external selectors or automation. A class used only as a JavaScript hook can be intentional even without styling. A class needed as a combo base is not disposable because it looks empty.
Where global usage cannot be established through available tools, mark the class uncertain and do not delete it. Do not claim an orphan cleanup is complete if only a sample was inspected. External dependency uncertainty should be named rather than silently ignored.

PROPOSE A CONCRETE CHANGE MAP
For each candidate list: verified identity; current name; proposed name/action; reason; usage/dependency evidence; affected consumers; required coupled updates; preservation checks; and recovery reference. Separate high-confidence cleanup from decisions requiring more evidence.

PILOT AND ROLLOUT
Choose a manageable representative example. Preserve the cascade, specificity, class ordering semantics, breakpoints, states, layout, interactions, and editor usability. When renaming, update verified selectors and references that depend on the old name as part of the same authorized change. If those updates are outside accessible/authorized scope, keep the old name and explain the dependency.

For consolidation, choose the retained class based on purpose and the agreed framework, remap consumers intentionally, and verify the result before retiring duplicates. Avoid replacing semantic clarity with one generic class simply because two declarations match today.

For orphan deletion, prove the relevant absence of consumers/dependencies, retain recovery information, and apply the authorized deletion scope. Do not run an indiscriminate “remove all unused styles” action without establishing what its usage detection covers. Shared styles require representative consumer checks beyond the pilot page.

SPECIFIC ACCEPTANCE CHECKS
Compare relevant desktop/mobile layouts, wrapping, spacing, images, hover/focus/active states, interactions, visibility, navigation, links, and code-dependent behavior before/after. Include template and component consumers where affected. A class rename that leaves the static screenshot unchanged but breaks a script is a regression.

Finish with counts and resource-level mappings for renamed, consolidated, and removed styles, plus retained exceptions and unresolved candidates. State which framework conventions now apply and what remains outside the completed scope. Preserve the distinction between “cleanup completed in this scope” and “entire site standardized.”


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 the agreed framework and naming conventions, retained classes, cleanup dependencies, and the verified rename/consolidation outcomes relevant to future work. Update references to renamed or retired styles; keep detailed migration logs separate from standing instructions.

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 with the current class strategy and candidate inventory. Return your framework assessment, targeted questions, and a proposed pilot with an explicit old-to-new mapping.

END PROMPT
