owflow 0.1.5 → 0.1.6

package/dist/skills/development/SKILL.md

@@ -18,7 +18,7 @@ Unified workflow for all development tasks — bug fixes, enhancements, and new
 
 1. `../orchestrator-framework/references/orchestrator-patterns.md` - Delegation rules, interactive mode, state schema, initialization, context passing, issue resolution
 
-### Step 2: Detect Research Context
+### Step 2: Detect Prior Work Context
 
 **If argument is a research folder path** (matches `.owflow/tasks/research/*`):
 
@@ -32,11 +32,39 @@ Unified workflow for all development tasks — bug fixes, enhancements, and new
 - Copy to `analysis/research-context/`
 - Set `research_reference` in state
 
+**If argument is a quick-\* task folder path** (matches `.owflow/tasks/quick-*/`):
+
+1. Read `task.yml` — extract `command`, `description`, `standards_applied`, `escalation_reason`
+2. Read `analysis/findings.md` — extract root cause, affected files, complexity assessment, test strategy
+3. Use `description` as the task description (same as research extracts `research_question`)
+4. Set `quick_reference` in orchestrator state:
+   ```yaml
+   task_context:
+     quick_reference:
+       path: .owflow/tasks/quick-bugfix/2026-05-28-fix-login-timeout
+       command: quick-bugfix
+       escalation_reason: "5+ files, unclear root cause"
+     phase_summaries:
+       quick_analysis:
+         { summary: "...", affected_files: [...], root_cause: "..." }
+   ```
+5. Update the quick-\* `task.yml`: set `escalated_to` to the new development task path
+
+**How quick-\* context informs development phases**:
+
+| Phase   | How Quick-\* Context is Used                                                |
+| ------- | --------------------------------------------------------------------------- |
+| Phase 1 | Codebase analyzer receives affected files and root cause as search guidance |
+| Phase 2 | Gap analyzer uses complexity assessment for risk level                      |
+| Phase 3 | TDD gate uses test strategy from findings.md as starting point              |
+| Phase 4 | Specification creator receives prior analysis as input context              |
+
 ### Step 3: Initialize Workflow
 
 1. **Create Task Items**: Use `TaskCreate` for all phases (see Phase Configuration), then set dependencies with `TaskUpdate addBlockedBy`
 2. **Create Task Directory**: `.owflow/tasks/development/YYYY-MM-DD-task-name/`
 3. **Initialize State**: Create `orchestrator-state.yml` with task info and research reference
