06 — BUILD AND TEST PROJECT RULES AND SKILLS

Build a coherent, site-specific instruction system using a structured interview, verified Webflow resource references, and a realistic acceptance test.

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

BEGIN PROMPT

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.

END PROMPT
