Skip to content

Investigate milestone preflight suggestions through dogfooding #568

Closed as not planned

Description

@shiny-code-bot

Suggestion

Investigate whether github-plan guidance or tooling should more consistently prompt an agent to inspect, suggest, or discuss a milestone when durable work expands into multiple implementation issues and no active phase gate exists.

This is a suggestion to test, not a commitment to add automatic milestone creation or to change the planning model.

Why Investigate

A recent TV Volume Bridge planning session had a durable parent issue and an emerging multi-issue implementation graph, but no milestone existed until the user explicitly suggested one. Once created, the milestone provided a useful phase-exit boundary while dependencies and Project Focus continued to determine execution order.

Completed work in #557 and #559 already makes milestones first-class and exposes them to dependency-aware next-work selection. The remaining question is whether agent behavior around discovering or proposing a missing milestone is appropriately calibrated.

Questions to Explore

  • When should an agent check for an active milestone: every planning turn, only when a plan fans out, after a foundation merge, or only when release/phase language appears?
  • Should a missing milestone produce no signal, an advisory suggestion, or an explicit planning question?
  • Can a useful phase-exit gate be distinguished reliably from a themed backlog container?
  • How should the suggestion interact with parent issues, sub-issues, native blockers, and Project Focus?
  • Does milestone prompting help users finish work, or does it create planning ceremony and excess containers?
  • Should gh-plan next remain purely descriptive, or could separate advisory output mention the absence of a phase gate without mutating anything?

Dogfood and Testing Ideas

  • Review recent multi-issue workstreams with and without milestones and classify whether a milestone would have clarified closure.
  • Run forward scenarios covering a single issue, a parent with parallel sub-issues, a release train, an indefinite backlog, and unrelated concurrent work.
  • Observe false positives: cases where suggesting a milestone adds no useful closure condition.
  • Observe false negatives: cases where work expands repeatedly because no phase boundary is represented.
  • Dogfood any proposed guidance across several real repositories before changing default behavior.
  • Compare agent recovery quality when only the parent issue exists versus when a strict milestone description is also present.

Possible Outcomes

  • Keep current behavior unchanged.
  • Clarify skill prose with an optional milestone preflight at phase boundaries.
  • Add non-mutating advisory evidence to an existing read command.
  • Add a separate explicit investigation/check command rather than changing next.
  • Document repository patterns where milestones are actively discouraged.

Guardrails

  • Do not replace session execution plans, durable parent issues, sub-issues, dependencies, or Project Focus with milestones.
  • Do not auto-create milestones merely because none exists.
  • Do not make milestone ordering authoritative over native blockers.
  • Do not invent due dates when the real gate is technical or decision-based.
  • Preserve the current rule that a milestone is a strict phase/release/date gate, not another backlog.

Current Status

State: Later; exploratory suggestion parked for future investigation and dogfooding.
Parked until: the owner selects this investigation and its concrete dogfooding question. No implementation direction has been selected.
Next action: decide the bounded question before implementation; a valid conclusion may be that the existing behavior is already correctly conservative.
Last verified: 2026-09-14 UTC; current issue contents still record no selected direction. The underlying exploratory observation remains dated August 24, 2026.

The waiting status reflects the existing parked state. This reconciliation does not select implementation work or add a new dependency.

Relationships

Evidence That Would Be Useful

  • A compact scenario matrix with expected and observed agent behavior.
  • Examples where milestone prompting materially improved or degraded planning.
  • An explicit recommendation to change guidance, add advisory tooling, or leave behavior unchanged.
  • Forward-test results from more than one repository and workstream shape.

Activity

  1. added
    plan:waitingPlan is waiting on non-issue evidence or decision
    and removed on Sep 14, 2026
  2. added
    plan:donePlan completed or superseded
    and removed
    plan:waitingPlan is waiting on non-issue evidence or decision
    on Sep 27, 2026
  3. shiny-code-app commented on Sep 27, 2026

    @shiny-code-app
    Contributor

    Closed as superseded, owner decision 2026-09-26 (backlog reconciliation).

    The direction skill answers this question. In a repository with DIRECTION.md, a milestone exists only when the owner lists it there, and executing agents cannot create an unlisted one. An executing agent that sees work needing a new waypoint escalates it to the direction session as an issue labeled direction. It does not create or suggest the milestone on its own. That escalation path is the supported way to bring a missing phase gate to the owner, so nothing is left to investigate here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    planDurable planning issueplan:donePlan completed or superseded

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions