peter/devclaw-gitea
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify PM/DEV/QA team structure and isolated group chat model

Browse Source 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Lauren ten Hoor
2026-02-08 15:38:26 +08:00
parent a94f4f9d54
commit 8178a79999
1 changed files with 29 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
README.md
View File

@@ -2,7 +2,7 @@
**One agent. One group chat. A full dev team.** **One agent. One group chat. A full dev team.**
Add the orchestrator agent to a Telegram group, point it at a GitLab repo, and you have an isolated development team — a DEV that writes code, a QA that reviews it, and a team lead that manages the pipeline. Add another group chat, get another team. Each project runs independently with its own task queue, its own sub-agents, and its own session state. Add the orchestrator to a Telegram group, point it at a GitLab repo, and it spins up an isolated dev team: a **PM** (the orchestrator itself) that manages the backlog, a **DEV** sub-agent that writes code, and a **QA** sub-agent that reviews it. Add another group chat — another team. Each runs independently with its own task queue, workers, and session state.
DevClaw is the [OpenClaw](https://openclaw.ai) plugin that makes this work. DevClaw is the [OpenClaw](https://openclaw.ai) plugin that makes this work.
@@ -14,51 +14,54 @@ DevClaw fills that gap with guardrails. It gives the orchestrator atomic tools t
## The idea ## The idea
You have one AI agent — the orchestrator. It lives in a Telegram group per project. Each project has its own GitLab repo, its own task backlog, and its own pair of sub-agent workers: a **DEV** that writes code and a **QA** that reviews it. The orchestrator decides what to work on, spawns the right worker with the right model, and moves tasks through the pipeline — across all projects at once. One head agent acts as the **PM** across all your projects. It reads task backlogs, decides priorities, and delegates work. For each task, it spawns (or reuses) a **DEV** sub-agent to write code or a **QA** sub-agent to review it. Every Telegram group is a separate project — the PM keeps them completely isolated while managing them all from a single process.
DevClaw gives the orchestrator four tools that replace hundreds of lines of manual orchestration logic. Instead of the agent following a 10-step checklist (fetch issue, check labels, pick model, check for existing session, transition label, update state, log audit event...), it calls `task_pickup` and the plugin handles everything atomically. DevClaw gives the PM four tools that replace hundreds of lines of manual orchestration logic. Instead of following a 10-step checklist per task (fetch issue, check labels, pick model, check for existing session, transition label, update state, log audit event...), it calls `task_pickup` and the plugin handles everything atomically.
## How it works ## How it works
```mermaid ```mermaid
graph TB graph TB
subgraph "Orchestrator Agent" subgraph "Group Chat A"
O[Orchestrator]
end
subgraph "Project A — Telegram Group"
direction TB direction TB
A_PM["🎯 PM (head agent)"]
A_GL[GitLab Issues] A_GL[GitLab Issues]
A_DEV[DEV sub-agent] A_DEV["🔧 DEV (sub-agent)"]
A_QA[QA sub-agent] A_QA["🔍 QA (sub-agent)"]
A_PM -->|task_pickup| A_GL
A_PM -->|spawns / sends| A_DEV
A_PM -->|spawns / sends| A_QA
end end
subgraph "Project B — Telegram Group" subgraph "Group Chat B"
direction TB direction TB
B_PM["🎯 PM (head agent)"]
B_GL[GitLab Issues] B_GL[GitLab Issues]
B_DEV[DEV sub-agent] B_DEV["🔧 DEV (sub-agent)"]
B_QA[QA sub-agent] B_QA["🔍 QA (sub-agent)"]
B_PM -->|task_pickup| B_GL
B_PM -->|spawns / sends| B_DEV
B_PM -->|spawns / sends| B_QA
end end
subgraph "Project C — Telegram Group" subgraph "Group Chat C"
direction TB direction TB
C_PM["🎯 PM (head agent)"]
C_GL[GitLab Issues] C_GL[GitLab Issues]
C_DEV[DEV sub-agent] C_DEV["🔧 DEV (sub-agent)"]
C_QA[QA sub-agent] C_QA["🔍 QA (sub-agent)"]
C_PM -->|task_pickup| C_GL
C_PM -->|spawns / sends| C_DEV
C_PM -->|spawns / sends| C_QA
end end
O -->|task_pickup / task_complete| A_GL AGENT["Single OpenClaw Agent"]
O -->|task_pickup / task_complete| B_GL AGENT --- A_PM
O -->|task_pickup / task_complete| C_GL AGENT --- B_PM
O -->|sessions_spawn / sessions_send| A_DEV AGENT --- C_PM
O -->|sessions_spawn / sessions_send| A_QA
O -->|sessions_spawn / sessions_send| B_DEV
O -->|sessions_spawn / sessions_send| B_QA
O -->|sessions_spawn / sessions_send| C_DEV
O -->|sessions_spawn / sessions_send| C_QA
``` ```
Each project is identified by its **Telegram group ID** — the orchestrator receives messages from project groups and knows which project context it's operating in. It's the same agent process — but each group chat gives it a different project context. The PM role, the workers, the task queue, and all state are fully isolated per group.
## Task lifecycle ## Task lifecycle