@webship.co/workspace-joomla 1.0.7 → 1.0.9

package/README.md

@@ -3,7 +3,8 @@
 Joomla for the [Webship Workspace](https://github.com/webship/workspace) dashboard: a builder
 that makes a real Joomla site in a container, a Joomla CLI tool for the sites it built, the default
 accounts, the [Joomla step pack](https://github.com/webship/joomla-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 Joomla 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-joomla   # npm install into the dashboard
 bash core/scripts/plugins.sh --activate joomla                            # plugins.joomla in settings.yml
-bash core/scripts/plugins.sh --install joomla                             # commands, functions, args, agents
+bash core/scripts/plugins.sh --install joomla                             # commands, functions, args, AI items
 bash core/scripts/plugins.sh --configure joomla                           # 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-joomla-project.sh`, `cmd-tools-joomla-cli.sh` | every active sites folder: `dev/`, `test/`, `sandboxes/`, `demos/` |
+| The agents `joomla-site-builder`, `joomla-tester` | `ai-agents/` |
+| The skill `joomla-scenarios` | `ai-skills/` |
+| The command `/joomla-test` | `ai-commands/` |
+| The prompt `joomla-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 joomla --with-needs   # dev and the four AI folders are required, activated and installed first
+bash core/scripts/plugins.sh --install joomla
+```
+
+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 joomla` 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-joomla.sh` | The bash functions behind both, sourced by bootstrap once installed; the names the core's tools look for (`set_joomla_users`, `add_joomla_users`, `cancel_joomla_users`, `testing_configure_joomla`) |
 | `scripts/args/arg-joomla.sh`, `arg-joomla-cli.sh` | Their argparse; the Build form draws the builder's flags from the first |
 | `testing/site.feature` | The first feature a Joomla project gets when testing is set up |
-| `agents/joomla-site-builder.md` | The agent that builds and maintains Joomla sites with these commands |
-| `agents/joomla-tester.md` | The agent that writes and runs scenarios with the Joomla step pack |
+| `ai/agents/joomla-site-builder.md` | The agent that builds and maintains Joomla sites with these commands |
+| `ai/agents/joomla-tester.md` | The agent that writes and runs scenarios with the Joomla step pack |
+| `ai/skills/joomla-scenarios/` | The skill: the step pack's phrases by area, the traps found on a real site, three example features |
+| `ai/commands/joomla-test.md` | The slash command `/joomla-test <site>`: set up, match every step, run, report |
+| `ai/prompts/joomla-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 Joomla here |
 | `features/joomla.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 |
-| --- | --- |
-| `joomla-site-builder` | Build, update, maintain or remove a Joomla site with the commands above, in containers only |
-| `joomla-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 | `joomla-site-builder` | Build, update, maintain or remove a Joomla site with the commands above, in containers only |
+| Agent | `joomla-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 | `joomla-scenarios` | Write a scenario from phrases that exist: the pack's steps by area (the administrator, lists and content, users and groups, the public site, search), the handles of the users registry, the traps found on a real site, and three features that pass on a fresh site |
+| Command | `/joomla-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 | `joomla-build-and-test` | Start a session that builds a site with the sample data, 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 joomla-tester --install
+cd ~/workspace/ai-agents   && bash cmd-tools-ai-items.sh joomla-tester --install
+cd ~/workspace/ai-skills   && bash cmd-tools-ai-items.sh joomla-scenarios --install
+cd ~/workspace/ai-commands && bash cmd-tools-ai-items.sh joomla-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}/joomla-site-builder.md

@@ -103,3 +103,11 @@ stack, with the Joomla step pack).
 | The site search finds nothing | The Smart Search index is empty: `--run "finder:index"`. |
 | **Add the test users** in the row's Users menu adds no Joomla account | The menu reads the DDEV project type, and a Joomla project is a `php` project. Use `bash cmd-tools-joomla-cli.sh <name> --add-users` or `bash cmd-tools-add-users.sh <name> joomla`. |
 | `is not a Joomla project` from the CLI tool | The project's docroot has no `cli/joomla.php`: it was not built by this builder. |
+
+## What comes with you
+
+The Joomla plugin places these beside you, each in the workspace folder of its kind: the agent
+`joomla-tester` (`ai-agents/`), the skill `joomla-scenarios` (`ai-skills/`), the command
+`/joomla-test <site>` (`ai-commands/`) and the prompt `joomla-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}/joomla-tester.md

@@ -20,8 +20,8 @@ tools:
 
 # joomla-tester
 
-You test Joomla sites in a Webship Workspace (`~/workspace`) with
-[webship-js](https://github.com/webship/webship-js) (Playwright and Cucumber) and its Joomla step
+You test Joomla 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 Joomla step
 pack, [`@webship-js/joomla-steps`](https://github.com/webship/joomla-steps). The suite lives in
 the project (`cucumber.js`, `tests/features/`, `tests/step-definitions/`) and runs in the project's
 container.
@@ -69,10 +69,12 @@ A scenario logs in by a **handle** of the users registry (`worldParameters.users
 The site and the administrator have a login each, and a step for each:
 
 ```gherkin
-Given I am a logged in user with the "manager" user        # the administrator
-Given I am logged in to the site with the "member" user    # the site
+Given I am a logged in user with the "manager" user
+Given I am logged in to the site with the "member" user
 ```
 
+The first is the administrator's login, the second the site's.
+
 | Handle | Account | User group | Logs in to |
 | --- | --- | --- | --- |
 | `admin` | `administrator` | Super Users | the administrator and the site |
@@ -97,7 +99,9 @@ account's username, not the handle.
 - **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 on the login
   page`, `I should see the administrator dashboard`, `I go to the administrator "Users" page`. Never
-  a phrase with the platform's name in it. The same holds for a custom step you write.
+  a phrase with the platform's name in it: the name is a value where a step needs it (`the page
+  generator should contain "Joomla"`, `the CMS version should start with "<version>"`). 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
   administrator "Users" page`, not `/administrator/index.php?option=com_users`.
 - **A custom step is the last resort.** Look in the pack and in webship-js first. If one is really
@@ -124,3 +128,13 @@ Feature: A manager looks after the articles
 
 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 Joomla plugin places these beside you, each in the workspace folder of its kind:
+
+| Item | Where | What it is for |
+| --- | --- | --- |
+| `joomla-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 |
+| `/joomla-test <site>` (command) | `ai-commands/` | The run itself: set up when missing, match every step, run, report |
+| `joomla-build-and-test` (prompt) | `ai-prompts/` | A new session that builds a site and runs its first feature |

package/ai/commands/joomla-test.md

@@ -0,0 +1,91 @@
+---
+description: Test a Joomla site of the Webship Workspace with webship-js and the Joomla 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]'
+---
+
+# /joomla-test
+
+Test the Joomla 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
+`ls ~/workspace/*/*/public/cli/joomla.php`.
+
+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`,
+`php`, `composer` or `npm` on the host for a site.
+
+## 1. Find the site
+
+```bash
+ls -d ~/workspace/*/<site>/.ddev/config.yaml
+ls ~/workspace/<folder>/<site>/public/cli/joomla.php
+```
+
+`<folder>` is the sites folder the site is in (`dev`, `test`, `sandboxes`, `demos`). If the
+docroot has no `cli/joomla.php`, stop: this command is for a site built with
+`cmd-joomla-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/joomla-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/joomla-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 menu item or an article of the sample data on a site
+   built without it, an account's username where the page shows its name), or the environment
+   (the site was stopped, an account is missing:
+   `bash cmd-tools-joomla-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 `joomla-scenarios` skill or hand over to the `joomla-tester`
+agent; for changing the site, to `joomla-site-builder`.

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

@@ -0,0 +1,27 @@
+Build a Joomla 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 Joomla 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 php, composer, npm or mysql outside the site's container
+
+1. bash cmd-joomla-project.sh <name> --install --add-users --sample-data
+   (add --version <x> for a release other than the latest; leave --sample-data out for an empty site)
+   if it stops because the workspace account's password is shorter than 12 characters, tell me
+   and stop: the password is mine to change (account: pass in core/config/settings.yml)
+2. bash cmd-tools-joomla-cli.sh <name>
+   tell me the version, the address and the accounts it lists, with their groups
+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/joomla-scenarios/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: joomla-scenarios
+description: Write and run webship-js scenarios for a Joomla site of the Webship Workspace with the Joomla step pack (`@webship-js/joomla-steps`) — the phrases of the pack by area (the administrator and its pages, lists and content, users and groups, the public site, the site login, 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 Joomla site", "test the manager account", "which step is there for an article", "add a feature for the search", or when a `.feature` file of a Joomla project is being written or fixed.
+argument-hint: '<site> [what to cover]'
+---
+
+# joomla-scenarios
+
+Scenarios for a Joomla site of a Webship Workspace (`~/workspace`, container-based, DDEV by
+default), written from the steps of [`@webship-js/joomla-steps`](https://github.com/webship/joomla-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 Joomla plugin (`@webship.co/workspace-joomla`),
+like the builder (`cmd-joomla-project.sh`), the CLI tool (`cmd-tools-joomla-cli.sh`) and the
+agents `joomla-site-builder` and `joomla-tester`.
+
+## Where everything is
+
+| What | Where |
+| --- | --- |
+| The site | `~/workspace/<folder>/<site>`, at `https://<site>.ddev.site`, the administrator at `/administrator` (`<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/joomla-steps/tests/step-definitions/*.steps.js` |
+| 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/joomla-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 page 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 by a handle of the users registry. The administrator and the site have a
+login each, and a step for each. The default accounts are on the site already
+(`bash cmd-tools-joomla-cli.sh <site> --add-users` adds them again if they were removed):
+
+| Handle | Account | User group | Logs in to |
+| --- | --- | --- | --- |
+| `admin` | `administrator` | Super Users | the administrator and the site |
+| `manager` | `manager` | Manager | the administrator and the site |
+| `editor` | `editor` | Editor | the site |
+| `member` | `member` | Registered | the site |
+
+```gherkin
+Given I am a logged in user with the "manager" user
+Then I should see the administrator dashboard
+Given I am logged in to the site with the "member" user
+Then I should be logged in to the site as "member"
+```
+
+## The phrases, by area
+
+Each line is a phrase the pack defines, and each one passed on a site built with
+`bash cmd-joomla-project.sh <site> --install --add-users --sample-data` (the names in quotes are
+that site's). Most `should` steps also take the negative: `should not see`, `should not be`,
+`should not exist`.
+
+### The administrator: session, pages, menu
+
+```gherkin
+Given I am on the administrator login page
+Given I am a logged in user with the "manager" user
+When I log out of the administrator panel
+Then I should be on the administrator login page
+Then I should see the administrator dashboard
+Then I should be logged in to the administrator panel as "Manager"
+Then I should see the administrator menu
+Then I should see the administrator menu item "Content"
+Then I should not see the administrator menu item "System"
+When I go to the administrator "Articles" page
+Then I should be on the administrator "Articles" page
+Then I should see the administrator page title "Articles"
+Then I should see the "New" toolbar button
+```
+
+### Lists and content
+
+```gherkin
+When I create an article titled "An article written by a scenario" with the text "Written by the suite."
+Then the article "An article written by a scenario" should exist
+Then the article "An article written by a scenario" should be published
+When I unpublish the article "An article written by a scenario"
+When I trash the article "An article written by a scenario"
+Then the article "An article written by a scenario" should be trashed
+When I delete the article "An article written by a scenario" permanently
+When I create a category titled "A category written by a scenario"
+When I trash the category "A category written by a scenario"
+When I delete the category "A category written by a scenario" permanently
+When I create a menu titled "A menu written by a scenario"
+Then the menu "A menu written by a scenario" should exist
+When I delete the menu "A menu written by a scenario"
+When I search the list for "no such article anywhere"
+Then I should see an empty list
+Then I should see a success message
+```
+
+### Users, groups and the system
+
+```gherkin
+Then the user "manager" should exist
+Then the user "manager" should be in the "Manager" group
+Then the access level "Special" should include the "Manager" group
+Then the group "Manager" should have 1 enabled user
+When I clear all caches
+Then there should not be checked out items
+```
+
+### The public site, its login and the search
+
+```gherkin
+Given I am on the login page
+Given I am on the password reset page
+Given I am on the username reminder page
+Given I am on the profile page
+Then I should see the login form
+Then I should see the password reset form
+Then I should see the username reminder form
+Given I am logged in to the site with the "member" user
+When I log out of the site
+Then I should be logged in to the site as "member"
+Then I should not be logged in to the site
+Then I should see the "Blog" menu item
+When I open the "Blog" menu item
+Then the breadcrumb should show "Home > Blog"
+Then I should see no system messages
+When I search the site for a word from the first article
+Then I should see that word in the search results
+Then I should see at least 1 search result
+When I search the site for "nosuchwordanywhere"
+Then I should see no search results
+```
+
+`I am an anonymous user`, `I am on the homepage`, `the page should have a title`,
+`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
+
+- **Two logins, two steps.** `I am a logged in user with the "<handle>" user` is the
+  administrator's login, `I am logged in to the site with the "<handle>" user` the site's.
+  `editor` and `member` have no administrator: use the site's step for them.
+- **The administrator shows the account's name, not its username.**
+  `I should be logged in to the administrator panel as "manager"` fails; the header says
+  `Manager`. The site's step (`logged in to the site as "member"`) takes the handle, and the user
+  steps (`the user "manager" should be in the "Manager" group`) take the username.
+- **A page a group may not open answers 403**: a manager on the administrator `"Users"` page.
+  Assert the status code; the administrator menu of a manager does not list `System` either.
+- **The breadcrumb is the whole trail**: `Home > Blog`, not `Blog`.
+- **The search step needs a page that lists articles first.**
+  `I search the site for a word from the first article` reads the word from the page on screen:
+  open the homepage before it.
+- **What the sample data brings is not on every site.** The `Blog` menu item, the articles and
+  the search index are there only when the site was built with `--sample-data`. A site built
+  without it has an empty front page: a scenario about them fails there.
+- **Trashing is not deleting.** A trashed article or category is still on the site:
+  `I delete the article "<title>" permanently` after the trash step, or the next run finds it.
+- **`I check in all items` fails when nothing is checked out.** Assert
+  `there should not be checked out items` instead, and check in only after a scenario left a
+  form open.
+- **The version and the generator are values of a step**, not a part of its phrase:
+  `the CMS version should start with "<version>"` reads the System Information page, which is
+  for Super Users only, and `the page generator should contain "<name>"` reads the generator
+  meta tag of the page. Without an account that may open that page, read the version with
+  `bash cmd-tools-joomla-cli.sh <site>`.
+
+## Rules
+
+- **No account is created in a suite.** No `user:add` in a hook, no registration scenario that
+  leaves an account behind. A group the registry does not have is asked for, not made.
+- **Never the workspace account.** The site's own Super User 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 am on the administrator login page`, never a phrase
+  that names the platform. The same holds for a custom step.
+- **No selector and no address when a step says it**: `the administrator "Users" page`, not the
+  address of the page.
+- **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-joomla-project.sh <site> --install --add-users --sample-data`. Copy one into the suite
+and run it:
+
+```bash
+cp ~/workspace/ai-skills/joomla-scenarios/examples/groups-and-pages.feature ~/workspace/<folder>/<site>/tests/features/
+cd ~/workspace/<folder>
+bash cmd-tools-testing.sh <site> --run --path tests/features/groups-and-pages.feature
+```
+
+| Feature | What it shows |
+| --- | --- |
+| `examples/groups-and-pages.feature` | Each default account logging in where its group may, the menu and the pages of a manager, the groups and access levels |
+| `examples/article-lifecycle.feature` | A manager writing, unpublishing, trashing and deleting an article; a category and a menu added and deleted |
+| `examples/site-and-search.feature` | The menu, the breadcrumb, the account pages and the search of the public site (needs `--sample-data`) |

package/ai/skills/joomla-scenarios/examples/article-lifecycle.feature

@@ -0,0 +1,36 @@
+Feature: A manager writes an article and removes it again
+  As a manager
+  I want to write, unpublish, trash and delete an article
+  So that the suite proves the content screens work and leaves the site as it found it
+
+  # Trashing is not deleting: the scenario deletes permanently, or the next run finds the item.
+
+  Scenario: The manager writes an article, takes it down and deletes it
+    Given I am a logged in user with the "manager" user
+    When I create an article titled "An article written by a scenario" with the text "This article is written and removed by the suite."
+    Then I should see a success message
+    And the article "An article written by a scenario" should be published
+    When I unpublish the article "An article written by a scenario"
+    Then the article "An article written by a scenario" should be unpublished
+    When I trash the article "An article written by a scenario"
+    Then the article "An article written by a scenario" should be trashed
+    When I delete the article "An article written by a scenario" permanently
+    Then the article "An article written by a scenario" should not exist
+
+  Scenario: An administrator adds a category and a menu and deletes them
+    Given I am a logged in user with the "admin" user
+    When I create a category titled "A category written by a scenario"
+    Then the category "A category written by a scenario" should exist
+    When I trash the category "A category written by a scenario"
+    And I delete the category "A category written by a scenario" permanently
+    Then the category "A category written by a scenario" should not exist
+    When I create a menu titled "A menu written by a scenario"
+    Then the menu "A menu written by a scenario" should exist
+    When I delete the menu "A menu written by a scenario"
+    Then the menu "A menu written by a scenario" should not exist
+
+  Scenario: A search of the list that finds nothing shows an empty list
+    Given I am a logged in user with the "manager" user
+    When I go to the administrator "Articles" page
+    And I search the list for "no such article anywhere"
+    Then I should see an empty list

package/ai/skills/joomla-scenarios/examples/groups-and-pages.feature

@@ -0,0 +1,41 @@
+Feature: Each account reaches what its user group may use
+  As the owner of the site
+  I want every default account to log in where its group may and to be refused the rest
+  So that a change of permissions is caught by the suite
+
+  # The accounts are the default ones; a scenario logs in by a handle of the users registry.
+  # The administrator and the site have a login each, and a step for each.
+
+  Scenario: A manager gets the administrator, with the menu of a manager
+    Given I am a logged in user with the "manager" user
+    Then I should see the administrator dashboard
+    And I should be logged in to the administrator panel as "Manager"
+    And I should see the administrator menu item "Content"
+    And I should not see the administrator menu item "System"
+
+  Scenario: A manager opens the articles and is refused the users
+    Given I am a logged in user with the "manager" user
+    When I go to the administrator "Articles" page
+    Then the response status code should be 200
+    And I should see the "New" toolbar button
+    When I go to the administrator "Users" page
+    Then the response status code should be 403
+
+  Scenario: An editor logs in to the site and has no administrator
+    Given I am logged in to the site with the "editor" user
+    Then I should be logged in to the site as "editor"
+    Given I am on the administrator login page
+    Then I should not see the administrator dashboard
+
+  Scenario: The groups and the access levels are the ones the accounts rely on
+    Given I am a logged in user with the "admin" user
+    Then the user "manager" should be in the "Manager" group
+    And the user "member" should not be in the "Manager" group
+    And the access level "Special" should include the "Manager" group
+    And the group "Manager" should have 1 enabled user
+
+  Scenario: A visitor is asked to log in before the profile
+    Given I am not logged in
+    And I am on the profile page
+    Then I should see the login form
+    And I should not be logged in to the site

package/ai/skills/joomla-scenarios/examples/site-and-search.feature

@@ -0,0 +1,33 @@
+Feature: A visitor finds their way around the site
+  As a visitor
+  I want the menu, the breadcrumb, the account pages and the search to work
+  So that a broken template or search index is caught by the suite
+
+  # For a site built with --sample-data: the "Blog" menu item, the articles and the search index
+  # come from the blog sample data. On a site built without it these scenarios fail.
+
+  Scenario: The menu leads to the blog, and the breadcrumb says where
+    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 "Blog" menu item
+    And I should see no system messages
+    When I open the "Blog" menu item
+    Then the breadcrumb should show "Home > Blog"
+
+  Scenario: The account pages are served with their forms
+    Given I am on the login page
+    Then I should see the login form
+    Given I am on the password reset page
+    Then I should see the password reset form
+    Given I am on the username reminder page
+    Then I should see the username reminder form
+
+  Scenario: The search finds a word of an article, and nothing for a word nobody wrote
+    Given I am an anonymous user
+    And I am on the homepage
+    When I search the site for a word from the first article
+    Then I should see that word in the search results
+    And I should see at least 1 search result
+    When I search the site for "nosuchwordanywhere"
+    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
  * Joomla CLI tool in the sites folders, their functions and argparse under core/scripts/plugins/joomla/,
- * 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 = "joomla";
 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 Joomla 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
  * Joomla CLI tool in the sites folders, their functions and argparse under core/scripts/plugins/joomla/,
- * 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 its functions and its user list are named after. */
@@ -21,6 +23,12 @@ exports.PLATFORM = 'joomla';
 exports.COMMANDS = ['cmd-joomla-project.sh', 'cmd-tools-joomla-cli.sh'];
 /** The agents the installer places in the AI Agents folder. */
 exports.AGENTS = ['joomla-site-builder', 'joomla-tester'];
+/** The skill the installer places in the AI Skills folder (a folder each, with its SKILL.md). */
+exports.SKILLS = ['joomla-scenarios'];
+/** The slash command the installer places in the AI Commands folder. */
+exports.AI_COMMANDS = ['joomla-test'];
+/** The prompt the installer places in the AI Prompts folder: each a whole launch command for a new session. */
+exports.PROMPTS = ['joomla-build-and-test'];
 /** What the assistant is told about Joomla in this workspace. */
 function assistantContext() {
     return [
@@ -32,6 +40,8 @@ function assistantContext() {
         '`bash cmd-tools-add-users.sh <name> joomla` adds the same accounts.',
         '`bash cmd-tools-testing.sh <name>` sets up webship-js with the Joomla step pack; `--run` runs the suite.',
         `For Joomla 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,gFAAgF;AACnE,QAAA,QAAQ,GAAG,QAAQ,CAAC;AAEjC,+DAA+D;AAClD,QAAA,QAAQ,GAAG,CAAC,uBAAuB,EAAE,yBAAyB,CAAC,CAAC;AAE7E,+DAA+D;AAClD,QAAA,MAAM,GAAG,CAAC,qBAAqB,EAAE,eAAe,CAAC,CAAC;AAE/D,iEAAiE;AACjE,SAAgB,gBAAgB;IAC9B,OAAO;QACL,8EAA8E;QAC9E,8GAA8G;QAC9G,6GAA6G;QAC7G,8HAA8H;QAC9H,yHAAyH;QACzH,qEAAqE;QACrE,0GAA0G;QAC1G,4CAA4C,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG;QAC1F,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,gFAAgF;AACnE,QAAA,QAAQ,GAAG,QAAQ,CAAC;AAEjC,+DAA+D;AAClD,QAAA,QAAQ,GAAG,CAAC,uBAAuB,EAAE,yBAAyB,CAAC,CAAC;AAE7E,+DAA+D;AAClD,QAAA,MAAM,GAAG,CAAC,qBAAqB,EAAE,eAAe,CAAC,CAAC;AAE/D,iGAAiG;AACpF,QAAA,MAAM,GAAG,CAAC,kBAAkB,CAAC,CAAC;AAE3C,wEAAwE;AAC3D,QAAA,WAAW,GAAG,CAAC,aAAa,CAAC,CAAC;AAE3C,+GAA+G;AAClG,QAAA,OAAO,GAAG,CAAC,uBAAuB,CAAC,CAAC;AAEjD,iEAAiE;AACjE,SAAgB,gBAAgB;IAC9B,OAAO;QACL,8EAA8E;QAC9E,8GAA8G;QAC9G,6GAA6G;QAC7G,8HAA8H;QAC9H,yHAAyH;QACzH,qEAAqE;QACrE,0GAA0G;QAC1G,4CAA4C,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG;QAC1F,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/joomla.feature

@@ -1,6 +1,7 @@
 Feature: The Joomla plugin on the dashboard
-  Once the plugin is activated and installed, the sites folders offer the Joomla builder, the
-  AI Agents folder lists the Joomla agents, and the Plugins page lists the plugin with its steps.
+  Once the plugin is activated and installed, the sites folders offer the Joomla 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 Joomla plugin on the dashboard
     Given I am on "/ai-agents"
      Then I should see "joomla-site-builder"
       And I should see "joomla-tester"
+
+  Scenario: The AI Skills folder lists the skill the plugin ships
+    Given I am on "/ai-skills"
+     Then I should see "joomla-scenarios"
+
+  Scenario: The AI Commands folder lists the command the plugin ships
+    Given I am on "/ai-commands"
+     Then I should see "joomla-test"
+
+  Scenario: The AI Prompts folder lists the prompt the plugin ships
+    Given I am on "/ai-prompts"
+     Then I should see "joomla-build-and-test"

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@webship.co/workspace-joomla",
-  "version": "1.0.7",
-  "description": "Joomla for Webship Workspace: the builder (`cmd-joomla-project.sh`) and the Joomla CLI tool in every sites folder, the default accounts, the Joomla step pack wired into the testing setup, and two AI agents in the AI Agents folder.",
+  "version": "1.0.9",
+  "description": "Joomla for Webship Workspace: the builder (`cmd-joomla-project.sh`) and the Joomla CLI tool in every sites folder, the default accounts, the Joomla 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": "joomla",
     "label": "Joomla",
+    "needs": [
+      [
+        "dev",
+        "test",
+        "sandboxes",
+        "demos"
+      ],
+      "ai-agents",
+      "ai-skills",
+      "ai-commands",
+      "ai-prompts"
+    ],
     "commands": {
       "types": [
         "sites"
@@ -56,8 +69,17 @@
     },
     "ai": {
       "agents": [
-        "agents/joomla-site-builder.md",
-        "agents/joomla-tester.md"
+        "ai/agents/joomla-site-builder.md",
+        "ai/agents/joomla-tester.md"
+      ],
+      "skills": [
+        "ai/skills/joomla-scenarios"
+      ],
+      "commands": [
+        "ai/commands/joomla-test.md"
+      ],
+      "prompts": [
+        "ai/prompts/joomla-build-and-test.md"
       ]
     },
     "features": [

package/scripts/functions/fun-joomla.sh

@@ -19,7 +19,7 @@
 
 # The step pack a Joomla project is tested with, and the release line it is required at.
 readonly JOOMLA_STEPS_PACKAGE='@webship-js/joomla-steps';
-readonly JOOMLA_STEPS_VERSION='^2.1.0';
+readonly JOOMLA_STEPS_VERSION='^2.2.0';
 
 # The release a build falls back on when the latest one cannot be read: the one this plugin was proven on.
 readonly JOOMLA_PROVEN_VERSION='6.2.0';