@leeovery/claude-technical-workflows 2.0.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Lee Overy
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,283 @@
+<h1 align="center">Claude Technical Workflows</h1>
+
+<p align="center">
+  <strong>Structured Discussion & Planning Skills for Claude Code</strong>
+</p>
+
+<p align="center">
+  <a href="#installation">Installation</a> •
+  <a href="#the-six-phase-workflow">Workflow</a> •
+  <a href="#skills">Skills</a> •
+  <a href="#commands">Commands</a> •
+  <a href="#how-it-works">How It Works</a> •
+  <a href="#contributing">Contributing</a>
+</p>
+
+---
+
+## Versions
+
+| Version | Package Manager | Status | Branch |
+|---------|----------------|--------|--------|
+| 2.x | npm | **Active** | `main` |
+| 1.x | Composer | Deprecated | [`v1`](https://github.com/leeovery/claude-technical-workflows/tree/v1) |
+
+## About
+
+A structured approach to technical discussions and implementation planning with Claude Code. These skills enforce a deliberate **research-then-discuss-then-specify-then-plan-then-implement-then-review** workflow that captures context, decisions, and rationale before any code is written—then validates the work against those artifacts.
+
+**Why this matters:** Complex features benefit from thorough discussion before implementation. These skills help you document the *what* and *why* before diving into the *how*—preserving architectural decisions, edge cases, and the reasoning behind choices that would otherwise be lost.
+
+**This is a work in progress.** The workflow is being refined through real-world usage. Expect updates as patterns evolve.
+
+## Installation
+
+```bash
+npm install @leeovery/claude-technical-workflows
+```
+
+That's it. The [Claude Manager](https://github.com/leeovery/claude-manager) handles everything else automatically.
+
+## The Six-Phase Workflow
+
+This package enforces a deliberate progression through six distinct phases:
+
+```
+┌───────────────┐   ┌───────────────┐   ┌───────────────┐   ┌───────────────┐   ┌───────────────┐   ┌───────────────┐
+│   Research    │──▶│  Discussion   │──▶│ Specification │──▶│   Planning    │──▶│Implementation │──▶│    Review     │
+│   (Phase 1)   │   │   (Phase 2)   │   │   (Phase 3)   │   │   (Phase 4)   │   │   (Phase 5)   │   │   (Phase 6)   │
+├───────────────┤   ├───────────────┤   ├───────────────┤   ├───────────────┤   ├───────────────┤   ├───────────────┤
+│ EXPLORING     │   │ WHAT & WHY    │   │ REFINING      │   │ HOW           │   │ DOING         │   │ VALIDATING    │
+│               │   │               │   │               │   │               │   │               │   │               │
+│ • Ideas       │   │ • Architecture│   │ • Validate    │   │ • Phases      │   │ • Tests first │   │ • Plan check  │
+│ • Market      │   │ • Decisions   │   │ • Filter      │   │ • Tasks       │   │ • Then code   │   │ • Specs check │
+│ • Viability   │   │ • Edge cases  │   │ • Enrich      │   │ • Criteria    │   │ • Commit often│   │ • Test quality│
+│               │   │ • Rationale   │   │ • Standalone  │   │ • Outputs     │   │ • Phase gates │   │ • Code quality│
+└───────────────┘   └───────────────┘   └───────────────┘   └───────────────┘   └───────────────┘   └───────────────┘
+        ▲                   ▲                   ▲                   ▲                   ▲                   ▲
+        │                   │                   │                   │                   │                   │
+ technical-research  technical-discussion  technical-spec  technical-planning  technical-impl  technical-review
+```
+
+**Phase 1 - Research:** Explore ideas from their earliest seed. Investigate market fit, technical feasibility, business viability. Free-flowing exploration that may or may not lead to building something.
+
+**Phase 2 - Discussion:** Captures the back-and-forth exploration of a problem. Documents competing solutions, why certain approaches won or lost, edge cases discovered, and the journey to decisions—not just the decisions themselves.
+
+**Phase 3 - Specification:** Transforms discussion documentation into a validated, standalone specification. Filters hallucinations and inaccuracies, enriches gaps through discussion, and builds a document that planning can execute against without referencing other sources.
+
+**Phase 4 - Planning:** Converts specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats (local markdown, Linear, Backlog.md).
+
+**Phase 5 - Implementation:** Executes the plan using strict TDD. Writes tests first, implements to pass, commits frequently, and stops for user approval between phases.
+
+**Phase 6 - Review:** Validates completed work against specification requirements and plan acceptance criteria. The specification is the validated source of truth—earlier phases may contain rejected ideas that were intentionally filtered out. Provides structured feedback without fixing code directly.
+
+## How It Works
+
+This package depends on [`@leeovery/claude-manager`](https://github.com/leeovery/claude-manager), which:
+
+1. **Copies skills** into your project's `.claude/skills/` directory
+2. **Copies commands** into your project's `.claude/commands/` directory
+3. **Copies agents** into your project's `.claude/agents/` directory
+4. **Tracks installed plugins** via a manifest file
+5. **Handles installation/removal** automatically via npm hooks
+
+You don't need to configure anything—just install and start discussing.
+
+### Output Structure
+
+Documents are stored using a **phase-first** organization:
+
+```
+docs/workflow/
+├── research/              # Phase 1 - flat, semantically named files
+│   ├── competitor-analysis.md
+│   └── pricing-models.md
+├── discussion/            # Phase 2 - one file per topic
+│   └── {topic}.md
+├── specification/         # Phase 3 - one file per topic
+│   └── {topic}.md
+└── planning/              # Phase 4 - one file per topic
+    └── {topic}.md
+```
+
+Research is a flat directory of semantically named files (topics emerge later). From discussion onwards, each topic gets its own file per phase.
+
+### Package Structure
+
+This package provides:
+
+```
+skills/
+├── technical-research/        # Phase 1: Explore and validate ideas
+├── technical-discussion/      # Phase 2: Document discussions
+├── technical-specification/   # Phase 3: Build validated specifications
+├── technical-planning/        # Phase 4: Create implementation plans
+├── technical-implementation/  # Phase 5: Execute via TDD
+└── technical-review/          # Phase 6: Validate against artifacts
+
+commands/
+├── start-research.md          # Begin research exploration
+├── start-discussion.md        # Begin technical discussions
+├── start-specification.md     # Begin specification building
+├── start-planning.md          # Begin implementation planning
+└── interview.md               # Focused questioning mode
+
+agents/
+└── chain-verifier.md          # Parallel task verification for review
+```
+
+## Skills
+
+| Skill | Phase | Description |
+|-------|-------|-------------|
+| [**technical-research**](skills/technical-research/) | 1 | Explore ideas from their earliest seed. Investigate market fit, technical feasibility, business viability. Free-flowing exploration across technical, business, and market domains. |
+| [**technical-discussion**](skills/technical-discussion/) | 2 | Document technical discussions as expert architect and meeting assistant. Captures context, decisions, edge cases, competing solutions, debates, and rationale. |
+| [**technical-specification**](skills/technical-specification/) | 3 | Build validated specifications from discussion documents through collaborative refinement. Filters hallucinations, enriches gaps, produces standalone spec. |
+| [**technical-planning**](skills/technical-planning/) | 4 | Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats. |
+| [**technical-implementation**](skills/technical-implementation/) | 5 | Execute implementation plans using strict TDD workflow. Writes tests first, implements to pass, commits frequently, and gates phases on user approval. |
+| [**technical-review**](skills/technical-review/) | 6 | Review completed implementation against specification requirements and plan acceptance criteria. Uses parallel subagents for efficient chain verification. Produces structured feedback without fixing code. |
+
+### technical-research
+
+Acts as **research partner** with broad expertise spanning technical, product, business, and market domains.
+
+**Use when:**
+- Exploring a new idea from its earliest seed
+- Investigating market fit, competitors, or positioning
+- Validating technical feasibility before committing to build
+- Learning and exploration without necessarily building anything
+- Brain dumping early thoughts before formal discussion
+
+**What it does:**
+- Explores ideas freely across technical, business, and market domains
+- Prompts before documenting: "Shall I capture that?"
+- Creates research documents that may seed the discussion phase
+- Follows tangents and goes broad when useful
+
+### technical-discussion
+
+Acts as both **expert software architect** (participating in discussions) and **documentation assistant** (capturing them) simultaneously.
+
+**Use when:**
+- Discussing or exploring architecture and design decisions
+- Working through edge cases before specification
+- Documenting technical decisions and their rationale
+- Capturing competing solutions and why certain choices were made
+
+**What it captures:**
+- Back-and-forth debates showing how decisions were reached
+- Small details and edge cases that were discussed
+- Competing solutions and why some won over others
+- The journey—false paths, "aha" moments, course corrections
+
+### technical-specification
+
+Acts as **expert technical architect** and **specification builder**. Transforms discussion documents into validated, standalone specifications.
+
+**Use when:**
+- Ready to validate and refine discussion content
+- Need to filter potential hallucinations or inaccuracies from source material
+- Building a standalone document that planning can execute against
+- Converting discussions into verified requirements
+
+**What it produces:**
+- Validated, standalone specification document
+- Filtered content (hallucinations and inaccuracies removed)
+- Enriched content (gaps filled through discussion)
+- Clear bridge document for formal planning
+
+### technical-planning
+
+Converts specifications into structured implementation plans.
+
+**Use when:**
+- Ready to plan implementation after specification is complete
+- Need to structure how to build something with phases and concrete steps
+- Converting specification into actionable developer guidance
+
+**What it produces:**
+- Phased implementation plans with specific tasks
+- Acceptance criteria at phase and task levels
+- Multiple output formats: local markdown, Linear, Backlog.md, or Beads
+
+### technical-implementation
+
+Executes plans through strict TDD. Acts as an expert senior developer who builds quality software through disciplined test-driven development.
+
+**Use when:**
+- Implementing a plan from `docs/workflow/planning/{topic}.md`
+- Ad hoc coding that should follow TDD and quality standards
+- Bug fixes or features benefiting from structured implementation
+
+**Hard rules:**
+- No code before tests—write the failing test first
+- No test changes to pass—fix the code, not the tests
+- No scope expansion—if it's not in the plan, don't build it
+- Commit after green—every passing test is a commit point
+
+### technical-review
+
+Reviews completed work with fresh perspective. Validates implementation against prior workflow artifacts without fixing code directly.
+
+**Use when:**
+- Implementation phase is complete
+- User wants validation before merging/shipping
+- Quality gate check needed after implementation
+
+**What it checks:**
+- Were specification requirements implemented?
+- Were all plan acceptance criteria met?
+- Do tests actually verify requirements?
+- Does code follow project conventions?
+
+## Commands
+
+Slash commands to quickly invoke the workflow.
+
+| Command | Description |
+|---------|-------------|
+| [**/start-research**](commands/start-research.md) | Begin research exploration. For early-stage ideas, feasibility checks, and broad exploration before formal discussion. |
+| [**/start-discussion**](commands/start-discussion.md) | Begin a new technical discussion. Gathers topic, context, background information, and relevant codebase areas before starting documentation. |
+| [**/start-specification**](commands/start-specification.md) | Start a specification session from an existing discussion. Validates and refines discussion content into a standalone specification. |
+| [**/start-planning**](commands/start-planning.md) | Start a planning session from an existing specification. Creates implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats (markdown, Linear, Backlog.md, Beads). |
+| [**/interview**](commands/interview.md) | Shift into focused questioning mode during research or discussion. Probes ideas with non-obvious questions, challenges assumptions, and surfaces concerns. |
+
+## Agents
+
+Subagents that skills can spawn for parallel task execution.
+
+| Agent | Used By | Description |
+|-------|---------|-------------|
+| [**chain-verifier**](agents/chain-verifier.md) | technical-review | Verifies a single plan task was implemented correctly. Checks implementation, tests (not under/over-tested), and code quality. Multiple chain-verifiers run in parallel to verify ALL tasks efficiently. |
+
+## Requirements
+
+- Node.js 18+
+- [@leeovery/claude-manager](https://github.com/leeovery/claude-manager) ^2.0.0 (installed automatically)
+
+## Contributing
+
+Contributions are welcome! Whether it's:
+
+- **Bug fixes** in the documentation or skill definitions
+- **Improvements** to the workflow or templates
+- **Discussion** about approaches and trade-offs
+- **New skills** that complement the discuss-specify-plan-implement workflow
+
+Please open an issue first to discuss significant changes.
+
+## Related Packages
+
+- [**@leeovery/claude-manager**](https://github.com/leeovery/claude-manager) — The plugin manager that powers skill installation
+- [**@leeovery/claude-laravel**](https://github.com/leeovery/claude-laravel) — Laravel development skills for Claude Code
+- [**@leeovery/claude-nuxt**](https://github.com/leeovery/claude-nuxt) — Nuxt.js development skills for Claude Code
+
+## License
+
+MIT License. See [LICENSE](LICENSE) for details.
+
+---
+
+<p align="center">
+  <sub>Built with care by <a href="https://github.com/leeovery">Lee Overy</a></sub>
+</p>

package/agents/chain-verifier.md

@@ -0,0 +1,129 @@
+---
+name: chain-verifier
+description: Verifies a single plan task was implemented correctly. Checks implementation, tests, and code quality against the task's acceptance criteria and spec context. Invoked by technical-review to verify ALL plan tasks in PARALLEL.
+tools: Read, Glob, Grep
+model: haiku
+---
+
+# Chain Verifier
+
+Act as a **senior software architect** with deep experience in code review. You verify that ONE plan task was implemented correctly, tested adequately, and meets professional quality standards.
+
+## Your Input
+
+You receive:
+1. **Plan task**: A specific task with its acceptance criteria
+2. **Specification path**: For loading context about this task's feature/requirement
+3. **Plan path**: The full plan for additional context
+4. **Implementation scope**: Files or directories to check
+
+## Your Task
+
+For the given plan task:
+
+```
+Plan Task (acceptance criteria)
+    ↓
+    Load Spec Context (deeper understanding)
+    ↓
+    Verify Implementation (code exists, correct)
+    ↓
+    Verify Tests (adequate, not over/under tested)
+    ↓
+    Check Code Quality (readable, conventions)
+```
+
+### Step 1: Understand the Task
+
+From the plan task:
+- What should be built?
+- What are the acceptance criteria?
+- What tests should exist (micro acceptance)?
+
+### Step 2: Load Spec Context
+
+Search the specification for relevant context:
+- What is the broader requirement this task fulfills?
+- Are there edge cases or constraints mentioned?
+- What behavior is expected?
+
+### Step 3: Verify Implementation
+
+Search the codebase:
+- Is the task implemented?
+- Does the implementation match the acceptance criteria?
+- Does it align with the spec's expected behavior?
+- Any drift from what was planned?
+
+### Step 4: Verify Tests
+
+Evaluate test coverage critically:
+- Is there a test for this task?
+- Does the test actually verify the acceptance criteria?
+- **Not under-tested**: Are edge cases from the spec covered?
+- **Not over-tested**: Are tests focused and necessary, or bloated with redundant checks?
+- Would the test fail if the feature broke?
+
+### Step 5: Check Code Quality
+
+Review the implementation as a senior architect would:
+
+**Project conventions** (if `.claude/skills/` contains project-specific guidance):
+- Check for project-specific code quality skills
+- Follow any framework or architecture guidelines defined there
+
+**General principles** (always apply):
+- **SOLID**: Single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion
+- **DRY**: No unnecessary duplication (but don't over-abstract prematurely)
+- **Low complexity**: Cyclomatic complexity is reasonable, code paths are clear
+- **Modern idioms**: Uses current language features appropriately
+- **Readability**: Code is self-documenting, intent is clear
+- **Security**: No obvious vulnerabilities (injection, exposure, etc.)
+- **Performance**: No obvious inefficiencies (N+1 queries, unnecessary loops, etc.)
+
+## Your Output
+
+Return a structured finding:
+
+```
+TASK: [Task name/description]
+
+ACCEPTANCE CRITERIA: [List from plan]
+
+STATUS: Complete | Incomplete | Issues Found
+
+SPEC CONTEXT: [Brief summary of relevant spec context]
+
+IMPLEMENTATION:
+- Status: [Implemented/Missing/Partial/Drifted]
+- Location: [file:line references]
+- Notes: [Any concerns]
+
+TESTS:
+- Status: [Adequate/Under-tested/Over-tested/Missing]
+- Coverage: [What is/isn't tested]
+- Notes: [Specific issues]
+
+CODE QUALITY:
+- Project conventions: [Followed/Violations/N/A]
+- SOLID principles: [Good/Concerns]
+- Complexity: [Low/Acceptable/High]
+- Modern idioms: [Yes/Opportunities]
+- Readability: [Good/Concerns]
+- Issues: [Specific problems if any]
+
+BLOCKING ISSUES:
+- [List any issues that must be fixed]
+
+NON-BLOCKING NOTES:
+- [Suggestions for improvement]
+```
+
+## Rules
+
+1. **One task only** - You verify exactly one plan task per invocation
+2. **Be thorough** - Check implementation, tests, AND quality
+3. **Be specific** - Include file paths and line numbers
+4. **Balanced test review** - Flag both under-testing AND over-testing
+5. **Report findings** - Don't fix anything, just report what you find
+6. **Fast and focused** - You're one of many running in parallel

package/commands/interview.md

@@ -0,0 +1,54 @@
+---
+description: Shift into focused questioning mode to probe an idea more deeply during research or discussion phases.
+---
+
+Shift into focused questioning mode to probe an idea more deeply.
+
+## Setup
+
+Before beginning, ask the user:
+
+1. **What stage are you in?** Research or discussion?
+2. **What topic or idea do you want to explore?**
+
+Wait for responses before proceeding.
+
+## Process
+
+1. **Check for existing context**:
+   - Research: Look for docs in `docs/workflow/research/`
+   - Discussion: Look for the topic's file in `docs/workflow/discussion/{topic}.md`
+
+   Read what exists to understand what's already been explored.
+
+2. **Begin interviewing**: Use the AskUserQuestion tool to probe the idea. Focus on:
+   - Non-obvious questions (not things already answered)
+   - Assumptions and unstated constraints
+   - Tradeoffs and concerns
+   - What could go wrong
+   - The "why" behind decisions
+
+3. **Go where it leads**: Follow tangents if they reveal something valuable. This isn't a checklist—it's a conversation.
+
+4. **Document as you go**: Don't defer writing to the end. Capture insights in the appropriate location:
+   - Research: `docs/workflow/research/` (semantic filenames)
+   - Discussion: `docs/workflow/discussion/{topic}.md`
+
+   Ask before documenting: "Shall I capture that?"
+
+5. **Commit frequently**: At natural breaks and before context refresh. Don't risk losing detail.
+
+6. **Exit when done**: The user decides when the interview is complete.
+
+## Question quality
+
+Aim for questions that:
+- The user hasn't already answered
+- Reveal hidden complexity
+- Surface concerns early
+- Challenge comfortable assumptions
+
+Avoid:
+- Restating what's already documented
+- Obvious surface-level questions
+- Leading questions that assume an answer

package/commands/start-discussion.md

@@ -0,0 +1,36 @@
+---
+description: Start a technical discussion using the technical-discussion skill. Gathers information about the topic and creates discussion documentation in docs/workflow/discussion/
+---
+
+Invoke the **technical-discussion** skill for this conversation.
+
+Before beginning, ask the user these questions to properly set up the discussion:
+
+## Essential Information
+
+1. **Discussion Topic**: What are we discussing? (This will be used as the filename in `docs/workflow/discussion/{topic}.md`)
+
+2. **Context & Background**:
+   - What sparked this discussion?
+   - What problem are we trying to solve?
+   - Why are we discussing this now?
+
+3. **Foundational Knowledge**:
+   - Is there any background information I need to understand before we begin?
+   - Are there specific concepts, technologies, or architectures I should know about?
+   - Any constraints, requirements, or limitations I should be aware of?
+
+4. **Codebase Review**:
+   - Are there specific files in this repository I should read first?
+   - Should I explore any particular directories or components?
+   - Is there existing code related to this discussion?
+
+## After Gathering Information
+
+Once I have this information:
+- Ensure discussion directory exists: `docs/workflow/discussion/`
+- Start documenting the discussion following the technical-discussion skill structure
+- Create file: `docs/workflow/discussion/{topic}.md`
+- Commit frequently at natural discussion breaks
+
+Ask these questions clearly and wait for responses before proceeding with the discussion.

package/commands/start-implementation.md

@@ -0,0 +1,107 @@
+---
+description: Start an implementation session from an existing plan. Discovers available plans, checks environment setup, and invokes the technical-implementation skill.
+---
+
+## IMPORTANT: Follow these steps EXACTLY. Do not skip steps.
+
+- Ask each question and WAIT for a response before proceeding
+- Do NOT install anything or invoke tools until Step 5
+- Even if the user's initial prompt seems to answer a question, still confirm with them at the appropriate step
+- Do NOT make assumptions about what the user wants
+- Complete each step fully before moving to the next
+
+## 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: Present Options to User
+
+Show what you found.
+
+> **Note:** If no plans exist, inform the user that this workflow is designed to be executed in sequence. They need to create plans from specifications prior to implementation using `/start-planning`.
+
+> **Auto-select:** If exactly one plan exists, automatically select it and proceed to Step 3. Inform the user which plan was selected. Do not ask for confirmation.
+
+```
+Plans found:
+  {topic-1}
+  {topic-2}
+
+Which plan would you like to implement?
+```
+
+## Step 3: Check Environment Setup
+
+> **IMPORTANT**: This step is for **information gathering only**. Do NOT execute any setup commands at this stage. The technical-implementation skill will handle execution when invoked.
+
+After the user selects a plan:
+
+1. Check if `docs/workflow/environment-setup.md` exists
+2. If it exists, note the file location for the skill handoff
+3. If missing, ask: "Are there any environment setup instructions I should follow?"
+   - If the user provides instructions, save them to `docs/workflow/environment-setup.md`, commit and push to Git
+   - See `skills/technical-implementation/references/environment-setup.md` for format guidance
+
+## Step 4: Ask About Scope
+
+Ask the user about implementation scope:
+
+```
+How would you like to proceed?
+
+1. **Implement all phases** - Work through the entire plan sequentially
+2. **Implement specific phase** - Focus on one phase (e.g., "Phase 1")
+3. **Implement specific task** - Focus on a single task
+
+Which approach?
+```
+
+If they choose a specific phase or task, ask them to specify which one.
+
+> **Note:** Do NOT verify that the phase or task exists. Accept the user's answer and pass it to the skill. Validation happens during the implementation phase.
+
+## Step 5: Invoke Implementation Skill
+
+Invoke the **technical-implementation** skill for this conversation.
+
+Pass to the technical-implementation skill:
+- Plan: `docs/workflow/planning/{topic}.md`
+- Format: (from frontmatter)
+- Scope: (all phases | specific phase | specific task)
+- Environment setup: (completed | not needed)
+
+**Example handoff:**
+```
+Implementation session for: {topic}
+Plan: docs/workflow/planning/{topic}.md
+Format: {format}
+Scope: All phases
+
+Environment setup: Completed (or: Not needed)
+
+Begin implementation using the technical-implementation skill.
+```
+
+## Notes
+
+- Ask questions clearly and wait for responses before proceeding
+- Execute environment setup before starting implementation