@leeovery/claude-technical-workflows 2.1.27 → 2.1.28

package/skills/technical-planning/references/process-review-findings.md

@@ -0,0 +1,171 @@
+# Process Review Findings
+
+*Reference for **[plan-review](plan-review.md)***
+
+---
+
+Process findings from a review agent interactively with the user. The agent writes findings — with full fix content — to a tracking file. Read the tracking file and present each finding for approval.
+
+**Review type**: `{review_type:[traceability|integrity]}` — set by the calling context (B or C in plan-review.md).
+
+#### If STATUS is `clean`
+
+> *Output the next fenced block as a code block:*
+
+```
+{Review type} review complete — no findings.
+```
+
+→ Return to **[plan-review.md](plan-review.md)** for the next phase.
+
+#### If STATUS is `findings`
+
+Read the tracking file at the path returned by the agent (`TRACKING_FILE`).
+
+→ Proceed to **A. Summary**.
+
+---
+
+## A. Summary
+
+> *Output the next fenced block as a code block:*
+
+```
+{Review type} Review — {N} items found
+
+1. {title} ({type or severity}) — {change_type}
+   {1-2 line summary from the Details field}
+
+2. ...
+```
+
+> *Output the next fenced block as a code block:*
+
+```
+Let's work through these one at a time, starting with #1.
+```
+
+→ Proceed to **B. Process One Item at a Time**.
+
+---
+
+## B. Process One Item at a Time
+
+Work through each finding **sequentially**. For each finding: present it, show the proposed fix, then route through the gate.
+
+### Present Finding
+
+Show the finding with its full fix content, read directly from the tracking file.
+
+> *Output the next fenced block as markdown (not a code block):*
+
+```
+**Finding {N} of {total}: {Brief Title}**
+
+@if(review_type = traceability)
+- **Type**: Missing from plan | Hallucinated content | Incomplete coverage
+- **Spec Reference**: {from tracking file}
+- **Plan Reference**: {from tracking file}
+- **Change Type**: {from tracking file}
+@else
+- **Severity**: Critical | Important | Minor
+- **Plan Reference**: {from tracking file}
+- **Category**: {from tracking file}
+- **Change Type**: {from tracking file}
+@endif
+
+**Details**: {from tracking file}
+
+**Current**:
+{from tracking file — the existing plan content}
+
+**Proposed**:
+{from tracking file — the replacement content}
+```
+
+### Check Gate Mode
+
+Check `finding_gate_mode` in the Plan Index File frontmatter.
+
+#### If `finding_gate_mode: auto`
+
+1. Apply the fix to the plan (use **Proposed** content exactly as in tracking file)
+2. Update the tracking file: set resolution to "Fixed"
+3. Commit the tracking file and plan changes
+
+> *Output the next fenced block as a code block:*
+
+```
+Finding {N} of {total}: {Brief Title} — approved. Applied to plan.
+```
+
+→ Present the next pending finding, or proceed to **C. After All Findings Processed**.
+
+#### If `finding_gate_mode: gated`
+
+> *Output the next fenced block as markdown (not a code block):*
+
+```
+· · · · · · · · · · · ·
+**Finding {N} of {total}: {Brief Title}**
+- **`y`/`yes`** — Approved. Apply to the plan verbatim.
+- **`a`/`auto`** — Approve this and all remaining findings automatically
+- **`s`/`skip`** — Leave as-is, move to next finding.
+- **Or provide feedback** to adjust the fix.
+· · · · · · · · · · · ·
+```
+
+**STOP.** Wait for user response.
+
+#### If the user provides feedback
+
+Incorporate feedback and re-present the proposed fix **in full**. Update the tracking file with the revised content. Then ask the same choice again. Repeat until approved or skipped.
+
+#### If approved
+
+1. Apply the fix to the plan — use the **Proposed** content exactly as shown, using the output format adapter to determine how it's written. Do not modify content between approval and writing.
+2. Update the tracking file: set resolution to "Fixed", add any discussion notes.
+3. Commit the tracking file and any plan changes — ensures progress survives context refresh.
+4. > *Output the next fenced block as a code block:*
+
+   ```
+   Finding {N} of {total}: {Brief Title} — fixed.
+   ```
+
+→ Present the next pending finding, or proceed to **C. After All Findings Processed**.
+
+#### If `auto`
+
+1. Apply the fix (same as "If approved" above)
+2. Update the tracking file: set resolution to "Fixed"
+3. Update `finding_gate_mode: auto` in the Plan Index File frontmatter
+4. Commit
+5. Process all remaining findings using the auto-mode flow above
+
+→ After all processed, proceed to **C. After All Findings Processed**.
+
+#### If skipped
+
+1. Update the tracking file: set resolution to "Skipped", note the reason.
+2. Commit the tracking file — ensures progress survives context refresh.
+3. > *Output the next fenced block as a code block:*
+
+   ```
+   Finding {N} of {total}: {Brief Title} — skipped.
+   ```
+
+→ Present the next pending finding, or proceed to **C. After All Findings Processed**.
+
+---
+
+## C. After All Findings Processed
+
+1. **Mark the tracking file as complete** — Set `status: complete`.
+2. **Commit** the tracking file and any plan changes.
+3. > *Output the next fenced block as a code block:*
+
+   ```
+   {Review type} review complete — {N} findings processed.
+   ```
+
+→ Return to **[plan-review.md](plan-review.md)** for the next phase.

