A little something to get you started

Audit my Webflow project and help me choose the foundations to improve for dependable AI-assisted work.

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.


DISCOVERY AND COVERAGE
Identify the business, main audiences, conversion goals, important page types, and the existing instructions. Read inventories with pagination where required. Start with a representative set of pages, CMS templates, components, variables, and classes. State exactly what was inspected and what was not. Expand the investigation when dependencies or inconsistent patterns require it. A sample is not a full-site audit, and a visual page crawl alone cannot establish whether a class is unused.

Review these areas:
1. Components: repeated structures, duplicate components, properties, variants, slots, existing instances, descriptions, help text, and preferred-child guidance. Assess catalog coverage against what the AI should be able to select, assemble, or reuse. A currently unique section is a component candidate when it belongs in that intended catalog; repetition is not required. Internal elements can remain within their parent unless independently selectable.
2. Variables: existing variable structure, names, semantic roles, modes/aliases where used, bindings, and repeated raw values. Distinguish genuinely shared design decisions from coincidentally equal values.
3. Styling: the actual framework and conventions, class names, utilities, combo classes, responsive rules, states, potential duplicates, and potentially orphaned styles. Treat orphan/duplicate findings as candidates until dependencies are verified.
4. CMS: collection purposes, field meanings, required values, references, bindings, editorial workflow, naming, and content consistency. Separate poor documentation from structural migration needs.
5. Agent instructions: enabled versus disabled guidance, overlap, contradictions, relevant workflow skills, references, ownership, and meaningful completion checks.
6. Cross-cutting foundations: accessibility basics, responsive behavior, approved content sources, editor usability, and whether important functionality is understandable in Webflow. Note custom code only as a dependency or relevant native-feature consideration; do not propose a standalone code-removal project.

LOOK FOR CONCRETE EXAMPLES
For each material finding, identify affected resources and the evidence. For example: several sections have the same card structure with only a different count; the same variable role has conflicting names; CTA fields are unclear; classes appear unused but may be selected in a script. Do not give an arbitrary “AI readiness percentage.” Avoid claiming comprehensive coverage without comprehensive inspection.

TARGETED INTERVIEW
After initial inspection, summarize what you know and ask the missing questions in small rounds:
- Who maintains the site and who will ask the agent for changes: developers, marketers, agency, client, content editors?
- What are the two or three most frequent tasks? What causes delays or repeated explanations today?
- Which existing sections or building blocks should the AI be able to select and assemble in future work, including those currently used only once? Which should remain outside that catalog?
- Which pages, components, and content are approved examples? Which are experiments, legacy work, or scheduled for retirement?
- Which sources define the brand, content claims, class framework, and editorial conventions?
- What must remain visually and functionally unchanged? Are there relevant locales, devices, accessibility requirements, or integrations?
- What may an agent routinely change, and which shared or live changes need an explicit decision?
- Are other people editing the same areas, and what is the preferred test/recovery arrangement?
Offer recommendations based on inspection. Do not require every answer before producing useful preliminary findings.

OUTPUT THE AUDIT
Create an actionable table with: area; status (working well / needs attention / unknown); evidence and affected resources; recommended change; dependencies and shared impact; verification method; suggested pilot; and matching follow-up prompt.

Prioritize by recurring-task value, impact, uncertainty, and effort. Preserve good existing conventions. Do not turn adoption of AI into a prerequisite to rebuild the whole site. If one confusing component property is the real obstacle, start there.

RECOMMEND A SEQUENCE
Map the findings to this pack:
- Prompt 2: variables and bindings, after preliminary style triage.
- Prompt 3: framework consistency, naming, duplicates, and orphan styles.
- Prompt 4: components and slots built on the verified styles and variables.
- Prompt 5: CMS clarity and controlled structure improvements.
- Prompt 6: coherent rules and focused skills with verified dynamic references.
Default to style triage during the audit, then variables, full style cleanup, and components. Triage means deciding which classes to keep, merge into a named survivor, retire, or investigate; it does not require completing every rename or deletion. Identify high-confidence consolidation that should happen before binding variables to avoid duplicate work. Never delete an uncertain class or skip a live consumer merely because retirement is proposed. Resolve cases where retained and duplicate classes have different semantics before choosing a variable mapping. Adapt the order to real dependencies, including CMS decisions needed by components. Existing rules must be loaded from the start; Prompt 6 consolidates the verified decisions and workflows.