+   - **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-development.yml`.
 4. **Discover project documentation**: Read `.owflow/docs/INDEX.md` (if exists), extract ALL file paths from the "Project Documentation" section. This includes predefined docs (vision, roadmap, tech-stack, architecture) AND any user-added project docs (e.g., deployment.md, api-strategy.md). Store complete list as `project_context.project_doc_paths` in state.
 
 **Output**:
@@ -67,17 +95,16 @@ Use for **all development tasks**: bug fixes, enhancements, new features, and an
 | 1     | "Analyze codebase & clarify requirements"    | "Analyzing codebase & clarifying"                 | Always                         |
 | 2     | "Analyze gaps & clarify scope"               | "Analyzing gaps & clarifying scope"               | Always                         |
 | 3     | "Write failing test (TDD Red)"               | "Writing failing test"                            | When `has_reproducible_defect` |
-| 4     | "Generate UI mockups"                        | "Generating UI mockups"                           | When `ui_heavy`                |
-| 5     | "Gather requirements & create specification" | "Gathering requirements & creating specification" | Always                         |
-| 6     | "Audit specification"                        | "Auditing specification"                          | Always (conditional)           |
-| 7     | "Plan implementation"                        | "Planning implementation"                         | Always                         |
-| 8     | "Execute implementation"                     | "Executing implementation"                        | Always                         |
-| 9     | "Verify test passes (TDD Green)"             | "Verifying test passes"                           | When Phase 3 was executed      |
-| 10    | "Prompt verification options"                | "Prompting verification options"                  | Always                         |
-| 11    | "Verify implementation & resolve issues"     | "Verifying implementation"                        | Always                         |
-| 12    | "Run E2E tests"                              | "Running E2E tests"                               | When `e2e_enabled`             |
-| 13    | "Generate user documentation"                | "Generating user documentation"                   | When `user_docs_enabled`       |
-| 14    | "Finalize workflow"                          | "Finalizing workflow"                             | Always                         |
+| 4     | "Gather requirements & create specification" | "Gathering requirements & creating specification" | Always                         |
+| 5     | "Audit specification"                        | "Auditing specification"                          | Always (conditional)           |
+| 6     | "Plan implementation"                        | "Planning implementation"                         | Always                         |
+| 7     | "Execute implementation"                     | "Executing implementation"                        | Always                         |
+| 8     | "Verify test passes (TDD Green)"             | "Verifying test passes"                           | When Phase 3 was executed      |
+| 9     | "Prompt verification options"                | "Prompting verification options"                  | Always                         |
+| 10    | "Verify implementation & resolve issues"     | "Verifying implementation"                        | Always                         |
+| 11    | "Run E2E tests"                              | "Running E2E tests"                               | When `e2e_enabled`             |
+| 12    | "Generate user documentation"                | "Generating user documentation"                   | When `user_docs_enabled`       |
+| 13    | "Finalize workflow"                          | "Finalizing workflow"                             | Always                         |
 
 ---
 
@@ -136,14 +163,12 @@ Use for **all development tasks**: bug fixes, enhancements, new features, and an
 
 **ANTI-PATTERN — DO NOT DO THIS:**
 
-- ❌ "The UI change is small/simple, skipping Phase 4..." — STOP. If `ui_heavy` is true, Phase 4 runs. The gap-analyzer made this assessment, not you.
 - ❌ "No new screens needed, just a component..." — STOP. `ui_heavy` is a signal from the gap-analyzer. Do NOT override it with your own complexity judgment.
 
-question - Display executive summary before asking. Read `analysis/gap-analysis.md` and extract: task type detected, risk level, key characteristics enabled (TDD gates, UI mockups, E2E, user docs), scope decisions made (if any). Then read `task_context.task_characteristics` from `orchestrator-state.yml` and determine the next phase:
+question - Display executive summary before asking. Read `analysis/gap-analysis.md` and extract: task type detected, risk level, key characteristics enabled (TDD gates, E2E, user docs), scope decisions made (if any). Then read `task_context.task_characteristics` from `orchestrator-state.yml` and determine the next phase:
 
 - If `has_reproducible_defect` is true → ask "Continue to Phase 3: TDD Red Gate?"
-- If `ui_heavy` is true → ask "Continue to Phase 4: UI Mockup Generation?"
-- Otherwise → ask "Continue to Phase 5: Technical Approach, Requirements & Specification?"
+- Otherwise → ask "Continue to Phase 4: Technical Approach, Requirements & Specification?"
 
 ---
 
@@ -166,30 +191,11 @@ question - "TDD red gate complete. Continue to Phase 4?"
 
 ---
 
-### Phase 4: UI Mockup Generation (Conditional)
+### Phase 4: Technical Approach, Requirements & Specification
 
 > **Phase gate**: Requires `question` confirmation from the preceding phase before executing.
 
-**Purpose**: Generate ASCII mockups showing UI integration
-**Execute**: Task tool - `ui-mockup-generator` subagent
-**Output**: `analysis/ui-mockups.md`
-**State**: Update `phase_summaries.ui_mockups`
-
-**Skip if**: `task_characteristics.ui_heavy` is false
-
-**Context to pass**: Gap analysis, scope decisions, component choices
-
-→ Pause
-
-question - "UI mockups complete. Continue to Phase 5?"
-
----
-
-### Phase 5: Technical Approach, Requirements & Specification
-
-> **Phase gate**: Requires `question` confirmation from the preceding phase before executing.
-
-**⛔ ROUTING GUARD**: Read `task_context.task_characteristics` from `orchestrator-state.yml`. If `has_reproducible_defect` is true and Phase 3 is NOT in `completed_phases` → STOP, execute Phase 3 first. If `ui_heavy` is true and Phase 4 is NOT in `completed_phases` → STOP, execute Phase 4 first.
+**⛔ ROUTING GUARD**: Read `task_context.task_characteristics` from `orchestrator-state.yml`. If `has_reproducible_defect` is true and Phase 3 is NOT in `completed_phases` → STOP, execute Phase 3 first.
 
 **Purpose**: Resolve technical decisions, gather specification requirements, then create comprehensive specification
 **Execute**:
@@ -253,9 +259,9 @@ question - Display executive summary before asking. Read `implementation/spec.md
 
 ---
 
-### Phase 6: Specification Audit (Recommended)
+### Phase 5: Specification Audit (Recommended)
 
-> **Phase gate**: Requires `question` confirmation from Phase 5 before executing.
+> **Phase gate**: Requires `question` confirmation from Phase 4 before executing.
 
 **Purpose**: Independent review of specification before implementation
 **Execute**: Task tool - `spec-auditor` subagent
@@ -272,9 +278,9 @@ question - Display executive summary before asking. Read `verification/spec-audi
 
 ---
 
-### Phase 7: Implementation Planning
+### Phase 6: Implementation Planning
 
-> **Phase gate**: Requires `question` confirmation from Phase 6 before executing.
+> **Phase gate**: Requires `question` confirmation from Phase 5 before executing.
 
 **Purpose**: Break specification into implementation steps
 
@@ -306,9 +312,9 @@ question - Display executive summary before asking. Read `implementation/impleme
 
 ---
 
-### Phase 8: Implementation
+### Phase 7: Implementation
 
-> **Phase gate**: Requires `question` confirmation from Phase 7 before executing.
+> **Phase gate**: Requires `question` confirmation from Phase 6 before executing.
 
 **Purpose**: Execute the implementation plan
 
@@ -328,8 +334,8 @@ question - Display executive summary before asking. Read `implementation/impleme
 **⚠️ POST-IMPLEMENTATION CONTINUATION** — After the skill completes and returns control:
 
 1. Read `orchestrator-state.yml` to confirm you are the orchestrator
-2. Update state: add Phase 8 to `completed_phases`
-3. Evaluate conditional: if `task_characteristics.has_reproducible_defect` AND Phase 3 in `completed_phases` → Phase 9, else → Phase 10
+2. Update state: add Phase 7 to `completed_phases`
+3. Evaluate conditional: if `task_characteristics.has_reproducible_defect` AND Phase 3 in `completed_phases` → Phase 8, else → Phase 9
 
 → Pause
 
@@ -337,9 +343,9 @@ question - Display executive summary before asking. Extract from `phase_summarie
 
 ---
 
-### Phase 9: TDD Green Gate (Conditional)
+### Phase 8: TDD Green Gate (Conditional)
 
-> **Phase gate**: Requires `question` confirmation from Phase 8 before executing.
+> **Phase gate**: Requires `question` confirmation from Phase 7 before executing.
 
 **Purpose**: Verify the failing test now passes
 **Execute**: Direct - run the test written in Phase 3
