05 — CLARIFY AND IMPROVE YOUR CMS

Make the CMS understandable to editors and agents, improve consistency, and handle structural changes as controlled migrations.

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

BEGIN PROMPT

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.

END PROMPT