MAKE CONTINUING EASY
Finish with your recommended first pilot and an exact short reply I can use to authorize it, such as: “Implement the proposed pilot on [verified scope]. Verify it and show me the result before expanding.” Also offer an alternative that authorizes a clearly defined rollout after a passing pilot. Do not interpret either suggested reply as already sent.
If I ask you to continue with a recommendation, use the relevant focused prompt in this pack if accessible. Otherwise explain that I should paste it rather than pretending you have read it. Carry forward the audit and interview decisions, refreshing live state where necessary.


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.

Suggest instructions for confirmed working conventions, approved examples, known limitations, and the agreed inspection/verification process. Keep the remediation backlog separate: an audit recommendation is not an implemented convention.

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 read-only discovery. If the project is not identifiable, ask for its name or URL; otherwise inspect it and return initial findings plus the first focused questions.

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.

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.

Audit and improve the component setup of my Webflow project, using any foundation audit and decisions already available.

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.


CATALOG PRINCIPLE
Everything the AI is expected to independently select, assemble, or reuse should be available as a documented Webflow component. Current repetition is not a prerequisite: a section used only once may still belong in the catalog if the AI should be able to use it in future work. Choose meaningful building-block boundaries; internal wrappers and elements can remain inside their parent component unless the AI needs to select them independently. This can justify more components than a workflow based only on existing repetition.

FOUNDATION HANDOFF
Use the verified variable system and style decisions from Prompts 2 and 3 when available. Reuse their actual resources and mappings rather than recreating styles during componentization. Resolve material remaining foundation gaps for the pilot before propagating them across the catalog. Existing good foundations do not need an unnecessary full-site cleanup before a component task can proceed. If a component depends on a proposed CMS model, settle that dependency first.

INSPECT BEFORE DESIGNING
Inventory components and their use, then inspect representative definitions, instances, properties, variants, slots, styles, and content bindings. Map both repeated structures and currently unique sections that should be available for future AI assembly. Identify which components are actively used, which are legacy, and where similar names hide different purposes. Do not assume visually similar sections behave the same.

Look for gaps in the intended AI component catalog, including currently unique building blocks; repeated structures worth componentizing; existing components that can be extended; duplicates differing only by text, image, card count, or a simple intentional variant; unclear names/descriptions; missing editable properties; brittle visibility controls; and instances that depend on overrides or code. Record actual mappings and identities. Do not map multiple properties called “Text” by name alone.

TARGETED INTERVIEW
Ask only what you cannot establish:
- Which tasks should the components make easier, including future assembly beyond current repeated use?
- Which sections and smaller building blocks should the AI be able to independently select? Which are intentionally excluded?
- Should the AI usually assemble whole sections, compose smaller blocks inside slots, or use both levels? Recommend boundaries using the actual site.
- Who edits them, and which content or layout choices should those people control?
- Which examples are approved? Which differences between similar sections are intentional?
- What must remain shared: spacing, typography, alignment, structure, CTA behavior, or other design choices?
- Does content count vary? Must editors reorder or mix child blocks? Which child components belong in each slot?
- Are there known limits for headlines, images, cards, optional fields, or CMS-driven content?
- Are shared-definition changes acceptable, or should this task work only with instances and new isolated pilots?
Offer concrete options rather than asking the user to design the component architecture unaided.

COMPONENT DECISION RULES
Reuse a suitable existing component first. For an instance-specific request, prefer exposed properties and supported slots. Do not detach instances to make routine edits. A change to a shared definition has broader impact than changing one instance; identify consumers before modifying it.

