owflow 0.1.3 → 0.1.4

package/README.md

@@ -1,169 +1,169 @@
-![Owflow logo](logo.png)
-
-# Owflow
-
-**Structured, standards-aware development workflows for OpenCode**
-
-Describe what you want to build, and the plugin handles the rest - from specification through implementation to verification - while enforcing your project's coding standards at every step.
-
-Started as a simple OpenCode fork of [Maister Claude Code plugin](https://github.com/SkillPanel/maister), Owflow aims to deliver production ready workflows using the full [Opencode](https://opencode.ai/) plugin support.
-
-## What You Get
-
-- **Guided workflows** for features, bug fixes, enhancements, performance, migrations, research, and product design
-- **Auto-discovered standards** from your codebase - config files, source patterns, and documentation are analyzed and enforced throughout every workflow
-- **Test-driven implementation** with automated planning, incremental verification, and full test suite runs before completion
-- **Pause and resume** any workflow - state is preserved across sessions
-- **Production readiness checks** including code review, reality assessment, and pragmatic over-engineering detection
-
-## Getting Started
-
-### Prerequisites
-
-- [Opencode](https://opencode.ai/) CLI installed and configured
-- [Node.js](https://nodejs.org/) >= 25
-
-### Installation
-
-#### Install the plugin
-
-```bash
-npm install owflow
-```
-
-#### Add owflow to the `plugin` array in your `opencode.json` ([global or project-level](https://opencode.ai/docs/plugins/#load-order)):
-
-```json
-{
-  "plugin": ["owflow"]
-}
-```
-
-### Initial project setup
-
-Initialize your project to auto-detect coding standards and generate project documentation:
-
-```bash
-/flow-init
-```
-
-This scans your codebase and creates `.owflow/` with standards, docs, and task folders. May take a few minutes on larger projects.
-
-If you have another project already using Owflow, you can reuse its standards as a starting point:
-
-```bash
-/flow-init --standards-from=/path/to/other-project
-```
-
-### First Workflow
-
-```bash
-/development Add user profile page with avatar upload
-```
-
-Or just discuss your task with LLM model and then run:
-
-```bash
-/development
-```
-
-The plugin picks up context from your conversation - no arguments needed.
-
-## How It Works
-
-1. You describe a task - either as an argument or just in conversation
-2. The plugin classifies it (feature, bug, enhancement, etc.) and proposes a workflow
-3. You confirm, and it guides you through phases: **requirements → spec → plan → implement → verify**
-4. At each phase, it asks for your input and decisions
-5. You get tested, verified code with a detailed work log
-
-All artifacts are saved in `.owflow/tasks/` organized by type and date.
-
-### Context-Aware Commands
-
-Every workflow command works without arguments. The plugin reads your current conversation to extract the task description and auto-detect the task type:
-
-```
-You: "The login page throws a 500 error when the session expires"
-You: /development
-→ Auto-detects: bug fix, extracts description from conversation
-```
-
-```
-You: /standards-update
-→ Scans conversation for patterns like "we always use..." or "prefer X over Y"
-```
-
-You can always be explicit when you prefer - arguments and flags simply override the auto-detection.
-
-## Supported Workflows
-
-| Command           | Use When                                    |
-| ----------------- | ------------------------------------------- |
-| `/development`    | Features, bug fixes, enhancements           |
-| `/research`       | Research with synthesis and solution design |
-| `/performance`    | Optimizing speed or resource usage          |
-| `/migration`      | Changing technologies or patterns           |
-| `/product-design` | Product and feature design                  |
-
-Task type (feature/bug/enhancement) is auto-detected from context. Override with `--type=feature|bug|enhancement` if needed. Or use `/work` as a single entry point that routes to the right workflow.
-
-### Quick Commands
-
-For smaller tasks that don't need a full workflow:
-
-| Command         | Use When                                                    |
-| --------------- | ----------------------------------------------------------- |
-| `/quick-plan`   | You want a plan with standards awareness before coding      |
-| `/quick-dev`    | You know what to do - just implement with standards applied |
-| `/quick-bugfix` | Quick TDD-driven bug fix — write failing test, fix, verify  |
-
-## Standards-Aware Development
-
-This is the key differentiator. Owflow doesn't just run workflows - it learns your project's conventions and enforces them:
-
-- **`flow-init`** scans config files, source code, and documentation to auto-detect your coding standards
-- **Continuous checking** - standards are consulted before specification, during planning, and while coding (not just at the start)
-- **`/standards-discover`** refreshes standards from your evolving codebase
-- **`/standards-update`** lets you add or refine standards manually, or sync from another project with `--from=PATH`
-
-Standards live in `.owflow/docs/standards/` and are indexed in `.owflow/docs/INDEX.md`.
-
-**Important**: Do not use plan mode with workflows (see [Best Practices](#best-practices) below).
-
-## Beta Channel
-
-Want to try experimental features before they hit stable? Install from the beta channel:
-
-TBD
-
-## Best Practices
-
-**Don't use plan mode when starting a workflow.** Planning is a built-in part of every workflow — the orchestrator creates specs, plans, and other files as it goes. Claude Code's plan mode restricts file creation, which conflicts with this. Let the workflow handle planning on its own.
-
-**Start workflows in a fresh session.** This is especially useful when chaining workflows (e.g., research → development). Research and product-design artifacts already contain all the context needed, so a clean session avoids noise from prior conversation.
-
-**Chain workflows by passing a task folder.** If you've completed a research or product-design workflow and want to build on those results, pass the task folder directly:
-
-```bash
-/development .owflow/tasks/research/2026-01-12-oauth-research
-```
-
-You can also append additional instructions to narrow scope or guide the workflow:
-
-```bash
-/development .owflow/tasks/product-design/2026-03-10-dashboard-redesign Implement only phase 1
-```
-
-## Known Issues
-
-**Orchestrator may stall after long phases.** After context compaction (which typically happens after lengthy phases like implementation), the main agent may stop progressing automatically. If you notice it's idle, just type something like "continue" or "proceed" — it will pick up where it left off. You can also re-invoke the workflow in resume mode to reload the orchestrator state:
-
-```bash
-/development .owflow/tasks/development/2026-03-24-my-feature
-```
-
-## Learn More
-
-- [Workflow Details](docs/workflows.md) - phases, examples, and task structure for each workflow type
-- [Full Command Reference](docs/commands.md) - all workflow, review, utility, and quick commands
+![Owflow logo](logo.png)
+
+# Owflow
+
+**Structured, standards-aware development workflows for OpenCode**
+
+Describe what you want to build, and the plugin handles the rest - from specification through implementation to verification - while enforcing your project's coding standards at every step.
+
+Started as a simple OpenCode fork of [Maister Claude Code plugin](https://github.com/SkillPanel/maister), Owflow aims to deliver production ready workflows using the full [Opencode](https://opencode.ai/) plugin support.
+
+## What You Get
+
+- **Guided workflows** for features, bug fixes, enhancements, performance, migrations, research, and product design
+- **Auto-discovered standards** from your codebase - config files, source patterns, and documentation are analyzed and enforced throughout every workflow
+- **Test-driven implementation** with automated planning, incremental verification, and full test suite runs before completion
+- **Pause and resume** any workflow - state is preserved across sessions
+- **Production readiness checks** including code review, reality assessment, and pragmatic over-engineering detection
+
+## Getting Started
+
+### Prerequisites
+
+- [Opencode](https://opencode.ai/) CLI installed and configured
+- [Node.js](https://nodejs.org/) >= 25
+
+### Installation
+
+#### Install the plugin
+
+```bash
+npm install owflow
+```
+
+#### Add owflow to the `plugin` array in your `opencode.json` ([global or project-level](https://opencode.ai/docs/plugins/#load-order)):
+
+```json
+{
+  "plugin": ["owflow"]
+}
+```
+
+### Initial project setup
+
+Initialize your project to auto-detect coding standards and generate project documentation:
+
+```bash
+/flow-init
+```
+
+This scans your codebase and creates `.owflow/` with standards, docs, and task folders. May take a few minutes on larger projects.
+
+If you have another project already using Owflow, you can reuse its standards as a starting point:
+
+```bash
+/flow-init --standards-from=/path/to/other-project
+```
+
+### First Workflow
+
+```bash
+/development Add user profile page with avatar upload
+```
+
+Or just discuss your task with Agent and then run:
+
+```bash
+/development
+```
+
+The plugin picks up context from your conversation - no arguments needed.
+
+## How It Works
+
+1. You describe a task - either as an argument or just in conversation
+2. The plugin classifies it (feature, bug, enhancement, etc.) and proposes a workflow
+3. You confirm, and it guides you through phases: **requirements → spec → plan → implement → verify**
+4. At each phase, it asks for your input and decisions
+5. You get tested, verified code with a detailed work log
+
+All artifacts are saved in `.owflow/tasks/` organized by type and date.
+
+### Context-Aware Commands
+
+Every workflow command works without arguments. The plugin reads your current conversation to extract the task description and auto-detect the task type:
+
+```
+You: "The login page throws a 500 error when the session expires"
+You: /development
+→ Auto-detects: bug fix, extracts description from conversation
+```
+
+```
+You: /standards-update
+→ Scans conversation for patterns like "we always use..." or "prefer X over Y"
+```
+
+You can always be explicit when you prefer - arguments and flags simply override the auto-detection.
+
+## Supported Workflows
+
+| Command           | Use When                                    |
+| ----------------- | ------------------------------------------- |
+| `/development`    | Features, bug fixes, enhancements           |
+| `/research`       | Research with synthesis and solution design |
+| `/performance`    | Optimizing speed or resource usage          |
+| `/migration`      | Changing technologies or patterns           |
+| `/product-design` | Product and feature design                  |
+
+Task type (feature/bug/enhancement) is auto-detected from context. Override with `--type=feature|bug|enhancement` if needed. Or use `/work` as a single entry point that routes to the right workflow.
+
+### Quick Commands
+
+For smaller tasks that don't need a full workflow:
+
+| Command         | Use When                                                    |
+| --------------- | ----------------------------------------------------------- |
+| `/quick-plan`   | You want a plan with standards awareness before coding      |
+| `/quick-dev`    | You know what to do - just implement with standards applied |
+| `/quick-bugfix` | Quick TDD-driven bug fix — write failing test, fix, verify  |
+
+## Standards-Aware Development
+
+This is the key differentiator. Owflow doesn't just run workflows - it learns your project's conventions and enforces them:
+
+- **`flow-init`** scans config files, source code, and documentation to auto-detect your coding standards
+- **Continuous checking** - standards are consulted before specification, during planning, and while coding (not just at the start)
+- **`/standards-discover`** refreshes standards from your evolving codebase
+- **`/standards-update`** lets you add or refine standards manually, or sync from another project with `--from=PATH`
+
+Standards live in `.owflow/docs/standards/` and are indexed in `.owflow/docs/INDEX.md`.
+
+**Important**: Do not use plan mode with workflows (see [Best Practices](#best-practices) below).
+
+## Beta Channel
+
+Want to try experimental features before they hit stable? Install from the beta channel:
+
+TBD
+
+## Best Practices
+
+**Don't use plan mode when starting a workflow.** Planning is a built-in part of every workflow — the orchestrator creates specs, plans, and other files as it goes. OpenCode's plan mode restricts file creation, which conflicts with this. Let the workflow handle planning on its own.
+
+**Start workflows in a fresh session.** This is especially useful when chaining workflows (e.g., research → development). Research and product-design artifacts already contain all the context needed, so a clean session avoids noise from prior conversation.
+
+**Chain workflows by passing a task folder.** If you've completed a research or product-design workflow and want to build on those results, pass the task folder directly:
+
+```bash
+/development .owflow/tasks/research/2026-01-12-oauth-research
+```
+
+You can also append additional instructions to narrow scope or guide the workflow:
+
+```bash
+/development .owflow/tasks/product-design/2026-03-10-dashboard-redesign Implement only phase 1
+```
+
+## Known Issues
+
+**Orchestrator may stall after long phases.** After context compaction (which typically happens after lengthy phases like implementation), the main agent may stop progressing automatically. If you notice it's idle, just type something like "continue" or "proceed" — it will pick up where it left off. You can also re-invoke the workflow in resume mode to reload the orchestrator state:
+
+```bash
+/development .owflow/tasks/development/2026-03-24-my-feature
+```
+
+## Learn More
+
+- [Workflow Details](docs/workflows.md) - phases, examples, and task structure for each workflow type
+- [Full Command Reference](docs/commands.md) - all workflow, review, utility, and quick commands

package/dist/agents/e2e-test-verifier.md

@@ -299,7 +299,7 @@ Categorized by severity (Critical/Major/Minor/Cosmetic):
 Detect unavailable tools and provide setup instructions:
 
 - Install playwright-mcp
-- Configure MCP server in Claude Code
+- Configure MCP server in OpenCode
 - Restart and retry
 
 ### Application Not Running

package/dist/commands/quick-plan.md

@@ -5,7 +5,7 @@ description: Enter planning mode with AI SDLC standards awareness
 
 # Planning Mode with Standards Awareness
 
-Enter Claude Code's planning mode for a task, with automatic discovery of project standards from `.owflow/docs/`.
+Enter OpenCode's planning mode for a task, with automatic discovery of project standards from `.owflow/docs/`.
 
 ## Usage
 
@@ -37,7 +37,7 @@ Enter Claude Code's planning mode for a task, with automatic discovery of projec
 
 ### Step 2: Discover and Read Standards (BEFORE Plan Mode)
 
-**CRITICAL: This step MUST complete before calling EnterPlanMode.**
+**CRITICAL: This step MUST complete before calling Plan Agent.**
 
 1. **Check if `.owflow/docs/INDEX.md` exists**
    - **If not exists**: Note that no standards are available, skip to Step 3
@@ -56,7 +56,7 @@ Enter Claude Code's planning mode for a task, with automatic discovery of projec
 
 ### Step 3: Enter Planning Mode
 
-**Use the `EnterPlanMode` tool to trigger Claude Code's builtin planning mode.**
+**Use the `Plan agent` to trigger OpenCode's builtin planning mode.**
 
 **Standards context from Step 2 MUST actively inform all plan mode phases:**
 
@@ -70,11 +70,11 @@ The planning mode will:
 2. Launch Plan agents to design implementation approach (with standards constraints)
 3. Review and verify alignment with user intent
 4. Write final plan to plan file (with standards woven into steps)
-5. Call ExitPlanMode for user approval (gated on mandatory standards sections)
+5. Ask for user approval (gated on mandatory standards sections)
 
-### ExitPlanMode Gate: Mandatory Standards Sections
+### Approval question gate: Mandatory Standards Sections
 
-**BLOCKING: Do NOT call `ExitPlanMode` until the plan file contains these sections:**
+**BLOCKING: Do NOT call ask user for approval until the plan file contains these sections:**
 
 1. **"## Applicable Standards"** — list each standard file that was read, with key guidelines extracted from each. If no standards exist, state: "No AI SDLC standards found. Consider running `/flow-init`."
 
@@ -85,7 +85,7 @@ The planning mode will:
    - [ ] New components use TypeScript strict mode (from `standards/frontend/components.md`)
    ```
 
-If these sections are missing from the plan file, add them before calling ExitPlanMode.
+If these sections are missing from the plan file, add them before asking user for approval.
 
 ### Graceful Fallback
 
@@ -102,9 +102,9 @@ project documentation and coding standards for better consistency.
 
 1. **Parses** task description from user input
 2. **Discovers and READS** applicable standard files from `.owflow/docs/` (BEFORE plan mode)
-3. **Enters** Claude Code's builtin planning mode via `EnterPlanMode` with standards already loaded
+3. **Enters** OpenCode's builtin planning mode via delegating to `Plan Agent` with standards already loaded
 4. **Produces** a plan file with implementation approach, applicable standards, and compliance checklist
-5. **Gates** ExitPlanMode on mandatory standards sections in the plan file
+5. **Gates** Approval question on mandatory standards sections in the plan file
 
 ## Benefits Over Manual Planning
 

package/dist/skills/docs-manager/SKILL.md

@@ -185,7 +185,7 @@ Use this to add new documentation to the project, either from plugin baseline or
    - Ask for the filename and purpose
    - Create a template file with appropriate frontmatter and structure
 4. Update INDEX.md to include the new documentation (see "Manage INDEX.md" operation)
-5. If this is a technical standard and corresponds to a Claude Code Skill, ensure consistency
+5. If this is a technical standard and corresponds to a Agent Skill, ensure consistency
 
 **Result:** New documentation is added to the project and indexed in INDEX.md.
 
@@ -211,7 +211,7 @@ Use this to help the user update or modify existing project documentation.
    - Check if INDEX.md needs updating (if the purpose/description changed significantly)
    - If updating tech-stack.md or architecture.md, suggest reviewing AGENTS.md for consistency
 6. For technical standards:
-   - If a corresponding Claude Code Skill exists, suggest reviewing it for consistency
+   - If a corresponding Agent Skill exists, suggest reviewing it for consistency
    - Standards should align with actual code patterns in the project
 
 **Result:** Documentation is updated to reflect current project state and team decisions.
@@ -273,7 +273,7 @@ Use this to ensure the project's AGENTS.md properly integrates with the document
 2. If it doesn't exist, ask the user if they want to create it
 3. Look for a documentation reference section in AGENTS.md
 4. If the section doesn't exist or is incomplete:
-   - Read `references/claude-md-template.md` for the template
+   - Read `references/agents-md-template.md` for the template
    - Add the template section to AGENTS.md
 5. Ensure the documentation section is placed prominently in AGENTS.md (near the top)
 6. Verify that the INDEX.md path is correct and the file exists
@@ -307,7 +307,7 @@ Use this to check that documentation is consistent, up-to-date, and properly int
    - Check if they contain placeholder text vs. actual project information
    - Warn if critical documentation is missing or empty
 5. **Check standards consistency:**
-   - If Claude Code Skills exist, check if corresponding standards documentation exists
+   - If Agent Skills exist, check if corresponding standards documentation exists
    - If standards exist without skills, suggest creating skills (if appropriate)
    - Report any inconsistencies
 6. **Generate validation report:**
@@ -330,42 +330,42 @@ Use this to check that documentation is consistent, up-to-date, and properly int
 
 ```
 User: "Set up documentation for this project"
-Claude: [Executes Initialize Documentation - creates structure, copies baseline docs, generates INDEX.md, updates AGENTS.md, gathers project info]
+Agent: [Executes Initialize Documentation - creates structure, copies baseline docs, generates INDEX.md, updates AGENTS.md, gathers project info]
 ```
 
 **Update project vision:**
 
 ```
 User: "I want to update our project vision to include AI-first approach"
-Claude: [Executes Update Documentation - reads current vision.md, helps user edit it, updates INDEX.md if needed]
+Agent: [Executes Update Documentation - reads current vision.md, helps user edit it, updates INDEX.md if needed]
 ```
 
 **Add custom documentation:**
 
 ```
 User: "Add documentation for our deployment process"
-Claude: [Executes Add Documentation File - creates custom project/deployment.md, updates INDEX.md]
+Agent: [Executes Add Documentation File - creates custom project/deployment.md, updates INDEX.md]
 ```
 
 **Reference plugin baseline:**
 
 ```
 User: "Show me the plugin's baseline error handling standard"
-Claude: [Executes Use Plugin Documentation as Reference - shows plugin baseline, compares with project version, no changes unless user requests]
+Agent: [Executes Use Plugin Documentation as Reference - shows plugin baseline, compares with project version, no changes unless user requests]
 ```
 
 **Validate documentation:**
 
 ```
 User: "Check if our documentation is complete and consistent"
-Claude: [Executes Validate Documentation Consistency - checks structure, INDEX.md, AGENTS.md integration, generates report]
+Agent: [Executes Validate Documentation Consistency - checks structure, INDEX.md, AGENTS.md integration, generates report]
 ```
 
 **Manage INDEX.md:**
 
 ```
 User: "Rebuild the documentation index"
-Claude: [Executes Manage INDEX.md - scans .owflow/docs/, regenerates comprehensive INDEX.md]
+Agent: [Executes Manage INDEX.md - scans .owflow/docs/, regenerates comprehensive INDEX.md]
 ```
 
 ---

package/dist/skills/migration/references/migration-strategies.md

@@ -1,6 +1,6 @@
 # Migration Strategies Reference
 
-> **Design Documentation**: This file serves as **design documentation** for developers and Claude implementing migration workflows. It provides conceptual patterns and decision frameworks for selecting and executing migration strategies.
+> **Design Documentation**: This file serves as **design documentation** for developers and Agents implementing migration workflows. It provides conceptual patterns and decision frameworks for selecting and executing migration strategies.
 
 **Purpose:** Pattern guide for migration execution strategies (incremental, rollback, dual-run)
 
@@ -23,11 +23,11 @@ This reference provides decision criteria and implementation patterns for the th
 
 Migration strategies define **how** to execute the transition from current to target state. The migration orchestrator supports three core strategies, which can be combined:
 
-| Strategy | Purpose | Risk Level | Use When |
-|----------|---------|------------|----------|
-| **Incremental** | Migrate piece-by-piece with checkpoints | Low-Medium | Large migrations, complex changes |
-| **Rollback** | Plan undo procedures for each phase | Medium | Critical systems, data migrations |
-| **Dual-Run** | Run old and new systems in parallel | Medium-High | Zero-downtime requirements, data sync needed |
+| Strategy        | Purpose                                 | Risk Level  | Use When                                     |
+| --------------- | --------------------------------------- | ----------- | -------------------------------------------- |
+| **Incremental** | Migrate piece-by-piece with checkpoints | Low-Medium  | Large migrations, complex changes            |
+| **Rollback**    | Plan undo procedures for each phase     | Medium      | Critical systems, data migrations            |
+| **Dual-Run**    | Run old and new systems in parallel     | Medium-High | Zero-downtime requirements, data sync needed |
 
 ### Key Principles
 
@@ -45,6 +45,7 @@ Migration strategies define **how** to execute the transition from current to ta
 **Definition**: Break migration into smaller phases, complete one phase fully before starting next
 
 **Pattern**:
+
 ```
 Current State → Phase 1 → Verify → Phase 2 → Verify → Phase 3 → Verify → Target State
                   ↑                    ↑                    ↑
@@ -54,12 +55,14 @@ Current State → Phase 1 → Verify → Phase 2 → Verify → Phase 3 → Veri
 ### When to Use
 
 **Strong Indicators**:
+
 - Large migration scope (>50 files, >5,000 lines affected)
 - Multiple independent subsystems to migrate
 - Complex breaking changes requiring staged adaptation
 - Team needs to learn new technology during migration
 
 **Avoid If**:
+
 - Small, isolated change (<10 files)
 - Tight deadline requiring fast completion
 - No logical breakpoints in migration
@@ -67,12 +70,14 @@ Current State → Phase 1 → Verify → Phase 2 → Verify → Phase 3 → Veri
 ### Implementation Pattern
 
 **Phase Definition**:
+
 1. **Identify Natural Boundaries**: Modules, layers, features that can migrate independently
 2. **Define Dependencies**: Which phases must complete before others
 3. **Set Verification Criteria**: How to validate each phase succeeded
 4. **Plan Checkpoints**: Git tags, deployment points, rollback triggers
 
 **Example - Framework Migration (Vue 2 → Vue 3)**:
+
 ```
 Phase 1: Core dependencies (package.json, build config)
   ↓ Verify: App still builds and runs
@@ -87,8 +92,10 @@ Phase 5: Cleanup (remove compatibility shims)
 ```
 
 **Task Group Structure**:
+
 ```markdown
 ### Task Group 1: Phase 1 - Core Dependencies
+
 - [ ] 1.1 Write tests for compatibility layer
 - [ ] 1.2 Upgrade core packages
 - [ ] 1.3 Update build configuration
@@ -96,6 +103,7 @@ Phase 5: Cleanup (remove compatibility shims)
 - [ ] 1.5 Run Phase 1 checkpoint tests
 
 ### Task Group 2: Phase 2 - Shared Components
+
 [continues with next phase after Phase 1 verified]
 ```
 
@@ -121,6 +129,7 @@ Phase 5: Cleanup (remove compatibility shims)
 **Definition**: Document undo procedures for each migration phase before executing
 
 **Pattern**:
+
 ```
 Before Phase 1: Define rollback procedure
 Execute Phase 1
@@ -131,6 +140,7 @@ If success: Continue to Phase 2
 ### When to Use
 
 **Strong Indicators**:
+
 - Production systems (downtime is costly)
 - Data migrations (data loss risk)
 - Critical business functionality
@@ -138,6 +148,7 @@ If success: Continue to Phase 2
 - First-time migration (learning experience)
 
 **Always Use For**:
+
 - Data migrations (required)
 - Production deployments (required)
 - Architecture migrations affecting multiple systems
@@ -145,36 +156,42 @@ If success: Continue to Phase 2
 ### Implementation Pattern
 
 **Rollback Plan Structure** (`planning/rollback-plan.md`):
+
 ```markdown
 # Rollback Plan: [Migration Name]
 
 ## Rollback Overview
+
 - **Rollback Complexity**: Simple | Moderate | Complex
 - **Data Loss Risk**: None | Minimal | Moderate | High
 - **Rollback Time Estimate**: [minutes/hours]
 
 ## Phase 1: [Phase Name] Rollback
+
 **Trigger**: [What indicates rollback needed]
 **Procedure**:
+
 1. [Undo step 1]
 2. [Undo step 2]
-**Verification**: [How to verify rollback succeeded]
-**Data Recovery**: [How to restore data if modified]
+   **Verification**: [How to verify rollback succeeded]
+   **Data Recovery**: [How to restore data if modified]
 
 ## Phase 2: [Phase Name] Rollback
+
 [Same structure for each phase]
 ```
 
 **Rollback Categories**:
 
-| Category | Example | Procedure |
-|----------|---------|-----------|
-| **Code Rollback** | Framework upgrade | `git revert [commit]`, redeploy |
-| **Data Rollback** | Schema migration | Restore from backup, revert migrations |
-| **Config Rollback** | Environment changes | Restore old config files, restart |
-| **Infrastructure Rollback** | Platform migration | Switch DNS back, restore old infrastructure |
+| Category                    | Example             | Procedure                                   |
+| --------------------------- | ------------------- | ------------------------------------------- |
+| **Code Rollback**           | Framework upgrade   | `git revert [commit]`, redeploy             |
+| **Data Rollback**           | Schema migration    | Restore from backup, revert migrations      |
+| **Config Rollback**         | Environment changes | Restore old config files, restart           |
+| **Infrastructure Rollback** | Platform migration  | Switch DNS back, restore old infrastructure |
 
 **Rollback Testing Strategy**:
+
 - **Non-Destructive Test**: Test rollback in non-prod first
 - **Documented Steps**: Exact commands/procedures
 - **Validation Criteria**: How to verify rollback succeeded
@@ -202,6 +219,7 @@ If success: Continue to Phase 2
 **Definition**: Run old and new systems in parallel, gradually shift traffic from old to new
 
 **Pattern**:
+
 ```
 Old System (100% traffic) → Dual-Run (Old + New in parallel) → New System (100% traffic)
                                   ↓
@@ -213,6 +231,7 @@ Old System (100% traffic) → Dual-Run (Old + New in parallel) → New System (1
 ### When to Use
 
 **Strong Indicators**:
+
 - Zero-downtime requirement (24/7 systems)
 - Data migration with live writes during migration
 - Need to compare old vs new behavior in production
@@ -220,6 +239,7 @@ Old System (100% traffic) → Dual-Run (Old + New in parallel) → New System (1
 - Regulatory requirement for parallel validation
 
 **Avoid If**:
+
 - Systems can't coexist (e.g., Vue 2 and Vue 3 in same app)
 - Data synchronization too complex
 - Cost of running both systems prohibitive
@@ -230,44 +250,52 @@ Old System (100% traffic) → Dual-Run (Old + New in parallel) → New System (1
 **Dual-Run Phases**:
 
 **Phase 1: Setup Dual Environment**
+
 - Deploy new system alongside old
 - Configure routing/load balancer for split traffic
 - Set up data synchronization mechanism
 
 **Phase 2: Shadow Mode** (new system receives traffic but doesn't affect users)
+
 - 100% traffic to old system
 - Duplicate writes to new system (shadow)
 - Compare old vs new results
 - Identify discrepancies, fix new system
 
 **Phase 3: Gradual Cutover**
+
 - 10% traffic → new system (monitor closely)
 - 50% traffic → new system (A/B test)
 - 100% traffic → new system (full cutover)
 
 **Phase 4: Old System Decommission**
+
 - Keep old system running for 7-30 days (rollback safety net)
 - After validation period, decommission old system
 
 **Dual-Run Plan Structure** (`planning/dual-run-plan.md`):
+
 ```markdown
 # Dual-Run Plan: [Migration Name]
 
 ## Synchronization Strategy
+
 **Sync Direction**: Old → New | Bidirectional | New → Old
 **Sync Mechanism**: [Database replication | Message queue | API calls]
 **Sync Frequency**: [Real-time | Batch every X minutes]
 **Conflict Resolution**: [Last-write-wins | Manual resolution | Application logic]
 
 ## Cutover Plan
-| Phase | Old Traffic % | New Traffic % | Duration | Success Criteria |
-|-------|---------------|---------------|----------|------------------|
-| Shadow | 100% | 0% (shadow) | 3-7 days | No errors in new system |
-| Pilot | 90% | 10% | 3-7 days | Error rate <0.1% in new |
-| Ramp | 50% | 50% | 3-7 days | Performance metrics equivalent |
-| Full | 0% | 100% | - | All users migrated |
+
+| Phase  | Old Traffic % | New Traffic % | Duration | Success Criteria               |
+| ------ | ------------- | ------------- | -------- | ------------------------------ |
+| Shadow | 100%          | 0% (shadow)   | 3-7 days | No errors in new system        |
+| Pilot  | 90%           | 10%           | 3-7 days | Error rate <0.1% in new        |
+| Ramp   | 50%           | 50%           | 3-7 days | Performance metrics equivalent |
+| Full   | 0%            | 100%          | -        | All users migrated             |
 
 ## Monitoring
+
 - **Key Metrics**: [Response time, error rate, data consistency]
 - **Alerting**: [Thresholds that trigger rollback]
 - **Comparison Dashboards**: [Old vs new side-by-side]
@@ -275,12 +303,12 @@ Old System (100% traffic) → Dual-Run (Old + New in parallel) → New System (1
 
 **Data Synchronization Patterns**:
 
-| Pattern | Description | Use When |
-|---------|-------------|----------|
-| **Write-Through** | Writes go to both old and new | Gradual migration, data validation |
-| **Replication** | Database-level replication (one-way) | Read-heavy systems, database migrations |
-| **Event Streaming** | Publish changes to message queue, both consume | Event-driven architectures |
-| **Dual-Write + Reconciliation** | Write to both, periodic reconciliation job | Complex data models, conflict resolution needed |
+| Pattern                         | Description                                    | Use When                                        |
+| ------------------------------- | ---------------------------------------------- | ----------------------------------------------- |
+| **Write-Through**               | Writes go to both old and new                  | Gradual migration, data validation              |
+| **Replication**                 | Database-level replication (one-way)           | Read-heavy systems, database migrations         |
+| **Event Streaming**             | Publish changes to message queue, both consume | Event-driven architectures                      |
+| **Dual-Write + Reconciliation** | Write to both, periodic reconciliation job     | Complex data models, conflict resolution needed |
 
 ### Benefits
 
@@ -333,17 +361,20 @@ START: What's the migration scope?
 ### Common Combinations
 
 **Incremental + Rollback** (Most Common):
+
 - Break into phases (Incremental)
 - Document rollback for each phase (Rollback)
 - Use for: Most medium-large migrations
 
 **Incremental + Rollback + Dual-Run** (Maximum Safety):
+
 - Break into phases (Incremental)
 - Document rollback (Rollback)
 - Run old/new in parallel (Dual-Run)
 - Use for: Critical systems, data migrations, zero-downtime requirements
 
 **Example - Database Migration (MySQL → PostgreSQL)**:
+
 ```
 Strategy: Incremental + Rollback + Dual-Run
 
@@ -370,12 +401,12 @@ Phase 5: Decommission MySQL
 
 ### Strategy Complexity Matrix
 
-| Combination | Complexity | Duration Overhead | Risk Reduction |
-|------------|------------|-------------------|----------------|
-| Incremental only | Low | +20-40% | Medium |
-| Incremental + Rollback | Medium | +30-50% | High |
-| Incremental + Dual-Run | High | +50-80% | High |
-| Incremental + Rollback + Dual-Run | Very High | +80-120% | Very High |
+| Combination                       | Complexity | Duration Overhead | Risk Reduction |
+| --------------------------------- | ---------- | ----------------- | -------------- |
+| Incremental only                  | Low        | +20-40%           | Medium         |
+| Incremental + Rollback            | Medium     | +30-50%           | High           |
+| Incremental + Dual-Run            | High       | +50-80%           | High           |
+| Incremental + Rollback + Dual-Run | Very High  | +80-120%          | Very High      |
 
 **Guidance**: Choose simplest strategy that adequately mitigates your risks. Over-engineering increases complexity without proportional benefit.
 
@@ -384,6 +415,7 @@ Phase 5: Decommission MySQL
 ## Summary
 
 **Key Takeaways**:
+
 1. **Incremental** = Lower risk through phased execution
 2. **Rollback** = Safety net for critical systems
 3. **Dual-Run** = Zero downtime for live systems
@@ -391,6 +423,7 @@ Phase 5: Decommission MySQL
 5. **Document procedures** before executing migration
 
 **References in SKILL.md**:
+
 - Phase 2 (Specification): Select migration strategy
 - Phase 3 (Planning): Structure implementation plan by strategy
 - Phase 4 (Execution): Execute according to selected strategy

package/dist/skills/migration/references/migration-types.md

@@ -1,6 +1,6 @@
 # Migration Types Reference
 
-> **Design Documentation**: This file serves as **design documentation** for developers and Claude implementing migration workflows. It provides guidance for identifying migration types and adapting workflows accordingly.
+> **Design Documentation**: This file serves as **design documentation** for developers and Agents implementing migration workflows. It provides guidance for identifying migration types and adapting workflows accordingly.
 
 **Purpose:** Pattern guide for the three migration types: Code, Data, and Architecture
 
@@ -23,16 +23,17 @@ This reference provides characteristics, detection patterns, and workflow adapta
 
 Migration types classify migrations based on **what** is being changed:
 
-| Type | Focus | Examples | Risk Profile |
-|------|-------|----------|--------------|
-| **Code** | Language, framework, library | Vue 2→3, Python 2→3, Express→Fastify | Medium |
-| **Data** | Database, storage, schema | MySQL→PostgreSQL, MongoDB→DynamoDB | High |
-| **Architecture** | Patterns, structure | REST→GraphQL, Monolith→Microservices | High |
-| **General** | Mixed or unclear | Complex refactoring with multiple aspects | Variable |
+| Type             | Focus                        | Examples                                  | Risk Profile |
+| ---------------- | ---------------------------- | ----------------------------------------- | ------------ |
+| **Code**         | Language, framework, library | Vue 2→3, Python 2→3, Express→Fastify      | Medium       |
+| **Data**         | Database, storage, schema    | MySQL→PostgreSQL, MongoDB→DynamoDB        | High         |
+| **Architecture** | Patterns, structure          | REST→GraphQL, Monolith→Microservices      | High         |
+| **General**      | Mixed or unclear             | Complex refactoring with multiple aspects | Variable     |
 
 ### Why Type Matters
 
 Different types require different:
+
 - **Risk assessments**: Data migrations are highest risk (data loss potential)
 - **Verification approaches**: Data needs integrity checks, code needs functional tests
 - **Rollback strategies**: Data rollback more complex than code rollback
@@ -47,6 +48,7 @@ Different types require different:
 **What**: Changing programming language, framework, library, or major version with breaking changes
 
 **Characteristics**:
+
 - Source code modifications (syntax, APIs, patterns)
 - Dependency updates (package.json, requirements.txt, pom.xml)
 - No data transformation (data structures unchanged or minimal changes)
@@ -55,17 +57,20 @@ Different types require different:
 ### Examples
 
 **Framework Migrations**:
+
 - Vue 2 → Vue 3 (composition API, breaking changes)
 - Angular 8 → Angular 15 (modules to standalone components)
 - React Class Components → Hooks
 - Express 4 → Express 5
 
 **Language Migrations**:
+
 - Python 2 → Python 3 (print statements, unicode)
 - JavaScript → TypeScript (type annotations)
 - Java 8 → Java 17 (new syntax, APIs)
 
 **Library Migrations**:
+
 - Moment.js → Day.js (date handling library change)
 - Axios → Fetch API (HTTP client change)
 - Lodash → Native JavaScript (utility functions)
@@ -73,11 +78,13 @@ Different types require different:
 ### Detection Keywords
 
 **Primary Indicators**:
+
 - Framework/library names: React, Vue, Angular, Express, Flask, Django, Spring, Rails
 - Version terms: "upgrade", "migrate from X to Y", "move to version N"
 - Language names: Python, Java, JavaScript, TypeScript, Go, Rust
 
 **Example Descriptions**:
+
 - "Migrate from Vue 2 to Vue 3" → Code migration (framework)
 - "Upgrade Express to v5" → Code migration (major version)
 - "Convert JavaScript to TypeScript" → Code migration (language)
@@ -85,28 +92,34 @@ Different types require different:
 ### Workflow Adaptations
 
 **Phase 1 (Current State Analysis)**:
+
 - Focus: Locate all source files using old framework/library
 - Analyze: Dependency tree, API usage patterns, deprecated features used
 
 **Phase 2 (Target State Planning)**:
+
 - Focus: Breaking changes between versions, API equivalents
 - Output: Breaking changes list, API migration map
 
 **Phase 3 (Specification)**:
+
 - Include: Compatibility shim requirements (if needed)
 - Rollback: Simple (revert code via git)
 
 **Phase 5 (Execution)**:
+
 - Strategy: Incremental (by module/component)
 - Testing: Functional tests per module
 
 **Phase 6 (Verification)**:
+
 - Focus: Functional equivalence (behavior unchanged)
 - Tests: Full test suite, manual testing of critical flows
 
 ### Risk Profile
 
 **Medium Risk**:
+
 - **Risk**: Breaking changes causing bugs, build failures
 - **Mitigation**: Comprehensive test coverage, incremental migration
 - **Rollback**: Relatively easy (git revert)
@@ -120,6 +133,7 @@ Different types require different:
 **What**: Changing database platform, storage system, or schema structure
 
 **Characteristics**:
+
 - Data transformation (format, structure, relationships)
 - Schema changes (tables, columns, indexes, constraints)
 - Data integrity critical (no data loss tolerated)
@@ -128,17 +142,20 @@ Different types require different:
 ### Examples
 
 **Platform Migrations**:
+
 - MySQL → PostgreSQL (SQL database change)
 - MongoDB → DynamoDB (document to key-value)
 - Redis → Memcached (caching layer change)
 - On-premise DB → Cloud DB (AWS RDS, Azure SQL)
 
 **Schema Migrations**:
+
 - Normalize database (split tables, add relationships)
 - Denormalize for performance (merge tables)
 - Add partitioning/sharding
 
 **Storage Migrations**:
+
 - Local files → S3 (file storage migration)
 - S3 → GCS (cloud provider change)
 - SQL → NoSQL (data model change)
@@ -146,11 +163,13 @@ Different types require different:
 ### Detection Keywords
 
 **Primary Indicators**:
+
 - Database names: MySQL, PostgreSQL, MongoDB, Redis, DynamoDB, Cassandra, Oracle
 - Data terms: "schema change", "data migration", "database migration", "move data"
 - Storage terms: "S3", "blob storage", "file migration"
 
 **Example Descriptions**:
+
 - "Migrate database from MySQL to PostgreSQL" → Data migration (platform)
 - "Move from MongoDB to DynamoDB" → Data migration (NoSQL change)
 - "Migrate schema to normalized structure" → Data migration (schema)
@@ -158,23 +177,28 @@ Different types require different:
 ### Workflow Adaptations
 
 **Phase 1 (Current State Analysis)**:
+
 - Focus: Database schema, row counts, data volume, stored procedures
 - Analyze: Data relationships, foreign keys, indexes, constraints
 
 **Phase 2 (Target State Planning)**:
+
 - Focus: Data transformation requirements, data mapping (old → new schema)
 - Output: Data transformation specification, estimated migration time
 
 **Phase 3 (Specification)**:
+
 - Include: Data validation procedures, integrity checks, rollback procedures
 - Rollback: Complex (requires backup/restore strategies)
 - Dual-Run: Often required (zero-downtime)
 
 **Phase 5 (Execution)**:
+
 - Strategy: Incremental + Dual-Run (high confidence in strategy choice)
 - Testing: Data integrity checks after each batch
 
 **Phase 6 (Verification)**:
+
 - Focus: Data integrity (100% row count match, checksums, data validation)
 - Tests: Full test suite + data integrity tests + performance benchmarks
 - Critical: If data integrity fails, HALT (don't auto-fix, prompt user)
@@ -182,11 +206,13 @@ Different types require different:
 ### Risk Profile
 
 **High Risk**:
+
 - **Risk**: Data loss, data corruption, downtime
 - **Mitigation**: Backups before migration, dual-run, incremental batches, 100% data validation
 - **Rollback**: Complex (restore from backup, may lose data written during migration)
 
 **Special Requirements**:
+
 - **Backup**: Full backup before starting (non-negotiable)
 - **Data Validation**: 100% row count match, checksums, business rule validation
 - **Dual-Run**: Strongly recommended (old and new databases in parallel)
@@ -202,6 +228,7 @@ Different types require different:
 **What**: Changing fundamental system structure, communication patterns, or architectural style
 
 **Characteristics**:
+
 - System-wide changes (affects multiple components/services)
 - Changes how components interact (APIs, communication patterns)
 - May affect both code and data (comprehensive migration)
@@ -210,17 +237,20 @@ Different types require different:
 ### Examples
 
 **API Style Migrations**:
+
 - REST API → GraphQL (query language change)
 - SOAP → REST (API pattern modernization)
 - RPC → REST (communication pattern change)
 
 **Architecture Pattern Migrations**:
+
 - Monolith → Microservices (decomposition)
 - Microservices → Monolith (consolidation)
 - MVC → Component-Based (frontend architecture change)
 - Layered → Hexagonal (backend architecture change)
 
 **Infrastructure Migrations**:
+
 - On-Premise → Cloud (infrastructure change)
 - Single Server → Distributed (scalability)
 - Synchronous → Event-Driven (async patterns)
@@ -228,11 +258,13 @@ Different types require different:
 ### Detection Keywords
 
 **Primary Indicators**:
+
 - Pattern names: REST, GraphQL, gRPC, SOAP, RPC
 - Architecture styles: Monolith, Microservices, Serverless, Event-Driven, Hexagonal
 - Refactoring terms: "refactor to", "change architecture", "restructure"
 
 **Example Descriptions**:
+
 - "Refactor REST API to GraphQL" → Architecture migration (API style)
 - "Migrate monolith to microservices" → Architecture migration (decomposition)
 - "Change from MVC to component-based architecture" → Architecture migration (pattern)
@@ -240,34 +272,41 @@ Different types require different:
 ### Workflow Adaptations
 
 **Phase 1 (Current State Analysis)**:
+
 - Focus: System components, communication patterns, dependencies between components
 - Analyze: Coupling/cohesion, service boundaries, data flow
 
 **Phase 2 (Target State Planning)**:
+
 - Focus: New architecture structure, component boundaries, communication patterns
 - Output: Architecture diagram, component mapping (old → new)
 
 **Phase 3 (Specification)**:
+
 - Include: Strangler fig pattern (if applicable), component interaction diagrams
 - Rollback: Moderate to complex (depends on dual-run feasibility)
 - Dual-Run: Often required (old and new architectures in parallel)
 
 **Phase 5 (Execution)**:
+
 - Strategy: Incremental (by component/service) + Dual-Run (if possible)
 - Testing: Integration tests, end-to-end tests, performance tests
 
 **Phase 6 (Verification)**:
+
 - Focus: System-level behavior (end-to-end flows work), performance comparison
 - Tests: Full test suite + integration tests + E2E tests
 
 ### Risk Profile
 
 **High Risk**:
+
 - **Risk**: System-wide breakage, performance degradation, complex rollback
 - **Mitigation**: Strangler fig pattern, incremental component migration, dual-run
 - **Rollback**: Moderate to complex (depends on how well old/new coexist)
 
 **Special Patterns**:
+
 - **Strangler Fig**: Gradually replace old system with new (route traffic to new incrementally)
 - **Branch by Abstraction**: Create abstraction layer, switch implementations behind it
 - **Parallel Run**: Run old and new architectures in parallel, compare results
@@ -281,6 +320,7 @@ Different types require different:
 **What**: Migrations that don't fit cleanly into Code/Data/Architecture, or mix multiple types
 
 **Characteristics**:
+
 - Ambiguous description ("modernize", "refactor" without specifics)
 - Multiple aspects (code + data + architecture)
 - Catch-all for unclear migrations
@@ -294,11 +334,13 @@ Different types require different:
 ### Workflow Adaptations
 
 **Phase 1-2 (Analysis + Planning)**:
+
 - Spend extra time clarifying scope
 - Prompt user to specify what's changing (code, data, architecture, or all)
 - May reclassify after analysis
 
 **General Approach**:
+
 - Use conservative defaults (high risk, incremental + rollback + dual-run)
 - Prompt user more frequently for decisions
 - Extra verification steps
@@ -316,6 +358,7 @@ Migration type detection uses keyword matching with confidence scoring.
 **Input**: `"Migrate from Vue 2 to Vue 3"`
 
 **Steps**:
+
 1. **Extract Keywords**: `["migrate", "Vue", "2", "3"]`
 2. **Match Against Patterns**:
    - Code: `["Vue"]` → 1 match
@@ -331,6 +374,7 @@ Migration type detection uses keyword matching with confidence scoring.
 ### Keyword Categories
 
 **Code Migration Keywords**:
+
 ```
 Frameworks: React, Vue, Angular, Express, Flask, Django, Rails, Spring, Laravel
 Languages: Python, Java, JavaScript, TypeScript, Go, Rust, C++, C#, Ruby, PHP
@@ -338,12 +382,14 @@ Terms: "upgrade", "migrate from X to Y", "version", "framework migration"
 ```
 
 **Data Migration Keywords**:
+
 ```
 Databases: MySQL, PostgreSQL, MongoDB, Redis, DynamoDB, Cassandra, Oracle, SQL Server
 Terms: "database", "schema", "data migration", "move data", "storage", "S3", "blob"
 ```
 
 **Architecture Migration Keywords**:
+
 ```
 Patterns: REST, GraphQL, gRPC, SOAP, Monolith, Microservices, Serverless, Event-Driven
 Terms: "refactor to", "architecture", "pattern", "system design", "restructure"
@@ -352,24 +398,26 @@ Terms: "refactor to", "architecture", "pattern", "system design", "restructure"
 ### Ambiguity Handling
 
 **Multiple Matches** (e.g., "Migrate MySQL database to PostgreSQL and refactor to microservices"):
+
 - Scores: Code=0, Data=2 ("MySQL", "PostgreSQL"), Architecture=1 ("microservices")
 - Primary Type: Data (highest score)
 - Classification: Data + Architecture (mixed)
 - Prompt user: "Detected primary type: Data. Also includes architecture changes. Proceed as data migration? [Y/n/specify]"
 
 **No Clear Matches** (e.g., "Modernize application"):
+
 - Scores: Code=0, Data=0, Architecture=0
 - Classification: General
 - Prompt user: "Unable to detect migration type. Please specify: [Code/Data/Architecture/Mixed]"
 
 ### Confidence Levels
 
-| Score | Confidence | Action |
-|-------|------------|--------|
-| Single category with matches | 100% | Auto-detect, confirm in interactive |
-| Primary category (>50% of matches) | 70-90% | Auto-detect, prompt to confirm |
-| Tied categories | 50% | Prompt user to choose |
-| No matches | 0% | Classify as General, prompt user |
+| Score                              | Confidence | Action                              |
+| ---------------------------------- | ---------- | ----------------------------------- |
+| Single category with matches       | 100%       | Auto-detect, confirm in interactive |
+| Primary category (>50% of matches) | 70-90%     | Auto-detect, prompt to confirm      |
+| Tied categories                    | 50%        | Prompt user to choose               |
+| No matches                         | 0%         | Classify as General, prompt user    |
 
 ---
 
@@ -377,14 +425,14 @@ Terms: "refactor to", "architecture", "pattern", "system design", "restructure"
 
 External research is automatically triggered by the gap-analyzer during Phase 2 (Target State Planning). The level of research depends on migration type.
 
-| Migration Type | External Research | Query Focus | Priority Sources |
-|---------------|-------------------|-------------|------------------|
-| **Code** (Version Upgrade) | **Required** | Migration guides, breaking changes, API changes | Official docs, release notes, upgrade guides |
-| **Code** (Library Swap) | **Required** | Comparison guides, migration paths, compatibility | Official docs, community migration stories |
-| **Data** (Platform Change) | **Recommended** | Compatibility, data transformation, tooling | Official docs, DBA resources, cloud provider docs |
-| **Data** (Schema Change) | **Optional** | Best practices only | Internal docs preferred |
-| **Architecture** | **Recommended** | Pattern implementation, migration strategies | Architecture blogs, official docs |
-| **General** | **Optional** | Clarification research | N/A |
+| Migration Type             | External Research | Query Focus                                       | Priority Sources                                  |
+| -------------------------- | ----------------- | ------------------------------------------------- | ------------------------------------------------- |
+| **Code** (Version Upgrade) | **Required**      | Migration guides, breaking changes, API changes   | Official docs, release notes, upgrade guides      |
+| **Code** (Library Swap)    | **Required**      | Comparison guides, migration paths, compatibility | Official docs, community migration stories        |
+| **Data** (Platform Change) | **Recommended**   | Compatibility, data transformation, tooling       | Official docs, DBA resources, cloud provider docs |
+| **Data** (Schema Change)   | **Optional**      | Best practices only                               | Internal docs preferred                           |
+| **Architecture**           | **Recommended**   | Pattern implementation, migration strategies      | Architecture blogs, official docs                 |
+| **General**                | **Optional**      | Clarification research                            | N/A                                               |
 
 ### When to Skip External Research
 
@@ -396,26 +444,29 @@ External research is automatically triggered by the gap-analyzer during Phase 2
 
 ### Research Depth by Complexity
 
-| Complexity | Research Depth | Queries | Focus |
-|------------|---------------|---------|-------|
-| Simple (<10 files) | Essential | 2-3 | Official migration guide only |
-| Moderate (10-30 files) | Essential | 2-3 | Migration guide + breaking changes |
-| Complex (>30 files) | Expanded | 4-6 | Guide + breaking changes + community experiences |
-| Data migration (any size) | Expanded | 4-6 | Guide + compatibility + data transformation |
+| Complexity                | Research Depth | Queries | Focus                                            |
+| ------------------------- | -------------- | ------- | ------------------------------------------------ |
+| Simple (<10 files)        | Essential      | 2-3     | Official migration guide only                    |
+| Moderate (10-30 files)    | Essential      | 2-3     | Migration guide + breaking changes               |
+| Complex (>30 files)       | Expanded       | 4-6     | Guide + breaking changes + community experiences |
+| Data migration (any size) | Expanded       | 4-6     | Guide + compatibility + data transformation      |
 
 ### Example Research Queries
 
 **Code Migration (Vue 2 → Vue 3)**:
+
 - Primary: "Vue 2 to Vue 3 migration guide"
 - Secondary: "Vue 3 breaking changes 2024"
 - Expanded: "Vue 3 composition API migration examples"
 
 **Data Migration (MySQL → PostgreSQL)**:
+
 - Primary: "MySQL to PostgreSQL migration guide"
 - Secondary: "PostgreSQL migration tools 2024"
 - Expanded: "MySQL PostgreSQL syntax differences"
 
 **Architecture Migration (REST → GraphQL)**:
+
 - Primary: "REST to GraphQL migration guide"
 - Secondary: "GraphQL migration best practices"
 - Expanded: "REST GraphQL coexistence patterns"
@@ -425,12 +476,14 @@ External research is automatically triggered by the gap-analyzer during Phase 2
 ## Summary
 
 **Key Takeaways**:
+
 1. **Code**: Focus on functional equivalence, incremental migration, medium risk
 2. **Data**: Focus on data integrity, dual-run often required, high risk
 3. **Architecture**: Focus on system-level behavior, strangler fig pattern, high risk
 4. **General**: Conservative defaults, extra clarification with user
 
 **References in SKILL.md**:
+
 - Initialization (Step 2): Type detection algorithm
 - Phase 1 (Analysis): Type-specific analysis focus
 - Phase 2 (Target Planning): Type-specific gap analysis + external research

package/dist/skills/quick-bugfix/SKILL.md

@@ -120,7 +120,7 @@ Use question:
 
 ### Step 4: Enter Planning Mode
 
-**Use the `EnterPlanMode` tool to present the fix plan for user approval.**
+**Use the `Plan Agent` to present the fix plan for user approval.**
 
 Standards context from Step 2 and analysis from Step 3 MUST inform the plan.
 
@@ -151,9 +151,9 @@ If no standards exist: "No AI SDLC standards found. Consider running `/flow-init
 - [ ] [Guideline from standard file] (from `standards/[path]`)
 ```
 
-### ExitPlanMode Gate: Mandatory Sections
+### User approval gate: Mandatory Sections
 
-**BLOCKING: Do NOT call `ExitPlanMode` until the plan file contains:**
+**BLOCKING: Do NOT ask for user approval until the plan file contains:**
 
 1. **"## Bug Analysis"** — root cause hypothesis with evidence
 2. **"## Proposed Fix"** — what changes and why
@@ -161,7 +161,7 @@ If no standards exist: "No AI SDLC standards found. Consider running `/flow-init
 4. **"## Applicable Standards"** — standards read and key guidelines
 5. **"## Standards Compliance Checklist"** — checkboxes for applicable guidelines
 
-If any section is missing, add it before calling ExitPlanMode.
+If any section is missing, add it before asking for user approval.
 
 ### Step 5: TDD Red Gate
 

package/dist/skills/standards-discover/references/docs-extractor-prompt.md

@@ -12,7 +12,7 @@ Find and parse documentation files, extract explicitly stated standards, return
 2. **CONTRIBUTING.md** — PR requirements, commit conventions, testing requirements, code review standards
 3. **ARCHITECTURE.md** / `docs/architecture/` — Design patterns, architectural decisions
 4. **ADRs** (Architecture Decision Records) — `adr/`, `decisions/`, `docs/decisions/` directories
-5. **AGENTS.md** / `.claude/AGENTS.md` — AI-specific coding instructions and project conventions
+5. **AGENTS.md** / `AGENTS.md` — AI-specific coding instructions and project conventions
 6. **Code of Conduct**, **STYLEGUIDE.md** — If present
 
 ## What to Extract

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "owflow",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Spec-driven development AI workflow for OpenCode",
   "type": "module",
   "module": "index.ts",