dw is a team-scale AI engineering system built on the Claude Code plugin architecture. Its core capabilities include isolated workspaces, full-stack code generation, test orchestration, bug fixing, DevOps execution, and knowledge capture. It addresses the core challenges of secure, reusable, and end-to-end AI collaboration in software development. Keywords: Claude Code, AI plugins, team development automation.
Technical specifications are summarized here
| Parameter |
Description |
| Core languages |
Markdown configuration with multi-stack support for Shell, Node, Python, Go, Java, and more |
| Extension protocols |
Claude Code plugin architecture, MCP |
| Core capabilities |
Skills, Agent Team, Hooks, Wiki |
| Number of Skills |
9 |
| Supported scenarios |
Frontend, backend, testing, bug fixing, DevOps, knowledge base |
| Key dependencies |
git worktree, npx skills, CloudEffect MCP, MasterGo MCP, Playwright |
| Security mechanisms |
PreToolUse interception, Secret Scan, auto-formatting, HITL |
| Knowledge capture |
Five-layer Wiki: raw / features / hubs / concepts / bugs |
This plugin system matters not because it can write code, but because it can deliver reliably
The dw system is a team-oriented collection of Claude Code plugins. It is not a point solution for individual productivity. Instead, it connects environment isolation, dependency installation, code generation, test validation, operations execution, and knowledge write-back into a standardized delivery pipeline.
Its design goal is explicit: solve the five most common problems teams face when introducing AI into real-world engineering. These include poor onboarding, AI changes contaminating the mainline branch, repeated investigation of similar bugs, frontend-backend contract mismatches, and uncontrolled execution of high-risk commands.
The plugin architecture is built on three layers: Skills, Agent Team, and Hooks
Skills package repeatable workflows. For example, /dw:backend generates APIs, tests, and documentation from a PRD, while /dw:fix pushes a bug fix all the way to a mergeable MR. Agent Team coordinates multi-role collaboration, and Hooks provide security guardrails throughout the tool invocation lifecycle.
/dw:work # Create an isolated AI workspace
/dw:depend # Install shared team Skills
/dw:feature # Orchestrate backend, frontend, and testing collaboration
/dw:fix "Login API returns 500" # Trigger the bug-fixing workflow
This command set creates a unified entry point for the team and reduces the cognitive load of remembering prompts and internal process details.
The nine Skills cover the core software delivery workflow
work serves as the infrastructure layer. It creates an isolated branch named `
-ai` with `git worktree`, automatically installs dependencies, and launches a dedicated Claude session. As a result, experimental AI-generated changes do not directly contaminate the main branch.
`depend` handles team Skill dependency management and supports personal, project, and team scopes. By combining `team-skills.yaml` with `npx skills`, it enables installation, upgrades, and targeted retries, making it well suited for standardized collaboration environments.
### Frontend and backend capabilities are split into independently executable but orchestratable units
`frontend` supports design-to-UI generation, API integration, and frontend logic development across three platforms: desktop web, mobile web, and mini-programs. Its input typically comes from `.dw/task/frontend-tasks.json`, and it includes a snapshot mechanism for resumable execution.
`backend` is designed for requirement-driven development. It follows a seven-step generation flow that produces schemas, entities, APIs, controllers, services, tests, and OpenAPI documentation. It supports Node, Java, Go, and Python, and it requires explicit declarations for `module` and `outputDir`.
“`json
{
“platform”: “node”,
“module”: “user”,
“outputDir”: “src/modules/user”
}
“`
The equivalent frontmatter metadata in this snippet determines the backend generation target and also serves as the key metadata for snapshot recovery and directory routing.
## feature, test, fix, and devops bring AI into real delivery workflows
`feature` acts as the full-stack orchestrator. When a requirement spans frontend, backend, and testing, it first queries the Wiki, then creates an Agent Team, dispatches tasks to downstream Skills, and completes API contract handoff and final aggregation.
`test` does more than generate test cases. It combines historical Wiki context with recent Git changes to build a two-layer test strategy: Layer A for baseline execution and Layer B for complex combinations. If no test runner is available, it degrades gracefully to static validation.
### Bug fixing and operations tasks are designed as controlled automation workflows
`fix` is arguably the most valuable Skill from an engineering perspective. Starting from either an issue description or a work item, it performs Wiki prechecks, root cause analysis, task decomposition, coding, self-validation, adversarial QA testing, and finally writes the result back to `.dw/wiki/bugs/`. If the workflow fails, it escalates through a five-level strategy instead of falling into an infinite loop.
`devops` unifies pipelines, deployments, MRs, branches, and work item operations behind natural-language or subcommand-based entry points. It uses HITL to guard all write operations and prevent AI from executing irreversible changes directly.
“`bash
/dw:devops pipeline run 1024 # Trigger a pipeline
/dw:devops mr create source=feat/a target=main title=”feat: add login”
“`
The value of these commands is that they turn click-driven UI operations into replayable and auditable operational semantics.
## The five-layer Wiki gives AI team memory
Knowledge capture in dw is not just log archiving. It is structured into five layers: `raw`, `features`, `hubs`, `concepts`, and `bugs`. `raw` stores the original inputs, `features` stores cleaned semantic data, `hubs` aggregates related topics, `concepts` extracts atomic concepts, and `bugs` maintains a dedicated fix index.
The immediate benefit of this structure is that future `fix` and `test` runs can retrieve historical context before execution. This avoids repeatedly diagnosing the same problem from scratch and gradually aligns AI output with accumulated team experience.
### Hooks shift security governance forward into the tool invocation stage
Another critical dw design choice is Hooks. Instead of relying only on after-the-fact review, dw inserts proactive guardrails into five stages: `SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, and `Stop`.
In particular, `PreToolUse(Bash)` blocks dangerous commands such as `rm -rf /`, force-pushing to the main branch, hard resets, and fork bombs. `PostToolUse` automatically formats code and scans for sensitive content such as AWS keys, GitHub tokens, Slack tokens, and private keys.
“`bash
# Example dangerous commands: blocked by Hooks
git push –force origin main
rm -rf /
“`
This interception is not an optional enhancement. It is the security foundation that teams must have once they allow AI to execute actions automatically.
## Project directory conventions make workflows recoverable and outcomes traceable
On the plugin side, dw maintains directories such as `skills/`, `agents/`, `hooks/`, and `scripts/`. On the business project side, it persists three categories of data: `.dw/task/`, `.dw/memory/`, and `.dw/wiki/`. Among them, `memory` is the core snapshot layer that supports resumable execution and failure recovery.
This dual-directory model decouples the plugin system from the business project: the plugin layer handles capability distribution, while the project layer persists context, tasks, and knowledge. For team collaboration, this is far more reliable than hiding all state inside conversation context.
### The onboarding path for new team members can be compressed into five steps
First, run `/dw:depend` to install shared Skills. Next, use `/dw:work` to create an AI workspace. Then call `backend`, `frontend`, `feature`, or `fix` based on the requirement. Finally, use `/dw:test` for validation and `/dw:wiki query` to retrieve and capture knowledge.
This means new team members do not need to understand the full plugin architecture up front. They can enter the team development workflow progressively through command-based entry points in a controlled environment.
## The essence of this system is upgrading AI from an assistant to a workflow participant
dw does not derive its value from the model alone, but from engineering encapsulation. It turns what AI can do into executable protocols, recoverable state, auditable actions, and persistent knowledge, making it truly suitable for team-scale software development.
For teams that want to scale Claude Code adoption, this kind of plugin architecture offers far more long-term value than one-off prompt tuning, because it solves process reuse, collaboration stability, and risk control.
## FAQ provides structured answers
### 1. What kind of team is dw best suited for?
It is best suited for engineering teams that already use Claude Code and want to standardize AI capabilities across multi-person collaboration workflows, especially in medium to large projects that involve frontend, backend, testing, and DevOps at the same time.
### 2. Why does dw emphasize worktree and Hooks?
Because AI-driven automation creates two major risks: contaminating the main branch and damaging the execution environment through mistakes. `worktree` solves isolation, and Hooks solve security. Together, they form the infrastructure foundation for operationalizing AI automation in teams.
### 3. If external dependencies are missing, does the workflow fail immediately?
No. dw includes degradation strategies across multiple stages. For example, `test` can fall back to static validation, `fix` can fall back from work-item mode to description mode, and when an MCP dependency is missing, the system explicitly reports what is missing and how to resolve it.
## AI Readability Summary
This article reconstructs the dw team-scale Claude Code plugin system in a structured way. It explains the nine Skills, Agent Team orchestration, Hook-based security controls, and the five-layer Wiki knowledge base, and shows how the system addresses key pain points such as difficult onboarding, branch contamination, repeated debugging, fragmented full-stack collaboration, and command safety.
