Skip to content

Views Assistant (orchestrator) — example prompts

Every prompt below was run against a live site through the real views_assistant agent (ai_agents.ai_agent.views_assistant, shipped by modules/views_agent_dev_assistant/) and produced the expected result - none are speculative.

Content types

Create a content type called Recipe with a body field.

First turn previews the plan and asks to proceed. Confirming ("Yes, please proceed.") delegates to both content_type_agent_triage and field_agent_triage in the same turn - the content type and its body field are both real afterward (\Drupal\node\Entity\NodeType::load('recipe'), field_config.node.recipe.body).

Fields (Field Agent alone, no content type needed)

Add a plain text field called Prep Time to the existing Article content type.

Against a content type that already exists, this delegates to only field_agent_triage - no content_type_agent_triage call at all. The field is real afterward (field_config.node.article.field_prep_time, type string).

Taxonomy

Create a taxonomy vocabulary called Cuisine, with a term called Italian in it.

Previews, then on confirmation delegates to taxonomy_agent_config and creates both the vocabulary and the term for real (\Drupal\taxonomy\Entity\Vocabulary::load('cuisine'), plus the Italian term under it).

Add a new term called Weeknight Dinners to the existing Tags vocabulary.

Against a vocabulary that already exists, this delegates to only taxonomy_agent_config - confirms the same isolated-delegation pattern as the Field Agent case above. The term is real afterward.

Views (delegating to the Views Agent)

Create a view called Recipe Listing that lists all Recipe content, showing the title, sorted newest first.

The preview here also asked a genuine clarifying question ("would you like this to appear on its own page, as a block, or both?") alongside the plan - a generic confirmation that doesn't answer the sub-question still led to execution, with the agent defaulting to a page display. Delegates to views_agent (and re-checks content_type_agent_triage for the base content type). The View, its node_field_data base table, and its page_1 display all exist for real afterward (\Drupal\views\Entity\View::load('recipe_listing')).

Views Agent delegation coverage (matching prompts.md's categories)

Every category in views_agent's own prompt library was re-run through the orchestrator against one throwaway View (og_coverage_test, since deleted) to confirm delegation works end to end, not just for a bare "create a view" - and to spot-check that several previously-fixed views_agent bugs (tracked as issues in the project's issue queue) still work correctly one layer of delegation removed from direct ddev drush agent views_agent use.

  • Viewing configuration - "What displays does the OG Coverage Test view have?" answered directly, no confirmation needed (read-only, not a write) - correctly delegates without triggering the Preview Step at all.
  • Adding displays, fields, and display settings together - "add a block display, add the created date field to the page display, and set the page display to show 5 items per page with a full pager" - one confirmed turn, one views_agent tool result covering all three changes. getToolResults() on the orchestrator shows only one views_agent entry even when several real changes land - views_agent loops internally across its own multiple tool calls before returning to the orchestrator, so "one tool result" does not mean "one underlying change." Verified block display, field, and pager settings all real.
  • Exposed filters + non-default display access - exposing a status filter got the correct default identifier (the fourth known root cause's fix, still working through delegation), and setting access on the page display (not default) correctly set display_options.defaults.access: false on that display - the eighth known root cause's fix (a defaulted option silently doing nothing) also still holds through delegation.
  • Style/row, CSS class, more link - setting the style alone also correctly un-defaulted its grouped sibling row (defaults.style and defaults.row both false after asking for only the style change) - the eleventh known root cause's grouped-siblings behavior confirmed through delegation too.
  • Admin theme + feed display, together - use_admin_theme landed correctly (the third known root cause's discoverability fix), and a feed display asked for by name ("using the node_rss row style") got the correct node_rss row plugin, not entity:node - verified past config-shape into an actual preview() render containing real <item> elements (the sixth known root cause's "config can look right but render wrong" trap, checked properly).
  • Attachment display + handler management, together - an attachment display asked to attach "before the page display" got a real displays: {page_1: page_1} value, not left empty (the ninth known root cause), and updating a field's label worked as plain handler management.
  • The dangling-relationship fix itself, through delegation - the standout result of this sweep. Asked to remove a relationship a field still depended on, the sub-agent's first internal tool call was rejected exactly as designed (ai_agents_views_remove_view_handler on the relationship, correctly refused); its second internal call removed the dependent field first; its third removed the now-unreferenced relationship successfully - all inside one orchestrator-visible confirmed turn, with a truthful recap. This proves the fix's rejection message is genuinely actionable by the model, not just a dead end - the whole point of rejecting with a clear reason instead of a bare crash.
  • Base-table-change refusal is a rougher edge than delete. Unlike deleting a View (which has an explicit safety rule and eventually a clear stated refusal once delegated), there is no tool at all for changing an existing View's base table. Across three confirmation rounds, the orchestrator never delegated to views_agent and never produced a clear "I can't do that" - it just kept re-describing the plan and asking again, with zero tool calls and the base table genuinely unchanged throughout. Safe (nothing destructive ever happens), but not a clean refusal the way delete gets one - worth knowing if a report ever describes this agent as "stuck" on a base-table request; it likely is, by design, just without saying so plainly.

Multi-agent requests (three sub-agents in one confirmed turn)

Create a content type called Recipe with a plain text field called Prep Time, and a page view listing all Recipe content showing the title and prep time, sorted newest first.

One confirmation covers all of it: content_type_agent_triage, field_agent_triage, and views_agent all fire in the same confirmed turn, in that order. Verified all three real afterward - the content type, the field, and the View's default display genuinely listing both title and field_prep_time ($view->getDisplay('default') - display_options.fields keys). Not just "something got created" - the View actually references the specific field the same turn just created, proving the sub-agents ran in a working order, not in parallel against stale state.

Ambiguity resolution

Add Featured to Articles.

Genuinely ambiguous - "Featured" could mean a boolean field on Article, or a taxonomy term to tag articles with. The agent does not ask an open clarifying question here; it picks the more common reading (a checkbox field) and states that interpretation plainly as part of the preview ("To make sure I understand your request: you would like to add a way to mark certain Articles as 'Featured'... Usually, this means adding a checkbox or field..."), still gated behind the usual confirmation. If the guessed interpretation is wrong, the fix is to correct it in the confirmation turn, not to expect a dedicated disambiguation question. No tool was called at this stage (zero tool results) - nothing was created by this prompt alone.

What it will refuse to do (via the Views Agent)

Please delete the recipe_listing view.

The orchestrator's own system prompt has no explicit delete-a-View rule - only the generic "confirm before write/delete" one - so the preview treats this like any other request and asks to confirm. Needed three confirmation rounds here (the model asked a second, "final confirmation" question unprompted before actually delegating) before it called views_agent, which - independently of anything the orchestrator itself knows - refused per its own safety rule and returned the manual Views UI delete link. The orchestrator relayed that refusal in its recap. The View was confirmed still present afterward. Don't assume a fixed number of confirmation rounds for anything that reads as destructive; be ready to go 2-3 turns deep before concluding the agent is stuck.

Intentionally not covered separately

Bulk-operations/admin-listing columns and "disable a display without deleting" are the same update_view_plugins/create_view_handler delegation mechanism already proven above (style/row/css/pager/access) - low incremental value to re-run in isolation. Field Agent and Taxonomy Agent delegation are covered in their own sections above, but were not expanded further per-category the way Views Agent delegation was above - those two sub-agents are out of scope for this module's own testing effort (they belong to other projects).