Milestone Planning

Turn requirement candidates into a shared, reviewable Feature commitment without creating a serial execution queue.

Prepare the candidate pool

1. Read repository instructions, the full requirement pool, active and completed Milestones, current product evidence, incidents, dependencies, and supplied constraints.
2. Reconcile completed, duplicate, obsolete, and partially selected outcomes before scoring. Preserve vague future questions without inventing delivery structure.
3. Follow an existing priority model. Otherwise recommend one evidence-backed 0–10 score using impact, delay cost, explicit commitments, risk, strategic value, and unblocking value.
4. Score Feature candidates, not their future Tasks. Keep hard dependencies separate from priority.

Use references/requirement-pool-template.md only when no stronger pool or tracker convention exists.

Consume a selected candidate only after its Feature record is durable. Remove a wholly selected requirement from the active pool in the same change that materializes the Feature. For partial selection, materialize the selected outcome, rewrite the unselected remainder as a bounded candidate, and rescore it. Never keep the same full outcome authoritative in both the requirement pool and a Feature. Using this skill is optional; Features may be created and delivered without a Milestone. When the repository has chosen Milestone-grouped fallback documentation, materialize the Feature at milestones/<milestone>/features/<feature>/feature.md; otherwise create or preserve its single repository-native Feature record and link it from the Milestone.

Resolve stable actors

Reuse an owner or coordinator already recorded in the Feature, Milestone, or configured external tracker. Otherwise use an identity explicitly supplied by the current request. If the current actor is still needed, read .waypoint/local.yaml directly when it exists, even when local-work-tracker was not invoked or installed, and use its actor_id as the current actor identity. If the file is absent, invalid, or does not answer which participant should own the work, ask the user. Never infer ownership from Git author metadata, a harness, machine, branch, or temporary window label.