@@ -352,11 +358,11 @@ question - Display executive summary before asking. Extract from `phase_summarie
 
 → Pause
 
-question - "TDD gate passed. Continue to Phase 10?"
+question - "TDD gate passed. Continue to Phase 9?"
 
 ---
 
-### Phase 10: Verification Options Prompt
+### Phase 9: Verification Options Prompt
 
 > **Phase gate**: Requires `question` confirmation from the preceding phase before executing.
 
@@ -398,9 +404,9 @@ Options: "Code review (Recommended)", "Pragmatic review (Recommended)", "Reality
 
 ---
 
-### Phase 11: Verification & Issue Resolution
+### Phase 10: Verification & Issue Resolution
 
-> **Phase gate**: Requires `question` confirmation from Phase 10 before executing.
+> **Phase gate**: Requires `question` confirmation from Phase 9 before executing.
 
 **Purpose**: Comprehensive implementation verification with fix-then-reverify cycles
 **Output**: `verification/implementation-verification.md`, optional code-review/pragmatic/reality reports, updated `implementation/work-log.md`
@@ -453,18 +459,18 @@ Verification Results:
 **⚠️ POST-VERIFICATION CONTINUATION** — After issue resolution completes:
 
 1. Read `orchestrator-state.yml` to confirm you are the orchestrator
-2. Update state: add Phase 11 to `completed_phases`
-3. Proceed to Phase 12
+2. Update state: add Phase 10 to `completed_phases`
+3. Proceed to Phase 11
 
 → Pause
 
-question - Display executive summary: total issues found, issues fixed, issues remaining by severity. Then "Continue to Phase 12?"
+question - Display executive summary: total issues found, issues fixed, issues remaining by severity. Then "Continue to Phase 11?"
 
 ---
 
-### Phase 12: E2E Testing (Optional)
+### Phase 11: E2E Testing (Optional)
 
-> **Phase gate**: Requires `question` confirmation from Phase 11 before executing.
+> **Phase gate**: Requires `question` confirmation from Phase 10 before executing.
 
 **Purpose**: Runtime browser verification with screenshots (via Playwright MCP tools, not test file generation)
 **Execute**: Task tool - `e2e-test-verifier` subagent
@@ -476,11 +482,11 @@ question - Display executive summary: total issues found, issues fixed, issues r
 
 → Pause
 
-question - "E2E complete. Continue to Phase 13?"
+question - "E2E complete. Continue to Phase 12?"
 
 ---
 
-### Phase 13: User Documentation (Optional)
+### Phase 12: User Documentation (Optional)
 
 > **Phase gate**: Requires `question` confirmation from the preceding phase before executing.
 
@@ -494,11 +500,11 @@ question - "E2E complete. Continue to Phase 13?"
 
 → Pause
 
-question - "Documentation complete. Continue to Phase 14?"
+question - "Documentation complete. Continue to Phase 13?"
 
 ---
 
-### Phase 14: Finalization
+### Phase 13: Finalization
 
 > **Phase gate**: Requires `question` confirmation from the preceding phase before executing.
 
@@ -522,44 +528,7 @@ question - "Documentation complete. Continue to Phase 14?"
 
 Development-specific fields in `orchestrator-state.yml`:
 
-```yaml
-orchestrator:
-  options:
-    spec_audit_enabled: true
-    skip_test_suite: true
-    e2e_enabled: null
-    user_docs_enabled: null
-    code_review_enabled: true
-    pragmatic_review_enabled: true
-    reality_check_enabled: true
-    production_check_enabled: true
-  task_context:
-    risk_level: null
-    clarifications_resolved: null
-    scope_expanded: null
-    architecture_decision: null
-    task_characteristics:
-      has_reproducible_defect: false
-      modifies_existing_code: false
-      creates_new_entities: false
-      involves_data_operations: false
-      ui_heavy: false
-    research_reference:
-      path: null
-      research_question: null
-      research_type: null
-      confidence_level: null
-    phase_summaries:
-      research: { summary: null, key_findings: [], recommended_approach: null }
-      codebase_analysis:
-        { key_files: [], primary_language: null, summary: null }
-      clarifications: []
-      gap_analysis: { integration_points: [], summary: null }
-      scope_clarifications: { scope_expanded: null, summary: null }
-      ui_mockups: { components_designed: [], summary: null }
-      specification: { summary: null }
-      architecture_decision: { decision: null, summary: null }
-```
+Refer to the template [src/templates/orchestrator-state-development.yml](../../templates/orchestrator-state-development.yml).
 
 ---
 
@@ -574,21 +543,20 @@ orchestrator:
 │   ├── clarifications.md          # Phase 1
 │   ├── gap-analysis.md            # Phase 2
 │   ├── scope-clarifications.md    # Phase 2 (conditional)
-│   ├── technical-clarifications.md # Phase 5 (conditional)
-│   └── ui-mockups.md              # Phase 4 (conditional)
+│   └── technical-clarifications.md # Phase 4 (conditional)
 ├── implementation/
-│   ├── spec.md                    # Phase 5
-│   ├── requirements.md            # Phase 5
-│   ├── implementation-plan.md     # Phase 7
-│   ├── work-log.md                # Phase 8
+│   ├── spec.md                    # Phase 4
+│   ├── requirements.md            # Phase 4
+│   ├── implementation-plan.md     # Phase 6
+│   ├── work-log.md                # Phase 7
 │   ├── tdd-red-gate.md            # Phase 3 (conditional)
-│   └── tdd-green-gate.md          # Phase 9 (conditional)
+│   └── tdd-green-gate.md          # Phase 8 (conditional)
 ├── verification/
-│   ├── spec-audit.md              # Phase 6 (recommended)
-│   ├── implementation-verification.md  # Phase 11
-│   └── e2e-verification-report.md      # Phase 12 (optional)
+│   ├── spec-audit.md              # Phase 5 (recommended)
+│   ├── implementation-verification.md  # Phase 10
+│   └── e2e-verification-report.md      # Phase 11 (optional)
 └── documentation/
-    └── user-guide.md              # Phase 13 (optional)
+    └── user-guide.md              # Phase 12 (optional)
 ```
 
 ---
