Register a new engineering goal and get a project id.

Call this once per goal, then decompose it with submit_plan. constraints holds non-negotiables (stack, deadline, style rules) that every agent should respect.

Decompose a project goal into a dependency-ordered task graph in one call.

depends_on entries are zero-based indexes into the tasks list itself (task 2 depending on [0, 1] waits for the first two tasks). Returns the created tasks with their real ids; agents then claim ready tasks with claim_task.

List all projects in this swarm with their status.

Introduce yourself to the swarm. Call once at startup.

Pick a stable, unique agent_id (e.g. 'impl-1', 'reviewer-claude') and use the same id in every later call: claims, submissions and reviews are attributed to it, and self-review is rejected based on it.

List tasks on the project board.

Use ready_only=true to see only tasks you could claim right now (open, with all dependencies done). Status filter accepts: open, claimed, in_progress, in_review, done.

Atomically claim an open task. Fails if it is taken or not ready.

The claim carries a lease: if you stop renewing it (update_task renews automatically) the task returns to the board so the swarm never stalls on a crashed agent. After claiming, call get_briefing before starting.

Report progress on your claimed task and renew its lease.

status may be 'claimed' or 'in_progress'. Any notes you pass are saved to shared context (tagged with the task id) so other agents can see what you are doing. Finishing goes through submit_for_review or complete_task instead.

Mark your claimed task done WITHOUT review (for trivial/mechanical tasks).

For anything substantive, prefer submit_for_review so another agent checks the work. summary is what future briefings will show to agents whose tasks depend on this one — write it for them.

See the whole dependency graph: every task, its status, blockers, and who holds it.

Use this to find the critical path or to check whether the project is done.

Write a fact to the shared blackboard so every agent can find it.

Use stable, descriptive keys ('api-schema', 'auth-flow'); writing the same key again updates it. Tag entries with 'task-' to make them show up in that task's briefing.

Search the shared blackboard by substring over keys, content, and tags.

An empty query returns the most recently updated entries.

Log an architectural/engineering decision so the swarm stops re-litigating it.

Decisions appear in every briefing. Record the WHY in rationale — future agents only see what is written here.

Get an onboarding packet for a task: everything needed to start cold.

Bundles the project goal and constraints, the task itself, summaries of its completed dependencies, all recorded decisions, related shared context, and reviewer feedback from earlier iterations. Call this right after claim_task, and again after a review requests changes.

Submit your claimed task's work product for peer review.

content is what the reviewer will judge: a diff, a list of changed files with explanations, or a results summary. self_assessment is your honest note on risks and what you did not verify. The task moves to in_review until a different agent posts a verdict.

List submissions waiting for review on this project.

Includes each submission's task title and iteration count, so reviewers can prioritise work that has already bounced.

Post a verdict on a submission: 'approve' or 'request_changes'.

approve completes the task. request_changes sends it straight back to the author as in_progress with your comments attached to their next briefing — be specific and actionable. You cannot review your own submission.

Run an allowlisted verification command (tests/linters/builds) for a task.

Allowed executables: pytest, python, uv, pip, ruff, mypy, black, flake8, npm, pnpm, yarn, npx, node, tsc, eslint, jest, vitest, go, cargo, make. The command runs without a shell (no pipes/redirects), with a hard timeout, and the result is recorded on the task as review evidence. Include the relevant output in your submit_for_review content.

Open a discussion when agents disagree or a choice needs multiple perspectives.

Frame the topic as a decidable question ('Postgres or SQLite for the cache?'), then invite positions via post_to_discussion.

State your position in an open discussion, with reasoning.

Read the existing posts first (list_discussions / get_briefing show them) and respond to the strongest opposing argument, not past it.

Close a discussion with the consensus and make it binding project memory.

Requires positions from at least 2 distinct agents. The resolution is automatically recorded as a project decision (with a digest of the debate as rationale), so every future briefing carries it — the swarm will not re-litigate.

List discussions on a project ('open' or 'resolved'), with their posts.

List battle-tested engineering workflow templates with what each is for.

Get a workflow template: recommended swarm + a task list shaped for submit_plan.

Available: ship-feature, refactor-module, debug-issue. Adapt the task titles/descriptions to your concrete goal, then pass the tasks straight to submit_plan — depends_on indexes are already wired.

Compile the project's performance evidence for a swarm retrospective.

Returns totals (review bounce rate, check pass rate, iterations), per-agent stats (tasks completed, submissions bounced, reviews given), and hotspots — the tasks that needed the most review round-trips. Analyze it to propose concrete process improvements, and record the ones the swarm adopts via record_decision.