This project-template turns software work into durable, observable, reviewable units. Agents do not free-roam the repo. They pick up tickets, produce artifacts, open pull requests, and leave enough state for a human or another agent to understand exactly what happened.
Human request, scheduled check, review finding, audit issue, or agent follow-up.
Everything becomes a clear, owned ticket.
Every agent can see the available specialist roles.
One specialist owns the slice, leaves a clear trail, and drives it to an artifact.
Assigned to Backend Builder
The agent works in isolation and opens a reviewable pull request.
Tests, security scan, model review, score bar, and review artifact.
Human inspects the pull request, artifacts, and blockers. Human owns merge to main.
Observed merge reality updates ticket status, pull request links, and follow-up state.
Build or review reveals another slice.
The slice gets an owner and clear scope.
It rejoins the same flow.
A ticket is the durable work object. It is simple enough to inspect in a Markdown file, but structured enough for routing, dashboards, agent runs, PR linkage, handoffs, and recovery.
Name, source, and stable place in the backlog.
The smallest useful slice: clear enough to finish, narrow enough to review.
Classifies the work and how quickly the factory should treat it.
Tracks whether work is ready, active, blocked, deferred, or done.
Exactly one agent lane owns the slice.
Links ordered work without making one ticket own the whole project.
Connects the ticket to the agent session that touched it.
Connects implementation output back to the control plane.
Review reports, request notes, logs, and follow-up evidence.
The factory does not depend on one generalist agent. It keeps a broad roster of narrow specialists, and tickets route to the role best shaped for that slice of work.
A ticket is not a vague backlog wish. It names one concrete slice and one agent responsible for moving that slice to a reviewable artifact. Related work becomes another ticket.
Add retry behavior and tests for failed webhook delivery.
Owns implementation and opens the pull request.
Fix a correctness finding from code review.
Owns the narrow fix and reruns the checks.
Capture a decision that should outlive the session.
Owns the write-up and links it back to the work.
Implementation happens away from the shared checkout. Agents work in isolated branches, open pull requests, and stop at the human gate: main and master merges are human-only.
Agent picks one owned ticket and leaves a clear run trail.
The change happens in an isolated branch checkout.
The output is reviewable, linked, and ready for gates.
Agents prepare the pull request. Humans decide when main or master changes.
Review has three layers: deterministic CI and tests, automated agent review, and human judgment before anything reaches main.
Agent reviewers run tests, inspect the change, score the result, and leave concrete findings.
Deterministic checks run before the human is asked to trust the change.
The human sees the ticket, pull request, automated verdict, findings, and unresolved risks.
Every agent knows every other agent.
The owning agent keeps the ticket, but collaborates with a specialist through a focused artifact.
When work reveals a different slice, the agent does not silently expand scope. It creates the next ticket.
Hyperspecific agents make hyperspecific evaluation possible. Each role can be judged against the work it is actually supposed to do, instead of one generic quality checklist for every task.
Tickets enter the factory from humans, agents, and scheduled maintenance. The source can vary; the control plane stays the same.
Direct product intent, bugs, design changes, or architecture needs.
Completed work often reveals the next slice for another specialist.
Recurring factory checks create work before humans have to notice.
Support notes, beta feedback, and usage friction become factory input.
Because each agent is hyperspecific, the trace can be hyperspecific too: model, tools, outputs, ticket movement, and evidence are all shaped around the role.
A builder log emphasizes files, tests, pull requests, and blockers.
Each agent exposes the commands and artifacts that make sense for its job.
The reviewer sees the exact trail needed to evaluate that type of work.
Agents run inside the repository, so the repo is the memory layer.
A blocked ticket that needs a human is a first-class citizen. The factory records the blocker, sends the request, waits cleanly, and resumes from the same ticket once the human decision is made.
The agent keeps the state, evidence, and exact ask attached to the ticket.
Production deploy needs approval. Review the linked run, diff, and test output.
Security finding needs a human decision before the agent can continue.
Approve, reject, answer, or redirect. The factory resumes without losing the trail.
Greenfield planning is intentionally open-ended. Use manual planning, a compound engineering stack, a design doc, or any other planning phase. The factory boundary is where the spec becomes owned tickets.
The upstream method can change by team, product, or project shape.
Convert intent into scoped, ordered, assignable slices.
Once work is ticketed, the same project-template loop takes over.