Assign work, contain actions and review what returns.
Assign work and resolve ownership.
Set the allowed files, network and runtime budget.
Check evidence, combine changes and decide whether to accept.
One ticket: export net, VAT and gross invoice values as CSV.
Who gets a task, what it depends on and who integrates the result.
What files, credentials, processes and network endpoints the tools can access.
A dashboard or Git worktree does not by itself enforce a security boundary.
| Bottleneck | Useful capability |
|---|---|
| Too many sessions to track | A monitor with task state and evidence links. |
| Independent changes collide | Separate workspaces plus explicit file ownership. |
| Ready work waits unclaimed | A queue with leases, retries and review gates. |
| Tools can touch too much | A restricted environment with scoped credentials. |
Choose products only after these requirements are clear.
Failed or blocked work returns with evidence. A green tool run does not automatically publish a change.
| Event | Expected state or action |
|---|---|
| Worker finds missing VAT rule | Blocked; request the rule before changing behavior. |
| Two workers claim the same ticket | One claim wins; the other does not start editing. |
| Tests pass but escaping is untested | Review records the gap and adds an acceptance check. |
Exercise: explain who owns each decision and what evidence is attached.
Review mounts, egress and permissions in the actual runtime.
| Failure | Concrete control |
|---|---|
| Repeats the same failed repair | Limit attempts; require a new hypothesis before retrying. |
| Weakens tests to make them pass | Review the test diff; run independent acceptance checks. |
| Changes unrelated behavior | Scope allowed paths; inspect the complete diff. |
Prompts help communicate these rules. Enforce the important boundaries in tools, permissions and review.
Assign the reviewer and agree on the return format.
Stop filling the queue when review capacity is exhausted.
Inspect the integrated result, including interactions between patches.
More workers can move the queue downstream. Measure completed, accepted work.
Procedure: inspect the diff → run the cases → report evidence and gaps.
| Need | Where it belongs |
|---|---|
| VAT rate comes from the order | Short project instruction. |
| How to verify an invoice export | Skill with cases and a reporting procedure. |
| Read the invoice specification ticket | An authorized CLI, API or MCP tool. |
A procedure teaches how to use access. It does not grant that access.
The repeatable invoice-check procedure and supporting files.
A versioned way to distribute the procedure and supported integrations.
Test discovery and behavior in a clean session before sharing. Installation does not replace review or permission boundaries.
Output: a small skill file and evidence that it is used when appropriate.
Example path: .claude/skills/invoice-check/SKILL.md. Check discovery in a fresh session.
Tools exposed through a client/server protocol, with structured inputs and supported authentication paths.
Commands executed by a shell tool, with help, arguments, output and error handling.
Both can reach local or remote services. Both need appropriate credentials, permissions and review.
Measure the actual client configuration. There is no universal cheaper interface.
This is an experiment design, not a completed case study.
Choose interface and orchestration tools from observed needs.
Primary documentation checked 3 October 2026. Examples are illustrative unless explicitly attributed.