Task types tell agents what kind of work they are responsible for.

Reads design docs, current code, conformance reports, and project status, then creates a small dependency graph for the next autonomous sprint.

Expected output

Ready-to-run task DAG with explicit dependencies and file ownership.

Best for

Game projects that need build, art, polish, QA, and audit sequenced together.

Surveys an arbitrary codebase and creates tasks instead of editing files. It is useful when the project needs decomposition before execution.

Expected output

A bounded plan with small tasks, owners, dependencies, and validation notes.

Best for

New work where parallelism is possible but write scopes need care.

Plans Python work with stack-aware validation, module ownership, and task descriptions that execution agents can run without seeing the planner context.

Expected output

A Python-focused task graph, usually limited to feature, bug, and refactor children.

Best for

Python services, CLIs, libraries, and test-heavy maintenance sprints.

Builds a new capability end to end. Feature agents are expected to wire systems into reachable flow, update observable state, add tests, validate, and commit.

Expected output

Working behavior, tests or equivalent validation, and a concise implementation commit.

Best for

New mechanics, screens, APIs, systems, or integrations.

Starts from a concrete failure, reproduces or localizes it, makes the smallest defensible fix, then runs targeted and broader validation.

Expected output

Reproduction notes, implicated files, fix summary, and validation evidence.

Best for

QA failures, test failures, runtime crashes, regressions, or broken interactions.

Reduces oversized or tangled files while preserving behavior. Refactor agents extract logical systems and validate after each meaningful step.

Expected output

Smaller modules, deleted duplication, passing validation, and behavior-preserving commits.

Best for

Large files, shared utilities, ownership boundaries, or risky accumulation during a sprint.

Improves visual quality after core systems exist, using project assets, screenshots, and visual review rather than treating appearance as an afterthought.

Expected output

Improved art direction, replaced placeholders, and screenshot-backed verification.

Best for

Games or interfaces that are playable but still look provisional.

Tightens the shipped feel: transitions, button feedback, menu flow, HUD clarity, audio cues, animation, game feel, and visual consistency.

Expected output

Sharper interaction quality with screenshot or runtime verification when visual.

Best for

The pass between implementation and final QA, where rough edges become visible.

Launches the app or game, captures screenshots, inspects behavior and visuals, and files bugs when the result does not match expectations.

Expected output

Observed pass/fail evidence, screenshots where useful, and queued bug tasks.

Best for

Visual regressions, UI flow, playability, and user-facing acceptance checks.

Uses a state server or test harness protocol to poll checkpoints, assert game state, and create repair tasks for failed milestones.

Expected output

Checkpoint results, bug tasks linked to the QA root, and reruns after repairs.

Best for

Repeatable gameplay checks, protocol-level validation, and milestone gates.

Writes a focused scenario JSON file, launches the game, and runs deterministic steps such as captures, button presses, waits, state assertions, and invariants.

Expected output

A scenario trace, pass/fail result, and an automatically filed bug task when a step fails.

Best for

Concrete player flows like booting to menu, starting gameplay, reaching a scoring state, or checking a first meaningful loop.

Combines harness/state validation with visual or manual-style checks, keeping generated bugs attached to the active QA chain.

Expected output

State-backed findings plus visual acceptance notes and dependent bug tasks.

Best for

Projects where automated state is necessary but not sufficient.

Compares the codebase against the design and writes a conformance report, then seeds the next planning pass when important gaps remain.

Expected output

A conformance report, closure assessment, and next project-plan task when needed.

Best for

End-of-sprint checks and making sure completed work still matches the original intent.

Investigates a specific question without changing product code. It records method, findings, recommendations, and confidence.

Expected output

A research note plus follow-up tasks when the findings need execution.

Best for

Architecture questions, library choices, unclear behavior, or design constraints.

Assesses a broken or unfamiliar project by checking scripts, tests, scenes, runtime behavior, and project completeness.

Expected output

Bug and feature tasks that reflect the actual health of the repo.

Best for

Unknown codebases, stalled runs, or repos that need a first useful work queue.

Looks across recent agent learnings and groups recurring lessons by task type so future work can inherit operational patterns.

Expected output

Condensed lessons that can improve prompts, QA checklists, and task planning.

Best for

Keeping rapid autonomous runs from losing what they discovered.

Runs every 6 hours by default across active game projects. It reads recent failures, completed tasks, and agent logs, then identifies repeated bugs such as state-server port collisions or Godot upgrade regressions.

Expected output

Entries in data/swarm_knowledge.jsonl, a readable data/SWARM_KNOWLEDGE.md report, and targeted fix tasks on affected projects.

Best for

Cross-project pattern recognition and preventing the same bug from being rediscovered by every project in the swarm.

Closes the loop between real task failures and the prompts that shape future agents. It groups recurring failures by task type and finds likely prompt instruction gaps.

Expected output

A data/LIBRARIAN_REPORT.md report, optional swarm knowledge entries, and bounded prompt-refactor tasks on the controller.

Best for

Improving agent instructions from actual failure history instead of one-off anecdotes.

Turns queue state, health scores, recent outcomes, and known patterns into a readable map of what every active project is doing and where it is stuck.

Expected output

data/PROJECT_MAP.md for humans and data/SWARM_SUMMARY.json for dashboards and other meta-agents.

Best for

Understanding swarm health without reading every project log by hand.

Audits systemic quality issues across projects, separate from a single-project audit. It looks for template drift, missing required files, recurring anti-patterns, and dependency hygiene problems.

Expected output

data/AUDIT_REPORT.md, coordinated fix tasks, and template sync tasks when shared project scaffolding has drifted.

Best for

Fixing one class of structural problem across many projects at once.

Balances future scheduling decisions using queue composition, project priority, agent slots, quota pressure, and project health. It can adjust config, but it does not kill running agents.

Expected output

data/SCHEDULER_LOG.md plus config adjustments such as pause recommendations or agent ceiling changes.

Best for

Keeping active capacity pointed at the projects most likely to make progress.

Investigates projects that have gone silent, exhausted their queue after failures, or entered repeated recovery chains. It is diagnosis-first and read-only on project code.

Expected output

An ARCHAEOLOGY_REPORT.md and a recovery task DAG that explains what should happen next.

Best for

Recovering stalled projects without guessing from the latest failed task alone.