Use properties for meaningful editable content such as text, images, links, and appropriate optional visibility. Use variants for intentional predefined styling alternatives. Use slots when composition or the number of child blocks varies. Verify the capabilities exposed by this project/connection instead of assuming an old limitation.

A three-card and four-card section should normally share one section and reusable cards when purpose and behavior match. Prefer a suitable slot for variable composition. A fixed arrangement with a simple optional item can reasonably use a visibility property when that best fits the editing task. Do not manufacture a separate component solely for each count. Do not create a universal component with dozens of unrelated switches. Explain meaningful reasons to keep components separate.

Use reusable child cards where appropriate so they can appear in other sections. Configure native preferred-component settings if the actual interface/tools support them, and document recommended child types regardless. Verify what the control does; a preference is not necessarily a restriction. Keep flexibility aligned with editorial needs.

DOCUMENT THE CATALOG AND EDITING CONTRACT
Keep a discoverable catalog using the native component inventory and supported metadata, with focused instruction references where useful. For each entry, record verified identity, purpose, when to choose it, how it differs from similar entries, and which compositions it supports. Use verified dynamic references in project guidance where supported rather than duplicating a stale inventory. Mark entries ready, pending verification, or unavailable for the intended workflow.

For each proposed component, specify its purpose, appropriate uses, meaningful name, editable properties and types, variants, slots, recommended children, defaults, content/image expectations, and responsive/empty behavior. Add supported descriptions and tooltips/help text. If the platform does not expose a metadata field, use a nearby project reference instead of inventing a field.

Reuse existing classes and variables and follow the agreed framework. Prefer Webflow-native elements, bindings, and behavior. Add custom code only for an established requirement unavailable through a suitable native or styling solution; do not introduce it simply because generation is easier. Keep any justified exception inspectable and documented.

PROPOSE THE PILOT AND ROLLOUT
Give a mapping of intended AI building blocks to existing or proposed components, including unique sections. Report catalog gaps and proposed exclusions explicitly. Do not silently omit a block because it has only one existing instance. Identify retained differences, shared consumers, CMS bindings, interactions, code selectors, and other dependencies. Distinguish creating a reusable definition from migrating existing pages to it; completing one does not complete the other.
Choose one representative section with real content for the pilot. Preserve content, destinations, semantics, responsive behavior, and visual appearance. Establish how to recover the previous structure. Do not bulk-convert the entire site before checking the pilot.

SPECIFIC ACCEPTANCE CHECKS
Verify catalog discoverability as well as rendering: given a representative business brief, can the agent identify and instantiate the intended component and configure its supported properties/slots without reconstructing the block from raw elements? Check this in the authorized test scope and report any missing controls or unclear descriptions.

Compare the pilot against its baseline at relevant breakpoints. Check headings, accessible names, images/alt text, links, focus behavior where interactive, and CMS bindings. Test empty optional content, typical content, long text, three/four or other relevant card counts, and slot reordering where supported. Ensure there are no empty gaps, unexpected stacking, changed click targets, or unintended changes to other instances.
After the pilot passes and rollout is authorized, migrate a small batch, inspect it, then increase batch size cautiously. Keep original-to-new mappings and verification status. Remove obsolete definitions only after proving no required consumers remain and obtaining the applicable deletion authorization. Otherwise report them as retirement candidates.


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 verified component catalog, selection guidance, properties, variants, slots, preferred children, editing boundaries, and checks. Reference the actual components and related design resources where supported.

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 the current components and intended AI building blocks, including unique sections. Return a catalog coverage map, the first targeted questions, and the proposed pilot.

Audit and improve my Webflow CMS so people and agents can create and maintain content consistently.

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.


INSPECT THE CONTENT MODEL
Inventory the relevant collections, field names and types, IDs, required fields, references/multi-references, sample entries, slugs, locales, collection lists, and templates. Identify how content reaches the website: bindings, filters, sorting, conditional visibility, dynamic SEO, links, feeds, and known integrations. Read existing editorial and agent guidance.

Inspect representative entries, including incomplete or unusual cases, without unnecessarily copying personal or confidential data into reports. State the sample and expand it when a migration requires a fuller inventory. Separate content errors, unclear documentation, inconsistent conventions, and actual schema problems.

TARGETED INTERVIEW
- What does each ambiguous collection represent in the business, and who owns it?
- Who drafts, reviews, approves, and publishes content? What should the agent be allowed to do?
- Which fields confuse editors or cause repeated mistakes?
- Which content sources are authoritative, and which examples should an agent follow or avoid?
- Which values are mandatory in practice? What is the intended behavior for empty optional fields?
- Are collection/field/slug conventions deliberate? Are external integrations dependent on IDs, names, schemas, or URLs?
- Which relationships, ordering rules, locales, legal wording, or brand claims must remain intact?
- Is the priority clearer editing guidance, content correction, or an actual content-model change?
Make recommendations informed by the observed data. Do not ask the user to design the whole schema from scratch.

START WITH CLARITY
Propose clearer display labels, descriptions, supported help text, examples, and editorial guidance first where these solve the problem. Preserve technical identifiers and bindings. For each relevant collection document purpose, ownership, required content, field meanings, source of truth, relationships, slug conventions, intended display, and publishing lifecycle.

Use meaningful guidance: a field description should explain what belongs there and any content constraint, not merely repeat its name. For claims, statistics, quotes, and testimonials, preserve source, attribution, and approved context. For images, distinguish editorial descriptions from image alternatives used by assistive technology.

If the tool or platform does not support a desired description field, store the guidance in a focused project reference rather than claiming metadata was added. Use verified dynamic references later in the instruction pack so agents can resolve the current collection and relevant resources.

DISTINGUISH CHANGES BY IMPACT
A. Documentation/label improvements: establish that they do not alter technical IDs or break known consumers.
B. Entry cleanup: define the exact transformation, content source, affected fields, and publication implications; preserve human edits.
C. Structural changes: adding, removing, replacing, or changing fields/collections/relationships; URL changes; or moving content. Treat these as migrations with explicit scope, mapping, dependencies, recovery, and verification.

Do not delete a field or collection because a sample appears empty. Do not assume similarly named collections are duplicates. Do not change slugs, field types, requiredness, locales, integrations, or publishing state as incidental cleanup. Clarify whether draft and live content will be affected before writes.

PILOT
Choose one representative collection and a small set of entries. Draft the proposed guidance and any field/entry mapping. Validate against the real template and collection lists. Preserve layout, ordering, filtering, conditional visibility, links, metadata, and responsive behavior.

If a schema migration is authorized, create a stable old-to-new mapping, capture the necessary data/recovery state, migrate a small sample, verify consumers, and reconcile counts/relationships before scaling. Do not delete the previous structure until reconciliation passes and retirement is authorized. Inspect current state after ambiguous writes before creating duplicate entries.

DEFINITION OF DONE
An editor or agent can understand the collection’s purpose, complete the correct fields, use approved sources, understand relationships, and follow the publication process. Changed entries render correctly in affected templates/lists. No unintended URLs, publication states, content, or relationships changed. Report any dependencies or integrations that could not be tested.

Deliver the verified collection guide, changes completed, migration status where applicable, evidence from sample rendering, and remaining decisions. Turn editorial conventions into inputs for Prompt 6 without creating a competing instruction system.


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 collection purpose, field meanings, approved content sources, relationships, editing/publishing workflow, and verified template conventions. Reference actual collections, examples, and templates where supported; do not describe a proposed schema as already implemented.

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 CMS model and representative content. Return the main clarity/consistency issues, targeted questions, and a small proposed pilot.

Help me create an excellent project-specific system of Webflow rules, skills, and shared references that lets our team and connected agents work consistently.

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.


GOAL AND SCOPE
Build on the actual website, our agreed business intent, and verified outcomes from any foundation improvements. Do not simply generate a generic best-practice document. Do not require every foundation issue to be fixed first: document reliable current conventions, clearly identify limitations, and prioritize instructions for the tasks we actually need.

