cdt
Scannednpx machina-cli add skill rube-de/cc-skills/cdt --openclawClaude Dev Team
Multi-agent development workflow with four modes. Pick one based on the user's needs:
| Mode | When to use |
|---|---|
| plan | Need architecture/design before coding |
| dev | Have an approved plan, ready to implement |
| full | End-to-end with user approval gate between plan and dev |
| auto | End-to-end without approval gate |
Before executing any mode, read references/plan-workflow.md and references/dev-workflow.md for detailed step-by-step instructions, spawn prompts, and output templates.
Architecture
Plan Phase (plan/full/auto) Dev Phase (dev/full/auto)
Lead (You) Lead (You)
├── architect [teammate] ├── developer [teammate]
├── prod-mgr [teammate] ├── code-tester [teammate]
└── researcher [subagent] ├── qa-tester [teammate]
├── reviewer [teammate]
└── researcher [subagent]
│ │
└──── plan.md (handoff) ─────────┘
Teammates message each other directly (Architect teammate↔PM teammate, Developer teammate↔Code-tester teammate, Developer teammate↔QA-tester teammate, Developer teammate↔Reviewer teammate). Researcher is a subagent — Lead relays results.
Roles
Researcher (subagent — spawn via Task without team_name)
Research specialist for doc lookups. Queries Context7 for library docs, searches web for best practices, returns structured findings with code examples. Bundled as agents/researcher.md in this plugin — Context7 MCP is auto-configured via .mcp.json.
Architect (teammate — spawn via Teammate tool, plan phase)
Discovers codebase structure using the Explore agent (preferred) or repomix-explorer (if available) for broad understanding, then targets specific files with Glob/Grep/Read for detailed inspection. Reads existing Architecture Decision Records (ADRs) from docs/adrs/ before designing. Designs architecture: components, interfaces, file changes, data flow, testing strategy. Writes new ADRs to docs/adrs/adr-NNNN-<slug>.md for each significant decision. References existing ADRs when relevant and supersedes old ones when decisions change. Debates tradeoffs with PM teammate. Messages design to lead and PM teammate. Writes the plan file as their final deliverable.
Product Manager (teammate — spawn via Teammate tool, plan phase)
Validates architecture against requirements. Challenges design with concerns. Produces verdict: APPROVED or NEEDS_REVISION with specifics.
Developer (teammate — spawn via Teammate tool, dev phase)
Implements tasks from plan. No stubs, no TODOs. Matches existing patterns. Iterates with code-tester teammate on failures, qa-tester teammate on QA issues, reviewer teammate on code quality. Updates project documentation (README.md, AGENTS.md, CLAUDE.md) to reflect implementation changes.
Code-Tester (teammate — spawn via Teammate tool, dev phase, always)
Unit/integration tests. Messages developer teammate with failures + root cause. Max 3 cycles.
QA-Tester (teammate — spawn via Teammate tool, dev phase, always)
Always spawned. Adapts testing approach based on task type: for UI tasks, writes Storybook stories and tests user flows via npx agent-browser; for non-UI tasks, runs integration/smoke tests, verifies regression safety, and tests API contracts. Messages developer teammate with issues + evidence. Max 3 cycles.
Reviewer (teammate — spawn via Teammate tool, dev phase)
Reviews changed files for completeness, correctness, security, quality, plan adherence. Validates review with /council (quick quality for routine, review security or review architecture for critical concerns). Scans for stubs. Messages developer teammate with file:line + fix suggestions. Max 3 cycles. Writes the dev report as their final deliverable after review is approved.
Rules
- One team at a time — cleanup plan-team before starting dev-team
- Teammates debate directly (Architect teammate↔PM teammate, Developer teammate↔Code-tester teammate, Developer teammate↔QA-tester teammate, Developer teammate↔Reviewer teammate)
- Researcher is always a subagent — Lead relays results
- Plan.md is the single source of truth and handoff artifact
- Every task declares
depends_on; parallel within waves, sequential between - Verify build between waves
- Avoid file conflicts between parallel tasks
- Testing + review are mandatory quality gates
- Always cleanup team before finishing
- In dev/full/auto modes, use delegate mode (Shift+Tab) to keep the lead focused on coordination
- Plan mode: do NOT implement — only plan
- If stuck — ask user, don't loop
Lead Identity
You are a coordinator, not an implementer. During active team phases:
NEVER do these — always delegate instead
- Edit or write source code files (
*.ts,*.js,*.py,*.go,*.rs,*.tsx,*.jsx,*.vue,*.svelte,*.css,*.scss,*.html) - Edit or write test files (
*.test.*,*.spec.*,__tests__/*) — delegate to code-tester teammate - Edit or write project doc files (
*.md) — delegate to the teammate with context (architect for plans/ADRs, reviewer for reports, developer for project docs) - Run implementation commands (npm run build, cargo build, etc.) — teammates do this
- Fix code bugs directly — send bug details to the developer teammate
- Explore the codebase during planning (Explore agent, repomix-explorer, Glob/Grep/Read on source files) — delegate to architect teammate
ALWAYS
- Delegate implementation to the developer teammate via SendMessage
- Delegate testing to code-tester and qa-tester teammates via SendMessage
- Delegate code review to the reviewer teammate via SendMessage
- Relay researcher subagent findings to teammates via SendMessage
ALLOWED to do directly
- Git operations: commit, push, branch, PR creation
Source
git clone https://github.com/rube-de/cc-skills/blob/main/plugins/cdt/skills/cdt/SKILL.mdView on GitHub Overview
CDT enables four modes (plan, dev, full, auto) for software development using Agent Teams. Teammates collaborate via peer messaging to design architecture, validate requirements, implement code, and optionally gate the handoff with approvals. The plan-to-dev handoff (plan.md) and role-based interactions ensure traceable decisions and faster feedback.
How This Skill Works
Modes structure the flow: plan or full start with architecture debate to produce plan.md, then development runs with developer + code-tester + QA-tester + reviewer. A Researcher subagent looks up docs and feeds findings, while teammates message directly for iterative feedback. In full, an approval gate sits between plan and dev; in auto, the plan flows straight to dev without gating.
When to Use It
- You need architecture/design before coding (plan mode).
- You have an approved plan and want to implement with peer validation (dev mode).
- End-to-end with an approval gate between plan and dev (full mode).
- End-to-end without gate (auto mode).
- Tasks benefit from collaborative agent teammates and peer messaging.
Quick Start
- Step 1: Select a mode (plan, dev, full, or auto) and spawn the corresponding teammates.
- Step 2: Have the Architect and PM debate to produce plan.md per the plan workflow.
- Step 3: Proceed with Dev teammates to implement, test, and review; follow gating rules for full or auto flow.
Best Practices
- Read and follow references/plan-workflow.md and references/dev-workflow.md before starting.
- Clearly assign architect, PM, developer, code-tester, QA-tester, and reviewer roles for the current mode.
- Write ADRs for significant decisions and update existing ADRs as decisions evolve.
- Use plan.md as the formal handoff between plan and dev and maintain traceability.
- Leverage Researcher to fetch docs and surface evidence, anchoring decisions in teammate messages.
Example Use Cases
- Architects debate a microservice design with a PM to produce plan.md, then developers implement with code-tester and reviewer.
- Feature upgrade where QA-tester validates behavior and code-tester runs tests during the dev phase.
- End-to-end new module with an approval gate between plan and dev (full mode).
- Rapid prototype using auto mode to go from plan to code without a gating step.
- Refactor driven by ADRs with peer reviews across Code-Tester, QA-Tester, and Reviewer.
