@leeovery/claude-technical-workflows 2.0.16 → 2.0.18

package/commands/workflow:start-review.md

@@ -0,0 +1,112 @@
+---
+description: Start a review session from an existing plan and implementation. Discovers available plans, validates implementation exists, and invokes the technical-review skill.
+---
+
+Invoke the **technical-review** skill for this conversation.
+
+## Workflow Context
+
+This is **Phase 6** of the six-phase workflow:
+
+| Phase | Focus | You |
+|-------|-------|-----|
+| 1. Research | EXPLORE - ideas, feasibility, market, business | |
+| 2. Discussion | WHAT and WHY - decisions, architecture, edge cases | |
+| 3. Specification | REFINE - validate into standalone spec | |
+| 4. Planning | HOW - phases, tasks, acceptance criteria | |
+| 5. Implementation | DOING - tests first, then code | |
+| **6. Review** | VALIDATING - check work against artifacts | HERE |
+
+**Stay in your lane**: Verify that every plan task was implemented, tested adequately, and meets quality standards. Don't fix code - identify problems. You're reviewing, not building.
+
+---
+
+## Instructions
+
+Follow these steps EXACTLY as written. Do not skip steps or combine them.
+
+Before beginning, discover existing work and gather necessary information.
+
+## Important
+
+Use simple, individual commands. Never combine multiple operations into bash loops or one-liners. Execute commands one at a time.
+
+## Step 1: Discover Existing Plans
+
+Scan the codebase for plans:
+
+1. **Find plans**: Look in `docs/workflow/planning/`
+   - Run `ls docs/workflow/planning/` to list plan files
+   - Each file is named `{topic}.md`
+
+2. **Check plan format**: For each plan file
+   - Run `head -10 docs/workflow/planning/{topic}.md` to read the frontmatter
+   - Note the `format:` field
+   - Do NOT use bash loops - run separate `head` commands for each topic
+
+## Step 2: Check Prerequisites
+
+**If no plans exist:**
+
+```
+No plans found in docs/workflow/planning/
+
+The review phase requires a completed implementation based on a plan. Please run /workflow:start-planning first to create a plan, then /workflow:start-implementation to build it.
+```
+
+Stop here and wait for the user to acknowledge.
+
+## Step 3: Present Options to User
+
+Show what you found:
+
+```
+Plans found:
+  {topic-1} (format: {format})
+  {topic-2} (format: {format})
+
+Which plan would you like to review the implementation for?
+```
+
+**Auto-select:** If exactly one plan exists, automatically select it and proceed to Step 4. Inform the user which plan was selected. Do not ask for confirmation.
+
+## Step 4: Identify Implementation Scope
+
+Determine what code to review:
+
+1. **Check git status** - See what files have changed
+2. **Ask user** if unclear:
+   - "What code should I review? (all changes, specific directories, or specific files)"
+
+## Step 5: Locate Specification (Optional)
+
+Check if a specification exists:
+
+1. **Look for specification**: Check `docs/workflow/specification/{topic}.md`
+2. **If exists**: Note the path for context
+3. **If missing**: Proceed without - the plan is the primary review artifact
+
+## Step 6: Invoke Review Skill
+
+Pass to the technical-review skill:
+- Plan: `docs/workflow/planning/{topic}.md`
+- Format: (from frontmatter)
+- Specification: `docs/workflow/specification/{topic}.md` (if exists)
+- Implementation scope: (files/directories to review)
+
+**Example handoff:**
+```
+Review session for: {topic}
+Plan: docs/workflow/planning/{topic}.md
+Format: {format}
+Specification: docs/workflow/specification/{topic}.md (or: Not available)
+Scope: {implementation scope}
+
+Begin review using the technical-review skill.
+```
+
+## Notes
+
+- Ask questions clearly and wait for responses before proceeding
+- Review produces feedback (approve, request changes, or comments) - it does NOT fix code
+- Verify ALL plan tasks, don't sample

package/commands/workflow:start-specification.md