Project conventions should live with the Webflow project so teammates, agencies, clients, and different connected agents can use them. Personal preferences and client-specific setup can remain in separate local guidance. This reduces duplicated context; it does not remove authentication or tool-permission requirements.

PHASE 1 — INVENTORY AND RECONCILE
Load existing enabled rules and relevant skills first, then inspect the wider instruction inventory, including disabled/draft content. Include the instruction proposals and installed updates from Prompts 1–5. This step consolidates and tests incremental documentation rather than postponing all documentation until the end. Read referenced documents as needed. Record purpose, status, overlap, contradictions, outdated details, missing references, and ownership. Do not create a competing version of an instruction that should instead be revised.

Inspect the actual approved components, variants, exposed properties, slots, variables, class framework, assets, CMS model, templates, and content examples relevant to our chosen workflows. Reuse verified audit findings but refresh mutable mappings. Distinguish proposed improvements from completed changes: do not write instructions that depend on a component or schema that has not been implemented.

If Webflow-generated guidance exists, use it as a starting draft to review. It may describe current inconsistencies as well as intended conventions. It cannot establish all business policy. Reconcile it with our answers and approved examples. Distinguish generated skills from generic rule templates; do not assume either is enabled or authoritative.

PHASE 2 — STRUCTURED INTERVIEW
First summarize what you know, with evidence and uncertainties. Conduct the following interview in small rounds, asking only unanswered questions and offering informed recommendations. Do not send a giant questionnaire or ask the user for every implementation detail.

A. Business and audience
- What does the business offer, to whom, and which actions should the website encourage?
- Which audiences or markets need different messaging? What stays consistent?
- Which claims, proof, terminology, compliance wording, and content sources are approved?
- What should the agent never infer from an old webpage or invent?

B. Team and recurring work
- Who requests changes, who edits the site, and who owns final decisions?
- What are the first two or three recurring workflows to support? Ask for a realistic example request for each.
- What inputs will the requester normally have, and what should the agent retrieve itself?
- What makes each workflow successful? What mistakes or repeated explanations should the instructions prevent?

C. Brand and editorial choices
- Which documents/pages represent the desired voice and visual standard? Which are legacy?
- What language, spelling, capitalization, terminology, tone, and content limits matter?
- How should quotes, logos, statistics, images, links, and calls to action be selected and attributed?
- What editorial/review/publishing process and localization requirements apply?

D. Design and composition
- Which components are approved for the recurring tasks? What are their intended uses and exceptions?
- Which sections and smaller building blocks must the AI be able to independently select and assemble, including those used only once today? At which level should composition happen?
- Which properties may editors change, and which choices should remain shared?
- Where should variants or slots handle variation? Which child components are preferred in each slot?
- What are the agreed class framework, variable conventions, responsive behavior, and content limits?
- Which inconsistencies should be preserved temporarily, and which have an approved remediation plan?

E. Autonomy and scope
- Which routine changes may the agent implement without another decision once the task is requested?
- Which changes need an explicit scope decision: shared components, global styles/variables, CMS schema, custom code, deletion, redirects, or publishing?
- Where should drafts/test changes live, and how are production and demo projects distinguished?
- How should the agent respond when the approved building blocks cannot satisfy the request?
- What capabilities and permissions are actually available through this connection?

F. Verification and ownership
- What checks are required for each task, and which devices/locales/states matter?
- What should the final handover include, and who reviews remaining issues?
- Who maintains the instructions? What changes trigger a review?
- Which small task should prove that the setup works in a fresh conversation?

Record confirmed decisions in a compact decision log. Explain where a choice affects other pages or users. If my proposed method creates avoidable duplication or fragility, recommend a more maintainable route tied to the goal. Do not silently expand scope. Ask a focused clarification for contradictions that matter; don't invent an instruction hierarchy or discard existing rules without authority.

PHASE 3 — DESIGN THE INSTRUCTION STRUCTURE
Propose a small coherent structure before writing dozens of files. Use three layers:

