MontréalCrépusculeCiel clair
David Paquet Pitts/Field Notes
Field noteMAY 19, 2025

4 min read

scopecraft-command, running Claude sessions against a real task system

A markdown task manager with an orchestration harness on top: parallel Claude Code sessions, one git worktree each, dispatched through tmux and watched from a dashboard.

Project
scopecraft-command
Curated by
David Paquet Pitts
Written & maintained by
his AI agent · Claude
Where it landed

Wound down late 2025. The worktree-per-session model appeared in Claude Code itself about a year later.

The build and the opinions are David's. The words are the agent's, drafted from his build records and kept current; he edits when he disagrees.

The itch

By May 2025 I was running Claude Code constantly, and the sessions had a problem: they floated free of everything. My tasks lived in markdown files; the AI work happened somewhere else, unrecorded, one session at a time, in whatever directory I happened to be in. I wanted coding sessions that ran against a real task system, several in parallel without stepping on each other, and I wanted to watch them while they ran.

What I built

The base layer was a markdown-driven task manager. Every task was a markdown file with YAML frontmatter and a fixed set of sections, instruction, tasks, deliverable, log, so a task carried its own context and its own history in the same place. The frontmatter tracked type, area, workflow, and status. It shipped as a CLI and as an MCP server, so any AI tool speaking the protocol could read and write the same tasks. MCP was brand new then; wiring a personal tool into it felt slightly premature, which was the appeal.

Scopecraft parent task detail view showing the rendered markdown instruction and vision on the left and a subtasks panel on the right with three sequenced subtasks, a Done/In Progress/To Do/Blocked legend, and Reorder and Make Parallel buttons
fig 01A parent task open in the tasks UI: the markdown task on the left, its sequenced subtasks on the right with Reorder and Make Parallel, and Start Claude Agent up top.

The part I still like was treating the parent task as an executable plan, not a folder of related work. Its subtasks carried a sequence, 01, 02, 03, and where two could run at once they shared a sequence number so the harness read them as a parallel group; that shared number was all the Make Parallel button in the screenshot actually wrote. With the phases and workflow states already in the frontmatter, the task file stopped describing the work and became the thing the orchestrator ran: spec and runnable plan in one file.

fig 02A parent task scrolled end to end in the tool: the instruction and vision up top, then the plan drawn as an ASCII orchestration flow right in the markdown. The sequence-01 research tasks fan out to @research-agent in parallel, the double-bordered gates (single-bordered boxes are tasks; see the legend) hold each phase until a decision clears, and the deliverable and log close it out.

I kept everything human-readable as text on purpose. Tasks were markdown, the AI's guidance was markdown, decisions and open questions lived inside the task file as sections you could check off. The reasoning was mundane: markdown is git-friendly and diff-able, and a model reads it as easily as I do, so the task file could be the one place where the human, the tool, and the AI all left notes. Live state, which sessions were running and their streams, sat outside git in ~/.scopecraft, ephemeral and machine-specific; what mattered, the decisions and outcomes, got written back into the task and committed. Keeping the durable memory in one legible file was the whole point.

The part I actually cared about was the orchestration harness on top, and the rule I held to there was that the orchestrator coordinates but never implements. dispatch, auto, and orchestrate didn't manage task data, run the model, or create worktrees themselves; they composed the services that did, a task service for context, channelcoder for the session, a git worktree for isolation. I made it coordinate rather than implement because the moment orchestration starts owning task storage or session internals, every part becomes load-bearing at once and nothing can be swapped. As a coordinator, it let me change how sessions ran without touching how tasks were stored.

The harness
coordinates, never implements
dispatch
Started Claude Code sessions in tmux windows, each in its own git worktree, so parallel sessions worked on isolated branches of the same repo: one session, one worktree, one branch, no shared working tree to corrupt.
auto
Ran a task autonomously: prepare a worktree, gather the task's context, start the session, follow the stream, write progress back into the task file.
orchestrate
Read that parent-task plan and fanned its subtasks out across worktrees, walking a sequence in order and starting a parallel group at once.

Two other convictions shaped it:

01
The task type decides how the AI works

Rather than a mode I picked by hand: a bug loads a diagnostic mindset, a spike an exploratory one, a parent an orchestration one, and the specific guidance was composed from the task instead of hardcoded into the tool. Guide, don't cage.

02
Autonomy is a dial, not a switch

Manual through guided and supervised to autonomous. The Autonomous Tasks Monitor was the face of that dial: running, waiting-for-feedback, and completed lanes over a combined activity log, built on the premise that a session which hits real uncertainty should document its assumption and raise a hand rather than stall or silently guess.

Scopecraft Autonomous Tasks Monitor screen with three empty lanes labelled Running, Waiting Feedback, and Completed above a Combined Activity Log panel, and a hint to start a session with ./implement-auto taskId
fig 03The Autonomous Tasks Monitor: running, waiting-for-feedback, and completed lanes over a combined activity log. Empty here because nothing was dispatched; the shape is the point.

Honestly, much of the orchestration layer stayed prototype-grade. The ideas were further along than the hardening.

What happened to it

The arc
  1. May 19, 2025The tmux dispatch prototyped: parallel Claude sessions, one git worktree each.
  2. Through 2025Kept iterating.
  3. Nov 2025I stop pushing commits. Other people sent the occasional patch after that, but for me it was done.
  4. A year laterClaude Code's own Agent View ships the same model as a research preview.

Later personal tools inherited its dashboard design and, more than the code, the convictions. The one that held up best: a session should own an isolated worktree, and the orchestrator should coordinate without implementing.

I do not think anyone at Anthropic was reading my repo. It is just the shape you arrive at once you seriously try to run more than one session, and I happened to need it early.

David Paquet Pitts
Head of Delivery & Solutions at Botpress