@@ -652,9 +620,9 @@ When research context is detected, read these files from the research folder:
 | -------------------- | --------------------------------- | ---------------------------------------------- |
 | State                | `orchestrator-state.yml`          | research_type, confidence_level                |
 | Report               | `outputs/research-report.md`      | Main findings and conclusions                  |
-| Solution Exploration | `outputs/solution-exploration.md` | Alternatives and trade-offs (input to Phase 5) |
-| High-Level Design    | `outputs/high-level-design.md`    | C4 architecture (input to Phase 5)             |
-| Decision Log         | `outputs/decision-log.md`         | ADR decisions (input to Phase 5)               |
+| Solution Exploration | `outputs/solution-exploration.md` | Alternatives and trade-offs (input to Phase 4) |
+| High-Level Design    | `outputs/high-level-design.md`    | C4 architecture (input to Phase 4)             |
+| Decision Log         | `outputs/decision-log.md`         | ADR decisions (input to Phase 4)               |
 
 ### How Research Informs Each Phase
 
@@ -664,8 +632,8 @@ When research context is detected, read these files from the research folder:
 | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | Phase 1 | Codebase analyzer receives research findings as search guidance                                                                                                                      |
 | Phase 2 | Gap analyzer uses research recommendations for comparison                                                                                                                            |
-| Phase 5 | Specification creator uses high-level-design.md as INPUT (still creates full spec). Architecture decisions use research report AND decision-log.md (lighter when ADRs comprehensive) |
-| Phase 7 | Implementation planner references research approach for task grouping                                                                                                                |
+| Phase 4 | Specification creator uses high-level-design.md as INPUT (still creates full spec). Architecture decisions use research report AND decision-log.md (lighter when ADRs comprehensive) |
+| Phase 6 | Implementation planner references research approach for task grouping                                                                                                                |
 
 ---
 
@@ -681,4 +649,4 @@ Invoked via:
 ## TDD Gate Rules
 
 **Phase 3 (Red Gate)**: Test MUST FAIL before implementation (activated when gap-analyzer detects reproducible defect)
-**Phase 9 (Green Gate)**: Test MUST PASS after implementation (activated when Phase 3 was executed)
+**Phase 8 (Green Gate)**: Test MUST PASS after implementation (activated when Phase 3 was executed)

package/dist/skills/migration/SKILL.md

