Development process

The subagent pipeline

A change moves through six roles, in order, before it merges:

• Visionary / qa-strategist (research mode) — proposes product direction and feature bets grounded in QA-tooling practice, before anything is scoped.
• Product-manager — turns a rough ask into a scoped written spec with user stories and acceptance criteria.
• Graphic-designer — produces a design spec for UI changes that need a deliberate visual pass.
• Coder — implements one scoped change per invocation, against repo conventions.
• Code-reviewer — read-only review of a diff for correctness and security bugs, and drift from repo conventions.
• Qa-strategist (release-gate mode) — an independent go/no-go call. Reruns tests and typecheck, verifies against the spec and acceptance criteria, and holds release-gate authority over the code-reviewer's findings.

A named team, not just role labels

Each subagent that produces human-facing updates — Slack standup posts, email digests, demo notes — signs under a first-name alias instead of its technical role name, so status reads like it came from a person on a team rather than a tool label. The alias is presentation only: Jira comment attribution and the subagent's technical name stay unchanged underneath, so the audit trail always points at the actual role.

• Mark — the visionary subagent (product direction, feature bets), running on Sonnet.
• Judy — the product-manager subagent (specs, acceptance criteria), running on Sonnet.
• Josh — the coder subagent (implementation, on dev/build tasks), running on Opus.
• Joe — the qa-strategist subagent, in its release-gate mode (go/no-go on QA), running on Sonnet.

The graphic-designer and code-reviewer subagents don't carry a human-facing alias — their Jira and pipeline attribution is their technical role name. Both also run on Sonnet.

Model assignment is per subagent, not uniform across the pipeline — Josh (coder) is the only role currently running on Opus; the rest run on Sonnet.

Tool integration

Subagents call MCP tools as part of the pipeline — for example, posting comments to Jira — and post human-facing status updates to Slack, Jira, and email under defined attribution conventions.

Milestone-driven delivery

The build order is explicit and documented in the project's VISION.md and README.md. Each architectural layer is proven before the next one starts: API and database first, then the worker and queue, then Codex integration, then Playwright validation, then GitHub PR automation. I don't build the full pipeline at once.