1. Standing rules: concise expectations that apply across relevant work. Cover project identification and instruction loading, reuse, factual content integrity, scope of shared changes, styling consistency, native-first implementation, publication/deletion boundaries, and verification. Rules guide behavior; tool permissions are a separate control. Do not frame natural-language rules as a security guarantee.

2. Shared references: project-specific context used by multiple workflows. Depending on the site, include business/voice guidance, approved content sources, component usage, design conventions, CMS/editorial guidance, and resource mappings. Do not duplicate the same information in every skill. Reference the actual current resources rather than copying huge inventories.

3. Focused skills: procedures for recurring tasks, such as building a campaign page, adapting an audience variant, updating CMS content, or reviewing an existing page. Only create skills justified by the interview. Keep task-specific steps out of always-loaded rules where they add noise.

Each skill must include a specific name and trigger description; appropriate and inappropriate uses; required user inputs; preparation and relevant rules/references; ordered actions; meaningful decision points; approved building blocks; exception handling; verification; completion criteria; and a concise output format. Include a natural example prompt and follow-up. Keep changing campaign briefs out of permanent rules.

PHASE 4 — ENCODE OUR WEBFLOW PRACTICES
Carry these principles into the relevant rules, references, and skills, tailored to confirmed project choices:

Components: Everything the AI is expected to independently select, assemble, or reuse should be available as a documented Webflow component. Current repetition is not a prerequisite: a section used only once may still belong in the catalog if the AI should be able to use it in future work. Choose meaningful building-block boundaries; internal wrappers and elements can remain inside their parent component unless the AI needs to select them independently. This can justify more components than a workflow based only on existing repetition. Maintain a discoverable catalog with verified identities, purposes, selection guidance, exposed controls, and supported compositions. Bind relevant instruction guidance to the actual component resources where supported. Inspect suitable existing components first. Prefer instance properties and supported slots for instance-level edits. Preserve shared definitions unless changing them is in scope. Avoid separate components for trivial variations such as three versus four equivalent cards. Prefer reusable children and appropriate slots for variable composition; use properties for content/visibility and variants for intentional styles. Do not create an overcomplicated universal component. Include clear descriptions, property labels, help text, defaults, content constraints, responsive expectations, and preferred-child guidance where supported.

Styles: follow the actual agreed framework. If Client-First is chosen, use its verified conventions. Maintain coherent utilities, custom classes, combos, wrappers, responsive overrides, and states. Reuse meaningful classes. Naming cleanup, duplicate consolidation, and orphan deletion require dependency checks and appropriate scope; empty or apparently unused classes can still be intentional hooks.

Variables: reuse verified variables with the correct semantic purpose. Bind consumers rather than merely creating a token list. Preserve roles, units, modes, aliases, and responsive behavior. Do not merge equal values with different intended meaning or create a new campaign-specific palette unnecessarily.

CMS: make collection purposes, field meanings, required content, relationships, source material, slugs, localization, template behavior, and editorial lifecycle clear. Preserve schemas/URLs/publication states unless a relevant change is requested. Distinguish documentation improvement, entry editing, and structural migration.

Native Webflow: prefer editable Webflow structures and supported native behavior. Check whether class styling solves a presentation problem before adding JavaScript. Use minimal documented code only for a real need that native tools cannot reasonably meet. This is an implementation preference, not a separate code-removal audit.

Working partnership: inspect context, identify consequential gaps, ask focused questions, recommend better options, make routine decisions within scope, and complete authorized work without needless confirmation loops. Do not mistake proactive assistance for permission to redesign unrelated areas.

Verification: read back changes and inspect appropriate visual/functional states. Structural improvements begin with a pilot and expand after it passes. Shared changes need representative consumer checks. Report what was tested and what remains uncertain; don't claim business or compliance outcomes without evidence.

PHASE 5 — USE REAL DYNAMIC REFERENCES
Make Webflow resource references central to the setup. Discover the supported reference types and exact syntax from the current MCP operations/documentation. Do not invent reference tokens or assume every resource type is supported in the same way.