@@ -23,6 +23,7 @@ Systematic migration workflow from current state analysis to verified migration
 1. **Create Task Items**: Use `TaskCreate` for all phases (see Phase Configuration), then set dependencies with `TaskUpdate addBlockedBy`
 2. **Create Task Directory**: `.owflow/tasks/migrations/YYYY-MM-DD-task-name/`
 3. **Initialize State**: Create `orchestrator-state.yml` with migration context
+   - **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-migration.yml`.
 4. **Discover project documentation**: Read `.owflow/docs/INDEX.md` (if exists), extract ALL file paths from the "Project Documentation" section — includes predefined docs AND any user-added project docs. Store as `project_context.project_doc_paths` in state.
 
 **Output**:
@@ -308,39 +309,7 @@ question - Display executive summary: total issues found, issues fixed, issues r
 
 Migration-specific fields in `orchestrator-state.yml`:
 
-```yaml
-migration_context:
-  migration_type: "code" | "data" | "architecture" | "general"
-  current_system:
-    description: null
-    technologies: []
-  target_system:
-    description: null
-    technologies: []
-  migration_strategy:
-    approach: "incremental" | "big-bang" | "dual-run" | "phased"
-    phases: []
-  risk_level: null
-  breaking_changes: []
-  rollback_plan_created: false
-  dual_run_configured: false
-
-external_research:
-  performed: false
-  category: null
-  breaking_changes: []
-  migration_guide_url: null
-
-verification_context:
-  last_status: null
-  issues_found: null
-  fixes_applied: []
-  decisions_made: []
-  reverify_count: 0
-
-options:
-  docs_enabled: false
-```
+Refer to the template [src/templates/orchestrator-state-migration.yml](../../templates/orchestrator-state-migration.yml).
 
 ---
 

package/dist/skills/orchestrator-framework/references/orchestrator-creation-checklist.md

@@ -10,6 +10,7 @@ Before considering an orchestrator complete, verify ALL items:
 
 - [ ] **Step 0: Load Framework** — Initialization reads `orchestrator-patterns.md`
 - [ ] **State file creation** — Explicit step to CREATE `orchestrator-state.yml`
+- [ ] **State verification** — Explicit step to use `verify_template` to check YAML validity after creation
 - [ ] **Phase structure** — Each phase has: Purpose, Execute, Output, State, Transition (`→ Pause` / `→ AUTO-CONTINUE` / `→ Conditional`)
 - [ ] **Delegation enforcement** — Each delegated phase has: ANTI-PATTERN block, INVOKE NOW block, SELF-CHECK
 - [ ] **POST-CONTINUATION blocks** — After Skill tool phases, explicit instructions to read state, update completed_phases, and continue

package/dist/skills/orchestrator-framework/references/orchestrator-patterns.md

@@ -163,42 +163,7 @@ All orchestrators use `orchestrator-state.yml` at `.owflow/tasks/[type]/YYYY-MM-
 
 ### Common Fields
 
-```yaml
-orchestrator:
-  # Phase tracking
-  started_phase: [phase-name]
-  completed_phases: []
-  failed_phases: []
-
-  # Auto-fix tracking (per phase)
-  auto_fix_attempts:
-    phase-1: 0
-    phase-2: 0
-
-  # Optional phase flags
-  options:
-    e2e_enabled: true | false | null
-    user_docs_enabled: true | false | null
-    code_review_enabled: true | false | null
-
-  # Timestamps
-  created: [ISO 8601 timestamp]
-  updated: [ISO 8601 timestamp]
-  task_path: .owflow/tasks/[type]/YYYY-MM-DD-task-name
-
-  # Task tracking IDs (maps phase names to TaskCreate IDs)
-  task_ids:
-    phase-1: null
-    phase-2: null
-
-# Task metadata
-task:
-  title: [human-readable task title]
-  description: [full task description]
-  status: pending | in_progress | completed | failed | blocked
-  tags: []
-  priority: null # high | medium | low
-```
+Refer to the template [src/templates/orchestrator-state-base.yml](../../../templates/orchestrator-state-base.yml).
 
 ### Extension Pattern
 