@@ -0,0 +1,106 @@
+---
+description: Start a specification session from an existing discussion. Discovers available discussions, checks for existing specifications, and invokes the technical-specification skill.
+---
+
+Invoke the **technical-specification** skill for this conversation.
+
+## Workflow Context
+
+This is **Phase 3** of the six-phase workflow:
+
+| Phase | Focus | You |
+|-------|-------|-----|
+| 1. Research | EXPLORE - ideas, feasibility, market, business | |
+| 2. Discussion | WHAT and WHY - decisions, architecture, edge cases | |
+| **3. Specification** | REFINE - validate into standalone spec | ◀ HERE |
+| 4. Planning | HOW - phases, tasks, acceptance criteria | |
+| 5. Implementation | DOING - tests first, then code | |
+| 6. Review | VALIDATING - check work against artifacts | |
+
+**Stay in your lane**: Validate and refine discussion content into a standalone specification. Don't jump to planning, phases, tasks, or code. The specification is the "line in the sand" - everything after this has hard dependencies on it.
+
+---
+
+## Instructions
+
+Follow these steps EXACTLY as written. Do not skip steps or combine them. Present output using the EXACT format shown in examples - do not simplify or alter the formatting.
+
+Before beginning, discover existing work and gather necessary information.
+
+## Important
+
+Use simple, individual commands. Never combine multiple operations into bash loops or one-liners. Execute commands one at a time.
+
+## Step 1: Discover Existing Work
+
+Scan the codebase for discussions and specifications:
+
+1. **Find discussions**: Look in `docs/workflow/discussion/`
+   - Run `ls docs/workflow/discussion/` to list discussion files
+   - Each file is named `{topic}.md`
+
+2. **Check discussion status**: For each discussion file
+   - Run `head -20 docs/workflow/discussion/{topic}.md` to read the frontmatter and extract the `status:` field
+   - Do NOT use bash loops - run separate `head` commands for each topic
+
+3. **Check for existing specifications**: Look in `docs/workflow/specification/`
+   - Identify discussions that don't have corresponding specifications
+
+## Step 2: Check Prerequisites
+
+**If no discussions exist:**
+
+```
+⚠️ No discussions found in docs/workflow/discussion/
+
+The specification phase requires a completed discussion. Please run /workflow:start-discussion first to document the technical decisions, edge cases, and rationale before creating a specification.
+```
+
+Stop here and wait for the user to acknowledge.
+
+## Step 3: Present Options to User
+
+Show what you found using a list like below:
+
+```
+📂 Discussions found:
+  ✅ {topic-1} - Concluded - ready for specification
+  ⚠️ {topic-2} - Exploring - not ready for specification
+  ✅ {topic-3} - Concluded - specification exists
+
+Which discussion would you like to create a specification for?
+```
+
+**Important:** Only concluded discussions should proceed to specification. If a discussion is still exploring, advise the user to complete the discussion phase first.
+
+Ask: **Which discussion would you like to specify?**
+
+## Step 4: Gather Additional Context
+
+Ask:
+- Any additional context or priorities to consider?
+- Any constraints or changes since the discussion concluded?
+- Are there any existing partial plans or related documentation I should review?
+
+## Step 5: Invoke Specification Skill
+
+Pass to the technical-specification skill:
+- Source: `docs/workflow/discussion/{topic}.md`
+- Output: `docs/workflow/specification/{topic}.md`
+- Additional context gathered
+
+**Example handoff:**
+```
+Specification session for: {topic}
+Source: docs/workflow/discussion/{topic}.md
+Output: docs/workflow/specification/{topic}.md
+
+Begin specification using the technical-specification skill.
+Reference: specification-guide.md
+```
+
+## Notes
+
+- Ask questions clearly and wait for responses before proceeding
+- The specification phase validates and refines discussion content into a standalone document
+- Commit the specification files frequently during the session

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leeovery/claude-technical-workflows",
-  "version": "2.0.16",
+  "version": "2.0.18",
   "description": "Technical workflow skills & commands for Claude Code",
   "license": "MIT",
   "author": "Lee Overy <me@leeovery.com>",

package/skills/technical-discussion/SKILL.md

@@ -7,16 +7,21 @@ description: "Document technical discussions as expert architect and meeting ass
 
 Act as **expert software architect** participating in discussions AND **documentation assistant** capturing them. Do both simultaneously. Engage deeply while documenting for planning teams.
 
-## Six-Phase Workflow
+## Purpose in the Workflow
 
