@webship.co/workspace-typo3 1.0.7 → 1.0.9

package/README.md

@@ -3,7 +3,8 @@
 TYPO3 for the [Webship Workspace](https://github.com/webship/workspace) dashboard: a builder
 that makes a real TYPO3 site in a container, a typo3 console tool for the sites it built, the default
 accounts, the [TYPO3 step pack](https://github.com/webship/typo3-steps) wired into the
-workspace's testing setup, and two AI agents that know all of it.
+workspace's testing setup, and its AI items — two agents, a skill, a command and a prompt —
+each listed in the workspace folder of its kind.
 
 The workspace is container-based (DDEV by default): a TYPO3 project is a row like any other, so
 the row menus the core draws (start, stop, launch, backup, clone, remove, tests) work on it unchanged.
@@ -17,19 +18,46 @@ It is made from the reference platform plugin,
 cd ~/workspace
 bash core/scripts/plugins.sh --require github:webship/workspace-typo3   # npm install into the dashboard
 bash core/scripts/plugins.sh --activate typo3                            # plugins.typo3 in settings.yml
-bash core/scripts/plugins.sh --install typo3                             # commands, functions, args, agents
+bash core/scripts/plugins.sh --install typo3                             # commands, functions, args, AI items
 bash core/scripts/plugins.sh --configure typo3                           # nothing to configure: it has no settings file
 ```
 
 The same four steps are buttons on the dashboard's **Settings → Plugins** page. `--install` is
-idempotent. `--uninstall` removes what it placed; an agent you edited stays.
+idempotent. `--uninstall` removes what it placed; an AI item you edited stays.
 
-The commands land in the sites folders that are in the workspace (`dev`, `test`, `sandboxes`,
-`demos`); the agents land in the AI Agents folder (`ai-agents/`) when the workspace has one, and are
-installed into `~/.claude/agents` from there like any other agent.
+Everything the plugin carries lands in the folder it belongs to, when that folder is an active
+workspace folder:
+
+| What | Lands in |
+| --- | --- |
+| `cmd-typo3-project.sh`, `cmd-tools-typo3-cli.sh` | every active sites folder: `dev/`, `test/`, `sandboxes/`, `demos/` |
+| The agents `typo3-site-builder`, `typo3-tester` | `ai-agents/` |
+| The skill `typo3-scenarios` | `ai-skills/` |
+| The command `/typo3-test` | `ai-commands/` |
+| The prompt `typo3-build-and-test` | `ai-prompts/` |
+
+There they are listed like any other item of the folder, and installed into Claude Code from there.
 
 It needs a Webship Workspace 1.0.7 or later.
 
+## What it needs
+
+A workspace starts empty, so the manifest says what else this plugin needs (`needs`):
+
+- one sites folder, for the builder and the tool: `dev`, `test`, `sandboxes`, `demos` (`dev` is the one added when none is there). The folder also carries `cmd-tools-testing.sh` and the Users tools this plugin's hooks answer to.
+- `ai-agents`, `ai-skills`, `ai-commands` and `ai-prompts`: the AI folders its agents, its skill, its command and its prompt are placed in.
+
+`--require` says so, `--activate` and `--install` stop until the workspace has them, and `--with-needs` adds what is missing first:
+
+```bash
+bash core/scripts/plugins.sh --activate typo3 --with-needs   # dev and the four AI folders are required, activated and installed first
+bash core/scripts/plugins.sh --install typo3
+```
+
+Everything the builder runs for a site runs in the site's own container, through the container tool the workspace already needs; the plugin asks for no command of its own on the machine.
+
+A workspace that knows none of this (Webship Workspace 1.0.8 and older) ignores the keys: add a sites folder and the AI folders yourself, then `--install typo3` again. A kind whose folder is not there is skipped, and the install says so.
+
 ## What the package holds
 
 | Path | What it is |
@@ -39,8 +67,12 @@ It needs a Webship Workspace 1.0.7 or later.
 | `scripts/functions/fun-typo3.sh` | The bash functions behind both, sourced by bootstrap once installed; the names the core's tools look for (`set_typo3_users`, `add_typo3_users`, `cancel_typo3_users`, `testing_configure_typo3`) |
 | `scripts/args/arg-typo3.sh`, `arg-typo3-cli.sh` | Their argparse; the Build form draws the builder's flags from the first |
 | `testing/site.feature` | The first feature a TYPO3 project gets when testing is set up |
-| `agents/typo3-site-builder.md` | The agent that builds and maintains TYPO3 sites with these commands |
-| `agents/typo3-tester.md` | The agent that writes and runs scenarios with the TYPO3 step pack |
+| `ai/agents/typo3-site-builder.md` | The agent that builds and maintains TYPO3 sites with these commands |
+| `ai/agents/typo3-tester.md` | The agent that writes and runs scenarios with the TYPO3 step pack |
+| `ai/skills/typo3-scenarios/` | The skill: the step pack's phrases by area, the traps found on a real site, three example features |
+| `ai/commands/typo3-test.md` | The slash command `/typo3-test <site>`: set up, match every step, run, report |
+| `ai/prompts/typo3-build-and-test.md` | The prompt: a whole launch command for a new session |
+| `docs/plugin-items-pattern.md` | How a plugin carries its own commands and AI items, and how to prove it |
 | `src/index.ts` | `register(api)`: what the assistant is told about TYPO3 here |
 | `features/typo3.feature` | Scenarios for the dashboard's own browser suite |
 
@@ -121,25 +153,46 @@ webship-js's own, writes the users registry (the handles above, overridable with
 project has none, and makes sure the default accounts are on the site. Run it again and it adds what
 is missing and keeps what you changed.
 
-## The agents
+## The AI items
 
-| Agent | Use it to |
-| --- | --- |
-| `typo3-site-builder` | Build, update, maintain or remove a TYPO3 site with the commands above, in containers only |
-| `typo3-tester` | Set the testing stack up, look at the site in the Playwright MCP browser first, write scenarios from the pack's steps and run them; it never creates an account in a suite and never writes a platform name into a step phrase |
+`ai/` in the package holds one folder per kind, the manifest's `ai` block names each item, and
+`--install` places it in the workspace folder of that kind.
 
-After `--install` they are in the AI Agents folder of the dashboard; **Install** there puts one into
-`~/.claude/agents`, or from the command line:
+| Kind | Item | Use it to |
+| --- | --- | --- |
+| Agent | `typo3-site-builder` | Build, update, maintain or remove a TYPO3 site with the commands above, in containers only |
+| Agent | `typo3-tester` | Set the testing stack up, look at the site in the Playwright MCP browser first, write scenarios from the pack's steps and run them; it never creates an account in a suite and never writes a platform name into a step phrase |
+| Skill | `typo3-scenarios` | Write a scenario from phrases that exist: the pack's steps by area (the backend and its modules, the page tree, records and content elements, the public site), the handles of the users registry, the traps found on a real site, and three features that pass on a fresh site |
+| Command | `/typo3-test <site> [feature or @tag]` | Run the suite of a site from inside a session: set up when missing, match every step, run, report what failed and why |
+| Prompt | `typo3-build-and-test` | Start a session that builds a site with the Introduction package, says what it is, sets the testing stack up and runs the first feature |
+
+After `--install` each is in its folder on the dashboard. **Install** there puts an agent, a skill
+or a command into Claude Code (`~/.claude/agents`, `~/.claude/skills`, `~/.claude/commands`), or
+from the command line:
 
 ```bash
-cd ~/workspace/ai-agents
-bash cmd-tools-ai-items.sh typo3-tester --install
+cd ~/workspace/ai-agents   && bash cmd-tools-ai-items.sh typo3-tester --install
+cd ~/workspace/ai-skills   && bash cmd-tools-ai-items.sh typo3-scenarios --install
+cd ~/workspace/ai-commands && bash cmd-tools-ai-items.sh typo3-test --install
 ```
 
+A prompt is not installed: it is the whole `claude …` launch command of a new session, and the
+dashboard's **New screen** form lists it as a template. By hand, fill the placeholders in and run
+the command of the file from the folder it names.
+
+The items are written for any AI CLI, with Claude Code as the default shape: the frontmatter and
+the file layout are Claude Code's, the body of each item is plain Markdown that names no tool or
+feature of one CLI, a command says in words what its arguments are, and the text between the
+triple quotes of a prompt can be given to another AI CLI as it is.
+
+Every step phrase the items show is checked against the definitions of the step pack and of
+webship-js (`tests/fixtures/step-definitions.txt`), and every command and flag against the
+plugin's own. The shape is the reference's: [`docs/plugin-items-pattern.md`](docs/plugin-items-pattern.md).
+
 ## Develop it
 
 ```bash
 npm install     # builds dist/ (TypeScript)
 npm run lint
-npm test        # the manifest, the commands, the agents, the functions against a scaffolded project
+npm test        # the manifest, the commands, the AI items, the functions against a scaffolded project
 ```

package/{agents → ai/agents}/typo3-site-builder.md

@@ -104,3 +104,11 @@ stack, with the TYPO3 step pack).
 | A page shows old content | The caches: `bash cmd-tools-typo3-cli.sh <name> --flush`. |
 | `The site has no backend group "Advanced editors"` | The accounts were added to a site without the Introduction package: `editor` exists, with no rights until you give it a group. |
 | `is not a TYPO3 project` from the CLI tool | The project's `.ddev/config.yaml` does not say `type: typo3`: it was not built by this builder. |
+
+## What comes with you
+
+The TYPO3 plugin places these beside you, each in the workspace folder of its kind: the agent
+`typo3-tester` (`ai-agents/`), the skill `typo3-scenarios` (`ai-skills/`), the command
+`/typo3-test <site>` (`ai-commands/`) and the prompt `typo3-build-and-test` (`ai-prompts/`), which is
+this agent's whole first job as a launch command: build, say what the site is, set the testing
+stack up, run the first feature.

package/{agents → ai/agents}/typo3-tester.md

@@ -20,8 +20,8 @@ tools:
 
 # typo3-tester
 
-You test TYPO3 sites in a Webship Workspace (`~/workspace`) with
-[webship-js](https://github.com/webship/webship-js) (Playwright and Cucumber) and its TYPO3 step
+You test TYPO3 sites in a Webship Workspace (`~/workspace`), a container-based workspace (DDEV
+by default), with [webship-js](https://github.com/webship/webship-js) (Playwright and Cucumber) and its TYPO3 step
 pack, [`@webship-js/typo3-steps`](https://github.com/webship/typo3-steps). The suite lives in
 the project (`cucumber.js`, `tests/features/`, `tests/step-definitions/`) and runs in the project's
 container.
@@ -93,7 +93,8 @@ for another environment with `TYPO3_<HANDLE>_USER` and `TYPO3_<HANDLE>_PASS`.
 - **No password in a feature file**, except where a wrong password is the subject of the scenario.
 - **No platform name in a step phrase.** A step says what a person does or sees: `I am a logged in
   user with the "editor" user`, `I open the "Page" module`, `I select the "Home" page in the page
-  tree`. Never a phrase with the platform's name in it. The same holds for a custom step you write.
+  tree`. Never a phrase with the platform's name in it: the name is a value where a step needs it
+  (`the page generator should start with "TYPO3"`). The same holds for a custom step you write.
 - **No CSS selector and no address in a scenario when a step of the pack says it.** `the "List"
   module`, not `/typo3/module/web/list`.
 - **A custom step is the last resort.** Look in the pack and in webship-js first. If one is really
@@ -123,3 +124,13 @@ Feature: An editor works in the page module
 
 Check every phrase against the installed definitions before you run it: the pack moves, and a phrase
 from memory is a guess.
+
+## What comes with you
+
+The TYPO3 plugin places these beside you, each in the workspace folder of its kind:
+
+| Item | Where | What it is for |
+| --- | --- | --- |
+| `typo3-scenarios` (skill) | `ai-skills/` | The pack's phrases by area, the traps found on a real site, and three example features that pass on a fresh site |
+| `/typo3-test <site>` (command) | `ai-commands/` | The run itself: set up when missing, match every step, run, report |
+| `typo3-build-and-test` (prompt) | `ai-prompts/` | A new session that builds a site and runs its first feature |

package/ai/commands/typo3-test.md

@@ -0,0 +1,90 @@
+---
+description: Test a TYPO3 site of the Webship Workspace with webship-js and the TYPO3 step pack — set the testing stack up when it is missing, match every step, run the suite (or one feature, or one tag) in the site's container, and report what failed and why.
+argument-hint: '<site> [tests/features/<name>.feature | @tag]'
+---
+
+# /typo3-test
+
+Test the TYPO3 site named in: `$ARGUMENTS`
+
+`$ARGUMENTS` stands for what was typed after the command. An AI CLI that does not fill it in
+reads the same from the request: the name of the site, then, if anything, one feature path or one
+tag.
+
+The first word is the site (its folder name in a sites folder of the workspace). What follows, if
+anything, narrows the run: a path that starts with `tests/features/` is one feature (or one
+folder of features), a word that starts with `@` is a tag expression. With nothing after the site,
+the whole suite runs. With no site at all, stop and ask for one: list the candidates with
+`grep -lE '^type: *"?typo3"?' ~/workspace/*/*/.ddev/config.yaml`.
+
+The workspace is container-based (DDEV by default) and everything below runs in the site's
+container through the workspace's own command. Never run `npx cucumber-js`, `npx playwright`,
+`typo3`, `composer` or `npm` on the host for a site.
+
+## 1. Find the site
+
+```bash
+ls -d ~/workspace/*/<site>/.ddev/config.yaml
+grep -E '^type:' ~/workspace/<folder>/<site>/.ddev/config.yaml
+```
+
+`<folder>` is the sites folder the site is in (`dev`, `test`, `sandboxes`, `demos`). If the type is
+not `typo3`, stop: this command is for a site built with `cmd-typo3-project.sh`. If `<folder>` has no `cmd-tools-testing.sh`, stop and say that the folder
+is not a sites folder of this workspace.
+
+## 2. Make sure the testing stack is there
+
+```bash
+cd ~/workspace/<folder>
+grep -c "@webship-js/typo3-steps" <site>/cucumber.js
+```
+
+If `cucumber.js` is missing or does not name the step pack, set the stack up (it adds what is
+missing and keeps what was changed):
+
+```bash
+bash cmd-tools-testing.sh <site>
+```
+
+## 3. Match every step, without a browser
+
+```bash
+bash cmd-tools-testing.sh <site> --dry-run                                        # the whole suite
+bash cmd-tools-testing.sh <site> --dry-run --path tests/features/<name>.feature   # one feature
+bash cmd-tools-testing.sh <site> --dry-run --tags "@critical"                     # one tag
+```
+
+Use the form that matches what was asked. An `Undefined` or `Ambiguous` step is a finding: name
+the feature, the line and the phrase, show the closest phrase the pack defines
+(`grep -hE "^(Given|When|Then)\(" <site>/node_modules/@webship-js/typo3-steps/tests/step-definitions/*.steps.js`),
+and stop before the real run.
+
+## 4. Run
+
+```bash
+bash cmd-tools-testing.sh <site> --run                                            # the whole suite
+bash cmd-tools-testing.sh <site> --run --path tests/features/<name>.feature       # one feature
+bash cmd-tools-testing.sh <site> --run --tags "@critical"                         # one tag
+```
+
+Run it once. Do not add `--retry`, do not tag a scenario `@wip` and do not change a feature to
+make the run pass.
+
+## 5. Report
+
+Say, in this order:
+
+1. The site, its address (`https://<site>.ddev.site`) and what was run (suite, feature or tag).
+2. The totals the run printed: scenarios and steps, passed and failed, and the time.
+3. For each failed scenario: the feature and line, the step that failed, the message with its
+   `Why` and `Hint` lines, and what it means for the site — a defect of the site, a scenario that
+   asserts something the site never did (a page of the Introduction package on a site built with
+   `--bare`, a page named by its title where the page tree needs its path), or the environment
+   (the site was stopped, an account is missing:
+   `bash cmd-tools-typo3-cli.sh <site> --add-users` adds the default ones).
+4. Where the report is: `~/workspace/<folder>/<site>/tests/reports/`.
+
+A failing suite is a result: report it as it is. Never create an account for a scenario, never
+write a password into a feature file, and never write a platform name into a step phrase. For
+writing or fixing scenarios, use the `typo3-scenarios` skill or hand over to the `typo3-tester`
+agent; for changing the site, to `typo3-site-builder`.

package/ai/prompts/typo3-build-and-test.md

@@ -0,0 +1,26 @@
+Build a TYPO3 site in a sites folder and prove it with its first webship-js feature.
+
+The launch command below is for Claude Code, the default; the text between the triple quotes can be given to another AI CLI as it is.
+
+```
+claude --permission-mode bypassPermissions """
+Build a TYPO3 site named <name> in this sites folder and test it with webship-js
+# ~/workspace/<dev|test|sandboxes|demos> · https://<name>.ddev.site · container-based (DDEV by default)
+# the builder deletes a project of the same name first: stop if <name> is a site somebody still needs
+# nothing on the host: no typo3, composer, npm or mysql outside the site's container
+
+1. bash cmd-typo3-project.sh <name> --install --add-users
+   (the Introduction package comes with it: a site with pages and content; add --version <x> for
+   another release)
+2. bash cmd-tools-typo3-cli.sh <name>
+   tell me the version, the address, the sites and the backend accounts it lists
+3. bash cmd-tools-testing.sh <name>
+   webship-js, the step pack, the users registry and tests/features/site.feature
+4. bash cmd-tools-testing.sh <name> --dry-run --path tests/features/site.feature
+5. bash cmd-tools-testing.sh <name> --run --path tests/features/site.feature
+
+If a command fails, show the line that failed and stop. Do not retry with other flags.
+When the feature is green: the address, the version, how many scenarios and steps passed.
+Then ask me whether to keep the site or remove it with: bash cmd-tools-remove.sh <name>
+"""
+```

package/ai/skills/typo3-scenarios/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: typo3-scenarios
+description: Write and run webship-js scenarios for a TYPO3 site of the Webship Workspace with the TYPO3 step pack (`@webship-js/typo3-steps`) — the phrases of the pack by area (the backend session and its modules, the page tree, records and content elements, the public site with its menus, breadcrumb, languages and search), the handles of the users registry, and the workspace command that runs them in the site's container. Use when asked to "write a scenario for this TYPO3 site", "test the editor account", "which step is there for the page tree", "add a feature for creating a page", or when a `.feature` file of a TYPO3 project is being written or fixed.
+argument-hint: '<site> [what to cover]'
+---
+
+# typo3-scenarios
+
+Scenarios for a TYPO3 site of a Webship Workspace (`~/workspace`, container-based, DDEV by
+default), written from the steps of [`@webship-js/typo3-steps`](https://github.com/webship/typo3-steps)
+and of [webship-js](https://github.com/webship/webship-js) itself, and run in the site's container
+by the workspace's own command. It comes with the TYPO3 plugin (`@webship.co/workspace-typo3`),
+like the builder (`cmd-typo3-project.sh`), the console tool (`cmd-tools-typo3-cli.sh`) and the
+agents `typo3-site-builder` and `typo3-tester`.
+
+## Where everything is
+
+| What | Where |
+| --- | --- |
+| The site | `~/workspace/<folder>/<site>`, at `https://<site>.ddev.site`, the backend at `/typo3` (`<folder>` is a sites folder: `dev`, `test`, `sandboxes`, `demos`) |
+| The suite's configuration | `<site>/cucumber.js`: the step definitions it loads and the users registry (`worldParameters.users`) |
+| The features | `<site>/tests/features/*.feature` (`site.feature` is the first one the setup wrote) |
+| The pack's steps | `<site>/node_modules/@webship-js/typo3-steps/tests/step-definitions/*.steps.js` |
+| The pack's own features | `<site>/node_modules/@webship-js/typo3-steps/tests/features/*.feature`: written for the same Introduction package, worth reading before writing one |
+| webship-js's steps | `<site>/node_modules/webship-js/tests/step-definitions/*.js` |
+| The reports | `<site>/tests/reports/` |
+
+## The order of work
+
+1. **Make sure the testing stack is there.** From the sites folder:
+   ```bash
+   cd ~/workspace/<folder>
+   bash cmd-tools-testing.sh <site>
+   ```
+   It adds webship-js, the step pack, the users registry and `tests/features/site.feature`, and
+   makes sure the default accounts are on the site. It is safe to run again: it adds what is
+   missing and keeps what was changed.
+2. **Read the installed steps before writing a phrase.** They are the source of truth: the pack
+   moves, and a phrase from memory is a guess.
+   ```bash
+   cd ~/workspace/<folder>/<site>
+   grep -hE "^(Given|When|Then)\(" node_modules/@webship-js/typo3-steps/tests/step-definitions/*.steps.js
+   ```
+   Every step carries a comment block with examples above it; open the file when a phrase is not
+   obvious.
+3. **Look at the page first** (the Playwright MCP browser, a tab of your own) when the scenario
+   is about a screen you have not seen. A scenario written without having seen the page asserts
+   what you imagine.
+4. **Write the feature** in `<site>/tests/features/`, from phrases that exist (the lists below).
+5. **Match every step without a browser**, then run the feature, then the suite:
+   ```bash
+   cd ~/workspace/<folder>
+   bash cmd-tools-testing.sh <site> --dry-run --path tests/features/<name>.feature
+   bash cmd-tools-testing.sh <site> --run --path tests/features/<name>.feature
+   bash cmd-tools-testing.sh <site> --run --tags "@critical"
+   bash cmd-tools-testing.sh <site> --run
+   ```
+   A dry run says `Undefined` for a phrase no definition matches: fix the phrase, do not write a
+   step for it.
+
+## Accounts: a handle, never a password
+
+A scenario logs in to the backend by a handle of the users registry. The default accounts are on
+the site already (`bash cmd-tools-typo3-cli.sh <site> --add-users` adds them again if they were
+removed):
+
+| Handle | Account | Role |
+| --- | --- | --- |
+| `admin` | `administrator` | administrator (not a system maintainer) |
+| `editor` | `editor` | the backend group "Advanced editors" of the Introduction package |
+
+```gherkin
+Given I am a logged in user with the "editor" user
+Then I should be logged in as "editor"
+```
+
+## The phrases, by area
+
+Each line is a phrase the pack defines, and each one passed on a site built with
+`bash cmd-typo3-project.sh <site> --install --add-users` (TYPO3 with the Introduction package; the
+names in quotes are that site's). Most `should` steps also take the negative: `should not see`,
+`should not be`.
+
+### The backend: session and modules
+
+```gherkin
+Given I am a logged in user with the "editor" user
+Given I am not logged in
+When I log out
+Then I should be logged in as "editor"
+Then I should not be logged in
+Then I should not see a login error
+When I open the "Page" module
+Then the "Page" module should be active
+Then I should see the "List" module
+Then I should not see the "Backend Users" module
+Then the module heading should be "Create new Page"
+```
+
+### The page tree
+
+```gherkin
+Then I should see the "Congratulations" page in the page tree
+When I search the page tree for "Rich Text"
+When I select the "Congratulations > 404" page in the page tree
+When I choose "New subpage" from the context menu of the "Congratulations > 404" page
+When I choose "Enable" from the context menu of the "Congratulations > 404 > A new page" page
+When I choose "Delete" from the context menu of the "Congratulations > 404 > A new page" page
+Then the "Congratulations > 404 > A new page" page should be hidden in the page tree
+Then I should not see the "Congratulations > 404 > A new page" page in the page tree
+Given there is no "Congratulations > 404 > A new page" page
+```
+
+### Records and content elements
+
+```gherkin
+When I fill in the "Page Title" record field with "A new page"
+When I save the record
+When I close the record
+Then I should see the notification "Record saved"
+Then the "Page Title" record field should be marked as invalid
+When I confirm the dialog
+When I add a "Header Only" content element to the "Normal" column
+When I fill in the "Header" record field with "A header written by a scenario"
+Then I should see the "A header written by a scenario" content element in the page module
+```
+
+### The public site
+
+```gherkin
+Then I should see the "Features" menu item
+When I open the "Features" menu item
+Then the "Features" menu item should be active
+Then I should see the "Search" subnavigation item
+When I open the "Search" subnavigation item
+Then I should be viewing the "Search" page
+Then I should see the breadcrumb
+Then the breadcrumb should contain "Content Examples"
+Then the "Deutsch" language should be available
+When I switch to the "Deutsch" language
+When I search the site for "zzzqqqxyz"
+Then I should see no search results
+Then I should be on the 404 page
+```
+
+`I am an anonymous user`, `I am on the homepage`, `I am on "<path>"`, `I should be on "<path>"`,
+`the page language should be "<code>"`, `I should see "<text>"` and
+`the response status code should be 200` are webship-js's own steps; its status codes, classes,
+landmarks and accessibility audits are used as they are and never redefined for this platform.
+
+## Traps found on a real site
+
+- **A page is named by its path in the page tree**, from the root: `"Congratulations > 404 > A
+  new page"`. A title alone finds only a page that is already shown.
+- **The page tree steps need the backend and a module of the Web group.**
+  `Given there is no "<path>" page` before the login, or before `I open the "Page" module`, fails:
+  log in, open the module, then clear.
+- **A new page is hidden**, and a logged in backend user previews hidden pages. Enable the page
+  from its context menu, and drop the session (`Given I am not logged in`) before asserting what a
+  visitor sees.
+- **`I should be viewing the "<title>" page` reads the `h1`.** On a landing page of the
+  Introduction package the `h1` is a slogan, not the page title: after
+  `I open the "Features" menu item` assert `I should be on "/features"` and
+  `the "Features" menu item should be active`. On a content page (`"Search"`) the step works.
+- **The start page has no breadcrumb**: `I should not see the breadcrumb` passes there.
+- **The pages, the menu and the translations are the Introduction package's.** A site built with
+  `--bare` has a backend and no page: the public-site phrases and every page path above fail
+  there.
+- **`admin` is an administrator and not a system maintainer**: no Extensions module and no Admin
+  Tools. A scenario about those needs another account, asked for, not made.
+- **The generator is a value of a step**, not a part of its phrase: `the page generator should
+  start with "TYPO3"`, `the page generator should be "TYPO3 CMS"`. The meta tag carries no
+  version: read the version with `bash cmd-tools-typo3-cli.sh <site>`.
+- A scenario that failed after it created a page left it behind: start the scenario with
+  `Given there is no "<path>" page`, so the next run clears it.
+
+## Rules
+
+- **No account is created in a suite.** No `backend:user:create` in a hook, no step that adds an
+  account. A role the registry does not have is asked for, not made.
+- **Never the workspace account.** The site's own administrator is not in the registry; `admin`
+  is the `administrator` default account.
+- **No password in a feature file**, except where a wrong password is the subject.
+- **No platform name in a step phrase**: `I open the "Page" module`, never a phrase that names
+  the platform. The same holds for a custom step.
+- **No selector when a step says it**: `the "Page" module`, `the "Header" record field`, not
+  their classes.
+- **What a scenario creates, it removes** in the same scenario, under a title nobody else uses.
+- **A custom step is the last resort**: look in the pack and in webship-js first, write it in
+  `<site>/tests/step-definitions/` with a comment block and examples, and say it may belong in
+  the pack.
+- **Everything runs in the container**, through `cmd-tools-testing.sh`. Never `npx cucumber-js`
+  or `npx playwright` on the host.
+- **A failing scenario is a result.** No `@wip`, no longer timeout, no looser assertion to turn a
+  run green: say what the site did.
+
+## Examples that run
+
+`examples/` holds three features that pass on a site built with
+`bash cmd-typo3-project.sh <site> --install --add-users`. Copy one into the suite and run it:
+
+```bash
+cp ~/workspace/ai-skills/typo3-scenarios/examples/modules-and-accounts.feature ~/workspace/<folder>/<site>/tests/features/
+cd ~/workspace/<folder>
+bash cmd-tools-testing.sh <site> --run --path tests/features/modules-and-accounts.feature
+```
+
+| Feature | What it shows |
+| --- | --- |
+| `examples/modules-and-accounts.feature` | The modules of the editor and of the administrator, a search of the page tree, the end of a session |
+| `examples/page-lifecycle.feature` | A page created, enabled, given a content element, seen by a visitor and deleted; a page refused without a title |
+| `examples/site-navigation.feature` | The main menu, the subnavigation, the breadcrumb, a translation, the 404 page and an empty search |

package/ai/skills/typo3-scenarios/examples/modules-and-accounts.feature

@@ -0,0 +1,35 @@
+Feature: Each account gets the backend modules of its role
+  As the owner of the site
+  I want the administrator and the editor to log in and to see their own modules
+  So that a change of backend groups is caught by the suite
+
+  # The accounts are the default ones; a scenario logs in by a handle of the users registry.
+
+  Scenario: The editor works in the Page module and has no administration module
+    Given I am a logged in user with the "editor" user
+    Then I should be logged in as "editor"
+    When I open the "Page" module
+    Then the "Page" module should be active
+    And I should see the "Congratulations" page in the page tree
+    And I should see the "List" module
+    And I should not see the "Backend Users" module
+    And I should not see the "Log" module
+
+  Scenario: The administrator has the administration modules
+    Given I am a logged in user with the "admin" user
+    Then I should see the "Backend Users" module
+    And I should see the "Log" module
+    When I open the "List" module
+    Then the "List" module should be active
+
+  Scenario: The page tree finds a page by its title
+    Given I am a logged in user with the "editor" user
+    When I open the "Page" module
+    And I search the page tree for "Rich Text"
+    Then I should see the "Rich Text" page in the page tree
+
+  Scenario: Logging out ends the session
+    Given I am a logged in user with the "editor" user
+    When I log out
+    Then I should not be logged in
+    And I should not see a login error

package/ai/skills/typo3-scenarios/examples/page-lifecycle.feature

@@ -0,0 +1,44 @@
+Feature: A page is made in the backend and taken away again
+  As an administrator
+  I want to create a page, give it content, show it to visitors and delete it
+  So that the suite proves the backend works and leaves the site as it found it
+
+  # A page is named by its path in the page tree. A new page is hidden until it is enabled, and a
+  # logged in backend user previews hidden pages: the visitor steps drop the session first.
+
+  Scenario: The administrator makes a page with a header, shows it and deletes it
+    Given I am a logged in user with the "admin" user
+    And I open the "Page" module
+    And there is no "Congratulations > 404 > A page written by a scenario" page
+    When I choose "New subpage" from the context menu of the "Congratulations > 404" page
+    And I fill in the "Page Title" record field with "A page written by a scenario"
+    And I save the record
+    Then I should see the notification "Record saved"
+    When I close the record
+    Then the "Congratulations > 404 > A page written by a scenario" page should be hidden in the page tree
+    When I choose "Enable" from the context menu of the "Congratulations > 404 > A page written by a scenario" page
+    Then the "Congratulations > 404 > A page written by a scenario" page should not be hidden in the page tree
+    When I select the "Congratulations > 404 > A page written by a scenario" page in the page tree
+    And I add a "Header Only" content element to the "Normal" column
+    And I fill in the "Header" record field with "A header written by a scenario"
+    And I save the record
+    And I close the record
+    Then I should see the "A header written by a scenario" content element in the page module
+    Given I am not logged in
+    And I am on "/404/a-page-written-by-a-scenario"
+    Then I should not be on the 404 page
+    And I should see "A header written by a scenario"
+    Given I am a logged in user with the "admin" user
+    And I open the "Page" module
+    When I choose "Delete" from the context menu of the "Congratulations > 404 > A page written by a scenario" page
+    And I confirm the dialog
+    Then I should not see the "Congratulations > 404 > A page written by a scenario" page in the page tree
+
+  Scenario: A page needs a title
+    Given I am a logged in user with the "admin" user
+    And I open the "Page" module
+    When I choose "New subpage" from the context menu of the "Congratulations > 404" page
+    Then the module heading should be "Create new Page"
+    When I save the record
+    Then the "Page Title" record field should be marked as invalid
+    And I should not see the notification "Record saved"

package/ai/skills/typo3-scenarios/examples/site-navigation.feature

@@ -0,0 +1,40 @@
+Feature: A visitor finds their way around the site
+  As a visitor
+  I want the menu, the breadcrumb, the languages and the search to work
+  So that a broken template is caught by the suite
+
+  # For a site built with the Introduction package (the builder's default; not with --bare):
+  # the pages, the menu and the translations are the package's.
+
+  Scenario: The main menu leads to a page
+    Given I am an anonymous user
+    And I am on the homepage
+    Then the response status code should be 200
+    And I should see the "Features" menu item
+    And I should not see the breadcrumb
+    When I open the "Features" menu item
+    Then I should be on "/features"
+    And the "Features" menu item should be active
+
+  Scenario: A content page has its subnavigation and its breadcrumb
+    Given I am on "/content-examples/form-elements/forms"
+    Then I should see the "Search" subnavigation item
+    And I should see the breadcrumb
+    And the breadcrumb should contain "Content Examples"
+    When I open the "Search" subnavigation item
+    Then I should be viewing the "Search" page
+
+  Scenario: A translated page offers its translations
+    Given I am on "/content-examples/and-more/any-language-any-character"
+    Then the "Deutsch" language should be available
+    When I switch to the "Deutsch" language
+    Then the page language should be "de-DE"
+
+  Scenario: An address nobody made is the 404 page
+    Given I am on "/no-such-page-anywhere"
+    Then I should be on the 404 page
+
+  Scenario: A search for a word nobody wrote finds nothing
+    Given I am on "/content-examples/form-elements/search"
+    When I search the site for "zzzqqqxyz"
+    Then I should see no search results

package/dist/src/index.d.ts

@@ -3,8 +3,10 @@
  *
  * What the package carries is placed by the installer from the manifest: the builder and the
  * typo3 console tool in the sites folders, their functions and argparse under core/scripts/plugins/typo3/,
- * the agents in the AI Agents folder. The dashboard needs nothing drawn for it: the builder is in the
- * Build list because it is a cmd-*-project.sh, the row menus are the core's, the agents are listed
+ * its AI items (ai/ in this package) in the folder of their kind:
+ * the agents in AI Agents, the skill in AI Skills, the command in AI Commands, the prompt in AI Prompts.
+ * The dashboard needs nothing drawn for it: the builder is in the
+ * Build list because it is a cmd-*-project.sh, the row menus are the core's, the AI items are listed
  * like any other. What register() adds is what the assistant is told.
  *
  * Everything the dashboard is asked for goes through `api`; this package requires nothing from the
@@ -17,6 +19,12 @@ export declare const PLATFORM = "typo3";
 export declare const COMMANDS: string[];
 /** The agents the installer places in the AI Agents folder. */
 export declare const AGENTS: string[];
+/** The skill the installer places in the AI Skills folder (a folder each, with its SKILL.md). */
+export declare const SKILLS: string[];
+/** The slash command the installer places in the AI Commands folder. */
+export declare const AI_COMMANDS: string[];
+/** The prompt the installer places in the AI Prompts folder: each a whole launch command for a new session. */
+export declare const PROMPTS: string[];
 /** What the assistant is told about TYPO3 in this workspace. */
 export declare function assistantContext(): string;
 export declare function register(api: PluginApi): void;

package/dist/src/index.js

@@ -4,15 +4,17 @@
  *
  * What the package carries is placed by the installer from the manifest: the builder and the
  * typo3 console tool in the sites folders, their functions and argparse under core/scripts/plugins/typo3/,
- * the agents in the AI Agents folder. The dashboard needs nothing drawn for it: the builder is in the
- * Build list because it is a cmd-*-project.sh, the row menus are the core's, the agents are listed
+ * its AI items (ai/ in this package) in the folder of their kind:
+ * the agents in AI Agents, the skill in AI Skills, the command in AI Commands, the prompt in AI Prompts.
+ * The dashboard needs nothing drawn for it: the builder is in the
+ * Build list because it is a cmd-*-project.sh, the row menus are the core's, the AI items are listed
  * like any other. What register() adds is what the assistant is told.
  *
  * Everything the dashboard is asked for goes through `api`; this package requires nothing from the
  * dashboard's own files, so it can be installed from npm and removed without a trace.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.AGENTS = exports.COMMANDS = exports.PLATFORM = void 0;
+exports.PROMPTS = exports.AI_COMMANDS = exports.SKILLS = exports.AGENTS = exports.COMMANDS = exports.PLATFORM = void 0;
 exports.assistantContext = assistantContext;
 exports.register = register;
 /** The plugin's name, which is also the DDEV project type its functions are named after. */
@@ -21,6 +23,12 @@ exports.PLATFORM = 'typo3';
 exports.COMMANDS = ['cmd-typo3-project.sh', 'cmd-tools-typo3-cli.sh'];
 /** The agents the installer places in the AI Agents folder. */
 exports.AGENTS = ['typo3-site-builder', 'typo3-tester'];
+/** The skill the installer places in the AI Skills folder (a folder each, with its SKILL.md). */
+exports.SKILLS = ['typo3-scenarios'];
+/** The slash command the installer places in the AI Commands folder. */
+exports.AI_COMMANDS = ['typo3-test'];
+/** The prompt the installer places in the AI Prompts folder: each a whole launch command for a new session. */
+exports.PROMPTS = ['typo3-build-and-test'];
 /** What the assistant is told about TYPO3 in this workspace. */
 function assistantContext() {
     return [
@@ -32,6 +40,8 @@ function assistantContext() {
         '`--update` updates the Composer packages, `--flush` flushes the caches, `--add-users` adds the default accounts (an administrator and an editor).',
         '`bash cmd-tools-testing.sh <name>` sets up webship-js with the TYPO3 step pack; `--run` runs the suite.',
         `For TYPO3 work, hand over to the agents ${exports.AGENTS.map((a) => `\`${a}\``).join(' and ')}.`,
+        `The plugin also places the skill ${exports.SKILLS.map((a) => `\`${a}\``).join(', ')} (the step pack's phrases, by area) in ai-skills/,`,
+        `the command ${exports.AI_COMMANDS.map((a) => `\`/${a} <site>\``).join(', ')} in ai-commands/ and the prompt ${exports.PROMPTS.map((a) => `\`${a}\``).join(' and ')} in ai-prompts/.`,
         'Never run php, composer, npm or mysql on the host for a project.',
     ].join(' ');
 }

package/dist/src/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;GAWG;;;AAcH,4CAYC;AAED,4BAEC;AA1BD,4FAA4F;AAC/E,QAAA,QAAQ,GAAG,OAAO,CAAC;AAEhC,+DAA+D;AAClD,QAAA,QAAQ,GAAG,CAAC,sBAAsB,EAAE,wBAAwB,CAAC,CAAC;AAE3E,+DAA+D;AAClD,QAAA,MAAM,GAAG,CAAC,oBAAoB,EAAE,cAAc,CAAC,CAAC;AAE7D,gEAAgE;AAChE,SAAgB,gBAAgB;IAC9B,OAAO;QACL,2EAA2E;QAC3E,6GAA6G;QAC7G,gIAAgI;QAChI,gGAAgG;QAChG,kIAAkI;QAClI,mJAAmJ;QACnJ,yGAAyG;QACzG,2CAA2C,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG;QACzF,kEAAkE;KACnE,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACd,CAAC;AAED,SAAgB,QAAQ,CAAC,GAAc;IACrC,GAAG,CAAC,mBAAmB,CAAC,gBAAgB,CAAC,CAAC;AAC5C,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;GAaG;;;AAuBH,4CAcC;AAED,4BAEC;AArCD,4FAA4F;AAC/E,QAAA,QAAQ,GAAG,OAAO,CAAC;AAEhC,+DAA+D;AAClD,QAAA,QAAQ,GAAG,CAAC,sBAAsB,EAAE,wBAAwB,CAAC,CAAC;AAE3E,+DAA+D;AAClD,QAAA,MAAM,GAAG,CAAC,oBAAoB,EAAE,cAAc,CAAC,CAAC;AAE7D,iGAAiG;AACpF,QAAA,MAAM,GAAG,CAAC,iBAAiB,CAAC,CAAC;AAE1C,wEAAwE;AAC3D,QAAA,WAAW,GAAG,CAAC,YAAY,CAAC,CAAC;AAE1C,+GAA+G;AAClG,QAAA,OAAO,GAAG,CAAC,sBAAsB,CAAC,CAAC;AAEhD,gEAAgE;AAChE,SAAgB,gBAAgB;IAC9B,OAAO;QACL,2EAA2E;QAC3E,6GAA6G;QAC7G,gIAAgI;QAChI,gGAAgG;QAChG,kIAAkI;QAClI,mJAAmJ;QACnJ,yGAAyG;QACzG,2CAA2C,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG;QACzF,oCAAoC,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,oDAAoD;QAChI,eAAe,mBAAW,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,MAAM,CAAC,WAAW,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,mCAAmC,eAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,kBAAkB;QACrK,kEAAkE;KACnE,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACd,CAAC;AAED,SAAgB,QAAQ,CAAC,GAAc;IACrC,GAAG,CAAC,mBAAmB,CAAC,gBAAgB,CAAC,CAAC;AAC5C,CAAC"}

package/docs/plugin-items-pattern.md

@@ -0,0 +1,150 @@
+# A plugin carries its own items
+
+Every `@webship.co/workspace-<name>` plugin manages what belongs to it: its `cmd-*.sh` commands and
+its AI items (agents, skills, commands, prompts). The package holds them, the manifest names them,
+and `plugins.sh --install <name>` lists each one in the workspace folder of its kind, when that
+folder is an active workspace folder. `--uninstall` takes them away again. The reference is
+[`@webship.co/workspace-wordpress`](https://github.com/webship/workspace-wordpress), and this plugin
+follows it; below, `<p>` is the plugin's name.
+
+## The layout
+
+```text
+commands/cmd-<p>-project.sh            cmd-*.sh scripts only: builders and tools, placed in workspace folders
+commands/cmd-tools-<p>-cli.sh
+ai/agents/<p>-<role>.md                one file per agent
+ai/skills/<p>-<topic>/SKILL.md         one folder per skill; every file in it is placed (examples/, references/)
+ai/commands/<p>-<verb>.md              one file per slash command
+ai/prompts/<p>-<task>.md               one file per prompt
+tests/items.test.ts                    the shape of every item, and that it names nothing that does not exist
+tests/fixtures/step-definitions.txt    the step definitions the items' phrases are checked against (a plugin with a step pack)
+```
+
+`commands/` is taken by the `cmd-*.sh` scripts, so the AI items live under `ai/`, one folder per
+kind, named like the manifest's `ai` keys. The installer places an item by the last part of its
+path, whatever folder the package keeps it in, so a plugin that kept its agents in `agents/` moves
+them with `git mv agents ai/agents` and changes two lines of its manifest.
+
+## The manifest
+
+```json
+"files": ["dist/src", "ai", "commands", "docs", "features", "scripts", "testing", "README.md"],
+"workspacePlugin": {
+  "name": "<p>",
+  "needs": [["dev", "test", "sandboxes", "demos"], "ai-agents", "ai-skills", "ai-commands", "ai-prompts"],
+  "commands": { "types": ["sites"], "workspaces": ["dev", "test", "sandboxes", "demos"],
+                "files": ["commands/cmd-<p>-project.sh", "commands/cmd-tools-<p>-cli.sh"] },
+  "ai": {
+    "agents":   ["ai/agents/<p>-site-builder.md", "ai/agents/<p>-tester.md"],
+    "skills":   ["ai/skills/<p>-scenarios"],
+    "commands": ["ai/commands/<p>-test.md"],
+    "prompts":  ["ai/prompts/<p>-build-and-test.md"]
+  }
+}
+```
+
+- `ai` is in `files`, or the items are not in the published package.
+- A skill is named by its folder, with no `/SKILL.md` and no trailing slash.
+- `needs` names the folder of every kind the plugin ships, after the folder its commands need. A
+  plugin with no `cmd-*.sh` for a sites folder leaves the first entry out; a kind it does not ship
+  is left out of `ai` and of `needs`.
+
+| Kind | Lands in | Claude Code reads it from |
+| --- | --- | --- |
+| `commands.files` | every active folder `commands.workspaces` names, else every active folder of `commands.types` | the folder itself: `bash cmd-….sh` |
+| `ai.agents` | `ai-agents/<name>.md` | `~/.claude/agents`, after Install |
+| `ai.skills` | `ai-skills/<name>/` | `~/.claude/skills`, after Install |
+| `ai.commands` | `ai-commands/<name>.md` | `~/.claude/commands`, after Install: `/<name>` |
+| `ai.prompts` | `ai-prompts/<name>.md` | nothing: the New screen form lists it as a template for a new session |
+
+## The shape of each kind
+
+| Kind | Shape |
+| --- | --- |
+| Agent | Frontmatter `name` (the file's name), `description` (when to use it, with the phrases a person says), `model: fable`, `tools`; then what it does, the commands it runs, its rules |
+| Skill | `SKILL.md` with frontmatter `name` (the folder's name) and `description` (what it does, then `Use when …`); files beside it for what is too long or is meant to be copied |
+| Command | Frontmatter `description` and `argument-hint`, no `name` (the file names it); the body reads what was typed from `$ARGUMENTS` |
+| Prompt | No frontmatter. One sentence that says what it is for, then a fenced block holding the whole launch command: `claude --permission-mode bypassPermissions """` … `"""`, with `<placeholders>` to fill in and a `#` line that says where it runs |
+
+Names start with the plugin's name (`<p>-…`): an item that is already in the folder under the same
+name is kept, so a name another plugin could also choose would never be placed. A command and a
+prompt never share a name: both end in `~/.claude/commands`.
+
+## What an item may say
+
+Nothing generic and nothing invented. An item is about what this plugin does in the workspace, and
+every command, flag, path and step phrase in it exists:
+
+- commands and flags: the plugin's own (`scripts/args/*.sh`) and the workspace's (`cmd-tools-testing.sh`
+  and its flags, `cmd-tools-remove.sh`, `cmd-tools-clone.sh --to`, `cmd-tools-ai-items.sh --install`);
+- step phrases: the plugin's step pack and webship-js, as installed in a real project;
+- the body is for any AI CLI, Claude Code being the default shape: plain Markdown ("run this
+  command", "read this file", "the AI assistant") that names no tool or feature of one CLI; the
+  frontmatter and a prompt's `claude …` launch line stay, with one line saying that the text between
+  the quotes can be given to another AI CLI as it is; a command keeps `$ARGUMENTS` and says in
+  words what the arguments are;
+- the workspace is container-based (DDEV by default); no platform name in a step phrase; no
+  account created by a scenario; no password, no personal path, addresses at `example.com`.
+
+Run every command an item tells its reader to run, and every scenario it shows, on a real site
+before it is pushed. Two of the three example features of the reference failed on their first real
+run, each on a phrase that exists and matched in a dry run.
+
+## The tests to copy
+
+`tests/items.test.ts` checks, with no site and no network:
+
+1. the manifest: one list per kind, each item under `ai/<kind>/`, in the package, named `<p>-…`,
+   `ai` in `files`, the folder of each kind in `needs`, no command and prompt of the same name;
+2. the shape of each kind (the table above; the two expressions the dashboard reads a prompt with);
+3. every `cmd-*.sh` an item names is the plugin's or the workspace's, with flags that exist;
+4. every step in a `gherkin` block or a `.feature` file matches a definition in
+   `tests/fixtures/step-definitions.txt`, names no platform and carries no password;
+5. the words: container-based, no personal value, the README lists every item.
+
+Refresh the fixture from a project whose testing stack is set up, whenever the pack's release
+line changes (`<pack>` is the plugin's step pack):
+
+```bash
+cd ~/workspace/<folder>/<site>
+{ echo "# <pack> <version> and webship-js <version>" ;
+  grep -hE "^(Given|When|Then)\(/" node_modules/<pack>/tests/step-definitions/*.steps.js node_modules/webship-js/tests/step-definitions/*.steps.js \
+    | sed -nE 's/^(Given|When|Then)\(\/(.*)\/, (\{[^}]*\}, )?(async )?function.*/\2/p' | sort -u ; } > step-definitions.txt
+```
+
+`tests/needs.test.ts` holds the exact `needs` list, and `tests/plugin.test.ts` that every file the
+manifest names ships.
+
+## Prove it on a fresh workspace
+
+Never in a workspace somebody works in. `webship-workspace init <folder>` makes an empty one.
+
+```bash
+npm pack                                                                 # in the plugin: the tarball of the branch
+cd <the fresh workspace>
+bash core/scripts/plugins.sh --require <path>/webship.co-workspace-<p>-<version>.tgz   # says what it needs
+bash core/scripts/plugins.sh --activate <p>                              # stops: lists what is not here, changes nothing
+bash core/scripts/plugins.sh --activate <p> --with-needs                 # adds the folders, then activates
+bash core/scripts/plugins.sh --install <p>                               # "placed …" once per file
+ls dev ai-agents ai-skills ai-commands ai-prompts                        # each item in its folder
+bash core/scripts/plugins.sh --list                                      # needs: … met by …
+bash core/scripts/plugins.sh --uninstall <p>                             # "removed …" once per file
+grep -c "<p>" core/config/plugins.installed.yml                          # 0: the record is gone
+```
+
+Then, installed again: build one site with the builder, run each command the items name, copy the
+skill's examples into the suite and run them, look at the four AI folders on the dashboard, and
+remove the site with `cmd-tools-remove.sh`.
+
+## What was found on the way
+
+- A phrase that matches in a dry run can still fail: a step may need another one before it
+  (`I should see the page title` needs `Given I am on a page`), or assert something the site does
+  not do as built. Only a real run tells.
+- Content a failed scenario created stays on the site. Name it so it is found, and remove it
+  through the CLI tool before the next run (an entry in the trash is not in a list of every status).
+- A folder that is not active gets nothing: the install says `skipped <n> <kind>` for it, and
+  places the items when the folder is added. With the folder in `needs`, `--activate` and
+  `--install` stop before that and offer to add it.
+- An item a person edited in its folder is kept by `--install` and by `--uninstall`: the record
+  holds the hash of what was placed.

package/features/typo3.feature

@@ -1,6 +1,7 @@
 Feature: The TYPO3 plugin on the dashboard
-  Once the plugin is activated and installed, the sites folders offer the TYPO3 builder, the
-  AI Agents folder lists the TYPO3 agents, and the Plugins page lists the plugin with its steps.
+  Once the plugin is activated and installed, the sites folders offer the TYPO3 builder, each
+  AI folder lists the items of its kind the plugin ships, and the Plugins page lists the plugin
+  with its steps.
 
   Scenario: The plugin is listed on the Plugins page
     Given I am on "/settings/plugins"
@@ -15,3 +16,15 @@ Feature: The TYPO3 plugin on the dashboard
     Given I am on "/ai-agents"
      Then I should see "typo3-site-builder"
       And I should see "typo3-tester"
+
+  Scenario: The AI Skills folder lists the skill the plugin ships
+    Given I am on "/ai-skills"
+     Then I should see "typo3-scenarios"
+
+  Scenario: The AI Commands folder lists the command the plugin ships
+    Given I am on "/ai-commands"
+     Then I should see "typo3-test"
+
+  Scenario: The AI Prompts folder lists the prompt the plugin ships
+    Given I am on "/ai-prompts"
+     Then I should see "typo3-build-and-test"

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@webship.co/workspace-typo3",
-  "version": "1.0.7",
-  "description": "TYPO3 for Webship Workspace: the builder (`cmd-typo3-project.sh`) and the typo3 console tool in every sites folder, the default accounts, the TYPO3 step pack wired into the testing setup, and two AI agents in the AI Agents folder.",
+  "version": "1.0.9",
+  "description": "TYPO3 for Webship Workspace: the builder (`cmd-typo3-project.sh`) and the typo3 console tool in every sites folder, the default accounts, the TYPO3 step pack wired into the testing setup, and its AI items in their folders: two agents, a skill, a command and a prompt.",
   "main": "dist/src/index.js",
   "types": "dist/src/index.d.ts",
   "license": "ISC",
@@ -11,8 +11,9 @@
   },
   "files": [
     "dist/src",
-    "agents",
+    "ai",
     "commands",
+    "docs",
     "features",
     "scripts",
     "testing",
@@ -27,6 +28,18 @@
   "workspacePlugin": {
     "name": "typo3",
     "label": "TYPO3",
+    "needs": [
+      [
+        "dev",
+        "test",
+        "sandboxes",
+        "demos"
+      ],
+      "ai-agents",
+      "ai-skills",
+      "ai-commands",
+      "ai-prompts"
+    ],
     "commands": {
       "types": [
         "sites"
@@ -56,8 +69,17 @@
     },
     "ai": {
       "agents": [
-        "agents/typo3-site-builder.md",
-        "agents/typo3-tester.md"
+        "ai/agents/typo3-site-builder.md",
+        "ai/agents/typo3-tester.md"
+      ],
+      "skills": [
+        "ai/skills/typo3-scenarios"
+      ],
+      "commands": [
+        "ai/commands/typo3-test.md"
+      ],
+      "prompts": [
+        "ai/prompts/typo3-build-and-test.md"
       ]
     },
     "features": [

package/scripts/functions/fun-typo3.sh

@@ -16,7 +16,7 @@
 
 # The step pack a TYPO3 project is tested with, and the release line it is required at.
 readonly TYPO3_STEPS_PACKAGE='@webship-js/typo3-steps';
-readonly TYPO3_STEPS_VERSION='^2.1.0';
+readonly TYPO3_STEPS_VERSION='^2.2.0';
 
 # The backend group the editor account joins: the one the Introduction package brings.
 readonly TYPO3_EDITOR_GROUP='Advanced editors';