A Drupal recipe that sets up a Drupal CMS site for an AI agent to build.

Droost CMS takes a fresh Drupal CMS project and, in one apply, gives an agent the initial site-building pieces: droost's tools, Droost Theme, UI Patterns 2 beside Canvas, and a worked example to copy. It is the reference install, the configuration Droost is built and tested against, and what droost.org itself runs on.

For an existing Drupal site, install the individual Droost packages you need rather than applying a fresh-site recipe.

What one apply gives you

  • Everything in drupal_cms_starter: Canvas page building, media, SEO and the admin UI.
  • Droost Theme as the default theme: Tailwind v4 and daisyUI, design tokens in one editable CSS file, 21 Canvas-ready components, and a compiled stylesheet, so the site needs no Node. Mercury stays installed.
  • UI Patterns 2 as the component display layer for structured content.
  • Droost's site tools: droost (the content tools) and droost_canvas, through which an agent reads and writes content and Canvas pages.
  • A worked design pattern: an event content type whose display is composed entirely from components, the example an agent copies.

The recipe installs only droost's content tools, because a recipe runs in production too. Turn on droost_build and droost_dev (configuration, fields, Views, the developer tools) in a development copy, never in production.

Install

On a fresh Drupal CMS project (composer create-project drupal/cms <dir>):

bash
composer require 'drupal/tool:^1.0@beta' 'drupal/droost_cms:^1.0'
drush site:install minimal -y          # or pick "Droost CMS" in the Drupal CMS installer
drush recipe ../recipes/droost_cms
recipes/droost_cms/scripts/assert-recipe-applied.sh .

The recipe brings droost 2 and Droost Theme 1 with it. Tool API is still in beta, so the site requires it at that stability. assert-recipe-applied.sh checks every promise the recipe makes against the running site, and refuses to say OK otherwise.

Apply it once. A second apply fails inside drupal_cms_starter, so the recipe cannot go on top of a site Drupal CMS has already built either.

The agent layer

The droost command (what the agent knows about the code, and the gated plan → code → test → complete run) lives in the project's own tools/droost/ folder. The recipe ships the part of it that is about Canvas: a component_lint gate that holds every custom component to Canvas's requirements, a paragraph for AGENTS.md, and house rules for droost/droost.yml.

bash
mkdir -p tools/droost
composer init -d tools/droost -n --name=local/droost-tools
composer config -d tools/droost platform.php 8.3.0      # the PHP the site runs
composer require -d tools/droost 'droost/workflow:^1.0'
php tools/droost/vendor/bin/droost init
php tools/droost/vendor/bin/droost code:index
recipes/droost_cms/scripts/install-layer.sh .
# merge recipes/droost_cms/examples/droost.yml into droost/droost.yml
php tools/droost/vendor/bin/droost init                 # again, to carry the layer into AGENTS.md
drush en droost_build droost_dev -y                     # a development copy only

install-layer.sh never overwrites a file you changed.

Canvas and UI Patterns, together

Canvas and UI Patterns once fought over Drupal's SDC plugin manager (#3561618). This recipe requires UI Patterns 2.0.22 or later, which steps aside once Canvas has taken the manager, so no patch and no bridge module are needed (measured on Canvas 1.12.0).

Version-specific issue

On Canvas 1.12, enabling Custom block (block_content) stops halfway and leaves the module enabled with no table. The fix is Canvas's (#3582851). Until it is released, keep site-wide editable details in configuration rather than a custom block type.

Requirements

  • A fresh Drupal CMS project (measured on Drupal CMS starter 2.2.4 and Canvas 1.12.0).
  • PHP 8.3 or later.
  • Tool API, required at beta stability as above.

The project: Droost CMS on drupal.org.