-1. **Research** (previous): EXPLORE - ideas, feasibility, market, business, learning
-2. **Discussion** (YOU): WHAT and WHY - decisions, architecture, edge cases
-3. **Specification** (next): REFINE - validate and build standalone spec
-4. **Planning** (after): HOW - phases, tasks, acceptance criteria
-5. **Implementation** (after): DOING - tests first, then code
-6. **Review** (final): VALIDATING - check work against artifacts
+This skill can be used:
+- **Sequentially** (Phase 2): After research to debate and document decisions
+- **Standalone** (Contract entry): To document technical decisions from any source
 
-You're at step 2. Capture context. Don't jump to specs, plans, or code.
+Either way: Capture decisions, rationale, competing approaches, and edge cases.
+
+### What This Skill Needs
+
+- **Topic** (required) - What technical area to discuss/document
+- **Context** (optional) - Prior research, constraints, existing decisions
+- **Questions to explore** (optional) - Specific architectural questions to address
+
+**If missing:** Will ask user what topic they want to discuss.
 
 ## What to Capture
 

package/skills/technical-implementation/SKILL.md

@@ -9,16 +9,23 @@ Act as **expert senior developer** who builds quality software through disciplin
 
 Execute plans through strict TDD. Write tests first, then code to pass them.
 
-## Six-Phase Workflow
+## Purpose in the Workflow
 
-1. **Research** (previous): EXPLORE - ideas, feasibility, market, business, learning
-2. **Discussion** (previous): WHAT and WHY - decisions, architecture, rationale
-3. **Specification** (previous): REFINE - validated, standalone specification
-4. **Planning** (previous): HOW - phases, tasks, acceptance criteria
-5. **Implementation** (YOU): DOING - tests first, then code
-6. **Review** (next): VALIDATING - check work against artifacts
+This skill can be used:
+- **Sequentially** (Phase 5): To execute a plan created by technical-planning
+- **Standalone** (Contract entry): To execute any plan that follows plan-format conventions
 
-You're at step 5. Execute the plan. Don't re-debate decisions.
+Either way: Execute via strict TDD - tests first, implementation second.
+
+### What This Skill Needs
+
+- **Plan content** (required) - Phases, tasks, and acceptance criteria to execute
+- **Plan format** (required) - How to parse tasks (from plan frontmatter)
+- **Specification content** (optional) - For context when task rationale is unclear
+- **Environment setup** (optional) - First-time setup instructions
+- **Scope** (optional) - Specific phase/task to work on
+
+**If missing:** Will ask user for plan location. If no specification, plan becomes sole authority.
 
 ## Hard Rules
 
@@ -51,9 +58,10 @@ Complete ALL setup steps before proceeding to implementation work.
 
    See **[environment-setup.md](references/environment-setup.md)** for details.
 
-2. **Read the plan** from `docs/workflow/planning/{topic}.md`
+2. **Read the plan** from the provided location (typically `docs/workflow/planning/{topic}.md`)
    - Check the `format` field in frontmatter
    - Load the output adapter: `skills/technical-planning/references/output-{format}.md`
+   - If no format field, ask user which format the plan uses
    - Follow the **Implementation** section for how to read tasks and update progress
 
 3. **Read the TDD workflow** - Load **[tdd-workflow.md](references/tdd-workflow.md)** before writing any code. This is mandatory.
@@ -85,14 +93,18 @@ Keep user informed of progress:
 
 ## When to Reference Specification
 
-Check the specification (`docs/workflow/specification/{topic}.md`) when:
+Check the specification when:
 
 - Task rationale is unclear
 - Multiple valid approaches exist
 - Edge case handling not specified in plan
 - You need the "why" behind a decision
 
-The specification is the source of truth. Don't look further back than this - earlier documents (research, discussion) may contain outdated or superseded information.
+**Location**: Specification should be linked in the plan file (check frontmatter or plan header). Ask user if not found.
+
+The specification (if available) is the source of truth for design decisions. If no specification exists, the plan is the authority.
+
+**Important:** If research or discussion documents exist from earlier workflow phases, ignore them during implementation. They may contain outdated ideas, rejected approaches, or superseded decisions. The specification filtered and validated that content - refer only to the specification and plan.
 
 ## Project-Specific Conventions
 

package/skills/technical-planning/SKILL.md

