fix: address additional PR review feedback - placeholder consistency and grammar

- Fix remaining [n] → [NN] placeholder inconsistencies in generate-spec.md and generate-task-list-from-spec.md
- Fix grammar: 'top level' → 'top-level' in archive document
- Fix capitalization: 'markdown' → 'Markdown' as proper noun
- All quality gates pass: pre-commit hooks, tests (79/85%), and linting

Author: ryderstorm

docs/archive/refactor-sdd-workflow-prompts.md

@@ -42,7 +42,7 @@ Based on prompt engineering best practices for spec-driven development, the work
 **generate-task-list-from-spec.md:**
 
 - Add explanation of why parent tasks are generated first
-- Add guidance on how to evaluate top level tasks against the spec
+- Add guidance on how to evaluate top-level tasks against the spec
 - Enhance the "Generate sub tasks" interaction with clearer context
 - Add "DO NOT generate sub-tasks until explicitly requested" constraint
 - Add clear guidance on "What happens next" section after task generation, including when to move to task implementation and how to do it
@@ -134,7 +134,7 @@ All specs, tasks, and proofs should be stored in `./docs/specs`. Simple director
 - **Co-located artifacts**: Proofs are organized by task number within each spec
 - **Team-managed lifecycle**: Teams determine when to archive specs, tasks, and proofs as they see fit
 - **Clear traceability**: Easy to see which proofs belong to which tasks and specs
-- **Consistent naming**: Proof artifacts follow single markdown file pattern `[spec]-[task]-proofs.md` containing all evidence as markdown code blocks
+- **Consistent naming**: Proof artifacts follow single Markdown file pattern `[spec]-[task]-proofs.md` containing all evidence as Markdown code blocks
 
 ### Simplify numbering system
 

prompts/generate-spec.md

@@ -289,7 +289,7 @@ Follow this exact sequence:
    - **Demoable Units** focus on tangible progress and WHAT will be shown
    - **Functional Requirements** focus on system behavior and WHAT the system must do
    - **Technical Considerations** focus on implementation constraints and HOW it will be built
-5. **Save**: Create directory `./docs/specs/[n]-spec-[feature-name]/` and save file as `[n]-spec-[feature-name].md` inside it
+5. **Save**: Create directory `./docs/specs/[NN]-spec-[feature-name]/` and save file as `[NN]-spec-[feature-name].md` inside it
 6. **Review and Refine**: Validate completeness and clarity with the user
 7. **Guide User**: Direct user to the next workflow step (`/generate-task-list-from-spec`)
 8. **Stop**: Stop working once user confirms spec is complete

prompts/generate-task-list-from-spec.md

@@ -103,7 +103,7 @@ Before generating any tasks, you must follow this reasoning process:
 
 ### Phase 1: Analysis and Planning (Internal)
 
-1. **Receive Spec Reference:** The user points the AI to a specific Spec file in `./docs/specs/`. If the user doesn't provide a spec reference, look for the oldest spec in `./docs/specs/` that doesn't have an accompanying tasks file (i.e., no `[n]-tasks-[feature-name].md` file in the same directory).
+1. **Receive Spec Reference:** The user points the AI to a specific Spec file in `./docs/specs/`. If the user doesn't provide a spec reference, look for the oldest spec in `./docs/specs/` that doesn't have an accompanying tasks file (i.e., no `[NN]-tasks-[feature-name].md` file in the same directory).
 2. **Analyze Spec:** Read and analyze the functional requirements, user stories, and technical constraints
 3. **Assess Current State:** Review existing codebase and documentation to understand:
    - Architectural patterns and conventions
@@ -122,7 +122,7 @@ Before generating any tasks, you must follow this reasoning process:
    - Have clear completion criteria
    - Follow logical dependencies
    - Be implementable in a reasonable timeframe
-2. **Save Initial Task List:** Save the parent tasks to `./docs/specs/[n]-spec-[feature-name]/[n]-tasks-[feature-name].md` before proceeding
+2. **Save Initial Task List:** Save the parent tasks to `./docs/specs/[NN]-spec-[feature-name]/[NN]-tasks-[feature-name].md` before proceeding
 3. **Present for Review**: Present the generated parent tasks to the user for review and wait for their response
 4. **Wait for Confirmation**: Pause and wait for user to respond with "Generate sub tasks"
 
@@ -132,7 +132,7 @@ Wait for explicit user confirmation before generating sub-tasks. Then:
 
 1. **Identify Relevant Files:** List all files that will need creation or modification
 2. **Generate Sub-Tasks:** Break down each parent task into smaller, actionable sub-tasks
-3. **Update Task List:** Update the existing `./docs/specs/[n]-spec-[feature-name]/[n]-tasks-[feature-name].md` file with the sub-tasks and relevant files sections
+3. **Update Task List:** Update the existing `./docs/specs/[NN]-spec-[feature-name]/[NN]-tasks-[feature-name].md` file with the sub-tasks and relevant files sections
 
 ## Phase 2 Output Format (Parent Tasks Only)