Feature Request: Milestone grouping extension for taskstoissues

[JonathanBowker]

Problem Statement

/speckit.taskstoissues creates GitHub 问题 from tasks.md, but all issues land flat in the repo with no milestone assignment. On any non-trivial feature (multiple user stories, phased delivery, or multi-repo workspaces), the issue list quickly loses structure. There is no way to track progress at the feature or delivery-phase level without manually creating GitHub 里程碑 and assigning issues after the fact.

Proposed Solution

A lightweight extension that hooks into after_taskstoissues and groups the newly created issues into GitHub 里程碑.

Behaviour

1. After taskstoissues completes, the extension reads the task structure from tasks.md (which already organises tasks by user story or feature group).
2. For each top-level group (user story, feature, or phase), it creates or updates a GitHub Milestone with a matching title.
3. Each issue created by taskstoissues is assigned to its corresponding milestone.
4. If a milestone already exists with that title, the extension reuses it rather than creating a duplicate.

Extension shape

schema_version: "1.0"
extension:
  id: "milestones"
  name: "Task 里程碑"
  version: "1.0.0"
  description: "Groups issues created by taskstoissues into GitHub 里程碑 by feature or user story"
  requires:
    speckit_version: ">=0.10.0"
    commands:
      - "speckit.taskstoissues"
  provides:
    commands:
      - name: "speckit.milestones.assign"
        file: "commands/assign.md"
        description: "Create or update GitHub 里程碑 and assign issues from the most recent taskstoissues run"
  hooks:
    after_taskstoissues:
      command: "speckit.milestones.assign"
      optional: true
      prompt: "Assign issues to GitHub 里程碑?"

Grouping logic

The natural grouping already exists in tasks.md. Tasks are organised under headings that correspond to user stories or feature areas. The extension maps each heading to a milestone. No new configuration is needed for the default case.

For teams that want custom grouping (e.g. by delivery phase rather than user story), a config file could allow explicit mapping:

# .specify/milestones-config.yml (optional)
grouping: "heading"  # default: use tasks.md headings as milestone titles
# OR
grouping: "custom"
milestones:
  - title: "Phase 1: Core API"
    match: ["T001*", "T002*", "T003*"]
  - title: "Phase 2: UI"
    match: ["T004*", "T005*"]

Why an extension, not core

This adds project management structure on top of the existing workflow without changing the core taskstoissues behaviour. Teams that do not use GitHub 里程碑 are unaffected. The extension model keeps it opt-in and independently versioned.

Alternatives Considered

Manual milestone assignment works for small features but does not scale to multi-story specs with dozens of tasks. External scripting is possible but loses integration with the SDD workflow and traceability from spec to milestone. GitHub 项目 boards are complementary but different: milestones track delivery scope, projects track workflow state.

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

All agents

Use Cases

1. When working on large features with multiple user stories, each story's tasks should map to a milestone so progress is visible at the story level, not just the individual issue level.
2. During phased delivery (e.g. "Phase 1: API, Phase 2: UI"), milestones give stakeholders a native GitHub view of which phase is complete without reading tasks.md.
3. In multi-repo workspaces where each repo runs its own taskstoissues, milestones provide cross-cutting delivery tracking that flat issue lists cannot.

Acceptance Criteria

• Running /speckit.milestones.assign after taskstoissues creates one GitHub Milestone per top-level task group in tasks.md
• Each issue created by taskstoissues is assigned to its corresponding milestone
• Existing milestones with matching titles are reused, not duplicated
• Optional milestones-config.yml allows custom grouping by task ID pattern
• The extension installs via specify extension add milestones
• The after_taskstoissues hook fires with a confirmation prompt
• Documentation covers default and custom grouping modes
• Works with all supported agents

Additional Context

The grouping data already exists in tasks.md. Tasks are organised under headings that correspond to user stories or feature areas. The extension maps each heading to a GitHub Milestone. No new task structure or metadata format is required. This closes the gap between task-level tracking (issues) and delivery-level tracking (milestones) within the existing SDD workflow.