I Built a Virtual Dev Team in My Terminal with Claude Code

You know that moment when you have a vague idea for a feature — "I need a subscription billing system for my SaaS app" — and you're sitting in front of your terminal, somewhere between excitement and overwhelm? You need to figure out the requirements, design the architecture, write the code, test it, and commit it cleanly. Oh, and if it involves AWS, you'll be switching between your terminal and a browser full of AWS documentation tabs.

What if your terminal could handle all of that?

That's the question that led me to build CM Stack Plugin — a hobby project that gives Claude Code a structured development workflow and direct access to AWS knowledge. It's two plugins, MIT licensed, and it runs entirely on markdown files. No npm, no pip, no build step.

Let me walk you through what it does and why I built it.

The Problem I Wanted to Solve

If you've used Claude Code, you know it's remarkably capable. You describe what you want, and it generates code. But here's the thing: the output is only as structured as your input. Ask a vague question, get a vague answer. Skip the design phase, and you'll refactor later. Forget to think about edge cases, and they'll bite you in production.

In my day job and side projects, I kept running into the same pattern:

• No structured process. I'd jump straight from "I need X" to writing code, skipping requirements analysis and design. Sometimes that worked. Often it didn't.
• Playing every role. In a side project, you're the business analyst, the architect, the engineer, and the QA reviewer. That's exhausting and error-prone. You don't catch your own blind spots.
• AWS context-switching. When working on AWS projects, I'd constantly break flow to look up documentation, check service availability in a region, or find the right SOP for an operational task. Tab after tab after tab.

The insight came when I realized that Claude Code has an Agent tool — it can spawn specialized subagents, each with its own system prompt, running in parallel. What if each agent played a specific team role? What if one agent thought like a business analyst, another like a technical architect, and so on?

That's exactly what CM Stack does.

How It Works

Before diving into features, I want to highlight something I find genuinely interesting about this project: the entire plugin system is just markdown files.

Every agent is a markdown file with YAML frontmatter:

---
name: business-analyst
description: "Use this agent when the user needs to analyze business requirements,
  create Product Requirement Documents (PRDs), translate user needs into structured
  specifications, or define feature scope and acceptance criteria."
model: opus
color: blue
---

You are a Senior Business Analyst with 15+ years of experience in requirements
engineering, stakeholder management, and product documentation...

Every skill is also a markdown file with workflow instructions, Mermaid diagrams, and step-by-step processes. The plugin manifest is a simple JSON file:

{
  "name": "cm-stack-workflows",
  "version": "0.1.5",
  "description": "A structured development team plugin for Claude Code...",
  "author": { "name": "Tien Le H." },
  "license": "MIT"
}

There's no JavaScript runtime, no Python interpreter, no compilation step. The "code" is natural language instructions that Claude Code interprets. When the runtime already understands natural language, you don't need a framework — you need well-written instructions.

This makes the plugin incredibly portable. Install it by pointing Claude Code at a directory. That's it.

The Workflow Plugin — A Virtual Dev Team in Your Terminal

The centerpiece of CM Stack is cm-stack-workflows, a plugin that provides four specialized AI agents and eight workflow skills covering the full software development lifecycle.

The Four Agents

Think of them as team members with distinct personalities:

• Business Analyst — The one who asks the right questions. Transforms vague ideas into structured Product Requirement Documents using techniques like 5 Whys, MoSCoW prioritization, and user story mapping.
• Technical Lead / Architect — The systems thinker. Designs architecture, defines component boundaries, plans API contracts, and documents decisions in Architecture Decision Record format.
• Senior Engineer — The implementer. Writes clean, production-ready code that adapts to your project's language, framework, and conventions. Handles database design, query optimization, and comprehensive testing.
• QA Engineer — The last line of defense. Performs line-by-line code review, designs test strategies, catches security vulnerabilities, and validates that implementation matches requirements.

The Pipeline