@@ -9,23 +9,25 @@ Act as **expert technical architect**, **product owner**, and **plan documenter*
 
 Your role spans product (WHAT we're building and WHY) and technical (HOW to structure the work).
 
-## Six-Phase Workflow
+## Purpose in the Workflow
 
-1. **Research** (previous): EXPLORE - ideas, feasibility, market, business, learning
-2. **Discussion** (previous): WHAT and WHY - decisions, architecture, edge cases
-3. **Specification** (previous): REFINE - validated, standalone specification
-4. **Planning** (YOU): HOW - phases, tasks, acceptance criteria
-5. **Implementation** (next): DOING - tests first, then code
-6. **Review** (final): VALIDATING - check work against artifacts
+This skill can be used:
+- **Sequentially** (Phase 4): From a validated specification
+- **Standalone** (Contract entry): From any specification meeting format requirements
 
-You're at step 4. Create the plan. Don't jump to implementation.
+Either way: Transform specifications into actionable phases, tasks, and acceptance criteria.
 
-## Source Material
+### What This Skill Needs
+
+- **Specification content** (required) - The validated decisions and requirements to plan from
+- **Topic name** (optional) - Will derive from specification if not provided
+- **Output format preference** (optional) - Will ask if not specified
 
-Plans are built **exclusively** from the specification:
-- **Specification** (`docs/workflow/specification/{topic}.md`)
+**If missing:** Will ask user for specification location or content.
 
-The specification is the **sole source of truth**. It contains validated, approved content that has already been filtered and enriched from discussions. Do not reference discussion documents or other source material - everything needed is in the specification.
+## Source Material
+
+**The specification is your sole input.** Everything you need should be in the specification - do not request details from discussion documents or other source material. If information is missing, ask for clarification on the specification itself.
 
 ## The Process
 
@@ -41,6 +43,8 @@ The specification is the **sole source of truth**. It contains validated, approv
 
 **Commit frequently**: Commit at natural breaks, after significant exchanges, and before any context refresh. Context refresh = lost work.
 
-**Never invent reasoning**: If it's not in the specification, ask again.
+**Never invent reasoning**: If it's not in the specification, ask again. The specification is the golden document - all plan content must trace back to it.
 
 **Create plans, not code**: Your job is phases, tasks, and acceptance criteria - not implementation.
+
+**Collaborate with the user**: Planning is iterative. Stop and ask when the specification is ambiguous, multiple valid approaches exist, or you're uncertain about task scope. The user expects collaboration - don't guess when you can ask.

package/skills/technical-planning/references/formal-planning.md

@@ -10,6 +10,20 @@ You are creating the formal implementation plan from the specification.
 
 **Confirm output format with user.** Ask which format they want, then load the appropriate output adapter from the main skill file. If you don't know which format, ask.
 
+## Planning is Collaborative
+
+Planning is an iterative process between you and the user. The specification contains validated, considered decisions - planning translates that work into actionable structure. But translation still requires judgment, and the user should guide that judgment.
+
+**Stop, reflect, and ask** when:
+- The specification is ambiguous about implementation approach
+- Multiple valid ways to structure phases or tasks exist
+- You're uncertain whether a task is appropriately scoped
+- Edge cases aren't fully addressed in the specification
+
+**Never invent to fill gaps.** If the specification doesn't address something, use `[needs-info]` and ask the user. The specification is the golden document - everything in the plan must trace back to it.
+
+**The user expects collaboration.** Planning doesn't have to be done by the agent alone. It's normal and encouraged to pause for guidance rather than guess.
+
 ## The Planning Process
 
 ### 1. Read Specification
@@ -86,13 +100,91 @@ Verify:
 
 ## Task Design
 
-**Each task should**:
-- Be a single TDD cycle
-- Have micro acceptance (specific test name)
-- Do one clear thing
-
 **One task = One TDD cycle**: write test → implement → pass → commit
 
+### Task Structure
+
+Every task should follow this structure:
+
+```markdown
+### Task N: [Clear action statement]
+
+**Problem**: Why this task exists - what issue or gap it addresses.
+
+**Solution**: What we're building - the high-level approach.
+
+**Outcome**: What success looks like - the verifiable end state.
+
+**Do**:
+- Specific implementation steps
+- File locations and method names where helpful
+- Concrete guidance, not vague directions
+
+**Acceptance Criteria**:
+- [ ] First verifiable criterion
+- [ ] Second verifiable criterion
+- [ ] Edge case handling criterion
+
+**Tests**:
+- `"it does the primary expected behavior"`
+- `"it handles edge case correctly"`
+- `"it fails appropriately for invalid input"`
+
+**Context**: (when relevant)
+> Relevant details from specification: code examples, architectural decisions,
+> data models, or constraints that inform implementation.
+```
+
+### Field Requirements
+
+| Field | Required | Notes |
+|-------|----------|-------|
+| Problem | Yes | One sentence minimum - why this task exists |
+| Solution | Yes | One sentence minimum - what we're building |
+| Outcome | Yes | One sentence minimum - what success looks like |
+| Do | Yes | At least one concrete action |
+| Acceptance Criteria | Yes | At least one pass/fail criterion |
+| Tests | Yes | At least one test name; include edge cases, not just happy path |
+| Context | When relevant | Only include when spec has details worth pulling forward |
+
+### The Template as Quality Gate
+
+If you struggle to articulate a clear Problem for a task, this signals the task may be:
+
+- **Too granular**: Merge with a related task
+- **Mechanical housekeeping**: Include as a step within another task
+- **Poorly understood**: Revisit the specification
+
+Every standalone task should have a reason to exist that can be stated simply. The template enforces this - difficulty completing it is diagnostic information, not a problem to work around.
+
+### Vertical Slicing
+
+Prefer **vertical slices** that deliver complete, testable functionality over horizontal slices that separate by technical layer.
+
+**Horizontal (avoid)**:
+```
+Task 1: Create all database models
+Task 2: Create all service classes
+Task 3: Wire up integrations
+Task 4: Add error handling
+```
+
+Nothing works until Task 4. No task is independently verifiable.
+
+**Vertical (prefer)**:
+```
+Task 1: Fetch and store events from provider (happy path)
+Task 2: Handle pagination for large result sets
+Task 3: Handle authentication token refresh
+Task 4: Handle rate limiting
+```
+
+Each task delivers a complete slice of functionality that can be tested in isolation.
+
+Within a bounded feature, vertical slicing means each task completes a coherent unit of that feature's functionality - not that it must touch UI/API/database layers. The test is: *can this task be verified independently?*
+
+TDD naturally encourages vertical slicing - when you think "what test can I write?", you frame work as complete, verifiable behavior rather than technical layers
+
 ## Plan as Source of Truth
 
 The plan IS the source of truth. Every phase, every task must contain all information needed to execute it.

package/skills/technical-research/SKILL.md

@@ -7,16 +7,20 @@ description: "Explore ideas, validate concepts, and research broadly across tech
 
 Act as **research partner** with broad expertise spanning technical, product, business, and market domains. Your role is learning, exploration, and discovery.
 
-## Six-Phase Workflow
+## Purpose in the Workflow
 
-1. **Research** (YOU): EXPLORE - ideas, feasibility, market, business, learning
-2. **Discussion** (next): WHAT and WHY - decisions, architecture, edge cases
-3. **Specification** (after): REFINE - validate and build standalone spec
-4. **Planning** (after): HOW - phases, tasks, acceptance criteria
-5. **Implementation** (after): DOING - tests first, then code
-6. **Review** (final): VALIDATING - check work against artifacts
+This skill can be used:
+- **Sequentially** (Phase 1): First phase, to explore ideas before discussion
+- **Standalone** (Contract entry): To research and validate any idea, feature, or concept
 
-You're at step 1. Explore freely.
+Either way: Explore feasibility (technical, business, market), validate assumptions, document findings.
+
+### What This Skill Needs
+
+- **Topic or idea** (required) - What to research/explore
+- **Existing context** (optional) - Any prior research or constraints
+
+**If missing:** Will ask user what they want to explore.
 
 ## Your Expertise
 
@@ -58,7 +62,7 @@ Start with one file. Early research is messy - topics aren't clear, you're follo
 
 **Let themes emerge**: Over multiple sessions, topics may become distinct. When they do, split into semantic files (`market-landscape.md`, `technical-feasibility.md`).
 
-**Periodic review**: Every few sessions, assess: are themes emerging? Split them out. Still fuzzy? Keep exploring. Ready for deeper discussion? Move to `docs/workflow/discussion/`.
+**Periodic review**: Every few sessions, assess: are themes emerging? Split them out. Still fuzzy? Keep exploring. Ready for deeper discussion? Research phase is complete.
 
 ## Documentation Loop
 

package/skills/technical-review/SKILL.md

@@ -9,20 +9,37 @@ Act as a **senior software architect** with deep experience in code review. You
 
 This is **product review**, **feature review**, **test review**, AND **code review**. Not just "does the code work?" but "was every task done correctly, tested properly, and built to professional standards?"
 
-## Six-Phase Workflow
+## Review Artifacts
 
-1. **Research** (artifact): EXPLORE - ideas, feasibility, market, business, learning
-2. **Discussion** (artifact): WHAT and WHY - decisions, architecture, rationale
-3. **Specification** (artifact): REFINE - validated, standalone specification
-4. **Planning** (artifact): HOW - phases, tasks, acceptance criteria
-5. **Implementation** (completed): DOING - tests and code
-6. **Review** (YOU): VALIDATING - verify every task
+This skill reviews against available artifacts. Required:
+- **Plan** (the tasks and acceptance criteria)
 
-You're at step 6. The code exists. Your job is comprehensive verification.
+Optional but helpful:
+- **Specification** (context for design decisions)
+
+## Purpose in the Workflow
+
+This skill can be used:
+- **Sequentially** (Phase 6): After implementation of a planned feature
+- **Standalone** (Contract entry): To review any implementation against a plan
+
+Either way: Verify every plan task was implemented, tested adequately, and meets quality standards.
+
+### What This Skill Needs
+
+- **Plan content** (required) - Tasks and acceptance criteria to verify against
+- **Specification content** (optional) - Context for design decisions
+- **Implementation scope** (optional) - What code/files to review. Will identify from git if not specified.
+
+**If missing:** Will ask user for plan location. Can proceed without specification.
 
 ## Review Approach
 
-Start from the **plan** - it contains the granular tasks and acceptance criteria. Use the **specification** for context. Verify **all** tasks, not a sample.
+Start from the **plan** - it contains the granular tasks and acceptance criteria.
+
+Use the **specification** for context if available. If no specification exists, the plan is the source of truth for design decisions.
+
+Verify **all** tasks, not a sample.
 
 ```
 Plan (tasks + acceptance criteria)

package/skills/technical-review/references/review-checklist.md

@@ -6,8 +6,10 @@
 
 ## Before Starting
 
-1. Read plan: `docs/workflow/planning/{topic}.md`
-2. Read specification: `docs/workflow/specification/{topic}.md` (for context)
+1. Read plan (from the location provided)
+   - If not found at expected path, ask user where the plan is
+2. Read specification if available and linked in plan
+   - Not required, but helpful for context if it exists
 3. Identify what code/files were changed
 4. Check for project-specific skills in `.claude/skills/`
 

package/skills/technical-specification/SKILL.md

@@ -9,16 +9,23 @@ Act as **expert technical architect** and **specification builder**. Collaborate
 
 Your role is to synthesize reference material, present it for validation, and build a specification that formal planning can execute against.
 
-## Six-Phase Workflow
+## Purpose in the Workflow
 
-1. **Research** (previous): EXPLORE - ideas, feasibility, market, business, learning
-2. **Discussion** (previous): WHAT and WHY - decisions, architecture, edge cases
-3. **Specification** (YOU): REFINE - validate, filter, enrich into standalone spec
-4. **Planning** (next): HOW - phases, tasks, acceptance criteria
-5. **Implementation** (after): DOING - tests first, then code
-6. **Review** (final): VALIDATING - check work against artifacts
+This skill can be used:
+- **Sequentially** (Phase 3): After discussion documents exist
+- **Standalone** (Contract entry): With reference material from any source (research docs, conversation transcripts, design documents, inline feature description)
 
-You're at step 3. Build the specification. Don't jump to phases, tasks, or code.
+Either way: Transform unvalidated reference material into a specification that's **standalone and approved**.
+
+### What This Skill Needs
+
+- **Source material** (required) - The content to synthesize into a specification. Can be:
+  - Discussion document content (from sequential workflow)
+  - Inline feature description (from `/start-feature`)
+  - Any other reference material (requirements docs, transcripts, etc.)
+- **Topic name** (required) - Used for the output filename
+
+**If missing:** Will ask user to provide context or point to source files.
 
 ## The Process
 
@@ -26,7 +33,7 @@ You're at step 3. Build the specification. Don't jump to phases, tasks, or code.
 
 **Output**: `docs/workflow/specification/{topic}.md`
 
-**When complete**: User signs off, then proceed to technical-planning.
+**When complete**: User signs off on the specification.
 
 ## What You Do