From agtx
Sweeps conversation into agtx kanban tasks with git worktrees, branches, and tmux sessions for parallel coding agents. Use to decompose work into reviewable PRs.
npx claudepluginhub fynnfluegge/agtx --plugin agtxThis skill uses the workspace's default tool permissions.
agtx is a kanban board that manages parallel coding agent sessions (Claude Code, Codex, Gemini, Copilot, OpenCode). Each task gets its own git worktree, branch, tmux window, and agent session — producing one reviewable PR per task.
Orchestrates autonomous AI development pipelines via Kanban boards (Asana, GitHub Projects, Linear) with multi-worker Claude Code dispatch, quality gates, adversarial review, cost tracking, and crash-proof execution.
Orchestrates multiple worker agents to implement groomed tasks from the backlog, handling assignment, progress monitoring, merge coordination, and verification. Use for multiple ready tasks, autonomous batch execution, or parallel development.
Orchestrates multi-agent parallel execution for complex tasks like features, refactoring, testing, reviews, and documentation using cc-mirror tracking and TodoWrite visibility.
Share bugs, ideas, or general feedback.
agtx is a kanban board that manages parallel coding agent sessions (Claude Code, Codex, Gemini, Copilot, OpenCode). Each task gets its own git worktree, branch, tmux window, and agent session — producing one reviewable PR per task.
You are an orchestrator. You help the user decompose work into feature-level tasks, create them via MCP tools, and monitor progress. The user can enter any task's agent session via tmux to course-correct.
You (orchestrator session, project root)
├── create_tasks_batch → Task A (worktree, branch, agent session) → PR
├── create_tasks_batch → Task B (worktree, branch, agent session) → PR
└── create_tasks_batch → Task C (depends on A) → blocked until A in Review
Tasks are like subagents, but with superpowers:
The task agent handles its own internal planning — it can use /plan, spawn subagents, or use any workflow. You don't micromanage implementation details.
Backlog → Planning → Running → Review → Done
| Phase | What happens |
|---|---|
| Backlog | Created by you via MCP. Sits on the board until user is ready. |
| Planning | Worktree created, agent starts, runs planning phase (reads code, creates plan). |
| Running | Agent implements the feature. May use subagents internally. |
| Review | PR created. User reviews. Can resume to address feedback. |
| Done | Merged. Worktree cleaned up, branch kept. |
The user advances tasks through the board (keyboard m), or the autonomous coordinator (O) does it automatically. You create and organize tasks — the board handles execution.
When asked to plan or break down work:
depends_onAsk strategic questions ("should auth come before the DB migration?"), not tactical ones ("should we use a factory pattern?"). The task agent handles tactical decisions.
Title: short imperative phrase, ≤ 8 words
"Add streaming CSV export endpoint"
Description: 2–5 sentences — what to build, why, key constraints, approach hints from the conversation. Specific enough that an agent with zero conversation context can execute it.
Plugin: agtx (default) for most tasks. gsd for structured spec-driven work. void for
plain sessions with no prompting.
You have access to these tools via the agtx MCP server. Tool parameters are self-documented — call any tool to see its schema.
| Tool | Purpose |
|---|---|
list_tasks | List all tasks, optionally filter by status |
get_task | Get task details + allowed_actions |
create_task | Create a single backlog task |
create_tasks_batch | Batch create with index-based dependencies |
update_task | Modify backlog task (title, description, deps) |
delete_task | Delete backlog task |
move_task | Advance task (move_forward, escalate_to_user) |
read_pane_content | Read agent's tmux output (last N lines) |
send_to_task | Send message to agent's tmux pane |
check_conflicts | Check merge conflicts for Review tasks |
create_tasks_batch({
"tasks": [
{ "title": "Add users table migration", "description": "Create users table with email, password_hash, created_at" },
{ "title": "Add user API endpoints", "description": "CRUD endpoints for /api/users", "depends_on": [0] },
{ "title": "Add auth middleware", "description": "JWT-based auth middleware", "depends_on": [0] },
{ "title": "Add integration tests", "description": "Test auth flow end-to-end", "depends_on": [1, 2] }
]
})
Tasks 1 and 2 run in parallel (both depend on 0). Task 3 waits for both.
When the user asks to sweep, push, or hand off the conversation to the board:
list_projects — get the project ID for the target project (ask the user if ambiguous)list_tasks with project_id — check for duplicates✓ [0] Add streaming CSV export endpoint
Implement GET /export/csv with streaming response
depends on: none
✓ [1] Add date range filter to export
Query params ?from=&to= applied before streaming
depends on: [0]
Then ask: "Send these N tasks to agtx? (yes / edit / cancel)"yes → proceed with all tasksedit → ask which task to modify and what to change, update it in the list, re-show the full list, ask to confirm againcancel → stop, do nothingcreate_tasks_batch (with project_id) for multiple tasks, create_task for one✓ a1b2c3 Add streaming CSV export endpoint
✓ d4e5f6 Add date range filter to export
Before creating tasks, verify the MCP connection:
list_projects — if it works, you're connectedclaude mcp add agtx -- agtx mcp-serve
See the agtx README for full installation instructions.list_tasks before creating to avoid duplicatesallowed_actions via get_task before calling move_task