Here's what the full workflow looks like:

                              Vague idea? ──▶ BRAINSTORM ──▶ lead_XXX.md ──┐
                                                                           │
 ┌──────────┐     ┌───────────┐     ┌──────────┐     ┌──────────┐     ┌────▼────┐
 │ ANALYZE  │────▶│  DESIGN   │────▶│   PLAN   │────▶│   TASK   │────▶│  COMMIT │
 │          │     │           │     │          │     │          │     │         │
 │ PRD      │     │ System    │     │ Impl.    │     │ Code +   │     │ Clean   │
 │ Document │     │ Design    │     │ Plan     │     │ Review   │     │ Commits │
 └──────────┘     └───────────┘     └──────────┘     └──────────┘     └─────────┘
       ▲
       │       ┌─────────────────────────────────────────────────────────────┐
       └───────│ Well-defined, small scope? ──▶ FAST-TRACK ──▶ Code (skip)   │
               └─────────────────────────────────────────────────────────────┘

Let me highlight two moments that make this different from just "asking Claude to code."

Brainstorm: When You Don't Even Know What You Want

Say you type: "I'm thinking about adding SSO to our app."

The brainstorm skill spawns two agents in parallel — a Business Analyst and a Technical Lead. The BA asks about identity providers, user types, and compliance requirements. The Tech Lead asks about session management, token formats, and integration points. Their questions are synthesized, and after you answer them, a clear lead document is produced at docs/leads/lead_XXX.md.

You went from a vague thought to structured requirements without playing 20 questions with yourself.

Design: Four Architects, Four Perspectives

The design skill does something I find genuinely powerful. Given a PRD, it spawns four Technical Lead agents simultaneously, each researching a different architectural concern:

Why parallel? Because different perspectives produce richer output than one person working linearly. The security architect catches things the data model architect wouldn't think about. The API specialist flags concerns the component architect missed. All findings get synthesized into a single design document.

The Triple Review Gate

When it's time to implement tasks from a plan, the task skill spawns Senior Engineer agents to write the code. But here's the part that feels like a real team: before any task is marked complete, it must pass three independent reviews:

1. Business Analyst — Does this actually solve the problem? Are the acceptance criteria met?
2. Technical Lead — Is the architecture sound? Any security concerns? Code quality up to standard?
3. QA Engineer — Bugs? Edge cases? Test coverage? Security vulnerabilities?

If any reviewer flags issues, the implementation is revised and re-reviewed. Only when all three pass does the task get marked complete.

A Walkthrough: From Idea to Commit

Here's what the full flow looks like in practice:

You:    "I need a subscription billing system for my SaaS app"
        ↓
        (analyze → spawns business-analyst + tech lead in parallel)

Output: docs/requirements/prd_001.md

You:    "Create a system design from docs/requirements/prd_001.md"
        ↓
        (design → spawns 4 tech lead agents in parallel)

Output: docs/designs/design_001.md

You:    "Create an implementation plan from docs/designs/design_001.md"
        ↓
        (plan → spawns tech lead + business analyst)

Output: docs/plans/plan_001.md

You:    "Execute tasks from docs/plans/plan_001.md"
        ↓
        (task → spawns senior engineers → triple review gate)

Output: Implementation + updated plan with completed tasks

You:    "Commit the changes"
        ↓ 
        (git-commit)

Output: Clean git commit(s)

Fast-Track: When You Know What You Want

Not everything needs the full pipeline. If the scope is small and clear — "Add a rate limiter to the API, max 100 req/min per IP" — the fast-track skill skips all documentation. It spawns a Senior Engineer to implement directly, followed by a lightweight QA review. Two agents, no paperwork, fast delivery.

The AWS Knowledge Plugin — Cloud Expertise On Demand

The second plugin, cm-stack-aws-knowledge, takes a different approach to a different problem. It wraps the AWS Knowledge MCP server using direct HTTP calls via curl — no MCP client configuration required.

