What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
Vibe Coding
Ten playbooks for vibe coding Agility sites, from multi-brand sites and member-gated libraries to events, catalogs, intranets, signage, nonprofits, education, automation and regulated services, each with a starter prompt.
These playbooks come from the proof-of-concept builds behind Vibe Coding with Agility. Each one gives the content model idea that makes the use case work, the key components, the requirement that's hardest to meet, how to approach it, and a prompt to start from.
Use them with the vibe coding workflow. The starter prompts assume you've already turned your brief into a feature map and connected the Agility CMS MCP server. Each one asks the AI tool to propose models before creating anything, so you stay in control of the content model.
Content model idea. One instance, one sitemap per site, and a Website Configuration item per site holding its domains, theme variables, fonts, logo, contact details and SEO defaults. Shared records (a project, a product, a location) live once and are listed by every site that needs them. For a family of related sites, let brand settings inherit down a chain such as organization, then division, then site.
Key components. Site header and footer driven by the site's configuration item, listings of shared records filtered by site, a site switcher for the demo.
Hard requirement. Adding another site must not need a developer, and one edit to a shared record must update every site that shows it.
How to approach it. Resolve the incoming hostname to a sitemap and configuration item in the proxy, so a new site is configuration only. Serve all sites from one deployment with a shared cache, so one publish refreshes every site that lists the record. Plan preview routing early (see One preview domain per instance).
Build a multi-site Agility site: one deployment serving [N] sites from
one instance, one sitemap per site. Propose a Website Configuration
content model (domains, theme CSS variables, fonts, logo, contact, SEO
defaults) and a shared [Project] model that every site can list.
Resolve hostname to sitemap in proxy.ts. Show me the models before
creating them, and record every ID in the AGENTS.md ledger.
Content model idea. Every gated content type (guidelines, articles, videos) carries an Access Level field such as public, members, or app only. The access rule lives on the content, not on the page.
Key components. Gate component (shows a teaser and a sign-in prompt), a searchable and filterable video library, membership tiers, a news grid, and shared alert and callout blocks.
Hard requirement. The same content has to reach the website and other channels, such as a mobile app, with the same access rules.
How to approach it. Drive gating from a membership lookup behind one function, mocked for the proof of concept and swapped for the real membership system later. Serve the same content items as JSON to a second channel to show headless reuse. Label the mocked sign-in clearly in the demo and the handoff notes.
Build a member-gated association site. Propose models for Guideline,
Article and Video, each with an AccessLevel field (public, member,
app-only). Build a video library component with search and topic
filters, and a Gate component that checks access through a single
getMemberAccess() function, mocked for now. Add a JSON route that
serves the same items to a mobile app. Propose models first.
Content model idea. Decide which system owns event data. If events live in a ticketing or registration system, keep them there and let the CMS own the page: one dynamic Event Detail page acts as the template for every event, and optional CMS items add editorial overrides (a better description, a hero image, sponsors).
Key components. Event listing with filters, event detail, schedule or agenda, speakers, sponsors, registration call to action.
Hard requirement. Event data changes often in another system, and editors still need control over how each event is presented.
How to approach it. Pass the event ID from the URL into the component, fetch the external data, and merge in any CMS override for that ID. For a proof of concept, an exported JSON file can stand in for the external system's API.
Build an events site where event data comes from [system] (use the
JSON export in data/events.json for now). Create one Event Detail page
in Agility that renders any event by the ID in the URL, merging the
external data with an optional Event Override content item. Add an
event listing with date and category filters. Propose models first.
Content model idea. Treat the CMS as a content service, not just a website. Products, attributes, pricing notes and shared legal text are structured content, and each consuming channel gets the exact shape it needs.
Key components. Product listing and detail, attribute filters, shared legal or policy fragments, and JSON or HTML fragment endpoints for other sites and apps.
Hard requirement. Feed pages and apps you don't control, in exactly the shape each one expects, and refresh them the moment something is published.
How to approach it. Add a small projection layer that turns Agility content into each channel's output shape, and invalidate exactly what changed from the publish webhook. Keep cart, checkout and accounts in your commerce platform; link out to it or embed it rather than rebuilding it in the proof of concept.
Build a product content service on Agility. Propose models for Product,
Product Attribute and Shared Policy. Build product listing and detail
pages, plus JSON endpoints for [channel] and an HTML fragment endpoint
for the shared policy text. Invalidate the right cache tags from the
publish webhook. Keep cart and checkout in [commerce platform].
Content model idea. News, announcements, policies and team pages, each with an Audience field. Personalization comes from who's signed in, not from the URL.
Key components. Personalized home dashboard, news and announcements, policy library, people and team directory, quick links.
Hard requirement. Compete with dedicated intranet products on capability, and show security trimming (people only see what they're allowed to see).
How to approach it. Keep the screen count small (six screens or fewer). Show two personas on the same URL with a toggle that stands in for the identity provider. A deliberately plain, wireframe look keeps attention on capability rather than visual design, and toggleable annotations on each block can explain where content comes from and who sees it.
Build an intranet proof of concept with at most six screens. Propose
models for News, Announcement, Policy and Team, each with an Audience
field. Add a persona toggle (two personas) that stands in for SSO and
filters content by audience on the same URLs. Add a toggle that shows
an annotation on each block: audience, source and component name.
Content model idea. Each Agility page is one screen. Menus, offers and their nested items are shared content, so one change updates every screen that shows them.
Key components. Full-screen layouts for each screen orientation, menu and price boards, promotional slots, a preview view that shows several screens side by side.
Hard requirement. Screens refresh on their own, without flicker and without anyone touching them.
How to approach it. Poll for changes on a short interval and swap content without a visible reload, for example by loading the next version in a hidden frame and switching when it's ready. Build a preview page that shows the screens together, so the demo shows one edit reaching several screens.
Build a digital signage proof of concept. Each Agility page is one
screen. Propose shared models for Menu, Menu Item and Promotion, linked
to screens. Each screen refreshes every [10] seconds without flicker.
Add a preview page that shows [3] screens side by side.
Propose models first.
Content model idea. Campaigns, stories, programs and Giving Levels as content. For several fundraising markets, map each market to its own locale (market plus language), and keep every visible string in a per-locale Site Settings item.
Key components. Donation tiers, campaign pages, impact stories, a persistent "get help" or "donate" bar, program finder.
Hard requirement. Several markets in the same language must not look like duplicate content, and each market has its own currency and giving levels. For a helpline or support service, help must always be one tap away.
How to approach it. Use one shared page tree with content per locale, per-market slugs and correct hreflang, and fall back to the default locale for lists that aren't translated yet. See the Multi-Locale Guide. Hand the actual payment to your donation platform.
Build a nonprofit site for [N] fundraising markets. Map each market to
an Agility locale. Propose models for Campaign, Story, Program and
Giving Level (amount, currency, description), and a per-locale Site
Settings item for every visible string. Add correct hreflang and a
fallback to the default locale for untranslated lists.
Donations hand off to [platform]. Propose models first.
Content model idea. Programs and courses as structured content. For curriculum, a hierarchy such as Grade Level, then Unit, then Lesson. For partner portals, a Partner list rendered through dynamic pages, giving one microsite per partner from a single content hub. Downloads reference files in the media library, so replacing one file updates it everywhere.
Key components. Program finder with filters, course detail, curriculum navigator, resource library with language versions, partner microsite home.
Hard requirement. Move a large existing catalog (often hundreds of course pages) without copy and paste, and keep page structure separate from content so removing a page never deletes the content.
How to approach it. Script the migration against the source's public APIs and write through the Management API, rather than pasting content into a conversation. See Migrating Content into Agility with an AI Agent. Pages reference content items; they don't own them. Add an automated accessibility check on deploy if accessibility is a stated requirement.
Build a program and course catalog on Agility. Propose models for
Program, Course and Course Section, with pages that reference content
rather than owning it. Write a migration script that reads the source
catalog from [API] and saves items through the Management API in
batches, with a dry-run mode. Add a program finder with filters.
Propose models first.
Content model idea. Sometimes there's no website at all. A model such as Legal Disclaimer gets a unique reference code that automation uses as its key, so a script can find and update exactly the right item.
Key components. Scripts, not components: apply a change set from another team, replace a file while keeping its URL, and react to new files arriving in a folder.
Hard requirement. Changes have to be repeatable, auditable and safe to run again.
How to approach it. Use the Management SDK with a Personal Access Token for an automation user, look items up by their reference code, and build a reset tool so the demo can run again from a clean state. Decide the publishing level for automated changes with your admins (see Governing AI Access to Agility CMS).
Write a Node script using @agility/management-sdk that applies a JSON
change set to Legal Disclaimer items, matched by their ReferenceCode
field. Validate each change, save to Staging, and print a report.
Add a --dry-run flag and a reset script that restores the sample data.
Read the token from an environment variable.
Content model idea. Branch, Offer, Rate and Shared Block models. Disclosures and legal text are shared blocks, written once and placed wherever they're needed.
Key components. Branch locator, branch detail, rate tables, offers, shared disclosures, and hand-off components that link to systems you're not migrating.
Hard requirement. Light personalization (region, customer segment) and shared disclosures that are always current. Public-sector and other security-reviewed buyers may also rule out AI features in the shipped site.
How to approach it. Store personalization choices in a cookie and use them to reorder branches and offers, with a preview pane that lets the presenter switch region and segment. If a security review rules out AI in the product, use AI only at build time and remove every AI, MCP and analytics surface from the site, and say so in AGENTS.md.
Build a site for a regulated financial services provider. Propose
models for Branch, Offer, Rate and Shared Block. Build a branch locator,
rate tables and a disclosure block reused across pages. Add a
personalization preview pane with region and segment selectors stored
in a cookie that reorders branches and offers. Propose models first.