Backlog organisation model

How work is organised in Tomat-Labs/Tempo: a four-layer model mapped onto native GitHub primitives, plus the skills that organise the backlog and execute from it. Ordering is cheap to change, and "organise, then act" is a repeatable loop.

The model — four layers, by intent not size

Layer	Meaning	Lifecycle
Milestone	a major product release (Launch, V2, V3)	top; made of many epics
Epic	an evolving theme/workstream you keep adding to (Harness, Tempo app, Deployment)	open-ended
Sprint	a bounded push you ship then verify (manual testing); bounded by intent, not time	closed when shipped + verified
Task	one unit of work	closed on merge

The axis is intent/lifecycle, not issue count — a sprint can be large or small; what bounds it is "ship this coherent slice, then verify it."

GitHub primitive mapping (all native)

Concept	Native mechanism
Release (Milestone)	native GH Milestone, set on epic issues — keeps due dates, the Milestones tab, milestone: search, and the cross-issue progress bar
Layer (Epic/Sprint/Task)	native Issue Type — Epic / Sprint / Task for the layer, plus Bug / Feature for category
Membership (which epic/sprint)	native sub-issue tree: Epic ⊃ Sprint ⊃ Task (the Parent issue field)
Dependency ("blocked by")	native blocked-by / blocking relationships (…/issues/{n}/dependencies/blocked_by) — first-class and API-readable; a warning, not an enforced gate
Ordering	Projects v2 board (manual drag order) + sub-issue order within a parent
Area (Harness vs App, cross-cutting)	a native Area Issue Field (App / Harness / App + Harness), set by triage — orthogonal to layer and milestone, so you can filter all harness work across epics
Readiness	a Projects v2 Status field — Needs Triage → Needs Info → Ready for Agent → Ready for Human → In Progress → Done (plus Wontfix), set by triage; the agent/human split lets an AFK agent pick up Ready for Agent work

Epics are named, never numbered. Ordering lives in the Project (drag order) and in milestone sequence — never in an epic's name. Reprioritising is a reorder on the board or a milestone move.

Moves (a first-class organise job):

• Vertical (promote/demote): change an issue's Issue Type + Parent + Milestone (e.g. a Task grows into a Sprint).
• Horizontal (re-home within a layer): change Parent to a sibling, or change Milestone.

The skills

build-* is execution only; the standalone organise skill owns backlog shaping; creation is to-issues.

Verb	Skill	Job
create	to-issues	idea / brainstorm / spec → typed issues (Epic/Sprint/Task), then calls triage (readiness + Area) and organise (placement). Default: no milestone → backlog.
shape	organise	organise issues into sprints/epics/milestones: prompts where things should go with recommendations; detects dependencies/blockers and recommends them; splits epics → sprints, sets order, re-homes (vertical/horizontal), plans and reorders milestones, places orphans. Calls triage for readiness. Always confirms before any update (surface-then-confirm).
classify	triage	set an issue's Status (readiness) and its Area field. Invoked by to-issues and organise; also standalone.
execute (one)	build-sprint	pick one Sprint (a Sprint issue → its child Tasks) → PLAN → build → PR → verify.
execute (many)	build-epic	step through an epic's sprints sequentially — run each via build-sprint, verify between.
discover	find-untracked-work	gaps between built / intended / tracked → feed to-issues and organise.

The loop

find-untracked-work (discover) → to-issues (create typed issues → triage for readiness + area → organise for placement; default = backlog) → organise (interactively place, order, set deps — recommends, you confirm) → build-sprint / build-epic (execute → verify) → repeat.

to-issues and organise both call triage, so classification (readiness + area) and placement are reusable steps shared across creation and standalone organising.

Conventions

• organise is a standalone single-word skill (like vet / debug / brainstorm), listed in config/harness.php standalone_skills so the verb-prefix check exempts it.
• build- means execute — build the working implementation a skill names, which covers build-sprint and build-epic as executors. Issue and metadata creation is to-issues, never a build-.
• Sprints are intent-boxed, not time-boxed — no dated iterations.
• Dependencies are advisory — GitHub warns on a blocked-by violation but doesn't block the work; organise surfaces them.

The model's terms (milestone, epic, sprint, task, area, readiness/Status, vertical/horizontal move) are defined in docs/agents/glossary.md and indexed in CLAUDE.md. The triage Status and Area values are documented in docs/agents/triage-labels.md; the git topology and issue-close semantics in docs/adr/0005-sprint-epic-branch-flow-and-completion.md.