owflow 0.1.3 → 0.1.5

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/performance/SKILL.md

@@ -168,6 +168,12 @@ question - "Performance analysis complete. [N] bottlenecks identified ([P0 count
 
 **SELF-CHECK**: Did you just invoke the Task tool with `specification-creator`? Or did you start writing spec.md yourself? If the latter, STOP and invoke the Task tool.
 
+**Part C — Diagram Refinement (Skill, content-preserving)**:
+
+5. Invoke Skill tool: `diagrams-mermaid` to refine `implementation/spec.md`
+6. Add diagrams that clarify bottleneck flows and optimization boundaries without replacing specification text.
+7. If context for a diagram is missing, document gaps and avoid speculative dependencies.
+
 → Pause
 
 question - Display executive summary before asking. Read `implementation/spec.md` and extract: optimization targets, approach chosen, number of changes planned, expected impact. Format as brief overview then "Continue to specification audit?"
@@ -217,6 +223,12 @@ question - Display executive summary before asking. Read `verification/spec-audi
 
 **SELF-CHECK**: Did you just invoke the Task tool with `implementation-planner`? Or did you start writing the plan yourself? If the latter, STOP and invoke the Task tool.
 
+**Post-plan diagram refinement (Skill, content-preserving)**:
+
+- Invoke Skill tool: `diagrams-mermaid` for `implementation/implementation-plan.md`
+- Add one compact optimization execution flow (task-group dependency or state flow).
+- Keep plan steps authoritative; diagrams are explanatory additions only.
+
 → Pause
 
 question - Display executive summary before asking. Read `implementation/implementation-plan.md` and extract: number of task groups, total steps, key dependencies, optimization sequence. Format as brief overview then "Continue to implementation?"

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/research/SKILL.md

@@ -326,6 +326,14 @@ question - "Brainstorming complete. Continue to high-level design?"
 - Key decision highlights (1 line each)
 - Integration points with existing system (if applicable)
 
+**Part D — Diagram Refinement (Skill, content-preserving)**:
+
+5. Invoke Skill tool: `diagrams-mermaid` to refine visual communication in `outputs/high-level-design.md`
+6. Add diagrams that supplement (not replace) existing architecture content:
+   - one architecture view (`C4Container` preferred, `C4Component` only if needed),
+   - one interaction/state view (`sequenceDiagram` or `flowchart`) for the critical flow.
+7. If minimum context for a diagram is missing, record explicit gaps in the document and avoid speculative components/relationships.
+
 → Pause
 
 question - "Design complete. Continue to output generation?"

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.5",
   "description": "Spec-driven development AI workflow for OpenCode",
   "type": "module",
   "module": "index.ts",