This belongs to a project with sprints in Planning Studio. The crew works along like colleagues, but whatever goes out is always signed by a person.
What the crew may pick up
Under Team every agent has its own rules for this project:
- How many at once: when full, the agent gets no new item.
- Monthly cap: an amount in euros, on your own key. It is checked beforehand; there is no emergency brake halfway. At the cap the agent picks up nothing more, not even what was already with it. You see per agent what it cost this month, and on an item's page what the work on it cost.
- Highest risk: R1 or R2. A risk level is set by a person; an agent never picks up R3.
- Excluded labels: by default payments, privacy and legal. An item with such a label stays with people, even if it looks small.
- There must be a criterion: without a criterion the agent does not know when it is done.
- Reviewer and green checks: the reviewer reads every pull request of the builder, and proposing a merge needs green checks.
- Paused: the agent picks up nothing new; what is running it finishes.
On the project's board, under Code, you set per repo whether the crew may work in it. A new link is off.
A person signs merging
On an item's page an open pull request shows Propose merging, if the checks are not red and no changes were requested. Merging is risk level 3: a person signs it under Approvals, with a code. The signature holds for the state of the branch at that moment. If the branch changes afterwards, it lapses and nothing is merged.
Standup and risks
Under Standup you see per person and agent what is done since yesterday, what they work on now and what blocks (red checks, requested changes or a deadline that has passed). Below are the risks: a sprint that is too full, an unknown capacity, a deadline before the end of the sprint, an item without an estimate, red checks, an agent at its cap. Every warning says why, and is about work, never about a person. The director reads the same and writes a summary with it.
Release notes
Under Release notes you make a draft per sprint from the pull requests merged in that sprint, grouped in New, Improved and Fixed. The pull request title is for the team. You write the text for the client, in plain language; a line without it is left out.
Publishing in the client portal goes to a client and is risk level 2: it waits for a signature. If a line changes afterwards, the signature publishes nothing and you propose again. You withdraw a published note immediately.
What the client sees
On the board of a project for a client you choose under What the client sees what that client sees in the client portal: the progress as a percentage, the parts (epics) with their progress, the published release notes, and the titles and column of the items in the running sprint. Read only. Points, names of colleagues and agents, time and risk never appear. If nothing is on, the client sees nothing of the project. A switch only counts once you press Save.
Recipes
Under Planning, Recipes are rules that prepare work between modules. They are off by default and never sign.
- Deal won: a project. A won deal in Relations becomes a project with a board for that client, unless the client already has a project with that name.
- Sprint done: prepare release notes. A completed sprint of a project with a client gets a draft. The text for the client and publishing are done by a person.
- Pull request merged: line in the release notes. If the item's sprint already has a draft, the pull request is added.
Every run is in the log, including skipped ones, with the reason. A message to the client when an issue is done, an issue from a support question and an invoice proposal are listed but not available yet.
The director
Through our MCP the director reads duplicates, an estimate from comparable work, the standup, the risks, the retro and the release notes. It can propose an epic with stories: that becomes an action you sign, and only then are the stories in the backlog, without a sprint and without a risk.
Who may do what
Rules for agents, repos for the crew, what the client sees and recipes need the right to manage. Making release notes and proposing to publish them, and proposing a merge, need the right to plan. Signing follows the usual rules for approvals.