agent-first
Your AI agent needs a map, not a guess.
As AI coding assistants take on more execution work, the question becomes: does your repository give them a clear operating model — or do they guess? Plumego's control plane gives agents the same routing signals a senior reviewer uses.
the control plane
Five files that define the operating model.
Agents read these files — in order — before making any change. The same files serve as the authoritative reference for human reviewers. One model, two audiences.
specs/task-routing.yaml Task router Maps every work intent (add middleware, change extension behavior, update boundary rules) to an owning module path and a start_with file list. An agent reads this before touching any Go file.
task: "add rate limiting" → module: middleware/ → read: middleware/module.yaml specs/dependency-rules.yaml Boundary enforcer Declares which packages may import which. Violations are caught mechanically by go run ./internal/checks/dependency-rules — not by reviewer memory.
stable roots cannot import x/* — enforced in CI specs/change-recipes/ Change templates 15 reusable recipes for standard task shapes: add-middleware, new-extension-family, promote-to-beta, and more. Each recipe has ordered steps and explicit stop conditions.
15 recipes covering every common change type <module>/module.yaml Module scope Each module declares its own ownership, risk level, test commands, and review checklist. Agents run only the checks relevant to the touched module.
validation: go test -race ./middleware/... && go vet ./middleware/... make gates CI-equivalent loop One command that mirrors CI: boundary checks, go vet, gofmt, race tests, and normal tests. Agents run this before every push — no surprises in CI.
make gates → boundary + vet + fmt + race + tests agent execution model
How a change flows through the control plane.
This is the ordered workflow every agent (and every contributor) follows. Each step has a deterministic output before moving to the next.
Read task-routing.yaml
Before opening any Go file, an agent reads specs/task-routing.yaml to find the owning module for the task type. This prevents misrouted changes before they happen.
Read module.yaml
The target module's module.yaml declares scope, risk, in-scope paths, out-of-scope paths, and the exact validation commands to run. The agent now has a bounded operating context.
Make the change
The agent edits only the files within the declared module scope. Boundary rules are machine-readable, so it knows which imports are allowed without reading every package.
Run make gates
One command runs the CI-equivalent validation loop locally. Boundary checks, vet, format check, race tests. Same result as CI — no surprises on push.
Agent-ready
Built for the way modern teams work.
This section is about AI coding assistants — Copilot, Claude, Cursor — tools that write or review code. It is not about building AI agent services; for that, see x/ai.
As AI coding assistants take on more execution work, the question shifts: does your repository give them a clear operating model — or do they guess? Plumego's control plane gives agents the same routing signals a senior reviewer uses.
specs/task-routing.yaml task routing Maps work types to owning modules. An agent reads this before writing a single line.
specs/dependency-rules.yaml boundary enforcement Import violations are caught by a machine, not by reviewer memory.
<module>/module.yaml per-module scope Each module declares its own checks. Agents run only what is relevant.
Try a scenario — see where it routes
middleware middleware/ Read the full agent workflow spec.
The concept doc covers every stop condition, the full AGENTS.md authority order, context budget rules, and the complete list of change recipes.