An AI engineering team that works from your GitHub issues.
Six specialised Claude Code agents, the GitHub-issue workflow that coordinates them, the standards they follow, and the hooks that enforce them. Installed once as a plugin; every repository gets the same team.
AI agent team
The idea
Agents do the steps. People make the calls.
Autocomplete is not a workflow. The gain from AI shows up when the mechanical work moves off the people and onto agents: claiming an issue, implementing it, running the tests, answering review comments. The decisions stay with the people. This is the team I built to do that, and it builds my own products.
It is a Claude Code plugin: six agents with one job each, four commands I run, the standards every agent carries, and three hooks that enforce those standards on every file an agent writes. Install it once and every repository on the machine gets the same team.
GitHub issues are the handoff. Each agent reads the issue, does one step, posts a short comment (what it did, what it decided, what is open, what comes next) and moves the label. Nothing is approved by an agent.
The team
Six agents, one job each
UX
OpusDesigns each feature in Figma from the issue and the repo's component registry, then posts the frames for approval. Never edits a file.
Frontend
SonnetBuilds the approved frames on the approved contract, in the project's frontend architecture, and opens the pull request.
Backend
SonnetContract mode writes the schema, API shapes and auth rules as a draft PR. Build mode implements the approved contract with tests.
Reviewer
OpusReviews every diff against the issue, the frames, the contract and the standards. Read-only: it reports, it changes nothing.
Test runner
HaikuRuns unit tests, lint and type checks for a package or the whole repo and returns only the failures.
E2E runner
HaikuRuns Playwright locally or against a Vercel preview deployment and returns only the failures.
The flow
From issue to merged pull request
Issue
A feature becomes an epic and child issues in one format every agent reads.
Design & contract
The UX agent posts Figma frames; the backend agent opens the API contract as a draft PR.
Your approval
Nothing is built until you approve the frames and the contract.
Build
Backend implements the contract with tests; frontend builds the frames on it; the PR opens.
Review & e2e
The reviewer checks the diff against spec, frames, contract and standards; e2e runs against the preview.
You merge
The last gate is a person.
Highlighted steps are yours. Agents move the labels; they never approve.
Your commands
Four commands you run
/plan-feature- Interviews you about an idea, explores the repo, proposes an epic and child issues, and creates them on your yes.
/refine-issue- Turns a thin issue, the kind typed on a phone, into the full format every agent reads.
/work-issue- Does whatever step comes next on an issue, from its labels, and stops at your gates.
/status- What is waiting on you, what is ready for an agent, what is blocked or stale, and epic progress.
Guardrails
Standards enforced, not suggested
Lint configs are off limits
A hook blocks any agent edit to ESLint, Stylelint or Prettier configuration. Rule changes go through a person, in one standards repo, not through an agent working around a failure.
Every file is linted as it is written
A hook lints each file the moment an agent writes it and hands the errors straight back, so the standards are enforced before review rather than during it.
Model routing
Judgment calls run on the heaviest model, building on a mid-weight one, test and lint runs on the lightest. A hook trims long test logs to the failures so spend goes to the work, not to reading output.
Standards travel as skills
Coding standards, frontend standards, backend architecture and the issue format are skills the agents carry, so every repository is held to the same rules.
Memory that survives the session
Each agent keeps its own memory across repositories. A correction given once is applied next time without being asked, and lessons that hold are promoted into the agent prompt.
A second opinion on every PR
An independent reviewer challenges each change so one model's blind spots are caught by another. People review design and correctness, and nothing merges without a person.
Where it runs
Laptop, cloud, and on a schedule
The team runs on a laptop, in Claude Code cloud sessions, and on a schedule. A script vendors the agents, skills and hooks into a repository so cloud sessions, which load nothing from your machine, carry the same team.
Routines pick up labelled issues on the hour, review every opened pull request against its preview deployment, and run the full end-to-end suite nightly, posting only failures.
As a service
Built for you, around your tools
This is the shape of the AI-Native Workflow Setup engagement. I design the team around your repository, your review process and the models and tools you have access to, install it, and train the people who will run it. The pieces stay the same: agents with one job each, an issue flow with human gates, standards enforced by hooks, and cross-model review so one model's blind spots are caught by another.
Want a team like this in your repos?
I design it around your repository, review process and tools, install it, and train the people who will run it. A short call is the quickest way to find out what that would look like for you.