Table of Contents
Overview
When we develop with AI, we typically hand everything — analysis, implementation, testing — to a single prompt or a single agent. That’s fine for small tasks, but the moment the scope grows, having one entity do everything quickly hits a wall.
Guild Plugin takes a different approach. It’s a Claude Code plugin that builds a dedicated, role-divided agent organization for each repo, and has that organization carry out the development flow collaboratively. This post looks at how that organization is structured and how development actually flows through it.
You can find Guild Plugin’s source code and installation instructions in the dev-yakuza/deku-claude-plugins repository.
This post is Part 2 of the Guild Plugin series.
- Part 1. Growing an Organization, Not a Skill — why I built this
- Part 2. The Structure of an Agent Organization and Its Development Flow (this post)
- Part 3. The Growth Engine ①② — Co-evolution of Output and Developer
- Part 4. The Growth Engine ③ + Safety — The Overseer (Human) Grows Too
Why an Organization Instead of One Agent
Asking a single agent to handle analysis, design, implementation, testing, and review all by itself creates three problems.
- Context overload — All the context (requirements, design, code, tests) piles into one conversation and gradually blurs together.
- The self-review trap — When you review your own code, you fall into confirmation bias. Even humans are bad at spotting bugs in their own code.
- Diluted expertise — It’s hard for a single persona to simultaneously hold different vantage points like security, accessibility, and performance.
Human organizations solve this with division of labor and independent review. They separate the person who builds from the person who reviews, and call in a specialist when needed. Guild Plugin does the same — it divides roles and separates the role that builds from the role that reviews.
Members of the Guild
Running /gld init analyzes the repo and stands up a dedicated guild (organization) for it. The members fall into two broad groups.
The Leader (Guildmaster)
The leader isn’t a separate agent — the main session itself takes on this role. For each task, it assembles the team needed, delegates work to each role, mediates when results conflict, and judges whether the work is done. In other words, it’s the orchestrator.
The Role Roster (16 roles)
During init, the repo’s stack, conventions, and risk points are analyzed, and the roles are specialized to fit that specific repo.
- Core roles that always participate — Leader, Tech Lead, Developer, Tester, QA
- Specialists summoned only when needed — Product Owner, Designer, Security, i18n, DBA, Performance, Analytics, Infrastructure, Tech Writer, Release Manager, Support Triage
The key point is that not everyone gets called in. A small change gets the minimum crew; touching the UI brings in the Designer; touching auth or external exposure brings in Security — the leader looks at the surface area and risk of the change and summons accordingly, each time. In effect, the size of the organization scales to the size of the task.
How the Roles Collaborate
The roles operate under a set of collaboration rules (a protocol), much like a team of people would. A few of these disciplines matter especially for preventing bias.
- Skeleton first — The Tech Lead lays out the design’s skeleton (module boundaries, extension points) first, and the Developer implements on top of it.
- Tests first, without bias — The Tester writes test cases based solely on the acceptance criteria (AC), without looking at the Developer’s implementation. This produces tests that hold to the requirements, not tests bent to match the implementation.
- No self-review — No role signs off on its own output. Another role handles the fitness check and review, structurally blocking confirmation bias.
- Handoffs via files, not conversation — Output between roles is passed as files rather than through conversation. This keeps large code diffs from flooding the main conversation — saving context — and means the output survives even if a session gets cut off.
In short, this takes the organizational common sense of “the builder and the reviewer are different people” and encodes it as a contract between agents.
The Development Flow
Development flows along a fixed spine. This sequence never changes.
Analyze → Design → Execute → Test → QA
- Analyze — Clarify what’s being built and why, and establish verifiable acceptance criteria (AC).
- Design — Lay out the skeleton of how it will be built. At the same time, the Tester writes test cases (without seeing the implementation).
- Execute — The actual implementation. This automatically branches into feature implementation, bug fix, or refactoring depending on the type of work.
- Test — Automated correctness verification. Claiming a pass requires actual execution results (raw logs), not just a claim.
- QA — Quality from a human perspective. This covers exploratory and user-flow checks that automated tests can’t catch, and surfaces items that specifically need a human to confirm.
So where does progress state live? In labels on the GitHub issue and PR. Because how far a task has progressed is recorded as a label, even if a session gets cut off, you can pick up exactly where it left off just by reading the label. (This state-management approach is inherited from SDD Plugin.)
Commands That Drive Guild
In practice, a handful of commands are what summon this organization. Here are the main ones.
/gld init— Analyzes the repo and sets up the harness, the guild, and standard docs. (Once per repo)/gld plan <doc|issue>— Breaks down a design document (file) or a large epic issue into development-sized issues. This is the role that turns a project spec into a backlog./gld dev <issue>— Develops a single issue through the entire spine flow. (The one you’ll use most often)/gld review <issue|PR>— A guided review where you walk through a PR one logical unit at a time, together with a human./gld audit,/gld evolve— Commands that diagnose and grow the organization. These two are the stars of the next posts.
To sum up: init stands up the organization → plan breaks work into issues → dev develops them → review checks them together.
How Is This Different from SDD Plugin
SDD Plugin, which I built earlier, is a Claude Code plugin that runs GitHub Issues through an analyze → design → implement → test flow. That might raise a question: “Isn’t Guild Plugin, in the end, just another staged-flow development approach?”
The biggest difference is who leads the staged flow.
- SDD Plugin — A human directly leads the 4-stage flow. The flow is fixed, and the skills that carry it out are managed by the human.
- Guild Plugin — The flow is carried out by an agent organization. Roles collaborate, the leader assembles the team, and even building the backlog via
planbecomes the organization’s own job. And — the subject of the next posts — that organization grows on its own.
In one sentence: if SDD Plugin is “a process,” Guild Plugin is “a growing team that carries out that process.” Guild Plugin inherits SDD Plugin’s core concern and generalizes it one level further.
Wrapping Up
To sum up, here’s what Guild Plugin looks like:
- The Leader assembles a team for each task,
- Only the necessary specialists are summoned from a team of role agents specialized to the repo,
- Under a collaboration protocol (skeleton first, tests first, no self-review),
- They carry out the spine flow (Analyze → Design → Execute → Test → QA),
- And progress state lives on GitHub, so work can be resumed at any time.
So far, this has been about “how development gets done.” But the real core of Guild Plugin is how this organization grows on its own, beyond just the development flow. In Part 3, we’ll dig into that growth engine in earnest — the co-evolution where the output and the developer (the organization itself) grow together.
Guild Plugin is available on the deku-claude-plugins marketplace.
Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!
App promotion
Deku.Deku created the applications with Flutter.If you have interested, please try to download them for free.
