04 — IMPROVE COMPONENTS AND SLOTS

Build a discoverable component catalog for AI assembly, improve the editing experience, and roll out verified changes without unnecessary duplication.

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

BEGIN PROMPT

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.

END PROMPT
