revert: remove all core template changes, pivot to preset approach

Author: Quratulain-bilal

templates/commands/plan.md

@@ -65,7 +65,6 @@ You **MUST** consider the user input before proceeding (if not empty).
 2. **Load context**: Read FEATURE_SPEC and `/memory/constitution.md`. Load IMPL_PLAN template (already copied).
 
 3. **Execute plan workflow**: Follow the structure in IMPL_PLAN template to:
-   - Include a **Table of Contents** section immediately after the title and header details, and before the Summary. List all `##`-level headings as markdown anchor links (lowercase, spaces to hyphens, strip special characters). Only include sections that actually appear in the final document.
    - Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION")
    - Fill Constitution Check section from constitution
    - Evaluate gates (ERROR if violations unjustified)

templates/commands/specify.md

@@ -120,7 +120,7 @@ Given that feature description, do this:
     7. Identify Key Entities (if data involved)
     8. Return: SUCCESS (spec ready for planning)
 
-5. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings. Include a **Table of Contents** section immediately after the title and initial metadata lines at the top of the file, and before the first content section. The TOC must list all `##`-level headings as markdown anchor links (lowercase, spaces to hyphens, strip special characters). Example: `- [User Scenarios & Testing](#user-scenarios--testing)`. Only include sections that actually appear in the final document.
+5. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
 
 6. **Specification Quality Validation**: After writing the initial spec, validate it against quality criteria:
 

templates/commands/tasks.md

@@ -77,7 +77,6 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Validate task completeness (each user story has all needed tasks, independently testable)
 
 4. **Generate tasks.md**: Use `templates/tasks-template.md` as structure, fill with:
-   - A **Table of Contents** section immediately after the title and metadata lines, and before the first `##` section. List all `##`-level headings as markdown anchor links (lowercase, spaces to hyphens, strip special characters). Only include sections that actually appear in the final document.
    - Correct feature name from plan.md
    - Phase 1: Setup tasks (project initialization)
    - Phase 2: Foundational tasks (blocking prerequisites for all user stories)

templates/plan-template.md

@@ -3,14 +3,6 @@
 **Branch**: `[###-feature-name]` | **Date**: [DATE] | **Spec**: [link]
 **Input**: Feature specification from `/specs/[###-feature-name]/spec.md`
 
-## Table of Contents
-
-- Summary
-- Technical Context
-- Constitution Check
-- Project Structure
-- Complexity Tracking
-
 **Note**: This template is filled in by the `/speckit.plan` command. See `.specify/templates/plan-template.md` for the execution workflow.
 
 ## Summary

templates/spec-template.md

@@ -5,13 +5,6 @@
 **Status**: Draft  
 **Input**: User description: "$ARGUMENTS"
 
-## Table of Contents
-
-- User Scenarios & Testing
-- Requirements
-- Success Criteria
-- Assumptions
-
 ## User Scenarios & Testing *(mandatory)*
 
 <!--

templates/tasks-template.md

@@ -12,19 +12,6 @@ description: "Task list template for feature implementation"
 
 **Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.
 
-## Table of Contents
-
-- Format
-- Path Conventions
-- Phase 1: Setup (Shared Infrastructure)
-- Phase 2: Foundational (Blocking Prerequisites)
-- Phase 3+: User Story phases (generated from spec.md priorities)
-- Phase N: Polish & Cross-Cutting Concerns
-- Dependencies & Execution Order
-- Parallel Example: User Story 1
-- Implementation Strategy
-- Notes
-
 ## Format: `[ID] [P?] [Story] Description`
 
 - **[P]**: Can run in parallel (different files, no dependencies)