package/skills/technical-planning/references/{steps/resolve-dependencies.md → resolve-dependencies.md}

@@ -1,28 +1,32 @@
 # Resolve External Dependencies
 
-*Reference for **[technical-planning](../../SKILL.md)***
+*Reference for **[technical-planning](../SKILL.md)***
 
 ---
 
-Orient the user:
+> *Output the next fenced block as a code block:*
 
-"All phases and tasks are written. Now I'll check for external dependencies — things this plan needs from other topics or systems."
+```
+All phases and tasks are written. Now I'll check for external
+dependencies — things this plan needs from other topics or systems.
+```
 
-After all phases are detailed and written, handle external dependencies — things this plan needs from other topics or systems.
+Handle external dependencies — things this plan needs from other topics or systems.
 
-Dependencies are stored in the plan's **frontmatter** as `external_dependencies`. See [dependencies.md](../dependencies.md) for the format and states.
+Dependencies are stored in the plan's **frontmatter** as `external_dependencies`. See [dependencies.md](dependencies.md) for the format and states.
 
 #### If the specification has a Dependencies section
 
 The specification's Dependencies section lists what this feature needs from outside its own scope. These must be documented in the plan so implementation knows what is blocked and what is available.
 
-1. **Document each dependency** in the plan's `external_dependencies` frontmatter field using the format described in [dependencies.md](../dependencies.md). Initially, record each as `state: unresolved`.
+1. **Document each dependency** in the plan's `external_dependencies` frontmatter field using the format described in [dependencies.md](dependencies.md). Initially, record each as `state: unresolved`.
 
 2. **Resolve where possible** — For each dependency, check whether a plan already exists for that topic:
    - If a plan exists, identify the specific task(s) that satisfy the dependency. Query the output format to find relevant tasks. If ambiguous, ask the user which tasks apply. Update the dependency entry from `state: unresolved` → `state: resolved` with the `task_id`.
    - If no plan exists, leave the dependency as `state: unresolved`. It will be linked later via `/link-dependencies` or when that topic is planned.
+   - If no other plans exist at all, skip resolution — there is nothing to resolve against. All dependencies remain unresolved.
 
-3. **Reverse check** — Check whether any existing plans have unresolved dependencies in their `external_dependencies` frontmatter that reference *this* topic. Now that this plan exists with specific tasks:
+3. **Reverse check** — If other plans exist, check whether any have unresolved dependencies in their `external_dependencies` frontmatter that reference *this* topic. Now that this plan exists with specific tasks:
    - Scan other plan files' `external_dependencies` for entries that mention this topic
    - For each match, identify which task(s) in the current plan satisfy that dependency
    - Update the other plan's `external_dependencies` entry with the task reference (`state: resolved`, `task_id`)
@@ -37,24 +41,26 @@ external_dependencies: []
 
 This makes it clear that dependencies were considered and none exist — not that they were overlooked.
 
-#### If no other plans exist
-
-Skip the resolution and reverse check — there is nothing to resolve against. Document the dependencies as unresolved. They will be linked when other topics are planned, or via `/link-dependencies`.
+---
 
-**STOP.** Present a summary of the dependency state: what was documented, what was resolved, what remains unresolved, and any reverse resolutions made.
+Present a summary of the dependency state: what was documented, what was resolved, what remains unresolved, and any reverse resolutions made.
 
 > *Output the next fenced block as markdown (not a code block):*
 
 ```
 · · · · · · · · · · · ·
 **To proceed:**
-- **`y`/`yes`** — Approved. I'll proceed to plan review.
+- **`y`/`yes`** — Approved.
 - **Or tell me what to change.**
 · · · · · · · · · · · ·
 ```
 
+**STOP.** Wait for the user's response.
+
 #### If the user provides feedback
 
 Incorporate feedback, re-present the updated dependency state, and ask again. Repeat until approved.
 
 #### If approved
+
+Commit: `planning({topic}): resolve external dependencies`

package/skills/technical-planning/references/review-integrity.md

@@ -0,0 +1,127 @@
+# Plan Integrity Review
+
+*Reference for **[plan-review](plan-review.md)***
+
+---
+
+Review the plan **as a standalone document** for structural quality, implementation readiness, and adherence to planning standards.
+
+**Purpose**: Ensure that the plan itself is well-structured, complete, and ready for implementation. An implementer (human or AI) should be able to pick up this plan and execute it without ambiguity, without needing to make design decisions, and without referring back to the specification.
+
+**Key distinction**: The traceability review checked *what's in the plan* against the spec. This review checks *how it's structured* — looking inward at the plan's own quality.
+
+Read the plan end-to-end — carefully, as if you were about to implement it. For each phase, each task, and the plan overall, check against the following criteria:
+
+## What You're NOT Doing
+
+- **Not redesigning the plan** — You're checking quality, not re-architecting
+- **Not adding content from outside the spec** — If a task needs more detail, the detail must come from the specification
+- **Not gold-plating** — Focus on issues that would actually impact implementation
+- **Not second-guessing phase structure** — Unless it's fundamentally broken, the structure stands
+
+---
+
+## What to Look For
+
+1. **Task Template Compliance**
+   - Every task has all required fields: Problem, Solution, Outcome, Do, Acceptance Criteria, Tests
+   - Problem statements clearly explain WHY the task exists
+   - Solution statements describe WHAT we're building
+   - Outcome statements define what success looks like
+   - Acceptance criteria are concrete and verifiable (not vague)
+   - Tests include edge cases, not just happy paths
+
+2. **Vertical Slicing**
+   - Tasks deliver complete, testable functionality
+   - No horizontal slicing (all models, then all services, then all wiring)
+   - Each task can be verified independently
+   - Each task is a single TDD cycle
+
+3. **Phase Structure**
+   - Phases follow logical progression (Foundation → Core → Edge cases → Refinement)
+   - Each phase has clear acceptance criteria
+   - Each phase is independently testable
+   - Phase boundaries make sense (not arbitrary groupings)
+
+4. **Dependencies and Ordering**
+   - Task dependencies are explicit and correct — each dependency reflects a genuine data or capability requirement
+   - No circular dependencies exist in the task graph
+   - Priority assignments reflect graph position — foundation tasks and tasks that unblock others are prioritised appropriately
+   - An implementer can determine execution order from the dependency graph and priorities alone
+
+5. **Task Self-Containment**
+   - Each task contains all context needed for execution
+   - No task requires reading other tasks to understand what to do
+   - Relevant specification decisions are pulled into task context
+   - An implementer could pick up any single task and execute it
+
+6. **Scope and Granularity**
+   - Each task is one TDD cycle (not too large, not too small)
+   - No task requires multiple unrelated implementation steps
+   - No task is so granular it's just mechanical boilerplate
+
+7. **Acceptance Criteria Quality**
+   - Criteria are pass/fail, not subjective
+   - Criteria cover the actual requirement, not just "code exists"
+   - Edge case criteria are specific about boundary values and behaviors
+   - No criteria that an implementer would have to interpret
+
+8. **External Dependencies**
+   - All external dependencies from the specification are documented in the plan
+   - Dependencies are in the correct state (resolved/unresolved)
+   - No external dependencies were missed or invented
+
+---
+
+## Tracking File
+
+After completing the analysis, create a tracking file at `docs/workflow/planning/{topic}/review-integrity-tracking-c{N}.md` (where N is the current review cycle).
+
+Categorize each finding by severity:
+
+- **Critical**: Would block implementation or cause incorrect behavior
+- **Important**: Would force implementer to guess or make design decisions
+- **Minor**: Polish or improvement that strengthens the plan
+
+Tracking files are **never deleted**. After all findings are processed, the orchestrator marks `status: complete`. Previous cycles' files persist as review history.
+
+**Format**:
+```markdown
+---
+status: in-progress
+created: YYYY-MM-DD  # Use today's actual date
+cycle: {N}
+phase: Plan Integrity Review
+topic: {Topic Name}
+---
+
+# Review Tracking: {Topic Name} - Integrity
+
+## Findings
+
+### 1. [Brief Title]
+
+**Severity**: Critical | Important | Minor
+**Plan Reference**: [Phase/task in plan]
+**Category**: [Which review criterion — e.g., "Task Template Compliance", "Vertical Slicing"]
+**Change Type**: [update-task | add-to-task | remove-from-task | add-task | remove-task | add-phase | remove-phase]
+
+**Details**:
+[What the issue is and why it matters for implementation]
+
+**Current**:
+[The existing content as it appears in the plan — omit for add-task/add-phase]
+
+**Proposed**:
+[The replacement/new content in full plan format — omit for remove-task/remove-phase]
+
+**Resolution**: Pending
+**Notes**:
+
+---
+
+### 2. [Next Finding]
+...
+```
+
+Commit the tracking file after creation: `planning({topic}): integrity review cycle {N}`

package/skills/technical-planning/references/review-traceability.md

@@ -0,0 +1,105 @@
+# Traceability Review
+
+*Reference for **[plan-review](plan-review.md)***
+
+---
+
+Compare the plan against the specification **in both directions** to ensure complete, faithful translation.
+
+**Purpose**: Verify that the plan is a faithful, complete translation of the specification. Everything in the spec must be in the plan, and everything in the plan must trace back to the spec. This is the anti-hallucination gate — it catches both missing content and invented content before implementation begins.
+
+Re-read the specification in full before starting. Don't rely on memory — read it as if seeing it for the first time. Then check both directions:
+
+## What You're NOT Doing
+
+- **Not adding new requirements** — If something isn't in the spec, the fix is to remove it from the plan or flag it with `[needs-info]`, not to justify its inclusion
+- **Not expanding scope** — Missing spec content should be added as tasks; it shouldn't trigger re-architecture of the plan
+- **Not being lenient with hallucinated content** — If it can't be traced to the specification, it must be removed or the user must explicitly approve it as an intentional addition
+- **Not re-litigating spec decisions** — The specification reflects validated decisions; you're checking the plan's fidelity to them
+
+---
+
+## Direction 1: Specification → Plan (completeness)
+
+Is everything from the specification represented in the plan?
+
+1. **For each specification element, verify plan coverage**:
+   - Every decision → has a task that implements it
+   - Every requirement → has a task with matching acceptance criteria
+   - Every edge case → has a task or is explicitly handled within a task
+   - Every constraint → is reflected in the relevant tasks
+   - Every data model or schema → appears in the relevant tasks
+   - Every integration point → has a task that addresses it
+   - Every validation rule → has a task with test coverage
+
+2. **Check depth of coverage** — It's not enough that a spec topic is *mentioned* in a task. The task must contain enough detail that an implementer wouldn't need to go back to the specification. Summarizing and rewording is fine, but the essence and instruction must be preserved.
+
+## Direction 2: Plan → Specification (fidelity)
+
+Is everything in the plan actually from the specification? This is the anti-hallucination check.
+
+1. **For each task, trace its content back to the specification**:
+   - The Problem statement → ties to a spec requirement or decision
+   - The Solution approach → matches the spec's architectural choices
+   - The implementation details → come from the spec, not invention
+   - The acceptance criteria → verify spec requirements, not made-up ones
+   - The tests → cover spec behaviors, not imagined scenarios
+   - The edge cases → are from the spec, not invented
+
+2. **Flag anything that cannot be traced**:
+   - Content that has no corresponding specification section
+   - Technical approaches not discussed in the specification
+   - Requirements or behaviors not mentioned anywhere in the spec
+   - Edge cases the specification never identified
+   - Acceptance criteria testing things the specification doesn't require
+
+3. **The standard for hallucination**: If you cannot point to a specific part of the specification that justifies a piece of plan content, it is hallucinated. It doesn't matter how reasonable it seems — if it wasn't discussed and validated, it doesn't belong in the plan.
+
+---
+
+## Tracking File
+
+After completing the analysis, create a tracking file at `docs/workflow/planning/{topic}/review-traceability-tracking-c{N}.md` (where N is the current review cycle).
+
+Tracking files are **never deleted**. After all findings are processed, the orchestrator marks `status: complete`. Previous cycles' files persist as review history.
+
+**Format**:
+```markdown
+---
+status: in-progress
+created: YYYY-MM-DD  # Use today's actual date
+cycle: {N}
+phase: Traceability Review
+topic: {Topic Name}
+---
+
+# Review Tracking: {Topic Name} - Traceability
+
+## Findings
+
+### 1. [Brief Title]
+
+**Type**: Missing from plan | Hallucinated content | Incomplete coverage
+**Spec Reference**: [Section/decision in specification, or "N/A"]
+**Plan Reference**: [Phase/task in plan, or "N/A" for missing content]
+**Change Type**: [update-task | add-to-task | remove-from-task | add-task | remove-task | add-phase | remove-phase]
+
+**Details**:
+[What was found and why it matters]
+
+**Current**:
+[The existing content as it appears in the plan — omit for add-task/add-phase]
+
+**Proposed**:
+[The replacement/new content in full plan format — omit for remove-task/remove-phase]
+
+**Resolution**: Pending
+**Notes**:
+
+---
+
+### 2. [Next Finding]
+...
+```
+
+Commit the tracking file after creation: `planning({topic}): traceability review cycle {N}`

