owflow 0.1.3 → 0.1.5

package/dist/skills/html-renderer/references/tokens.json

@@ -0,0 +1,104 @@
+{
+  "meta": {
+    "name": "html-renderer-tokens",
+    "version": "1.0.0",
+    "description": "Global visual tokens for markdown to HTML rendering."
+  },
+  "colors": {
+    "primary": "#cc785c",
+    "primaryActive": "#a9583e",
+    "primaryDisabled": "#e6dfd8",
+    "ink": "#141413",
+    "body": "#3d3d3a",
+    "bodyStrong": "#252523",
+    "muted": "#6c6a64",
+    "mutedSoft": "#8e8b82",
+    "hairline": "#e6dfd8",
+    "hairlineSoft": "#ebe6df",
+    "canvas": "#faf9f5",
+    "surfaceSoft": "#f5f0e8",
+    "surfaceCard": "#efe9de",
+    "surfaceCreamStrong": "#e8e0d2",
+    "surfaceDark": "#181715",
+    "surfaceDarkElevated": "#252320",
+    "surfaceDarkSoft": "#1f1e1b",
+    "onPrimary": "#ffffff",
+    "onDark": "#faf9f5",
+    "onDarkSoft": "#a09d96",
+    "accentTeal": "#5db8a6",
+    "accentAmber": "#e8a55a",
+    "success": "#5db872",
+    "warning": "#d4a017",
+    "error": "#c64545"
+  },
+  "spacing": {
+    "xxs": "4px",
+    "xs": "8px",
+    "sm": "12px",
+    "md": "16px",
+    "lg": "24px",
+    "xl": "32px",
+    "xxl": "48px",
+    "section": "96px"
+  },
+  "radius": {
+    "xs": "4px",
+    "sm": "6px",
+    "md": "8px",
+    "lg": "12px",
+    "xl": "16px",
+    "pill": "9999px",
+    "full": "9999px"
+  },
+  "typography": {
+    "displayXl": {
+      "fontFamily": "\"Copernicus\", \"Tiempos Headline\", \"Cormorant Garamond\", \"EB Garamond\", Georgia, serif",
+      "fontSize": "64px",
+      "fontWeight": 400,
+      "lineHeight": 1.05,
+      "letterSpacing": "-1.5px"
+    },
+    "displayLg": {
+      "fontFamily": "\"Copernicus\", \"Tiempos Headline\", \"Cormorant Garamond\", \"EB Garamond\", Georgia, serif",
+      "fontSize": "48px",
+      "fontWeight": 400,
+      "lineHeight": 1.1,
+      "letterSpacing": "-1px"
+    },
+    "displayMd": {
+      "fontFamily": "\"Copernicus\", \"Tiempos Headline\", \"Cormorant Garamond\", \"EB Garamond\", Georgia, serif",
+      "fontSize": "36px",
+      "fontWeight": 400,
+      "lineHeight": 1.15,
+      "letterSpacing": "-0.5px"
+    },
+    "titleMd": {
+      "fontFamily": "\"StyreneB\", \"Styrene B\", Inter, -apple-system, BlinkMacSystemFont, \"Segoe UI\", sans-serif",
+      "fontSize": "18px",
+      "fontWeight": 500,
+      "lineHeight": 1.4,
+      "letterSpacing": "0"
+    },
+    "bodyMd": {
+      "fontFamily": "\"StyreneB\", \"Styrene B\", Inter, -apple-system, BlinkMacSystemFont, \"Segoe UI\", sans-serif",
+      "fontSize": "16px",
+      "fontWeight": 400,
+      "lineHeight": 1.55,
+      "letterSpacing": "0"
+    },
+    "bodySm": {
+      "fontFamily": "\"StyreneB\", \"Styrene B\", Inter, -apple-system, BlinkMacSystemFont, \"Segoe UI\", sans-serif",
+      "fontSize": "14px",
+      "fontWeight": 400,
+      "lineHeight": 1.55,
+      "letterSpacing": "0"
+    },
+    "code": {
+      "fontFamily": "\"JetBrains Mono\", ui-monospace, monospace",
+      "fontSize": "14px",
+      "fontWeight": 400,
+      "lineHeight": 1.6,
+      "letterSpacing": "0"
+    }
+  }
+}

package/dist/skills/migration/SKILL.md

@@ -150,6 +150,12 @@ question - Display executive summary before asking. Extract from gap analysis: c
 **Output**: `analysis/requirements.md`, `implementation/spec.md`, `analysis/rollback-plan.md`, optionally `analysis/dual-run-plan.md`
 **State**: Update `rollback_plan_created`, `dual_run_configured`
 
+**Part C — Diagram Refinement (Skill, content-preserving)**:
+
+4. Invoke Skill tool: `diagrams-mermaid` to refine `implementation/spec.md`
+5. Add migration-focused visuals (target architecture and transition/compatibility flow) as supplements, not replacements for strategy prose.
+6. If minimum context is missing, record open gaps instead of inventing systems, protocols, or migration paths.
+
 → Pause
 
 question - Display executive summary before asking. Read `implementation/spec.md` and extract: migration strategy chosen, scope boundaries, rollback approach, breaking changes identified, key constraints. Format as brief overview then "Continue to implementation planning?"
@@ -167,6 +173,12 @@ question - Display executive summary before asking. Read `implementation/spec.md
 
 **Context to pass to subagent**: task_path, task_type (migration), migration_type, task_description, phase_summaries (current_state_analysis, gap_analysis, specification)
 
+**Post-plan diagram refinement (Skill, content-preserving)**:
+
+- Invoke Skill tool: `diagrams-mermaid` for `implementation/implementation-plan.md`
+- Add one migration execution/state flow with rollback checkpoints.
+- Preserve written task steps and rollback details as source of truth.
+
 → Pause
 
 question - Display executive summary before asking. Read `implementation/implementation-plan.md` and extract: number of task groups, total steps, rollback steps included, key dependencies, execution sequence. Format as brief overview then "Continue to execute migration?"

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