@webship.co/workspace-odoo 1.0.7 → 1.0.9

package/README.md

@@ -3,7 +3,8 @@
 Odoo Community for the [Webship Workspace](https://github.com/webship/workspace) dashboard: a
 builder that makes a real Odoo site in containers, an odoo-bin tool for the sites it built, the
 default accounts, the [Odoo step pack](https://github.com/webship/odoo-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): an Odoo project is a row like any other, so
 the row menus the core draws (start, stop, launch, backup, clone, remove, tests) work on it
@@ -23,20 +24,47 @@ what Odoo needs, see [What is different from a PHP platform](#what-is-different-
 cd ~/workspace
 bash core/scripts/plugins.sh --require github:webship/workspace-odoo   # npm install into the dashboard
 bash core/scripts/plugins.sh --activate odoo                            # plugins.odoo in settings.yml
-bash core/scripts/plugins.sh --install odoo                             # commands, functions, args, agents
+bash core/scripts/plugins.sh --install odoo                             # commands, functions, args, AI items
 bash core/scripts/plugins.sh --configure odoo                           # 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-odoo-project.sh`, `cmd-tools-odoo-cli.sh` | every active sites folder: `dev/`, `test/`, `sandboxes/`, `demos/` |
+| The agents `odoo-site-builder`, `odoo-tester` | `ai-agents/` |
+| The skill `odoo-scenarios` | `ai-skills/` |
+| The command `/odoo-test` | `ai-commands/` |
+| The prompt `odoo-build-and-test` | `ai-prompts/` |
+
+There they are listed like any other item of the folder, and installed into Claude Code from there.
 
 The agents, the builder's flags in the Build form and the step pack in the testing setup need a
 Webship Workspace after 1.0.6.
 
+## 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 odoo --with-needs   # dev and the four AI folders are required, activated and installed first
+bash core/scripts/plugins.sh --install odoo
+```
+
+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 odoo` again. A kind whose folder is not there is skipped, and the install says so.
+
 ## This builder and `cmd-odoo20-project.sh`
 
 The sites folders of the workspace (the `dev`, `test` and `sandboxes` folder plugins) carry an
@@ -71,10 +99,14 @@ and its testing setup work on the projects `cmd-odoo-project.sh` built (they car
 | `scripts/args/arg-odoo.sh`, `arg-odoo-cli.sh` | Their argparse; the Build form draws the builder's flags from the first |
 | `scripts/odoo-accounts.py` | The administrator, the default accounts and what keeps the site local, run in the Odoo shell of the project |
 | `testing/site.feature` | The first feature an Odoo project gets when testing is set up |
-| `agents/odoo-site-builder.md` | The agent that builds and maintains Odoo sites with these commands |
-| `agents/odoo-tester.md` | The agent that writes and runs scenarios with the Odoo step pack |
+| `ai/agents/odoo-site-builder.md` | The agent that builds and maintains Odoo sites with these commands |
+| `ai/agents/odoo-tester.md` | The agent that writes and runs scenarios with the Odoo step pack |
+| `ai/skills/odoo-scenarios/` | The skill: the step pack's phrases by area, the traps found on a real site, three example features |
+| `ai/commands/odoo-test.md` | The slash command `/odoo-test <site>`: set up, match every step, run, report |
+| `ai/prompts/odoo-build-and-test.md` | A prompt: the whole launch command for a new session |
 | `src/index.ts` | `register(api)`: what the assistant is told about Odoo here |
 | `features/odoo.feature` | Scenarios for the dashboard's own browser suite |
+| `docs/plugin-items-pattern.md` | How a plugin carries its own commands and AI items, and how to prove it |
 
 The `workspacePlugin` block in `package.json` is the manifest the installer reads.
 
@@ -163,25 +195,41 @@ 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 |
-| --- | --- |
-| `odoo-site-builder` | Build, update, restart, maintain or remove an Odoo Community site with the commands above, in containers only |
-| `odoo-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 | `odoo-site-builder` | Build, update, restart, maintain or remove an Odoo Community site with the commands above, in containers only |
+| Agent | `odoo-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 | `odoo-scenarios` | Write a scenario from phrases that exist: the pack's steps by area (sessions, apps and menus, views and search, records and the chatter, the website), the handles of the users registry, the traps found on a real site, and three features that pass on a fresh site with the default apps and demo data |
+| Command | `/odoo-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 | `odoo-build-and-test` | Start a session that builds a Community site, 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 odoo-tester --install
+cd ~/workspace/ai-agents   && bash cmd-tools-ai-items.sh odoo-tester --install
+cd ~/workspace/ai-skills   && bash cmd-tools-ai-items.sh odoo-scenarios --install
+cd ~/workspace/ai-commands && bash cmd-tools-ai-items.sh odoo-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.
+
+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.
+
 ## 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}/odoo-site-builder.md

@@ -129,3 +129,11 @@ other; the files Odoo stores (attachments) are in the `odoo_data` volume of the
 | The database selector, or "database does not exist" | The build ran without `--install`: `--install-apps contacts` creates the database, or build again with `--install`. |
 | `… is archived instead of deleted` from `--cancel-users` | The account is part of the data of the site (the demo data has a `portal` user), or records point at it; `--add-users` activates it again. |
 | `is not an Odoo project of this plugin` from the CLI tool | The project has no `.ddev/config.odoo.yaml`: it was built by the folder's example builder, or by hand. |
+
+## What comes with you
+
+The Odoo plugin places these beside you, each in the workspace folder of its kind: the agent
+`odoo-tester` (`ai-agents/`), the skill `odoo-scenarios` (`ai-skills/`), the command
+`/odoo-test <site>` (`ai-commands/`) and the prompt `odoo-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}/odoo-tester.md

@@ -20,8 +20,8 @@ tools:
 
 # odoo-tester
 
-You test Odoo Community sites in a Webship Workspace (`~/workspace`) with
-[webship-js](https://github.com/webship/webship-js) (Playwright and Cucumber) and its Odoo step
+You test Odoo Community 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 Odoo step
 pack, [`@webship-js/odoo-steps`](https://github.com/webship/odoo-steps). The suite lives in the
 project (`cucumber.js`, `tests/features/`, `tests/step-definitions/`) and runs in the project's web
 container, against the project's address.
@@ -133,3 +133,13 @@ Feature: A salesperson works on quotations, not on invoices
 
 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 Odoo plugin places these beside you, each in the workspace folder of its kind:
+
+| Item | Where | What it is for |
+| --- | --- | --- |
+| `odoo-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 |
+| `/odoo-test <site>` (command) | `ai-commands/` | The run itself: set up when missing, match every step, run, report |
+| `odoo-build-and-test` (prompt) | `ai-prompts/` | A new session that builds a site with `odoo-site-builder`'s commands and runs its first feature |

package/ai/commands/odoo-test.md

@@ -0,0 +1,88 @@
+---
+description: Test a Odoo Community site of the Webship Workspace with webship-js and the Odoo 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]'
+---
+
+# /odoo-test
+
+Test the Odoo Community site named in: `$ARGUMENTS`
+
+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 -d ~/workspace/*/*/.ddev/config.odoo.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`,
+`odoo-bin`, `python`, `psql` or `npm` on the host for a site.
+
+## 1. Find the site
+
+```bash
+ls ~/workspace/*/<site>/.ddev/config.odoo.yaml
+```
+
+`<folder>` is the sites folder the site is in (`dev`, `test`, `sandboxes`, `demos`). If the file is
+not there, stop: this command is for a site built with `cmd-odoo-project.sh`, which writes it. 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 site answers and the testing stack is there
+
+```bash
+cd ~/workspace/<folder>
+bash cmd-tools-odoo-cli.sh <site>
+grep -c "@webship-js/odoo-steps" <site>/cucumber.js
+```
+
+The first prints the version, the address, the apps and the accounts; if the site does not answer,
+`bash cmd-tools-odoo-cli.sh <site> --restart` starts it again and waits for it. 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/odoo-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, and what
+   it means for the site — a defect of the site, a scenario that asserts something the site never
+   did, or the environment (the site was stopped, an account is missing:
+   `bash cmd-tools-odoo-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. The site is the Community edition: a scenario
+that needs an app of another edition is reported as such, never worked around. 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 `odoo-scenarios` skill or hand over to the `odoo-tester`
+agent; for changing the site, to `odoo-site-builder`.

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

@@ -0,0 +1,27 @@
+Build an Odoo Community site in a sites folder and prove it with its first webship-js feature.
+
+`claude` is the default launcher; the text between the triple quotes is plain and can be given to another AI CLI as it is.
+
+```
+claude --permission-mode bypassPermissions """
+Build an Odoo Community site named <name> in this sites folder and test it with webship-js
+# ~/workspace/<dev|test|sandboxes|demos> · https://<name>.ddev.site · the login at /web/login · 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 odoo-bin, python, psql or npm outside the site's container
+# the Community edition only: no other edition, no trial, no licence, no vendor account
+
+1. bash cmd-odoo-project.sh <name> --install --add-users
+   (the default apps with demo data; add --apps <a,b> for another list of apps, --without-demo to leave the demo data out)
+2. bash cmd-tools-odoo-cli.sh <name>
+   tell me the version, the address, the apps and the 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
+   the first feature expects the default apps: with another list of apps, tell me which scenarios do not apply instead of changing them
+
+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/odoo-scenarios/SKILL.md

@@ -0,0 +1,236 @@
+---
+name: odoo-scenarios
+description: Write and run webship-js scenarios for an Odoo Community site of the Webship Workspace with the Odoo step pack (`@webship-js/odoo-steps`) — the phrases of the pack by area (sessions, apps and menus, views and search, records, dialogs and the chatter, the website with its blog, shop, events and jobs), 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 Odoo site", "test the salesperson account", "which step is there for a kanban column", "add a feature for creating a contact", or when a `.feature` file of an Odoo project is being written or fixed.
+argument-hint: '<site> [what to cover]'
+---
+
+# odoo-scenarios
+
+Scenarios for an Odoo Community site of a Webship Workspace (`~/workspace`, container-based, DDEV
+by default), written from the steps of [`@webship-js/odoo-steps`](https://github.com/webship/odoo-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 Odoo plugin (`@webship.co/workspace-odoo`), like
+the builder (`cmd-odoo-project.sh`), the odoo-bin tool (`cmd-tools-odoo-cli.sh`) and the agents
+`odoo-site-builder` and `odoo-tester`. The site is the Community edition, never the Enterprise
+edition.
+
+## Where everything is
+
+| What | Where |
+| --- | --- |
+| The site | `~/workspace/<folder>/<site>`, at `https://<site>.ddev.site`, the login at `/web/login` (`<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/odoo-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. **Know which apps the site has.** A scenario about an app that is not installed fails at its
+   first step:
+   ```bash
+   bash cmd-tools-odoo-cli.sh <site>                           # the version, the apps, the accounts
+   bash cmd-tools-odoo-cli.sh <site> --install-apps project    # only when an app is asked for
+   ```
+3. **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/odoo-steps/tests/step-definitions/*.steps.js
+   ```
+   Every step carries a comment block with five examples above it; open the file when a phrase
+   is not obvious.
+4. **Look at the screen first** (the Playwright MCP browser, a tab of your own) when the scenario
+   is about a screen you have not seen: the label of a field, the name of a column and the items
+   of a menu are the site's own words, and a form does not always label its first field.
+5. **Write the feature** in `<site>/tests/features/`, from phrases that exist (the lists below).
+6. **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 default accounts are on the site
+already (`bash cmd-tools-odoo-cli.sh <site> --add-users` adds them again if they were removed):
+
+| Handle | Account | What it may do |
+| --- | --- | --- |
+| `admin` | `administrator` | Every installed app, and the settings |
+| `salesperson` | `salesperson` | Sales and CRM, own documents only; no Invoicing |
+| `accountant` | `accountant` | Invoicing; no Sales, no CRM |
+| `employee` | `employee` | An internal user with no app of a role |
+| `portal` | `portal` | A portal user: the website and `/my`, never the web client |
+
+```gherkin
+Given I am a logged in user with the "salesperson" user
+Then I should be logged in as "salesperson"
+And I should be in the web client
+```
+
+## The phrases, by area
+
+Each line is a phrase the pack defines, and each one passed on a site built with
+`bash cmd-odoo-project.sh <site> --install --add-users` (the default apps with demo data; the
+names in quotes are that site's). Most `should` steps also take the negative.
+
+### Sessions
+
+```gherkin
+Given I am not logged in
+Given I am on the login page
+Given I am a logged in user with the "salesperson" user
+When I log in as "salesperson" with password "not-the-password"
+When I log out
+Then I should see the login form
+Then I should see a login error
+Then I should be logged in as "salesperson"
+Then I should not be logged in
+Then I should be in the web client
+Then I should be in the portal
+When I open the user menu
+Then I should see "Log out" in the user menu
+```
+
+### Apps, menus and views
+
+```gherkin
+Then I should see the "CRM" app
+Then I should not see the "Invoicing" app
+When I open the "CRM" app
+Then I should be in the "CRM" app
+Then I should see the "Orders" menu
+Then I should see "Quotations" in the breadcrumb
+When I go back to "Contacts" in the breadcrumb
+Then I should see the kanban view
+When I switch to the list view
+Then I should see the list view
+Then I should see the "New" column
+```
+
+### Records, search, dialogs and the chatter
+
+```gherkin
+When I create a new record
+When I set the "Email" field to "suite-contact@example.com"
+Then the form should have unsaved changes
+When I save the record
+Then the form should not have unsaved changes
+Then the "Email" field should be "suite-contact@example.com"
+Then I should see the chatter
+When I log the note "Written by the suite."
+Then I should see "Written by the suite." in the chatter
+When I search the records for "A contact from the suite"
+Then I should see the "A contact from the suite" record
+Then I should see 1 record
+When I select the "A contact from the suite" record
+Then I should see 1 selected record
+When I choose "Delete" in the Actions menu
+Then I should see a dialog
+When I confirm the dialog
+Then I should see no records
+```
+
+### The website
+
+```gherkin
+Then I should be on a website page
+Then I should see the menu
+Then I should see the footer
+Then I should be on the blog page
+Then I should be on the shop page
+When I search the shop for "desk"
+Then I should see shop search results for "desk"
+When I open the first product in the shop
+Then I should be on a product page
+When I add the product to the cart
+Then I should see "1" item in the cart
+Then I should be on the events page
+Then I should be on the jobs page
+Then I should see job openings
+Given I am on the contact page
+Then I should see the contact form
+Then I should be on the 404 page
+Then I should be able to edit the website
+```
+
+`I am an anonymous user`, `I am on the homepage`, `I go to "/shop"`, `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 field is named by what the form shows, and the first field of a contact shows no label.**
+  `When I set the "Name" field to "…"` failed in Contacts: the form labels `Email`, `Phone`,
+  `Tags` and the others, and the name is a placeholder. The technical name passed:
+  `When I set the "name" field to "A contact from the suite"`. The failure message lists the
+  labels the form has.
+- **`I should be able to edit the website` is a step for an internal user.** A visitor and a
+  portal user are not shown the website preview: they get the public page, and
+  `I should not be able to edit the website` passes for them. (With the pack before 2.1.1 it
+  failed there with `Expected the website preview of the web client`.) The positive form fails
+  for them and says to log in first.
+- **Deleting a record is done from the list.** Search for it, switch to the list view, select
+  it, choose `Delete` in the Actions menu and confirm the dialog, as the example does.
+- **A product in the cart is a quotation in Sales.** `When I add the product to the cart` passed
+  for a visitor and left a quotation behind that a visitor cannot remove. The examples stop at
+  the product page; a cart scenario belongs in a site that is rebuilt for the run.
+- **The pages are the default apps'.** `/blog`, `/shop`, `/event`, `/jobs` and the pipeline
+  columns `New` and `Won` come with the apps and the demo data the builder installs. A site built
+  with `--apps` or `--without-demo` has its own.
+- **The demo data has its own `portal` user.** The handle `portal` logs in as that account, with
+  the groups and the password of the default list.
+
+## Rules
+
+- **No account is created in a suite.** No user is added by a scenario or a hook. 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 "CRM" app`, `I should be in the web client`,
+  never a phrase that names the product. The same holds for a custom step.
+- **No selector and no address when a step says it**: `the "Sales" app`, not the path of its
+  action.
+- **What a scenario creates, it removes** in the same scenario, under a name nobody else uses.
+- **Community only.** No scenario needs an app of another edition, a trial or a vendor account,
+  and nothing is sent to an outside service.
+- **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-odoo-project.sh <site> --install --add-users`. Copy one into the suite and run it:
+
+```bash
+cp ~/workspace/ai-skills/odoo-scenarios/examples/apps-and-views.feature ~/workspace/<folder>/<site>/tests/features/
+cd ~/workspace/<folder>
+bash cmd-tools-testing.sh <site> --run --path tests/features/apps-and-views.feature
+```
+
+| Feature | What it shows |
+| --- | --- |
+| `examples/apps-and-views.feature` | A salesperson in the pipeline and in the quotations, an employee with no app of a role, the user menu |
+| `examples/contact-lifecycle.feature` | An administrator creating a contact, logging a note, finding it and deleting it: a record a scenario creates and removes |
+| `examples/website.feature` | A visitor on the front page, the blog, the shop, the events, the jobs and the contact page, an address with no page, and a portal user kept out of the web client |

package/ai/skills/odoo-scenarios/examples/apps-and-views.feature

@@ -0,0 +1,36 @@
+Feature: Each account works in the apps of its role
+  As the owner of the site
+  I want every account to open the apps of its role, with their views and menus
+  So that a change of groups or of an app is caught by the suite
+
+  # The accounts are the default ones; a scenario logs in by a handle of the users registry.
+
+  Scenario: A salesperson works in the pipeline
+    Given I am a logged in user with the "salesperson" user
+    When I open the "CRM" app
+    Then I should be in the "CRM" app
+    And I should see the kanban view
+    And I should see the "New" column
+    And I should see the "Won" column
+    When I switch to the list view
+    Then I should see the list view
+
+  Scenario: A salesperson opens the quotations
+    Given I am a logged in user with the "salesperson" user
+    When I open the "Sales" app
+    Then I should be in the "Sales" app
+    And I should see "Quotations" in the breadcrumb
+    And I should see the "Orders" menu
+
+  Scenario: An employee has the web client and no app of a role
+    Given I am a logged in user with the "employee" user
+    Then I should be in the web client
+    But I should not see the "Sales" app
+    And I should not see the "Settings" app
+
+  Scenario: The user menu ends the session
+    Given I am a logged in user with the "accountant" user
+    When I open the user menu
+    Then I should see "Log out" in the user menu
+    When I log out
+    Then I should not be logged in

package/ai/skills/odoo-scenarios/examples/contact-lifecycle.feature

@@ -0,0 +1,29 @@
+Feature: A contact is written and removed again
+  As an administrator
+  I want to create a contact, note something on it, find it and delete it
+  So that the suite proves records, the chatter and the search work, and leaves the site as it found it
+
+  Scenario: The administrator creates a contact, finds it in the list and deletes it
+    Given I am a logged in user with the "admin" user
+    When I open the "Contacts" app
+    And I create a new record
+    And I set the "name" field to "A contact written by a scenario"
+    And I set the "Email" field to "scenario-contact@example.com"
+    Then the form should have unsaved changes
+    When I save the record
+    Then the form should not have unsaved changes
+    And the "Email" field should be "scenario-contact@example.com"
+    And I should see the chatter
+    When I log the note "Written and removed by the suite."
+    Then I should see "Written and removed by the suite." in the chatter
+    When I go back to "Contacts" in the breadcrumb
+    And I search the records for "A contact written by a scenario"
+    Then I should see the "A contact written by a scenario" record
+    And I should see 1 record
+    When I switch to the list view
+    And I select the "A contact written by a scenario" record
+    Then I should see 1 selected record
+    When I choose "Delete" in the Actions menu
+    Then I should see a dialog
+    When I confirm the dialog
+    Then I should see no records

package/ai/skills/odoo-scenarios/examples/website.feature

@@ -0,0 +1,43 @@
+Feature: A visitor reads the website
+  As the owner of the site
+  I want the pages of the website apps to be served to a visitor
+  So that an app or a theme that breaks the website is caught by the suite
+
+  # For a site built with the default apps: the blog, the shop, the events and the jobs.
+
+  Scenario: The front page has its menu and its footer
+    Given I am an anonymous user
+    And I am on the homepage
+    Then I should be on a website page
+    And I should see the menu
+    And I should see the footer
+
+  Scenario: Each website app has its page
+    Given I am an anonymous user
+    When I go to "/blog"
+    Then I should be on the blog page
+    When I go to "/event"
+    Then I should be on the events page
+    When I go to "/jobs"
+    Then I should be on the jobs page
+    And I should see job openings
+    Given I am on the contact page
+    Then I should see the contact form
+
+  Scenario: The shop lists products and finds one
+    Given I am an anonymous user
+    When I go to "/shop"
+    Then I should be on the shop page
+    When I search the shop for "desk"
+    Then I should see shop search results for "desk"
+    When I open the first product in the shop
+    Then I should be on a product page
+
+  Scenario: An address with no page is not found, and a portal user stays out of the web client
+    Given I am an anonymous user
+    When I go to "/this-page-does-not-exist"
+    Then I should be on the 404 page
+    Given I am a logged in user with the "portal" user
+    When I go to "/web"
+    Then I should be in the portal
+    And I should not be in the web client

package/dist/src/index.d.ts

@@ -3,9 +3,9 @@
  *
  * What the package carries is placed by the installer from the manifest: the builder and the
  * odoo-bin tool in the sites folders, their functions, argparse and the accounts script under
- * core/scripts/plugins/odoo/, the agents in the AI Agents folder. The dashboard needs nothing
+ * core/scripts/plugins/odoo/, its AI items (ai/) in the AI folders. 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 like any other. What register() adds is what the
+ * 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
@@ -18,6 +18,12 @@ export declare const PLATFORM = "odoo";
 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: a whole launch command for a new session. */
+export declare const PROMPTS: string[];
 /** What the assistant is told about Odoo in this workspace. */
 export declare function assistantContext(): string;
 export declare function register(api: PluginApi): void;

package/dist/src/index.js

@@ -4,16 +4,16 @@
  *
  * What the package carries is placed by the installer from the manifest: the builder and the
  * odoo-bin tool in the sites folders, their functions, argparse and the accounts script under
- * core/scripts/plugins/odoo/, the agents in the AI Agents folder. The dashboard needs nothing
+ * core/scripts/plugins/odoo/, its AI items (ai/) in the AI folders. 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 like any other. What register() adds is what the
+ * 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 are named after. */
@@ -22,6 +22,12 @@ exports.PLATFORM = 'odoo';
 exports.COMMANDS = ['cmd-odoo-project.sh', 'cmd-tools-odoo-cli.sh'];
 /** The agents the installer places in the AI Agents folder. */
 exports.AGENTS = ['odoo-site-builder', 'odoo-tester'];
+/** The skill the installer places in the AI Skills folder (a folder each, with its SKILL.md). */
+exports.SKILLS = ['odoo-scenarios'];
+/** The slash command the installer places in the AI Commands folder. */
+exports.AI_COMMANDS = ['odoo-test'];
+/** The prompt the installer places in the AI Prompts folder: a whole launch command for a new session. */
+exports.PROMPTS = ['odoo-build-and-test'];
 /** What the assistant is told about Odoo in this workspace. */
 function assistantContext() {
     return [
@@ -33,6 +39,8 @@ function assistantContext() {
         '`--add-users` adds the default accounts (one per kind of user).',
         '`bash cmd-tools-testing.sh <name>` sets up webship-js with the Odoo step pack; `--run` runs the suite.',
         `For Odoo 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/.`,
         'Community only: never the Enterprise edition, never a vendor account. Never run odoo, python or psql on the host for a project.',
         'The example builder cmd-odoo20-project.sh of a sites folder is a different, simpler build; this plugin leaves it as it is.',
     ].join(' ');

package/dist/src/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;GAYG;;;AAcH,4CAaC;AAED,4BAEC;AA3BD,8DAA8D;AACjD,QAAA,QAAQ,GAAG,MAAM,CAAC;AAE/B,+DAA+D;AAClD,QAAA,QAAQ,GAAG,CAAC,qBAAqB,EAAE,uBAAuB,CAAC,CAAC;AAEzE,+DAA+D;AAClD,QAAA,MAAM,GAAG,CAAC,mBAAmB,EAAE,aAAa,CAAC,CAAC;AAE3D,+DAA+D;AAC/D,SAAgB,gBAAgB;IAC9B,OAAO;QACL,mFAAmF;QACnF,4GAA4G;QAC5G,gGAAgG;QAChG,0HAA0H;QAC1H,gHAAgH;QAChH,iEAAiE;QACjE,wGAAwG;QACxG,0CAA0C,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG;QACxF,iIAAiI;QACjI,4HAA4H;KAC7H,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;;;;;;;;;;;;GAYG;;;AAuBH,4CAeC;AAED,4BAEC;AAtCD,8DAA8D;AACjD,QAAA,QAAQ,GAAG,MAAM,CAAC;AAE/B,+DAA+D;AAClD,QAAA,QAAQ,GAAG,CAAC,qBAAqB,EAAE,uBAAuB,CAAC,CAAC;AAEzE,+DAA+D;AAClD,QAAA,MAAM,GAAG,CAAC,mBAAmB,EAAE,aAAa,CAAC,CAAC;AAE3D,iGAAiG;AACpF,QAAA,MAAM,GAAG,CAAC,gBAAgB,CAAC,CAAC;AAEzC,wEAAwE;AAC3D,QAAA,WAAW,GAAG,CAAC,WAAW,CAAC,CAAC;AAEzC,0GAA0G;AAC7F,QAAA,OAAO,GAAG,CAAC,qBAAqB,CAAC,CAAC;AAE/C,+DAA+D;AAC/D,SAAgB,gBAAgB;IAC9B,OAAO;QACL,mFAAmF;QACnF,4GAA4G;QAC5G,gGAAgG;QAChG,0HAA0H;QAC1H,gHAAgH;QAChH,iEAAiE;QACjE,wGAAwG;QACxG,0CAA0C,cAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,GAAG;QACxF,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,iIAAiI;QACjI,4HAA4H;KAC7H,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,145 @@
+# 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 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/odoo.feature

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

package/package.json

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

package/scripts/functions/fun-odoo.sh

@@ -25,7 +25,7 @@
 
 # The step pack an Odoo project is tested with, and the release line it is required at.
 readonly ODOO_STEPS_PACKAGE='@webship-js/odoo-steps';
-readonly ODOO_STEPS_VERSION='^2.1.0';
+readonly ODOO_STEPS_VERSION='^2.1.1';
 
 # The one database of a project (the container tool's own), and the port Odoo listens on.
 readonly ODOO_DATABASE='db';