Feature Request: Milestone grouping extension for taskstoissues

首先跟踪现有的 /speckit.taskstoissues 流程及其 after_taskstoissues hook，然后检查扩展 manifest 的结构和 commands/assign.md 入口点。使用 tasks.md 标题作为默认分组，并审查 .specify/milestones-config.yml 中提议的映射。满足验收标准即视为完成，包括复用 milestone、安装、确认、文档以及对所有 agent 的支持。

Problem Statement

/speckit.taskstoissues creates GitHub Issues 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 Milestones and assigning issues after the fact.

Proposed Solution

A lightweight extension that hooks into after_taskstoissues and groups the newly created issues into GitHub Milestones.

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 Milestones"
  version: "1.0.0"
  description: "Groups issues created by taskstoissues into GitHub Milestones 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 Milestones and assign issues from the most recent taskstoissues run"
  hooks:
    after_taskstoissues:
      command: "speckit.milestones.assign"
      optional: true
      prompt: "Assign issues to GitHub Milestones?"

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 Milestones 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 Projects 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.