organise

organise

standalonewriteshands-on

Use this when: issues need placing and ordering into epics / sprints / milestones

Problem it solves — A pile of issues with no order is just a list. This places and orders the backlog — milestones, epics, sprints, dependencies — drafting the whole plan for your approval, then applying it in one hands-off pass.

Used in workflows: Idea → shipped

Organise

Shape the backlog so it always says what each issue is, where it belongs, what blocks it, and what's next — across the four layers (Milestone → Epic → Sprint → Task). It's faster than doing it by hand — hand-holdy when you want it, one-shot when you don't.

Task class: shape (a standalone single-word skill, like vet). Tools:gh (issues, native Issue Types, sub-issues, dependencies, Projects v2), Read/ codegraph for context. Runs in-thread. Artifact: issues placed — type/parent/milestone/board-order/deps set, Status + the Area label via triage.

This is the skill — surface a plan, confirm, apply

Pick a cadence up front (front-load → hands-off):

• Hands-on — propose each move with a one-line reason and wait; apply on confirm. Best for a few targeted moves or a delicate reshape.
• Hands-off — gather the whole backlog, draft the complete reorganisation plan in one document (the full Epic → Sprint → Task tree, milestones, deps, ordering, and every Type / parent / Status change), share it, and apply it all on a single approval. No per-move prompts.

Either way nothing is written until you approve — surface-then-confirm holds; the plan is the surface and your approval is the confirm, hands-off just batches it into one. Default to hands-off for a full backlog reshape, hands-on for a handful of moves.

What it does

• Place — for each issue, recommend its Epic / Sprint (sub-issue parent) and Milestone (release); newly-created issues default to backlog (no milestone) until placed.
• Re-home — vertical (promote/demote): change the Issue Type + parent (+ milestone) — a Task grows into a Sprint, etc. Horizontal: reparent to a sibling, or move to another milestone.
• Dependencies — detect likely blockers and recommend native blocked-by links (…/issues/{n}/dependencies/blocked_by); flag any order that violates them.
• Order — sequence sprints/epics on the Projects v2 board (manual order) and tasks within a parent (sub-issue order). Ordering lives here, never in a name.
• Readiness gates scheduling — never place an un-cleared issue into a live sprint: one at Needs Info (incl. vet-flagged) or blocked by an open blocked-by dependency is held + surfaced as blocked-on-review; only Ready for Agent / Ready for Human get scheduled. Weighs Status and deps together.
• Orphans — surface untyped/unplaced backlog and place it.
• Readiness — call triage to set Status + the Area label as it places.

Sad paths

• No Projects board configured (adoption prerequisite) → report what it would set and stop; never invent a board. Type/parent/deps still work via the issues API.
• Partial run → per-item confirm; each write is idempotent (re-reads current board state), so re-running is safe.

Workflow (when appropriate)

The read/classify gather can fan out via the Workflow tool when there are many issues. But ordering, dependencies and placement stay a central synthesis (they need the whole set in one view) — don't parallelise those.

Where it sits

to-issues calls organise after creating issues; also standalone. NOT to-issues (creates) / triage (classifies one issue) / build-sprint/build-epic (execute). The four-layer model + native GitHub mapping live in docs/brainstorms/2026-06-04-backlog-organisation-model.md.