Skip to content

[Feature]: Honor template overrides for tasks-template (parity with plan) #2278

@jordipuigbou

Description

@jordipuigbou

Problem Statement

The tasks skill/command does not honor the template override / preset resolution mechanism that plan uses. The path to tasks-template.md is hardcoded in the command prompt (templates/commands/tasks.md:79), so projects with a custom template under .specify/templates/overrides/ (or in a preset / extension) are silently ignored.

As a workaround, I currently have to duplicate the override instructions into my project's CLAUDE.md so the model reads the correct template — which is agent-specific and drifts from the documented override stack.

This breaks the expectation set in docs/reference/presets.md:144-179, which documents the override stack as a general mechanism — but in practice it only works for plan-template.

Proposed Solution

Mirror the plan flow for tasks:

  1. Add a setup-tasks.sh (and PowerShell equivalent), or extend check-prerequisites.sh for the tasks flow, that calls resolve_template "tasks-template" "$REPO_ROOT" and exports the resolved path (e.g. TASKS_TEMPLATE).
  2. Update templates/commands/tasks.md to reference the resolved path from that variable instead of the literal templates/tasks-template.md.

Reference for how plan does it today:

  • scripts/bash/setup-plan.sh:42TEMPLATE=$(resolve_template "plan-template" "$REPO_ROOT")
  • scripts/bash/common.sh:299-374resolve_template() priority stack: overrides → presets → extensions → core

Alternatives Considered

  • Duplicating override instructions into the project's CLAUDE.md (current workaround — fragile and agent-specific).
  • Forking/patching templates/commands/tasks.md per project (breaks on upgrade).
  • Post-processing the generated tasks.md (runs after the model already used the wrong template).

Component

Scripts (Bash/PowerShell utilities)

AI Agent (if applicable)

All agents

Use Cases

  1. Teams maintaining a corporate/organizational task-template shape (extra sections, compliance fields, different phase ordering) and expecting the documented override stack to apply uniformly across plan and tasks.
  2. Presets shipping an opinionated tasks-template.md (e.g. a preset tailored to a specific methodology) that today has no effect.
  3. Extensions that want to contribute task templates the same way they can contribute plan templates.

Acceptance Criteria

  • .specify/templates/overrides/tasks-template.md is used by /tasks when present.
  • Presets and extensions can provide tasks-template.md and it resolves through the same priority stack as plan-template.
  • templates/commands/tasks.md no longer hardcodes templates/tasks-template.md; it consumes the resolved path from the setup script.
  • Parity between Bash and PowerShell script variants.
  • Documentation in docs/reference/presets.md reflects that the override stack applies to tasks-template as well.

Additional Context

Observed on spec-kit 0.7.3 (main at c118c1c).

Related files:

  • templates/commands/tasks.md:79 (hardcoded reference)
  • scripts/bash/check-prerequisites.sh (no template resolution)
  • scripts/bash/setup-plan.sh:42 (reference implementation)
  • scripts/bash/common.sh:299-374 (resolve_template)
  • docs/reference/presets.md:144-179 (documented override mechanism)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions