---
name: mmo-release-bugs
description: Turn the bugs of a release (a recette / QA report, a feedback file, a list pasted in chat, screenshots) into <mmo-kanban> tickets each holding a ready-to-run fix prompt; fix them with parallel agents that report in each ticket's discussion; then build the release checklist (mmo.admin) that verifies every ticket before it moves to done. Use whenever the user has bugs to triage or fix in an MMOFramework application (my.oviepro or any other), mentions a kanban board of the hub (`boards/*.json`, `api/boards/...`), a recette, a release to ship, tickets to fix, or a checklist to review before committing — even if they do not name this skill.
---
# Bugs of a release: tickets, fixes, checklist
The method that took my.oviepro 4.1 from a 100-point recette to a reviewed release: **every bug is a ticket with
its own prompt, everything about a ticket stays in its discussion, and nothing moves to done until a checklist has
proved it.** Three phases; do only the one the user asks for, and stop at its end.
| phase | asked as | ends with |
|---|---|---|
| 1. tickets | "turn this report into tickets", "put these bugs on the board" | every bug a ticket in **backlog**, with a ```` ```claude ```` prompt |
| 2. fixes | "fix the tickets", "treat the backlog" | each ticket commented (`**Claude — result**`) and moved: fixed → review column, not done → todo |
| 3. checklist | "what do I review before committing", "a checklist linked to the board" | a release checklist following the board, shown at `admin/checklists?name=...` |
Never commit, push, deploy or run a data migration in any phase: say what is ready, and ask.
## Where things are
- **Boards**: the application a release is for keeps its `<mmo-kanban>` boards: my.oviepro in
`~/dev/src/my.oviepro/boards/{board}.json`, served by mmo.admin's `BoardController` at
`http://localhost/my.oviepro/api/boards/{board}.json`, shown at Administration > Développeur > Boards
(`admin/developer/boards?board={board}`, dev only). A new board is a new file: `PUT api/boards/{board}.json`.
- **Checklists**: mmo.admin's `ChecklistController` keeps each one in the same application's `checklists/{name}.json`
(`api/checklists/...`), shown at Administration > Checklists (`http://localhost/my.oviepro/admin/checklists`),
whose selector goes from one to another. On localhost both answer without logging in (`configs/dev.json`).
- The application under repair: its own repository (`~/dev/src/<app>`), served at `http://localhost/<app>/`, its
libraries linked from `~/dev/src/MMO/master/libs`. Logging in as an agent: the `mmo-agent-login` skill.
- The API in one place: [references/api.md](references/api.md).
## Phase 1 — the report becomes tickets
1. **Read the whole report**, images included: a markdown export often embeds screenshots as `data:image` lines
(extract them to files and look at them: some bugs exist only in a screenshot). Note who reported what and what
was already confirmed ("Retour Flo : confirmé").
2. **Read the board first** (`GET api/boards/{board}.json`): keep its statuses, labels, categories and existing
tickets. Give new tickets the next free ids; never renumber.
3. **Tour the application's code** before writing a prompt: a prompt names the real files, routes, classes and
collections (`src/views/parts/temoins-tiers.jhs`, `PUT|data/{repository}/{collection}` of
`RepositoryController`). A prompt that says "find where X is" when you could have found it is a wasted agent.
4. **One ticket per bug**, merged when two lines of the report are the same bug, split when one line holds two.
Each gets:
- `title`: the symptom, short, in the report's language;
- `category`: the area (security, a form, lists, PDF, e-mails, responsive...) — the board's `categories`;
- `labels`: a severity (`bloquant` / `majeur` / `mineur`), its nature (`securite`, `rgpd`, `texte`, `pdf`,
`responsive`, `performance`, `amelioration`), and `confirme-<who>` or `a-reproduire`;
- `status`: the board's first backlog status;
- `description`: the template of [references/tickets.md](references/tickets.md) — **Constat**, the reporter's
answer, **Attendu**, then **Prompt suggéré** holding one ```` ```claude ```` block.
5. **The prompt** is self-sufficient: a shared head (the application, its path, version, branch, local url, where
the libraries are, where the bug was seen), the bug's own paragraph (what happens, where, the files to look at,
what "fixed" means, the test to add), and a shared foot (reproduce first, fix the cause not the symptom, fix it in
the library when the cause is there and say so, verify on screen or by the API, do not commit, report in the
ticket's discussion).
6. **Write the tickets with a generator script** (scratchpad, Python or PHP) rather than by hand: the head and foot
are constants, one call per ticket. Save through the API, whole board, with its `version`
(`PUT api/boards/{board}.json {version, data}`); a 409 means someone saved meanwhile: re-read, merge, retry.
Check `GET api/boards/{board}/prompts.json?agent=claude` lists one prompt per ticket.
## Phase 2 — fixing the tickets
1. **Check the ground**: `git status` of the application and of every library is clean (or note what is already
modified, it is not yours); find how the front end rebuilds in dev mode (`.jhs`, `.scs`, `i18n`), so agents do not
fight over builds.
2. **Split by domain, not by number**: at most 8 agents, each owning the tickets of one area (security and data API,
persistence, business rules, e-mails and messages, PDF, lists, forms, the application's shell and responsive).
Two agents never own tickets in the same files when it can be helped; shared files (theme `.scs`, `fr.js`,
common elements) are edited in small, re-read-first changes.
3. **One shared brief** for all of them ([references/agent-brief.md](references/agent-brief.md)): where things are,
how to read and comment a ticket, the result comment's format, the rules (no commit, no board writes, test data
prefixed `TEST CLAUDE`, browser tab of their own, never a token in a comment). Each agent's prompt is then a few
lines: read the brief, your domain, your tickets, your priorities.
4. **Every agent comments every ticket it owns** (`POST api/boards/{board}/{ticket}/comments.json`), starting with
`**Claude — result**` (or `**Claude — résultat**`) and a verdict — FIXED / PARTIAL / NOT DONE — then the cause,
the files changed (full paths), what was verified and how, what remains or which decision is awaited, and a
```` ```check ```` block: the functional checks phase 3 will list, one per line, `page | url | what to check`.
Agents never write the board itself: the orchestrator moves tickets.
5. **While they run**, relay what each one finished in a sentence or two; turn the bugs they find outside their
tickets into a list for new tickets.
6. **When all are done**: `php tools/mmo.php verify --lib=<lib>` for each library touched, `php -l` on the
application's changed PHP files, a smoke test of every page (`GET pages.json`, each page answers 200 without a
PHP error), a look in the browser at the console of the main pages. Compare each ticket's verdict with its
comment. Then, in one script: move FIXED to the review column (`Recette`), PARTIAL and NOT DONE to todo, with an
orchestration comment on each saying why it is there and what is not yet done (not committed, not deployed);
add a ticket for each bug found along the way, same template, its prompt's head saying where it was found.
Leave temporary files nowhere (an agent's `> null` creates a file named `null`).
## Phase 3 — the release checklist
The checklist lists everything to look at before committing: each changed file by repository and folder, a
functional check per treated ticket by page, and what no ticket covers. Each item names the tickets it verifies;
a ticket all of whose items are checked gets the board's `vérifié` label and can be moved to done from the page,
which comments what was checked. Details and the recipe: [references/checklist.md](https://mcp.mmoframework.fr/search/read?uri=mmoframework-skill%3A%2F%2Fmmo.admin%2Fmmo-release-bugs%2Freferences%2Fchecklist.md).
1. `PUT api/checklists/{name}.json` with `version: 0`, a `title`, the `board` it follows, the page of that board
(`boardUrl`: `admin/developer/boards`), and a `recipe`: the repositories (the application, with
`"exclude": ["checklists/"]`, each library touched, the hub with `"pages": false` and `"exclude": ["libs/"]`), the site's url, the hand-written items (verify passes, config
files to re-read, commit order, test data to clean up), and the texts in the user's language.
2. `POST api/checklists/{name}/build.json`, then read its `build`: `orphans` are changed files no ticket cites
(transverse changes, reviewed for themselves — say which), `unmatched` are treated tickets no file names.
3. Give the user the page: `http://localhost/my.oviepro/admin/checklists?name={name}`; the board's page links it by itself.
4. After any new fix, rebuild: what was checked stays checked while its item is still there.
## Traps
- The board's ids are strings (`"12"`); PHP turns numeric keys into ints: compare as strings.
- `BoardController` holds `boards/{board}.json.lock`: write through the API, never the file, while the site runs.
- The web server is not you: `~` in a recipe is the home of the application folder's owner, files it creates belong to
`www-data` (make new folders writable: `chmod 777 checklists`).
- A ticket's prompt is run by another agent with none of your context: name files by their path from the home
folder, never "the file we saw".