원클릭으로
agtx-sweep
// Sweep this conversation into agtx tasks and push them to the kanban board. Use when the user wants to capture, decompose, or hand off conversation results to the agtx board.
// Sweep this conversation into agtx tasks and push them to the kanban board. Use when the user wants to capture, decompose, or hand off conversation results to the agtx board.
| name | agtx-sweep |
| description | Sweep this conversation into agtx tasks and push them to the kanban board. Use when the user wants to capture, decompose, or hand off conversation results to the agtx board. |
| disable-model-invocation | true |
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_taskExecute an approved implementation plan. Implement the changes, then write a summary to .agtx/execute.md and stop.
Plan a task implementation. Analyze the codebase, create a detailed plan, write it to .agtx/plan.md, then stop and wait for user approval before making any changes.
Explore the codebase to understand a task before planning. Write findings to .agtx/research.md and stop. This is a read-only exploration — do not modify any files.
Self-review completed work. Check for correctness, edge cases, and code quality. Write review to .agtx/review.md and stop.
Enter brainstorm mode to explore a feature or enhancement idea. Stays in discussion mode only — no planning, no implementation. Use /agtx:sweep when ready to push outcomes to the board.