A frustrated prompt to Claude turned into a 7-agent plugin system that automates my most of the tasks
I build things on DevRev for a living — snap-ins, AirSync connectors, dashboards, widgets. If you've ever built on a platform like this, you know the pattern: every new connector follows the same steps. Every dashboard has the same JSON boilerplate. Every time, you're making the same 15 engineering decisions you already made for the last project.
I got tired of it. So I opened Claude and typed:
"I want to build a plugin for my client DevRev. Right now there's a lot of manual work — creating agents, dashboards, connectors. I want to give a plugin complete context of what we do, and it should behave as a DevRev architect and give a solution."
That was the start. I had no idea it would turn into 6,000+ lines of agent instructions with 7 specialized AI agents. Here's how it happened.
The problem: every connector is the same (but also different)
Building an AirSync connector always goes through the same cycle:
- PM phase: Gather requirements, write a PRD, write a TDD, get approval.
- Architect phase: Research the external API, figure out auth, pagination, rate limits, data mapping — then generate TypeScript, manifests, and deployment scripts.
- Test phase: Unit tests, deploy to a test org, run the import, verify every field.
Each phase involves dozens of decisions but none of that knowledge was reusable. It lived in people's heads and old PRs. I wanted agents that knew all the patterns.
How I built them
The PM agent — I studied patterns across our past projects and wrote detailed reference templates: discovery questions by snap-in type, PRD sections covering object mapping and permissions, TDD sections covering sequence diagrams and data mapping. The agent now asks focused questions in rounds, classifies snap-in type, and produces both a PRD and TDD before anything gets built. Key insight: don't say "write a PRD" — give it the exact format your team expects.
The architect agent — This one taught me something important. The first version generated code that looked great but was wrong. It had manual timeout tracking when the real ADaaS SDK uses processTask({ task, onTimeout }) where the platform manages everything. I caught this by comparing against official docs. That mistake led me to build the self-learning agent.
The tester agent — Two modes: Jest unit tests first (fix code bugs cheap), then UI automation that drives the actual DevRev browser — install snap-in, configure connection, go through the mapping screen, run the sync, verify every field. The mapping screen is where 80% of bugs hide.
The dashboard vertical — Wasn't planned. A teammate found 6 metric bugs in a dashboard — wrong date aggregation, wrong ticket counts, wrong response definitions. All SQL expression problems. I realized: if an agent had the complete widget JSON reference, it could both create dashboards AND diagnose broken ones. Same PM → Architect → Tester pipeline, different domain knowledge.
The skill improver — The 7th agent. When any agent makes a mistake, you run /devrev:improve-skill. It traces the error to the exact reference file, produces a patch, asks for confirmation, and logs the learning. The agents get smarter every time someone finds an issue.
The architecture
Seven agents, two verticals, one self-learning loop — packaged as a Claude Code plugin:
Snap-in vertical: PM → Architect → Tester (connectors, automations)
Implementation vertical: PM → Architect → Tester (dashboards, widgets)
Cross-cutting: Skill Improver (patches any agent from real mistakes)
6,400+ lines of skill instructions. 7 slash commands. Bug feedback flows back upstream.
What I learned
- Be specific about format — define the exact sections and patterns your team uses, not generic templates.
- The agent will be wrong — plan for it. The self-learning agent is how the system improves.
- Separate the phases. One agent doing everything skips research and jumps to code. Handoffs force discipline.
- Reference files are the real product. The workflow is just glue. The SDK patterns, SQL rules, and visualization catalogs are where the knowledge lives.
- Test in the UI, not just in code. The mapping screen is where real bugs surface.
The approach is transferable: study your past projects → extract patterns → encode as agent skills → build a feedback loop. The tools are all available today.
Top comments (0)