@@ -217,21 +182,7 @@ See each orchestrator's SKILL.md "Domain Context" section for full schema.
 
 When development starts from completed research (`--research` flag):
 
-```yaml
-task_context:
-  research_reference:
-    path: null
-    research_question: null
-    research_type: null # technical | requirements | literature | mixed
-    confidence_level: null # high | medium | low
-
-  phase_summaries:
-    research:
-      summary: null
-      key_findings: []
-      recommended_approach: null
-      decisions_made: []
-```
+Refer to `research_reference` in the template [src/templates/orchestrator-state-development.yml](../../../templates/orchestrator-state-development.yml).
 
 Research context flows to ALL phases via context passing. Artifacts are also copied to `analysis/research-context/`.
 
@@ -239,14 +190,7 @@ Research context flows to ALL phases via context passing. Artifacts are also cop
 
 All orchestrators with verification phases use:
 
-```yaml
-verification_context:
-  last_status: passed | passed_with_issues | failed | null
-  issues_found: []
-  fixes_applied: []
-  decisions_made: []
-  reverify_count: 0 # max 3
-```
+Refer to `verification_context` in the template [src/templates/orchestrator-state-base.yml](../../../templates/orchestrator-state-base.yml) or domain templates.
 
 ---
 
@@ -258,6 +202,7 @@ verification_context:
 2. **Determine starting phase**: New task starts Phase 1; resume reads state for first incomplete phase
 3. **Create task directory**: Standard structure with analysis/, implementation/, verification/, documentation/ _(skip on resume)_
 4. **Create state file**: `orchestrator-state.yml` _(skip on resume)_
+   - **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against the corresponding template.
 5. **Create task items**: `TaskCreate` for all phases, then `TaskUpdate addBlockedBy` for dependencies. On resume, also restore completed phase statuses.
 6. **Output summary**: Show task info, phases, starting message
 

package/dist/skills/performance/SKILL.md

@@ -24,6 +24,7 @@ Static-analysis-first performance optimization workflow. Identifies bottlenecks
 2. **Create Task Directory**: `.owflow/tasks/performance/YYYY-MM-DD-task-name/`
 3. **Create Subdirectories**: `analysis/`, `analysis/user-profiling-data/`, `implementation/`, `verification/`
 4. **Initialize State**: Create `orchestrator-state.yml` with performance context
+   - **CRITICAL**: Use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-performance.yml`.
 5. **Discover project documentation**: Read `.owflow/docs/INDEX.md` (if exists), extract ALL file paths from the "Project Documentation" section — includes predefined docs AND any user-added project docs. Store as `project_context.project_doc_paths` in state.
 
 **Output**:
@@ -353,36 +354,7 @@ question - Display executive summary: total issues found, issues fixed, issues r
 
 Performance-specific fields in `orchestrator-state.yml`:
 
-```yaml
-performance_context:
-  bottlenecks_identified: null # count from bottleneck-analyzer
-  user_data_available: false # whether user provided profiling data
-  bottleneck_priorities:
-    p0: 0
-    p1: 0
-    p2: 0
-    p3: 0
-  phase_summaries:
-    codebase_analysis: { key_files: [], summary: null }
-    bottleneck_analysis:
-      { bottlenecks: [], summary: null, user_data_incorporated: false }
-    specification: { summary: null }
-
-verification_context:
-  last_status: null
-  issues_found: null
-  fixes_applied: []
-  decisions_made: []
-  reverify_count: 0
-
-options:
-  spec_audit_enabled: null
-  skip_test_suite: true
-  code_review_enabled: true
-  pragmatic_review_enabled: true
-  reality_check_enabled: true
-  production_check_enabled: null
-```
+Refer to the template [src/templates/orchestrator-state-performance.yml](../../templates/orchestrator-state-performance.yml).
 
 ---