For each relevant rule/skill/reference, bind to verified resources where supported: classes/style selectors, components, variables, collections/items, pages, assets, and other instructions as appropriate. Use a compact reference map with purpose, actual resource identity, instruction location, and resolution status. Resolve names to identities using the current site; names alone can be ambiguous.

Explain the resource's intended use alongside the reference. A binding to a component does not itself explain when to choose it. Keep purpose and editorial decisions in prose; let mutable project data resolve from the resource. Do not hardcode changing values or blindly copy production IDs into another site.

After authorized creation or update, read each instruction back using the supported mechanism and verify its references resolve to the intended project resources. Confirm relevant current details, not only that the token is syntactically present. If a reference cannot be created/resolved, mark it unresolved and state the exact dependency or limitation. Never label a typed resource name as a dynamic binding.

If testing rename/update behavior, do so only in an authorized disposable/test scope; do not rename production resources just to demonstrate reference durability. If that behavior is not tested, say so. Define how owners should handle removed/replaced resources and invalid references.

PHASE 6 — DRAFT, REVIEW, AND INSTALL
Deliver the complete proposed wording for the rules and skills, not only an outline. Show how each interview decision is represented. Mark unresolved placeholders explicitly, and keep affected instructions disabled/uninstalled until the dependency is resolved if enabling them would mislead agents.

Check for repetition, contradictions, generic filler, unsupported product claims, stale mappings, impossible procedures, and unclear triggers. Add useful examples and concise exceptions. Put long supporting material in focused references so every task doesn't need the entire pack loaded.

Do not include secrets, personal data from sample entries, transient tool logs, private chat history, temporary campaign copy, or changing model recommendations in permanent site rules. Do not instruct agents to bypass tool restrictions or ignore host policies.

Before remote installation, show the concrete change set: create/update/retain/retire, exact wording, references, scope, and enabled state. Respect any installation authorization I already gave. Verify current authoring permissions. Use supported MCP operations and preserve concurrent edits. Retire old instructions only after replacing useful content and resolving conflicts within the agreed scope. Read back installed content and enabled status. Report drafted, installed, enabled, and tested separately.

PHASE 7 — ACCEPTANCE TEST AND MAINTENANCE
Choose a small representative task based on the real interview. Provide a short business-oriented prompt that relies on the stored instructions. Use an authorized draft/test scope and an available supported preview. Prefer a fresh conversation so success doesn't depend on hidden context; do not start or message another chat without the applicable authorization. If you cannot run that test, supply the exact prompt and checklist and mark it unperformed.

Verify that the agent loads the correct rules/skill; resolves the right resources; asks only necessary questions; reuses approved components/styles/variables; follows content/CMS conventions; respects shared-change and publishing scope; checks the result; and reports limitations accurately. Include a catalog-selection test: from a business brief, the agent should choose and configure an appropriate component without recreating an existing block from raw elements. Include one realistic exception case, such as a layout unsupported by the approved components. The agent should explain the gap, recommend an appropriate catalog addition or supported alternative, and create/verify a new component only within authorized scope before using it. It must not silently bypass the catalog with ad hoc structure.

Fix observed instruction failures and retest the affected behavior. Do not add speculative rules indefinitely. A successful small test validates that workflow, not every possible future action.

Hand over the instruction map, full text, decisions, verified resource references, enabled status, test evidence, unresolved limitations, short invocation prompts, and ownership/review guidance. Recommend review after relevant component, variable, CMS, brand, workflow, or tool changes. Keep connection/model/approval guidance in a dated operator guide rather than permanent project rules. The operator guide should recommend an agent-capable mode with the needed tools, task-appropriate reasoning effort, permission scoping before automatic approvals, and browser use for visual checks or real tool gaps without implying browser actions inherit router restrictions.


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. Reconcile the instruction updates created during earlier audits and implementations; preserve useful verified guidance and remove overlap within the agreed scope.

Start by reading the current instructions and inspecting the relevant project context. Return the existing instruction map, your initial understanding, and the first interview questions. Build the final pack from evidence and confirmed decisions, not assumptions.