Workflow
Idea to shipped
Here's the whole loop, from a message I send to a change I approve. It's the same loop on every project, because every agent runs the same shared skills.
Robert
An idea
It starts with me. A bug I hit, a feature I want, a page that needs a rewrite. I write it the way I'd say it out loud.
Output A message in chat
Grok Bot · Wes
Grok Bot routes it
Grok Bot picks up the message and Wes scopes it: what's in, what's out, which repo, and which agent owns it. Big ideas get split into tickets first.
Output A scoped brief or a set of tickets
Fleet skills
The agent loads the shared skills
Before writing anything, the agent pulls the same playbooks every other project uses: how to triage, how to test, how to write the PR. That's why the work looks consistent across repos.
Output The same process on every project
Cody · Archie · Penny · Bugsy
An agent builds it in Cursor
A Cursor cloud agent works on its own branch. Archie shapes it, Cody writes it, Bugsy breaks it, and Penny makes it look right. Lint, typecheck, and build have to pass before anything else happens.
Output A branch with passing checks
Cody · Otto
PR + Vercel preview
The agent opens a pull request with a plain-English description. Vercel builds a preview URL for that branch, so I review the real thing, not a screenshot.
Output A pull request and a preview link
Robert
I approve it
Nothing merges, deploys to production, or shows up in the public Ship Log until I say so. The agents do the work and I make the call.
Output A merge, a deploy, and an approved log entry
The layer that makes it repeatable
Shared fleet skills
Every agent pulls from the same library of skills: written playbooks for how we triage a bug, write a spec, test a fix, review a PR, and ship a preview. The playbooks travel with the agent, so the mobile apps, the web platforms, client work, and this site all get the same process instead of one-off prompts.
- One playbook, many repos. When a playbook improves, every project gets the improvement on its next run.
- Agents follow the playbook, not their mood. The same request gets handled the same way on Tuesday and on Saturday.
- Each repo carries its own context file, and the shared skills read it. The process stays the same while each project keeps its own details.
- The process has guardrails: tests before fixes, previews before merges, and my approval before anything goes public.
The kinds of playbooks the fleet shares
- Triage
- Specs & tickets
- Test-first fixes
- Code review
- Design polish
- Preview & deploy
The playbooks themselves are private. This page describes the pattern, not the prompts.
The fleet
Who does what
Coordinator
Wes Wright
Turns a loose idea into a scoped brief, splits it into tickets, and keeps the rest of the fleet pointed the same way.
Linear · Notion · GitHub · Gmail · Google Calendar
Architecture
Archie Tekton
Picks the shape before anyone writes code: data model, routes, what lives on the server, and what can break.
GitHub · Supabase · Notion
Engineering
Cody Shipley
Writes the code, runs lint, typecheck, and build, and opens the pull request with a real description.
GitHub · Vercel · Supabase
Design
Penny Pixel
Owns the look. Takes a working first pass and polishes type, spacing, motion, and the brand details.
Figma · GitHub · Vercel
QA
Bugsy Checkett
Reproduces the bug, writes the failing test first, and checks the preview before anything gets approved.
GitHub · Vercel · Linear
Deploys
Otto Deploy
Runs the Vercel side: projects, env vars, previews, and, only with my go-ahead, production.
Vercel · GitHub · Supabase