---
name: schedule-backlog
description: >-
  Map BACKLOG.md items into roadmap phases, checking issue/decision impacts and
  pausing before roadmap edits. Use when scheduling backlog work or reshaping
  the roadmap; use `plan-work` for one implementation plan.
---

# schedule-backlog

This is a backlog-scheduling workflow, not an implementation workflow.
Default behavior is proposal-first:
- evaluate a coherent backlog slice
- map it into roadmap phases
- summarize the proposal before mutating `ROADMAP.md`, `BACKLOG.md`, or `ISSUES.md`

## Defaults

- Default mode is proposal-only.
- Default proposal size is small to medium and reviewable.
- Prefer existing incomplete phases when they fit the work cleanly.
- Do not renumber completed phases.

## Inputs

Accept any combination of:
- a focus area, phase number, or text query
- a proposal size
- a maximum number of new phases
- whether issue-impact notes should be included
- whether approved changes should later be applied

## Multi-agent pattern

Recommended roles:
1. `Standards reader`: extracts roadmap and decision constraints.
2. `Backlog triage lead`: selects candidate backlog items.
3. `Issue cross-checker`: identifies issue prerequisites or obsoletions.
4. `Roadmap integrator`: drafts the phase proposal.
5. `Reporter`: writes the proposal and approval guidance.

## Global constraints

- Do not implement backlog items in this workflow.
- Do not invent requirements that are not in `BACKLOG.md`, `ROADMAP.md`, `ISSUES.md`, `DECISIONS.md`, or `README.md`.
- Keep the proposal reviewable and coherent.
- Treat non-user-visible engineering work as issue-ledger material unless the roadmap explicitly needs a separate engineering phase.

## Human checkpoints

- Required: ask when a proposed placement would require renumbering a completed phase or making a non-obvious sequencing tradeoff.
- Optional: ask after the proposal only when the requested apply step would commit to a non-obvious prioritization or sequencing choice.
- When a checkpoint involves a genuine tradeoff between substantive alternatives, present at least two options with brief pros and cons, state which you recommend and why, and let the human decide.
- Stay autonomous while reading, triaging, and drafting the proposal itself.

## Roadmap workflow

### Phase 0: Preflight (Standards reader)

1. Read, in order, when they exist:
   - `ROADMAP.md`
   - `DECISIONS.md`
   - `BACKLOG.md`
   - `ISSUES.md`
   - `README.md`

### Phase 1: Select the backlog slice (Backlog triage lead)

1. Respect any user focus first.
2. Otherwise choose a reviewable subset using:
   - roadmap alignment
   - priority
   - cohesion
   - dependency clarity
3. Separate any misclassified engineering-only items that belong in `ISSUES.md`, not the roadmap.

### Phase 2: Cross-check issue and decision impacts (Issue cross-checker)

For each candidate group, identify:
- prerequisite issues
- issues that would likely become obsolete
- decisions or roadmap constraints that affect scheduling

### Phase 3: Draft the proposal (Roadmap integrator)

For each suggestion, provide:
- target phase or new phase proposal
- included backlog items
- why the grouping fits
- prerequisites
- issue impacts

If a new phase is needed, include:
- preferred placement
- goal
- high-level tasks
- exit criteria

### Phase 4: Draft the proposal summary (Reporter)

The proposal summary must contain:

1. `# Roadmap Update Summary`
   - current roadmap shape
   - backlog slice reviewed
   - short recommendation summary
2. `## Suggestions`
   - labeled `A`, `B`, `C`, ...
3. `## Backlog Hygiene Notes`
   - duplicates or misclassified items
4. `## Open Questions`
   - only when a sequencing decision truly needs the human
5. `## Approval Options`
   - how the user can approve, reject, or modify each suggestion

## Guardrails

- Do not schedule a huge backlog sweep in one proposal.
- Do not bury prerequisites or sequencing risk.
- Do not mutate roadmap files in the same step as drafting the proposal unless the request already includes applying a clear, low-ambiguity proposal.
- Do not present engineering refactors as user-visible roadmap work unless the roadmap truly needs them there.

## Definition of done

- The proposal summary includes every required section (`Summary`, `Suggestions`, `Backlog Hygiene Notes`, `Open Questions`, `Approval Options`).
- `ROADMAP.md`, `BACKLOG.md`, and `ISSUES.md` were not mutated in this run unless the user's request explicitly included an apply step with a clear, low-ambiguity proposal.
- Each proposal entry names its target phase (existing or new), included backlog items, grouping rationale, prerequisites, and issue impacts.
- Misclassified engineering-only items are flagged in `Backlog Hygiene Notes` rather than silently included in a roadmap phase.

## Final handoff

After drafting the proposal:
1. Summarize the best proposal options.
2. Tell the user how to approve, reject, or modify each suggestion.
