Table of Contents
Overview
If you’ve built software with an AI coding tool like Claude Code, you know the drill: code comes out fast, and then you run into a different kind of wall. That’s why I built SDD Plugin — to develop with AI in a more disciplined way. It’s a Claude Code plugin built around GitHub Issues that enforces four stages — analysis → design → implementation → testing — to catch problems like coding without analysis, implementing without a design, or losing context along the way.
But after using it in real work for a while, I kept running into a problem one level up. The output (code) keeps piling up, but the tool that produces that code never actually gets better on its own. This post lays out what that problem looked like, and how I tried to solve it by borrowing an idea from the way people work together — an organization. (The tool that came out of this is Guild Plugin, which this series introduces.)
You can find Guild Plugin’s source code and installation instructions in the dev-yakuza/deku-claude-plugins repository.
This post is Part 1 of the Guild Plugin series. The series continues as follows.
- Part 1. Growing an Organization, Not Just a Skill (this post)
- Part 2. How the Agent Organization Is Structured, and Its Development Flow
- Part 3. Growth Engines ①② — Co-Evolution of Output and Developer
- Part 4. Growth Engine ③ + Safety — The Overseer (Human) Grows Too
The background behind SDD Plugin is covered in The Traps of AI Coding and How to Escape Them, and its full structure is covered in SDD Plugin’s Full Structure and Usage.
What SDD Plugin Gave Me
SDD Plugin turned the classic traps of AI coding into things a process could prevent.
- Coding without analysis → requirements are analyzed first, acceptance criteria (AC) are set, and only then does implementation begin.
- Implementation without design → a skeleton (design) is laid out first, and a tester writes test cases before ever seeing the implementation.
- Lost context → state is written to the GitHub Issue/PR, so work can resume even after a session drops.
Thanks to that, “this task” could proceed in a much more disciplined way. But there was a hidden assumption baked into all of it: the process and the skills themselves still had to be built well in advance, by a human.
The Problem of a Tool That Doesn’t Grow
The more I iterated on development with AI, the more I kept running into the same scenes.
- The same mistakes repeat across projects, across issues. (For example: I’d say “don’t hardcode this value, pull it from the shared config,” and next time it would hardcode it again.)
- Even after a correction, it’s forgotten by the next session. The conversation is gone, and the skill file is unchanged.
- A project’s conventions and pitfalls have to be explained all over again, every single time.
- To improve a skill, in the end a human has to manually rewrite the prompts and instructions.
Here’s the short version: SDD Plugin makes sure “this task” goes well, but making sure “the next task” goes better was still entirely on the human. Output piles up every day, but the tool that produces that output doesn’t grow on its own. Every bit of improvement is tied to manual human labor.
Why is this a fundamental problem? The longer you spend developing alongside AI, the more the tool itself should improve along with that experience. Otherwise, we end up repeating the same onboarding, the same corrections, the same explanations, over and over. If the tool stays static, nothing accumulates.
How People Keep Getting Better
So I changed the question. Instead of “how do I manage skills better?”, I asked: “how do people keep getting better?”
To find an answer, I looked at software development organizations. Here’s what they had in common.
- Division of labor and specialists — roles like architect, tester, reviewer, and security lead are split apart, and each is called in when needed.
- Onboarding new hires — when someone new joins, project knowledge is passed on so they can ramp up quickly.
- Code review — someone other than the author gives an independent second opinion.
- Retrospectives — looking back at what went well and what went wrong, and feeding that back into what comes next.
- HR — people who perform well grow, people whose role isn’t a good fit get reassigned, and when a new role is needed, someone new is hired.
- Knowledge sharing and documentation — even as people come and go, knowledge is preserved through documents or handoffs. In other words, the organization’s knowledge outlives any individual member.
The core idea is this: an organization is a structure that improves itself through the traces its work leaves behind, and retains knowledge even as its members change. A good team produces good output, and the traces of that output feed back into making the team better.
“Shouldn’t a tool work the same way?” — that question was the starting point for building Guild Plugin.
Guild Plugin Is a Repo-Specific Agent Organization
Guild Plugin is a Claude Code plugin that builds a dedicated agent organization for each repository.
Running /gld init analyzes the repo and creates a dedicated guild (organization) for it. A Leader — the guild master — is created, along with role agents including an architect, developers, testers, and QA. This organization then carries out the development flow (analysis → design → implementation → testing → QA) collaboratively.
But it doesn’t stop there. Guild reads the traces left behind during development — human corrections, reverts, recurring friction — and uses them to let the organization grow on its own. Corrections that keep coming up become habits baked into a role, facts discovered about the code become the organization’s knowledge, and rules that tests can’t catch get promoted into gates.
If SDD Plugin was the “development flow,” Guild is the “organization that grows itself while carrying out that flow.” Guild picks up where SDD Plugin’s problem statement left off, and generalizes it one level further.
What Grows Together
The most important principle in Guild is “what grows together.” Guild grows three things together (co-evolution).
- ① Output — the quality of the codebase (what the development flow produces)
- ② Developer — the agent organization itself (role habits, organizational knowledge, rules)
- ③ Overseer — the human using Guild Plugin
Most tools only improve ① (the output). Guild grows all three in a single loop. A good team produces good output (①↔②), and the human overseeing that process also learns the “why” behind it, growing alongside it (③).
This growth engine is the heart of Guild Plugin. Parts 3 and 4 of this series dig into exactly how traces get distilled into habits, knowledge, and rules (②), and how the human (③) grows right along with it.
Wrapping Up
SDD Plugin brought discipline to “this task,” but it left one limitation standing: the tool itself never grew. Every improvement stayed tied to manual human labor.
Guild solved this by borrowing an idea from how people work together — an organization. A repo-specific agent organization carries out the development, and the traces it leaves behind let the output, the developer, and the overseer grow together.
In Part 2, we’ll look at how this organization is actually put together — the Leader and role roster, the collaboration protocol, and the development flow.
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.
