Feature Request: Milestone grouping extension for taskstoissues

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

After taskstoissues completes, the extension reads the task structure from tasks.md (which already organises tasks by user story or feature group).
For each top-level group (user story, feature, or phase), it creates or updates a GitHub Milestone with a matching title.
Each issue created by taskstoissues is assigned to its corresponding milestone.
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

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

I'm interested in picking this up. Happy to discuss approach if needed.

Be aware that we are going to move this particular command into its own extension as issue tracking functionality is not part of the SDD process itself

@mnriem

Good to know, thanks for flagging. This spec currently assumes taskstoissues is core, so once it moves I'll update the requires.commands dependency to point at the new extension instead.

@mnriem, please could you link the new extension (or its tracking issue) once it exists? I'll adjust the requires block and the after_taskstoissues hook reference to match wherever that command ends up living.

@MannXo, still happy for you to pick this up. The grouping and milestone-assignment logic doesn't change, only the dependency target once the split happens.

@mnriem

Heads up on the home for this: the tasks-to-issues work is moving into a bundled github extension (#4421), scoped as the GitHub-platform domain (parallel to the git extension). Milestone grouping should land there too — e.g. speckit.github.milestones or milestone options on speckit.github.taskstoissues — rather than as a separate narrow extension. Let's build this on top of #4421 once it lands.

Posted by GitHub Copilot (model: Claude Opus 4.8) on behalf of @mnriem.

feat(extensions): add bundled github extension for taskstoissues (git…

feat(extensions): add bundled `github` extension for taskstoissues (#…

@mnriem

Thanks for the detailed proposal. Now that the bundled github extension provides /speckit.github.taskstoissues, this looks like a good candidate for a preset on top of that extension, rather than a separate milestone extension.

Presets can wrap an existing extension command, retaining its normal task-to-issue conversion while adding project-specific behavior. A task-milestones preset could preserve the existing conversion and then offer milestone assignment. See the GitHub extension and preset composition documentation.

A rough package layout:

task-milestones/
├── preset.yml
├── commands/
│   └── taskstoissues-with-milestones.md
└── README.md

The relevant preset manifest contribution would look like this:

# Excerpt from preset.yml
provides:
  templates:
    - type: command
      name: speckit.github.taskstoissues
      file: commands/taskstoissues-with-milestones.md
      description: Group task issues into GitHub milestones
      strategy: wrap

Conceptually, the wrapper would contain:

Before conversion:
- Read the active tasks.md and its task-group headings.
- Read .specify/milestones-config.yml if present.
- Retain the task-to-group mapping and the issue numbers returned
  or identified during conversion.

{CORE_TEMPLATE}

After successful conversion:
- Ask whether to assign the feature's task issues to milestones.
- If confirmed, resolve each group to a milestone in the same repository.
- Reuse matching milestones; create missing ones.
- Assign the corresponding issues and report the results.

The detailed instructions should cover default heading-based grouping and the optional task-ID-pattern mapping proposed here. They should also define how to handle ambiguous matches, closed milestones, and issues already assigned to another milestone—without silently overwriting an existing assignment. Retaining actual issue numbers is important because task IDs such as T001 can recur across features.

For local development, the intended usage would be:

specify extension add github
specify preset add --dev ./task-milestones

Then run /speckit.github.taskstoissues as usual. Milestone operations would require suitable GitHub tooling and write permissions; those capabilities need to be included in the effective command's tool configuration.

This would change the proposed packaging and hook-specific acceptance criteria, but preserve the opt-in user experience without requiring changes to core or the bundled extension. Confirmation would happen within the wrapped command, rather than through a newly registered after_taskstoissues hook. This remains agent-executed behavior, not a deterministic milestone service.

Cross-agent delivery would need verification; the generic integration currently does not register preset command or skill overrides. GitHub milestones also remain repository-scoped: matching milestone names across repositories do not create a shared cross-repository milestone.

This is an implementation sketch, not an implemented or validated preset. The suggested disposition is to redirect this request to an independently maintained preset rather than track it as a core or bundled-extension feature.

Drafted and posted by GitHub Copilot (model: GPT-6.1 Sol), at @mnriem's request, in interactive agent mode. AI assistance covered repository/issue assessment and comment drafting; no preset implementation was performed.

Navigation Menu

Repository navigation

Feature Request: Milestone grouping extension for taskstoissues #4370

Problem Statement

Proposed Solution

Behaviour

Extension shape

Grouping logic

Why an extension, not core

Alternatives Considered

Component

AI Agent (if applicable)

Use Cases

Acceptance Criteria

Additional Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature Request: Milestone grouping extension for taskstoissues #4370

Description

Problem Statement

Proposed Solution

Behaviour

Extension shape

Grouping logic

Why an extension, not core

Alternatives Considered

Component

AI Agent (if applicable)

Use Cases

Acceptance Criteria

Additional Context

Activity

MannXo commented on Aug 30, 2026

mnriem commented on Aug 31, 2026

JonathanBowker commented on Sep 3, 2026

mnriem commented on Sep 8, 2026

mnriem commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions