Incremental Work Order — Git skill for Claude Code

incremental-work-order

[English](README.md) · [中文](README.zh-CN.md)

**A dispatch workflow for long-running coding agents.**

One main tree schedules; each sub-tree executes its own slice of work orders; batches end in git checkpoints that are *inspection windows*, not stops; merges back are approval-gated and re-verified on the main tree.

The problem

Long-running agent work fails in predictable ways: the plan lives in chat and evaporates; the executor invents product decisions it had no mandate for; gates go green without proving anything; parallel worktrees fan out and never merge back; and "done" turns out to be unverified.

This skill is a **repository-backed dispatch process** that fixes those five things.

The model

user  ⇄  scheduler (main worktree)
          │   plans, writes orders, delivers, observes, merges
          └── authority (repo files)
              ├── README.md       rules + index (single text)
              ├── manifest.json   dispatch view: orders, executors, rules
              ├── status.md       roll-up: states, known gaps, cost
              ├── rulings.md      R-0001… citable decisions
              └── prefs.md        standing user preferences
              └── executor (one long-running session per sub-tree)
                  ├── worktree-charter.md   scope, write rights, slice, batches
                  ├── work-orders/**        the contract of record
                  ├── status.md             execution ledger + checkpoint reports
                  └── evidence/**

• Trees are hierarchical: a parent may write the sub-trees it dispatched — inside a whitelist (work-orders/**, worktree-charter.md). Sub-trees read the parent, never write it. Siblings never write each other. Repos outside the hierarchy are read-only, and get no orders at all.
• Delivery is the notification: writing an order into the sub-tree and committing it there is what notifies the executor — it re-reads its own tree and th