task: #3586563 [1.x] Add a setup-automators agent skill to configure automators on fields
Description
Adds the setup-automators agent skill for the ai_automators submodule. letting an AI agent configure AI Automators on fields via Tool-module plugins (drush tool:run) instead of the admin UI.This fix includes:
- SKILL.md — agent instructions mirroring setup-guardrails: Step 0 intent gate, Tool-module enable/restore dance, discovery steps, one drush tool:run example per tool, critical rules (destructive delete needs confirmation, computed automator ID, plugin_config semantics).
- 6 Tool plugins in src/Plugin/tool/Tool/ (gated on administer ai_automator):
- ListAutomatorTypes — automator type catalog, or full detail for one via type filter
- ListTokens — Twig placeholders (base mode) or core Token placeholders (token mode)
- ListAutomators / GetAutomator — list (filterable) / full detail
- SaveAutomator — create/update
- DeleteAutomator — destructive
- src/Traits/AutomatorToolIdentifierTrait.php — shared <entity_type>..<field_name>.default ID computation, used by 3 tools since the entity has no free-form ID
- Kernel tests in tests/src/Kernel/Plugin/tool/Tool/ — shared fixture base + 5 test classes covering create/update/delete/list/get/tokens and validation failures
Testing instructions
Testing steps — setup-automators skill
Trigger the skill
- Open an AI agent session (e.g. Claude Code) in this repo, in Agent/edit mode with tool access.
- Paste this prompt: Please use the setup-automators skill to help me configure an automator.
- Expected: the agent should first ask the Step 0 clarifying-intent questions (discovery vs. create/update/delete), not immediately run any drush command.
Skill gate
- Invoking the skill on an unrelated request does not run any drush command until Step 0's clarifying question is answered.
Tool module lifecycle
- With tool module disabled beforehand, running the skill enables it automatically and leaves it enabled only if the skill itself enabled it.
- With tool module already enabled beforehand, the skill does not disable it afterward.
- After the skill run, drush pm:list shows the Tool module's enabled/disabled state matches what it was before the run.
Discovery tools
- Listing automator type plugins returns every registered rule ID with label, target field types, and description.
- Inspecting a single automator type (e.g. summarize_to_text_long) returns its needs_prompt, advanced_mode, allowed_inputs, and placeholder_text.
- Listing replacement tokens in base mode for a field returns Twig-style placeholders (e.g. {{ context }}).
- Listing replacement tokens in token mode for the same field returns core Token-module placeholders (e.g. [node:title]) instead.
- Listing tokens without specifying a rule falls back to the rule already configured on that field.
Read tools
- Listing configured automators with no filters returns every ai_automator entity on the site.
- Listing configured automators filtered by entity type/bundle/field name returns only matching entities.
- Reading one automator by entity type/bundle/field name returns its full configuration, including prompt/token and plugin_config.
Create/update tool
- Creating a new automator on a field with no existing automator succeeds and computes the entity ID as <entity_type>..<field_name>.default.
- Updating only the prompt on an existing automator changes just the prompt and leaves provider, model, and every other plugin_config key untouched (non-clobbering regression check).
- Creating two chained automators (a "producer" and a "consumer") with explicit weights 10 spaces apart runs them in the correct order on entity save.
- Attempting to save an automator with a rule incompatible with the field's type fails and the error lists compatible rule IDs instead of crashing.
Delete tool
- Deleting an automator only removes the ai_automator config entity — the underlying field and its data are untouched.
- The skill asks for explicit user confirmation before calling delete, and never calls it as a side effect of another operation.
Checklist
- I have linked the related issue in the MR title or description
- I have performed a self-review of my own code
- I have added or updated tests, or explained in the description why this change is not covered by tests
- I have updated documentation for any new or changed functionality
- I have written testing instructions and verified them locally
- I have noted any required post-merge steps (config imports, cache rebuilds, manual changes)
- This MR contains no breaking API or hook changes, or they are explicitly documented in the description
AI Compliance
Note
Check the one that best describes your usage, or leave all unchecked if AI was not significantly used.
-
AI Assisted Code
Mainly written by a human; AI used for autocomplete or partial generation under full human supervision. -
AI Generated Code
Mainly generated by AI, reviewed and approved by a human before this MR was created. -
Vibe Coded
Generated by AI and only functionally reviewed before this MR was created.
Closes #3586563