How should I organize tasks for AI coding agents?

Give each agent one task, one branch and one worktree. Write every task as a self-contained brief with the scope, the files involved and a check the agent can run. Split work so that two agents never edit the same files, plan before anyone codes, and keep the list where the agents can read it: GitHub Issues or a file in the repo.

The rest of this article turns that into a routine you can use with Claude Code, Codex CLI or any terminal agent.

1. Keep the list where agents can read it

A task list only helps if agents can reach it without you pasting it. Two simple options:

GitHub Issues, read with gh:

gh issue list --label ready --state open
gh issue view 42 --comments

Anthropic's best-practices guide notes that Claude knows how to use gh for issues, pull requests and comments. Setup details are in how to connect Claude Code to GitHub Issues.

A file in the repo, such as TASKS.md:

## Ready
- [ ] #12 CSV export drops the last row — src/export/csv.ts — test: export.test.ts
- [ ] #13 Add retry to webhook sender — src/webhooks/ — test: webhooks.test.ts

## In progress
- [ ] #11 Rename user settings API (agent: tab 2, branch task-11)

The file costs nothing and works offline. Issues give you history, labels and a place for the agent to report back.

2. Write briefs, not titles

An agent stops when the work looks done. Anthropic's guide puts it plainly: without a check it can run, "looks done" is the only signal available. Each task needs:

• The symptom or goal, in one or two sentences.
• Where to look: the folder or files most likely involved.
• What done means: a test to pass, a command whose output must change, a build that must succeed.
• What not to touch, if there is a risk of drift.

Compare Anthropic's own example: "fix the login bug" versus "users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it."

3. Split along file boundaries

Agents sharing one checkout edit the same files on disk, so one can undo another's work. Use one worktree per agent. Git supports several working trees attached to one repository:

git worktree add ../app-task-12 -b task-12

Claude Code can create one for you:

claude --worktree task-12    # or: claude -w task-12

This starts Claude in <repo>/.claude/worktrees/task-12. For an issue, gh can create a linked branch and check it out in a worktree:

gh issue develop 12 --checkout --worktree ../app-task-12

Worktrees stop file collisions, not logic conflicts. Two tasks that each pass their tests can still break each other once merged. When you split, prefer tasks that touch different modules, and keep shared files (schemas, config, routing) in a single task.

4. Plan first, then code

Anthropic recommends separating exploration from implementation. Start a task in plan mode, where Claude reads files and answers questions without making changes:

claude --permission-mode plan

Or press Shift+Tab in a session until the status bar shows plan mode, or run /plan. Use the plan to check the scope matches the brief. If the plan touches files another agent owns, split or reorder the tasks before anyone writes code.

5. Review with a fresh context

Anthropic's guide describes a Writer/Reviewer pattern: one session implements, a second one reviews, because a fresh context isn't biased toward code it just wrote. Then:

git diff main...task-12 --stat

One branch per task means one pull request per task, which keeps reviews small.

6. Know when to coordinate automatically

Claude Code also offers built-in ways to run several sessions: worktrees, cross-session messaging, the desktop app, Claude Code on the web, the agent view (claude agents, a research preview), and agent teams. Agent teams coordinate sessions with shared tasks and messaging. As of October 2026 they are experimental and disabled by default, and each teammate has its own context window, so they use more of your plan.

For most solo work, a task list, worktrees and you as the coordinator are enough. Running multiple Claude Code agents in parallel covers the terminal side.

Limits of this approach

• The mapping is manual. Which tab is on task 12? Is it waiting for you? A TASKS.md line like agent: tab 2 goes stale quickly.
• Launching takes copy and paste. Each new agent needs the brief pasted in. See how to give Claude Code a task from a GitHub issue for a shortcut.
• Waiting agents are invisible. Past three or four sessions, you lose track of which one has a question pending.
• Reporting back to the issue is another manual step.

With Kanbell

Kanbell is a macOS app with one window per project, real terminals in panes and tabs, and a task board next to them.

• The board is local or backed by GitHub Issues (columns open/closed, or by labels).
• Launch from a card: the brief is pasted into a terminal, not sent. You read it, then press Enter. For issues opened by someone outside the repository, Kanbell asks for confirmation first.
• Agents read the board through the kanbell CLI (kanbell list, kanbell show). On GitHub, it is read-only. Agents write with their own gh.
• Waiting is visible: an orange dot in the window, the menu bar and the overview, a macOS notification, and ⌘⇧J to jump to the next agent that is waiting. Full state tracking covers Claude Code. Codex CLI and Gemini CLI show state and pending permissions.
• Git sits beside the terminals: changes, diffs, history and worktrees.

There is no Linear, Jira or Trello integration.