Problem
Some requests are too big for one shepherd run: the way to the destination isn't visible yet, and forcing them through a single design gate either balloons the design or fakes decisions that aren't ready. The original note here (divide the work, fix one by one, subagent per fix — the Bun-rewrite pattern) named the instinct but not a mechanism.
Proposal (prior art: wayfinder)
Compose, don't merge — planning stays outside shepherd; shepherd stays the executor of one scoped task:
- Chart: a parent "map" issue on the tracker holds the destination, an index of decisions made (one-line gist + link — the map is an index, not a store), a "not yet specified" fog section, and out-of-scope rulings. Child issues are decision tickets — questions whose resolution is a decision, not build slices.
- Resolve tickets one at a time (research / prototype / grilling), until nothing is left to decide before someone goes and does the thing.
- Execute: each cleared, scoped task becomes one shepherd run — shepherd already supports this ("Sequential runs are normal; for batch tasks off one base, note sibling PRs touching the same files in each PR body").
Deliberately NOT adopted into shepherd: tracker-held run state (blindness routing needs file-level read control), claim/assignee concurrency (shepherd is single-run), a per-session ticket cap (stages already bound context via subagents).
Open question: does this need any shepherd change at all (a README section on composing with a map may be enough), or a tiny sibling skill for charting? Start with the README paragraph; add tooling only if real efforts demand it.
Problem
Some requests are too big for one shepherd run: the way to the destination isn't visible yet, and forcing them through a single design gate either balloons the design or fakes decisions that aren't ready. The original note here (divide the work, fix one by one, subagent per fix — the Bun-rewrite pattern) named the instinct but not a mechanism.
Proposal (prior art: wayfinder)
Compose, don't merge — planning stays outside shepherd; shepherd stays the executor of one scoped task:
Deliberately NOT adopted into shepherd: tracker-held run state (blindness routing needs file-level read control), claim/assignee concurrency (shepherd is single-run), a per-session ticket cap (stages already bound context via subagents).
Open question: does this need any shepherd change at all (a README section on composing with a map may be enough), or a tiny sibling skill for charting? Start with the README paragraph; add tooling only if real efforts demand it.