Module library
The Q-Code module library holds 20 installable modules, grouped into foundations, content, catalogue and booking, engagement, and accounts and agents.
A module is a feature that has already been built, argued about and hardened on other projects, so installing one is a switch rather than a build. Each brings its own admin panel, its own structured data and its own audit rules with it.
Five groups
Not by size or by how much they do. Each group answers one question about a project, and most projects work through them roughly in this order.
Visibility, analytics, security, legal pages and cookie consent: the five modules every Q-Code project installs first, and what each one does.
Visibility engine
@ccd/visibility
Analytics
@ccd/analytics
Security baseline
@ccd/security
Legal pages
@ccd/legal-pages
Cookie consent
@ccd/cookie-consent
Blog, FAQ, testimonials, gallery and footer: the five Q-Code modules that make posts, reviews, photos and site-wide links editable in a panel.
Self-improving blog
@ccd/blog
FAQ
@ccd/faq
Testimonials
@ccd/testimonials
Gallery
@ccd/gallery
Footer
@ccd/footer
Listings and booking: the two Q-Code modules for a catalogue that reshapes itself per project, and appointments with real availability.
Listings
@ccd/listings
Booking
@ccd/booking
Contact form, newsletter, social and AI chat: the four Q-Code modules that turn a brochure site into somewhere people actually reach you.
Contact form and inbox
@ccd/contact-form
Newsletter
@ccd/newsletter
Social profiles
@ccd/social
AI chat
@ccd/ai-chat
Admin, auth, Google and agent access: the four Q-Code modules for who can sign in, what Google knows about the site, and what an assistant can call.
Admin dashboard
@ccd/admin
Sign-in and members
@ccd/auth
Google connections
@ccd/google
Agent access
@ccd/agent-api
What a module is
A library is only worth having if its parts behave predictably. These are the rules a module has to satisfy before it goes in.
A bug found on one project is fixed in the module, and every project that has it installed gets the fix. That is the whole economic argument for a library.
A module that adds data adds the screen for editing it. No module leaves you with a database table and no way to reach it.
Structured data comes with the module and describes only what the module actually renders, so installing one cannot quietly cost you a point of visibility.
A module that adds a page registers its own navigation link. A module that adds a section registers for a slot. Installing it puts it somewhere a visitor can find.
Uninstalling removes the code and the links. It does not remove your data, and it never touches an account in your name.
Modules use the guaranteed token vocabulary rather than their own colours, so an installed module looks like the site it landed on instead of like a widget.
Modules and agents
Agent access turns the site into an MCP server, and its tools are derived from the modules already there rather than from a list somebody maintains.
Install the catalogue and the next build exposes a search tool and an item tool. Install booking and it exposes availability and a booking. Remove one and its tools go with it, so an assistant is never offered a door that leads nowhere. On a site with every tool-bearing module installed that is 13 tools, and on a site with none of them it is one: the tool that says what the site is.
The same rule holds for the discovery cards the site publishes, which are generated from that registry and therefore cannot describe a tool the site does not have. All of it stays off until agent access is switched on.
All of them
Sorted by group. The install name is the real one, and a few of these are already load-bearing in the template itself.
| Module | Group | Package | What it does |
|---|---|---|---|
| Visibility engine | Foundations | @ccd/visibility | One score across SEO, AEO, LLMO, conversion and agent readiness, measured on the built HTML. |
| Analytics | Foundations | @ccd/analytics | Server-side page and event counts with no cookies and no consent banner. |
| Security baseline | Foundations | @ccd/security | The baseline hardening every project ships with: HTTPS, headers, row-level security and a firewall. |
| Legal pages | Foundations | @ccd/legal-pages | A privacy policy and terms of service that read the project’s own configuration rather than a template. |
| Cookie consent | Foundations | @ccd/cookie-consent | A consent banner for the project that sets a cookie needing one. |
| Self-improving blog | Content | @ccd/blog | A blog that reads the site’s own visibility report before it decides what to write. |
| FAQ | Content | @ccd/faq | A visible questions-and-answers page, marked up as FAQPage for exactly what it shows. |
| Testimonials | Content | @ccd/testimonials | Collect, approve and place customer quotes, as a wall or a carousel. |
| Gallery | Content | @ccd/gallery | The shared image foundation: one original kept in storage, every size made at the edge. |
| Footer | Content | @ccd/footer | The site footer: navigation, legal links, social profiles and the copyright line, wired once. |
| Listings | Catalogue and booking | @ccd/listings | One listing engine that reshapes itself for cars, property, products or services. |
| Booking | Catalogue and booking | @ccd/booking | Real availability and real time zones, confirmed by email and added to a calendar. |
| Contact form and inbox | Engagement | @ccd/contact-form | Any form on the site, with the replies threaded in a shared inbox. |
| Newsletter | Engagement | @ccd/newsletter | A list you own, sent from your own domain, with double opt-in as the default. |
| Social profiles | Engagement | @ccd/social | Your profiles in the footer and in the structured data, plus a posting queue. |
| AI chat | Engagement | @ccd/ai-chat | A chat widget on the site itself, answering from the same content the pages already show. |
| Admin dashboard | Accounts and agents | @ccd/admin | The private dashboard every other module adds its panel to, with one login for the owner. |
| Sign-in and members | Accounts and agents | @ccd/auth | Sign-in for the site’s owner and, where a project needs it, its members. |
| Google connections | Accounts and agents | @ccd/google | Connects the site to Google: Business Profile, Search Console and review data, in one panel. |
| Agent access | Accounts and agents | @ccd/agent-api | Makes the site an MCP server, so an assistant can call its tools instead of scraping its pages. |
Q&A
A build, which is minutes, because the module already exists rather than being written for you. What the build does is wire it into this project and place it on the pages where it belongs.
Yes. Anything can be built for a single project, and the ones that turn out to be generally useful become modules afterwards. That is where most of these came from.
Not measurably. Pages stay static HTML and ship no JavaScript unless a module genuinely needs interactivity, and the ones that do are loaded only when they scroll into view.
It stays in the project database and is exportable. Uninstalling removes the code that reads it and the links that pointed at it.
Yes, when agent access is installed. The tools the site offers an assistant are derived from the modules it has, so a catalogue gives search and item tools, booking gives availability and booking, and a site with nothing installed offers nothing. There is no separate list to maintain.
You do not need to know which module you want. Describe what the site should do and the build picks the parts that already exist.