Tasks

A task is the unit of work WTmag dispatches to a worker. The starting point can be a real conversation — you talk through a problem with your orchestrator, shape a rough idea into a brief, or point it at something that already exists. The orchestrator turns that into a wtmag create call, and a worker gets spawned in its own worktree and tmux session.

Two work types

WTmag splits work into two types. They're different enough that they have separate config keys, separate default prompts, and separate worker behavior.

Implementation work is end-to-end delivery oriented. The worker implements the task, commits, pushes the branch, opens a PR, and reports the link back. The full workflow is baked into the default prompt. You don't have to tell the agent to open a PR — it already knows.

Review work is read-only. The worker inspects the diff, reports findings, and doesn't touch anything. No edits, no commits, no approvals, no merges. If it finds a problem, it describes the fix instead of making it.

These map to the [launch] config keys: implementation and review. Each can default to window or session independently. See configuration.

Task sources

WTmag doesn't care where a task comes from. It cares about the task itself. The source system is extensible at its core — GitHub Issues ship built-in, but the architecture is meant to grow.

What works today:

What the system is designed for:

• Linear, Asana, GitLab Issues, or any platform you track work in. The same extensibility principle applies to both sides of the system — task sources and agents can grow without the other changing.

Source-native terminology

"Tasks" is the umbrella product term. But WTmag doesn't flatten source-native terminology in commands or prompts. GitHub issues are still GitHub issues. Jira tickets are still Jira tickets. PRs are still PRs. The umbrella term is for talking about the concept — not for replacing the names your tools already use.

How context gets to the agent

WTmag fetches the full context from the source — the complete issue text, the PR diff, or your custom prompt — and writes it to .wtmag/prompt.md in the worktree. The agent starts with a one-line bootstrap: "read that file." This keeps the command line short and the context intact. No summaries, no truncation, no pasting by hand.

If you pass --prompt alongside a source like --github, WTmag keeps the source context and adds your instructions on top. Don't use --prompt to restate the issue — it's already in the brief. Use it when you want something specific on top, like "Start by writing regression tests."

Read more

• GitHub Issues — implementation workers that go to PR
• PR Reviews — read-only workers that report findings
• Custom Prompts — implementation work with no source
• Commands reference for exact syntax