Seven skills give you AWS expertise without leaving your terminal:

Cloud Migration from the Terminal

Here's a practical scenario. You're planning a cloud migration and need to make infrastructure decisions:

# Search for documentation
"Search AWS docs for Lambda best practices"

# Check if a service is available in your target region
"Is AWS Lambda available in ap-southeast-5?"

# Get step-by-step migration guidance
"I need step-by-step guidance to deploy a Lambda function with API Gateway"

# Do comprehensive research with sources
"Research AWS VPC peering best practices"

The aws-research skill is the powerhouse here. It chains search and read operations, synthesizes the findings, and presents them with source citations — all in one call. No opening 15 browser tabs, no losing context, no breaking flow.

Why Direct HTTP Matters

Most MCP-based tools require you to configure an MCP client, manage server processes, and handle authentication. The AWS Knowledge Plugin bypasses all of that. It calls the AWS Knowledge MCP server's JSON-RPC 2.0 API directly via curl. Zero setup, immediate utility.

What I Learned Building This

A few reflections from building this as a side project:

Markdown is a surprisingly powerful plugin format. When the runtime (Claude Code) already understands natural language, you don't need a programming language for your plugin system. Well-structured text instructions with YAML metadata are enough. The "code" is the clarity of your writing.

Parallel agent execution changes the design space. Traditional software decomposes problems into sequential steps. With parallel agents, you can decompose by perspective instead. Four architects looking at the same system from different angles produce richer output than one architect working through a checklist. That's a different paradigm.

The review gate pattern has legs. Multi-perspective validation before completion — business logic, architecture, quality — is something that translates beyond this project. It mirrors how real teams operate, and it catches issues that any single reviewer would miss.

Honest trade-offs. All agents use Opus, which is the most capable but also the most expensive model. The system depends on Claude Code's Agent tool. And at v0.1.x, this is early-stage software with rough edges. I'm not pretending otherwise.

Why open-source. The Claude Code plugin ecosystem is still nascent. By sharing the patterns I've discovered — multi-agent orchestration, markdown-as-code, parallel review gates — I hope others can build on them. MIT license, fork it, take what's useful.

Getting Started

If you want to try CM Stack Plugin, there are three ways to install it:

Option 1: From the marketplace

/plugin marketplace add cmdn-tienle/cm-stack-plugin
/plugin install cm-stack-workflows@cm-stack-plugin

Option 2: Per-session (try it once)

claude --plugin-dir /path/to/cm-stack-plugin/plugins/cm-stack-workflows

Option 3: Project-level (persistent)
Add to your project's .claude/plugins.json:

{
  "plugins": [
    { "path": "/path/to/cm-stack-plugin/plugins/cm-stack-workflows" }
  ]
}

To install the AWS Knowledge Plugin, just replace cm-stack-workflows with cm-stack-aws-knowledge in any of the above.

Quick start: The fastest path to value is the fast-track skill. Give it a clear, small-scope requirement and watch it implement with a QA review.

The source code is at github.com/cmdn-tienle/cm-stack-plugin — MIT licensed, contributions welcome.

Closing

CM Stack Plugin started as a way to bring structure to my own development workflow. Along the way, it became something more: a demonstration that multi-agent orchestration, structured workflows, and cloud expertise can all be delivered as pure markdown files running in a terminal.

The core idea is simple — give AI the same structure that makes human development teams effective. Specialized roles. Parallel work streams. Multi-perspective review. Clear handoffs between phases.

If you're using Claude Code, give it a try. If you're building plugins for AI tools, take inspiration from the patterns. And if you have ideas for improving it, I'd love to hear them.

The project is young, the ecosystem is growing, and there's a lot of interesting territory to explore. That's what makes side projects fun.

CM Stack Plugin is open-source under the MIT license. You can find it at github.com/cmdn-tienle/cm-stack-plugin.