package/skills/technical-planning/references/task-design.md

@@ -140,7 +140,7 @@ Every task should follow this structure:
 > Relevant details from specification: code examples, architectural decisions,
 > data models, or constraints that inform implementation.
 
-**Spec Reference**: `docs/workflow/specification/{topic}.md` (if specification was provided)
+**Spec Reference**: `docs/workflow/specification/{topic}/specification.md` (if specification was provided)
 ```
 
 ### Field Requirements

package/skills/technical-planning/references/{steps/verify-source-material.md → verify-source-material.md}

@@ -1,6 +1,6 @@
 # Verify Source Material
 
-*Reference for **[technical-planning](../../SKILL.md)***
+*Reference for **[technical-planning](../SKILL.md)***
 
 ---
 
@@ -15,6 +15,6 @@ Verify that all source material exists and is accessible before entering agent-d
 ### Example
 
 ```bash
-ls docs/workflow/specification/{topic}.md
-ls docs/workflow/specification/{cross-cutting-spec}.md
+ls docs/workflow/specification/{topic}/specification.md
+ls docs/workflow/specification/{cross-cutting-spec}/specification.md
 ```

package/skills/technical-research/SKILL.md

@@ -23,11 +23,27 @@ Either way: Explore feasibility (technical, business, market), validate assumpti
 
 **Before proceeding**, confirm the required input is clear. If anything is missing or unclear, **STOP** and resolve with the user.
 
-- **No topic provided?**
-  "What would you like to research or explore? This could be a new idea, a technical concept, a market opportunity — anything you want to investigate."
+#### If no topic provided
 
-- **Topic is vague or could go many directions?**
-  "You mentioned {topic}. That could cover a lot of ground — is there a specific angle you'd like to start with, or should I explore broadly?"
+> *Output the next fenced block as a code block:*
+
+```
+What would you like to research or explore? This could be a new idea, a
+technical concept, a market opportunity — anything you want to investigate.
+```
+
+**STOP.** Wait for user response.
+
+#### If topic is vague or could go many directions
+
+> *Output the next fenced block as a code block:*
+
+```
+You mentioned {topic}. That could cover a lot of ground — is there a specific
+angle you'd like to start with, or should I explore broadly?
+```
+
+**STOP.** Wait for user response.
 
 ---
 

package/skills/technical-review/SKILL.md

@@ -24,11 +24,28 @@ Either way: Verify plan tasks were implemented, tested adequately, and meet qual
 
 **Before proceeding**, verify the required input is available. If anything is missing, **STOP** — do not proceed until resolved.
 
-- **No plan provided?**
-  > "I need the implementation plan to review against. Could you point me to the plan file (e.g., `docs/workflow/planning/{topic}.md`)?"
+#### If no plan provided
 
-- **Plan references a specification that can't be found?**
-  > "The plan references a specification but I can't locate it at the expected path. Could you confirm where the specification is? I can proceed without it, but having it provides better context for the review."
+> *Output the next fenced block as a code block:*
+
+```
+I need the implementation plan to review against. Could you point me to the
+plan file (e.g., docs/workflow/planning/{topic}/plan.md)?
+```
+
+**STOP.** Wait for user response.
+
+#### If plan references a specification that can't be found
+
+> *Output the next fenced block as a code block:*
+
+```
+The plan references a specification but I can't locate it at the expected path.
+Could you confirm where the specification is? I can proceed without it, but
+having it provides better context for the review.
+```
+
+**STOP.** Wait for user response.
 
 The specification is optional — the review can proceed with just the plan.
 

package/skills/technical-specification/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: technical-specification
-description: "Build validated specifications from source material through collaborative refinement. Use when: (1) User asks to create/build a specification from source material, (2) User wants to validate and refine content before planning, (3) Converting source material (discussions, research, requirements) into standalone specifications, (4) User says 'specify this' or 'create a spec', (5) Need to filter hallucinations and enrich gaps before formal planning. Creates specifications in docs/workflow/specification/{topic}.md that can be used to build implementation plans."
+description: "Build validated specifications from source material through collaborative refinement. Use when: (1) User asks to create/build a specification from source material, (2) User wants to validate and refine content before planning, (3) Converting source material (discussions, research, requirements) into standalone specifications, (4) User says 'specify this' or 'create a spec', (5) Need to filter hallucinations and enrich gaps before formal planning. Creates specifications in docs/workflow/specification/{topic}/specification.md that can be used to build implementation plans."
 user-invocable: false
 ---
 
@@ -29,14 +29,39 @@ Either way: Transform unvalidated reference material into a specification that's
 
 **Before proceeding**, verify all required inputs are available and unambiguous. If anything is missing or unclear, **STOP** — do not proceed until resolved.
 
-- **No source material provided?**
-  > "I need source material to build a specification from. Could you point me to the source files (e.g., `docs/workflow/discussion/{topic}.md`), or provide the content directly?"
+#### If no source material provided
 
-- **No topic name provided?**
-  > "What should the specification be named? This determines the output file: `docs/workflow/specification/{name}.md`."
+> *Output the next fenced block as a code block:*
 
-- **Source material seems incomplete or unclear?**
-  > "I have the source material, but {concern}. Should I proceed as-is, or is there additional material I should review?"
+```
+I need source material to build a specification from. Could you point me to the
+source files (e.g., docs/workflow/discussion/{topic}.md), or provide the content
+directly?
+```
+
+**STOP.** Wait for user response.
+
+#### If no topic name provided
+
+> *Output the next fenced block as a code block:*
+
+```
+What should the specification be named? This determines the output file:
+docs/workflow/specification/{name}/specification.md
+```
+
+**STOP.** Wait for user response.
+
+#### If source material seems incomplete or unclear
+
+> *Output the next fenced block as a code block:*
+
+```
+I have the source material, but {concern}. Should I proceed as-is, or is there
+additional material I should review?
+```
+
+**STOP.** Wait for user response.
 
 **Multiple sources:** When multiple sources are provided, extract exhaustively from ALL of them. Content may be scattered across sources - a decision in one may have constraints or details in another. The specification consolidates everything into a single standalone document.
 
@@ -50,6 +75,7 @@ Context refresh (compaction) summarizes the conversation, losing procedural deta
 2. **Read all tracking and state files** for the current topic — plan index files, review tracking files, implementation tracking files, or any working documents this skill creates. These are your source of truth for progress.
 3. **Check git state.** Run `git status` and `git log --oneline -10` to see recent commits. Commit messages follow a conventional pattern that reveals what was completed.
 4. **Announce your position** to the user before continuing: what step you believe you're at, what's been completed, and what comes next. Wait for confirmation.
+5. **Check `finding_gate_mode`** in the specification frontmatter — if `auto`, the user previously opted in during this session. Preserve this value.
 
 Do not guess at progress or continue from memory. The files on disk and git history are authoritative — your recollection is not.
 
@@ -59,7 +85,7 @@ Do not guess at progress or continue from memory. The files on disk and git hist
 
 **Load**: [specification-guide.md](references/specification-guide.md)
 
-**Output**: `docs/workflow/specification/{topic}.md`
+**Output**: `docs/workflow/specification/{topic}/specification.md`
 
 **When complete**: User signs off on the specification.