owflow 0.4.3 → 0.6.0

package/README.md

@@ -130,15 +130,26 @@ You can always be explicit when you prefer - arguments and flags simply override
 
 ## Supported Workflows
 
-| Command                | Use When                                    |
-| ---------------------- | ------------------------------------------- |
-| `/owflow:development`  | Features, bug fixes, enhancements           |
-| `/owflow:research`     | Research with synthesis and solution design |
-| `/owflow:performance`  | Optimizing speed or resource usage          |
-| `/owflow:migration`    | Changing technologies or patterns           |
+| Command                    | Use When                                       |
+| -------------------------- | ---------------------------------------------- |
+| `/owflow:development`      | Features, bug fixes, enhancements              |
+| `/owflow:research`         | Research with synthesis and solution design    |
+| `/owflow:performance`      | Optimizing speed or resource usage             |
+| `/owflow:migration`        | Changing technologies or patterns              |
 
 Use `/owflow:work` as a single entry point — it classifies the task with the `task-classifier` subagent and routes to the right workflow.
 
+### Autonomous Workflows
+
+Each workflow has a `/owflow:goal-*` equivalent that runs the same pipeline back-to-back in one session, pausing at decision gates between steps. Both modes share one task state, so you can mix them freely on a single task.
+
+| Command                    | Runs                          |
+| -------------------------- | ----------------------------- |
+| `/owflow:goal-development` | The full development pipeline |
+| `/owflow:goal-research`    | The full research pipeline    |
+| `/owflow:goal-performance` | The full performance pipeline |
+| `/owflow:goal-migration`   | The full migration pipeline   |
+
 ### Research Utility
 
 | Command                       | Use When                                                                        |
@@ -146,6 +157,10 @@ Use `/owflow:work` as a single entry point — it classifies the task with the `
 | `/owflow:research-quick "<description>"` | Condensed research: brief → plan → gather → synthesis in one pass     |
 | `/owflow:research-fork <task-path> ["<what this fork should explore>"]` | Branch a research task and re-run from the fork point with different choices |
 
+### Migration Subskills
+
+Migration runs as a pipeline of eight standalone subskills — `/owflow:migration-analyze`, `/owflow:migration-target`, `/owflow:migration-spec`, `/owflow:migration-plan`, `/owflow:migration-implement`, `/owflow:migration-verify`, `/owflow:migration-fix`, `/owflow:migration-finalize` — with `/owflow:migration` as the dispatcher and `/owflow:goal-migration` running the whole pipeline in one session. Flags: `--from=<slug>`, `--type=code|data|architecture|general`, `--no-web-research`.
+
 ### Quick Commands
 
 For smaller tasks that don't need a full workflow:
@@ -191,6 +206,17 @@ The full `/owflow:development` workflow consists of standalone subskills — `/o
 
 If a subskill is invoked too early in the workflow (prerequisite phases not yet complete), it stops and tells you exactly which steps to run first, in order. If the workflow state doesn't exist yet, use `/owflow:development <description>` to start from scratch.
 
+### Fine-Grained Control: Performance Subskills
+
+The full `/owflow:performance` workflow consists of standalone subskills — `/owflow:performance-analyze`, `/owflow:performance-spec`, `/owflow:performance-plan`, `/owflow:performance-implement`, `/owflow:performance-verify`, `/owflow:performance-finalize` — which you can also invoke individually. Each accepts a task path, or just a task-directory identifier:
+
+```bash
+/owflow:performance-analyze 2026-01-12-dashboard-queries
+/owflow:performance-verify .owflow/tasks/performance/2026-01-12-dashboard-queries
+```
+
+If a subskill is invoked too early in the workflow (prerequisite steps not yet complete), it stops and tells you exactly which steps to run first, in order. If the workflow state doesn't exist yet, use `/owflow:performance <description>` to start from scratch.
+
 ## Standards-Aware Development
 
 This is the key differentiator. Owflow doesn't just run workflows - it learns your project's conventions and enforces them:

package/dist/agents/bottleneck-analyzer.md

@@ -74,9 +74,11 @@ Detect ORM calls inside iteration constructs:
   - **Django**: Attribute access on queryset (lazy loading) inside template/view loops
   - **Rails**: Association method calls without `.includes()` or `.preload()`
   - **SQLAlchemy**: Relationship access without `joinedload()` or `subqueryload()`
+  - **Hibernate**: `@ManyToOne` lazy access in loop → `@Fetch(FetchMode.JOIN)` or JPQL `JOIN FETCH`
 
 **Missing Index Detection** (read schema/migrations, don't run EXPLAIN):
 - Read migration files and schema definitions to catalog existing indexes
+- Per-framework index locations: Rails `add_index`, Django `db_index` / Meta `indexes`, Sequelize `indexes`, Prisma `@@index`/`@@unique`, TypeORM `@Index`, SQL migrations `CREATE INDEX`
 - Grep for query patterns (WHERE, ORDER BY, JOIN columns)
 - Cross-reference: columns filtered/sorted on without corresponding indexes
 - Flag composite conditions without composite indexes
@@ -85,7 +87,9 @@ Detect ORM calls inside iteration constructs:
 - `SELECT *` when only a few columns are needed
 - Missing `LIMIT` on queries against large tables
 - String operations in WHERE clauses (`LIKE '%...'`)
+- `OR` conditions on different columns (prevents single index use)
 - Subqueries that could be JOINs
+- `DISTINCT` masking a JOIN issue
 - Unbounded queries without pagination
 
 **Output**: List of database bottlenecks with file:line references and fix approach

package/dist/agents/implementation-planner.md

@@ -281,7 +281,7 @@ groups:
 
 ## Integration
 
-**Invoked by**: development orchestrator (Phase 7), migration orchestrator (Phase 3)
+**Invoked by**: dev-plan, migration-plan
 
 **Prerequisites**:
 

package/dist/agents/production-readiness-checker.md

@@ -268,7 +268,7 @@ issue_counts:
 
 ## Integration
 
-**Invoked by**: implementation-verifier (Phase 3), performance orchestrator (Phase 4), standalone via `/owflow:reviews-production-readiness` command
+**Invoked by**: implementation-verifier (Phase 3; inside `performance-verify` for performance tasks), standalone via `/owflow:reviews-production-readiness` command
 
 **Prerequisites**:
 

package/dist/agents/specification-creator.md

@@ -303,7 +303,7 @@ warnings: ["any non-critical observations"]
 
 ## Integration
 
-**Invoked by**: development orchestrator (Phase 5), migration orchestrator (Phase 2)
+**Invoked by**: dev-spec, migration-spec
 
 **Prerequisites**:
 

package/dist/commands/work.md

@@ -146,8 +146,8 @@ Use Skill tool:
 Examples:
 
 - Resume development: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-23-fix"`
-- Restart from step: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-26-auth --from=verification-done"` (dev tasks use descriptive step slugs in `completed_phases`; performance and migration are the remaining `phase-N` holdouts — research uses the descriptive slugs in `templates/orchestrator-state-research.yml`)
-- Fresh attempts: `skill: "owflow:migration"` with `args: "--resume .owflow/tasks/migrations/2025-10-20-redux --reset-attempts"`
+- Restart from step: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-26-auth --from=verification-done"` (development, research, performance, and migration tasks use descriptive step slugs in `completed_phases`)
+- Fresh attempts: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-23-fix --reset-attempts"`
 
 ### Step 3: Classify & Route New Task
 
@@ -236,8 +236,8 @@ Display:
 | Workflow Type | Skill         | Args                                                |
 | ------------- | ------------- | --------------------------------------------------- |
 | development   | `development` | `--resume [path] [--from=<slug>] [--reset-attempts]` |
-| performance   | `performance` | `--resume [path] [--from=PHASE]`                    |
-| migration     | `migration`   | `--resume [path] [--from=PHASE]`                    |
+| performance   | `performance` | `--resume [path] [--from=<slug>]`                   |
+| migration     | `migration`   | `--resume [path] [--from=<slug>]`                   |
 | research      | `research`    | `--resume [path] [--from=<slug>]`                   |
 
 ---

package/dist/skills/codebase-analyzer/SKILL.md

@@ -155,8 +155,8 @@ risk_level: low|low-medium|medium|medium-high|high
 
 ## Integration
 
-| Orchestrator | Phase | artifact_name |
+| Orchestrator | Step (slug) | artifact_name |
 |-------------|-------|---------------|
-| development orchestrator | Phase 1 | `codebase-analysis.md` (default) |
-| migration orchestrator | Phase 1 | `current-state-analysis.md` |
-| performance orchestrator | Phase 1 | `codebase-analysis.md` (default) |
+| development orchestrator | `codebase-analysed` | `codebase-analysis.md` (default) |
+| migration-analyze | `state-analysed` | `current-state-analysis.md` |
+| performance-analyze | `codebase-analysed` | `codebase-analysis.md` (default) |

package/dist/skills/dev-verify/SKILL.md

@@ -43,7 +43,7 @@ Resolve the `task-path-or-identifier` argument BEFORE anything else (see [Gate C
 
 ## Execute
 
-**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md) and [Issue Resolution](../orchestrator-framework/references/orchestrator-patterns.md) (Section 6).
+**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md), the [Fix Loop Contract](../orchestrator-framework/references/fix-loop-contract.md), and [Issue Resolution](../orchestrator-framework/references/orchestrator-patterns.md) (Section 6).
 
 ### Verification Options Prompt (`options-chosen`, inline)
 
@@ -94,14 +94,7 @@ Verification Results:
 
 **Step 3**: Gate on status — `passed` → skip to State Update. `passed_with_issues` or `failed` → fix loop (Step 4).
 
-**Step 4**: User-driven fix loop (max 3 iterations):
-
-1. Present critical + warning issues as a numbered list.
-2. `question` — "Which issues should I fix?" Options: "Fix all fixable issues" / "Let me choose specific issues" / "Skip fixes, proceed as-is".
-3. Fix selected issues; **immediately** log each to `verification_context.fixes_applied` in state (not deferred to the end).
-4. After fixes: set `skip_test_suite: false` (code changed, tests must re-run).
-5. `question` — "Re-run verification to check fixes?" → re-invoke `implementation-verifier` → back to Step 2, or "No, proceed to next phase".
-6. **Immediately** update `verification_context.reverify_count` and `verification_context.last_status` in state after each verifier run.
+**Step 4**: User-driven fix loop (max 3 iterations) — follow the [Fix Loop Contract](../orchestrator-framework/references/fix-loop-contract.md): the three-option question wording, immediate `fixes_applied` writes, `skip_test_suite: false` after fixes, re-invoking `implementation-verifier` on request, and refreshing `reverify_count` / `last_status` / `issues_found` right after each verifier run.
 
 **Exit conditions**: no critical issues remain → proceed; user explicitly chooses to proceed with issues → proceed with issues logged; max 3 iterations → `question` "Proceed with known issues?" / "Stop workflow". **MUST NOT proceed with unresolved critical issues unless the user explicitly approves.**
 
@@ -111,7 +104,7 @@ Apply after EVERY phase/step above:
 
 1. **Write immediately** — update `orchestrator-state.yml` as soon as the step completes, appending ONLY the step slug actually performed plus that step's fields. Never defer writes to the end of the skill.
 2. **Options prompt** — append `options-chosen` to `completed_phases` with the chosen `options.*` and `skip_test_suite` (written right after the options prompt, before verification starts).
-3. **Per verifier run** — update `verification_context.last_status`, `issues_found`, `fixes_applied`, and `reverify_count` immediately after each `implementation-verifier` run and after each fix-loop iteration (per steps 3/6 above), so an interruption loses nothing.
+3. **Per verifier run** — update `verification_context.last_status`, `issues_found`, `fixes_applied`, and `reverify_count` immediately after each `implementation-verifier` run and after each fix-loop iteration (per the [Fix Loop Contract](../orchestrator-framework/references/fix-loop-contract.md)'s immediate-write cadence), so an interruption loses nothing.
 4. **Completion** — append `verification-done` to `completed_phases` only at skill exit: status `passed`, or user-approved proceed with issues logged. Bump `orchestrator.updated` on every write.
 5. **Failures** — if `implementation-verifier` itself fails or the workflow stops with unresolved critical issues, do NOT append `verification-done` to `completed_phases`; append it to `orchestrator.failed_phases` and increment `auto_fix_attempts["verification-done"]`.
 6. **Validate** — after every write, re-read the file to confirm values, then run the `verify_template` tool with `filePath: <task-path>/orchestrator-state.yml`, `templateName: orchestrator-state-development.yml`. Fix any reported issue immediately before proceeding.

package/dist/skills/diagrams-mermaid/references/reference.md

@@ -138,10 +138,10 @@ Better:
 
 Integrated into:
 - `src/skills/flow-init/SKILL.md` - Phase 6 (architecture and tech-stack doc refinement)
-- `src/skills/development/SKILL.md` - Phase 5 (spec refinement), Phase 7 (plan refinement)
-- `src/skills/research/SKILL.md` - Phase 5 (high-level design refinement)
-- `src/skills/performance/SKILL.md` - Phase 3 (spec refinement), Phase 5 (plan refinement)
-- `src/skills/migration/SKILL.md` - Phase 3 (spec refinement), Phase 4 (plan refinement)
+- `src/skills/dev-spec/SKILL.md` - `spec-written` (spec refinement); `src/skills/dev-plan/SKILL.md` - `plan-created` (plan refinement)
+- `src/skills/research-design/SKILL.md` - `design-generated` (high-level design refinement)
+- `src/skills/performance-spec/SKILL.md` - `spec-written` (spec refinement); `src/skills/performance-plan/SKILL.md` - `plan-created` (plan refinement)
+- `src/skills/migration-spec/SKILL.md` - `strategy-specified` (spec refinement); `src/skills/migration-plan/SKILL.md` - `plan-created` (plan refinement)
 
 Reference files:
 - `src/skills/flow-init/references/architecture-template.md`

package/dist/skills/goal-migration/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: owflow:goal-migration
+description: Full orchestrated migration wrapper — runs ALL migration steps in one session by invoking every migration-* subskill in sequence with question gates between them. Use /owflow:migration for the same lifecycle in assisted mode — tasks can mix both modes freely.
+argument-hint: "[task description | task-path] [--from=<slug>] [--type=TYPE] [--no-web-research]"
+user-invocable: true
+---
+
+# Orchestrated Migration Wrapper
+
+Autonomous mode for migration tasks. Initializes (or resumes) the task, then invokes every required `migration-*` subskill back-to-back via the Skill tool, pausing at gates between subskills. Shares `orchestrator-state.yml` with assisted mode (`/owflow:migration`) — tasks can mix both modes freely. There is no migration quick lane.
+
+Gates follow the shared contract in [Gate Contract](../orchestrator-framework/references/gate-contract.md) — orchestrated mode exception: each subskill's own Exit Gate acceptance question IS the loop gate (Accept = continue to the next subskill).
+
+## Input / Output Artifacts
+
+| Artifact                             | Behavior (this wrapper)                                                                        |
+| ------------------------------------ | ---------------------------------------------------------------------------------------------- |
+| Consumed: argument (description / path) | migration description (new task) or task path/identifier (resume)                           |
+| Consumed/produced: all task artifacts | owned entirely by the invoked subskills (none here — delegate, never inline)                  |
+| State write                           | `orchestrator.task_ids` (task items) + `orchestrator.updated` only; first-time initialization per the dispatcher's Step 3 is the one permitted write outside the loop |
+
+## Entry Gate
+
+Identical to the migration dispatcher — complete ALL of its entry-gate steps first (see `../migration/SKILL.md` Entry Gate):
+
+1. Read the framework reference files NOW, exactly as the migration dispatcher's Step 1: the [Dispatcher & Handoff Pattern](../orchestrator-framework/references/dispatcher-handoff.md), the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md), and the [Orchestrator Patterns](../orchestrator-framework/references/orchestrator-patterns.md).
+2. Resolve the argument the same way the migration dispatcher does: task path or identifier (a directory, or a directory name under `.owflow/tasks/migrations/`) → **resume mode** (read `orchestrator-state.yml`, artifact-validate `completed_phases` against the dispatcher's marker table; find the first step slug NOT in `completed_phases` whose condition holds, with `--from=<slug>` overriding after prerequisite validation); a migration description (free text) → new task; nothing provided → ask via `question` — "What technology, platform, or architecture should be migrated, and to what?" — then WAIT. Missing state file → print `No migration task found at <path>. Run /owflow:migration <description> to start a migration task from scratch.` and STOP.
+3. Initialize (new task) exactly as the dispatcher's Step 3: create `.owflow/tasks/migrations/YYYY-MM-DD-task-name/` + `orchestrator-state.yml` from the migration template — `task.title` / `task.description` from the description, `task.status: in_progress`, `orchestrator.started_phase: state-analysed`, `orchestrator.entry_point: "migration"`, `orchestrator.task_path`, flags recorded (`--type` → `migration_context.migration_type`; `--no-web-research` is forwarded to `migration-target` per invocation — nothing is persisted for it). **CRITICAL**: use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-migration.yml`. First-time initialization is the one permitted write outside the loop.
+4. Create ONE task item via `TaskCreate` per subskill in the upcoming loop (subject: `"<step name>: <subskill>"`, e.g. `"Spec: migration-spec"`), then set the execution order with `TaskUpdate addBlockedBy` (analyze → target → spec → plan → implement → verify → fix → finalize). Record the ids in `orchestrator.task_ids`. On resume, refresh the already-evidenced items instead of re-creating them. Update statuses as the loop progresses.
+
+**Output**:
+
+```
+🚀 Orchestrated Migration
+
+Task: [migration description]
+Directory: [task-path]
+Loop: migration-analyze → migration-target → migration-spec → migration-plan → migration-implement → migration-verify → [migration-fix] → migration-finalize
+```
+
+---
+
+## The Loop
+
+For each subskill in sequence, execute — skipping any row whose condition is not met (a row whose slug is already in `completed_phases` counts as done). **Compatibility re-verification fallback**: when the loop finds no runnable row and `verification-done` is complete with `verification_context.compatibility_status != passed` (failed or null/invalidated), invoke `migration-verify` once (re-verification, overriding slug completeness), then re-read state and continue from the first row whose condition holds; it does not re-fire while the Fix row is runnable; a recorded data-integrity HALT keeps the user-confirmed rollback path dominant.
+
+1. **Announce**: 1-line step banner.
+2. **Invoke**: Skill tool with `name: "owflow:<subskill>"` and `prompt: "<task-path> [flags relevant to that subskill]"`. The subskill owns its Entry Gate, delegation, and state updates. Flags forwarded per subskill: `--type` and `--no-web-research` to `migration-target`.
+3. **Verify handback**: after the skill returns, re-read `orchestrator-state.yml` — confirm the expected step slug(s) were appended to `completed_phases` per the Sequence and Conditionals table. If a subskill stopped early (its Entry Gate failed), STOP the loop and relay its routing message to the user verbatim.
+4. **Gate (subskill's Exit Gate is the loop gate)**: each subskill presents its results box and fires its own results-acceptance `question` before its handoff hint (Orchestrated-mode exception, [Gate Contract](../orchestrator-framework/references/gate-contract.md)). [Rule 5 of the Dispatcher & Handoff Pattern](../orchestrator-framework/references/dispatcher-handoff.md) — "subskills only SUGGEST the next command" — is superseded for Accept: when the user answers **Accept** to the subskill's Exit Gate question pointing at the next subskill in this loop, treat that as "continue to the next subskill" and invoke it. Any other answer (Adjust / Discuss / Stop / other options picked) ends the loop: print the standard handoff block (next command + `/owflow:migration <task-path>` resume hint) and end.
+   - **Non-loop-gate questions**: the in-phase questions inside subskills (analyze clarifiers, spec requirement questions, verify's options step, fix's per-iteration questions) are part of that subskill's own decision flow — they are NOT the loop gate and are NEVER auto-accepted or answered by this wrapper. There is exactly ONE gate definition per subskill hop; the wrapper adds NO second consecutive `question`.
+   - **No quick lane**: migration has no quick lane — every row runs at full fidelity.
+
+### Sequence and Conditionals
+
+| Order | Subskill           | Run when (re-read from state)                                                                                          |
+| ----- | ------------------ | ----------------------------------------------------------------------------------------------------------------------- |
+| 1     | migration-analyze  | Always (new task or partial foundation)                                                                                  |
+| 2     | migration-target   | `state-analysed` in `completed_phases`                                                                                  |
+| 3     | migration-spec     | `target-planned` completed                                                                                              |
+| 4     | migration-plan     | `strategy-specified` completed                                                                                          |
+| 5     | migration-implement | `plan-created` completed                                                                                               |
+| 6     | migration-verify   | `migration-executed` completed                                                                                          |
+| 7     | migration-fix      | `verification-done` completed **and** (`verification_context.compatibility_status = failed` **or** (`verification_context.last_status != passed` **and** no recorded deliberate skip)); otherwise the row is skipped and `migration-finalize`'s own Entry Gate routes forward |
+| 8     | migration-finalize | `verification-done` completed **and** `verification_context.compatibility_status = passed` **and** the fix phase is settled (`issues-resolved` present, or `last_status = passed`, or a recorded deliberate skip) |
+
+`task-completed` already in `completed_phases` → the task is TERMINAL: skip the loop and present the wrapper Exit Gate.
+
+**Interruptible**: at any gate the user may answer "stop" — print the standard handoff block (next command + `/owflow:migration <task-path>` resume hint) and end the session. The task resumes later in either mode; a fresh invocation of this wrapper resumes from state, never from loop memory.
+
+---
+
+## Exit Gate
+
+When migration-finalize completes (`task.status: completed`):
+
+1. Mark the final task item completed via `TaskUpdate`.
+2. Present the workflow results box:
+
+```markdown
+## ✅ MIGRATION WORKFLOW COMPLETE — <task name>
+
+**Migration** — [current → target, type]
+**Strategy** — [incremental / big-bang / dual-run / phased]
+**Steps** — [executed step slugs, e.g. state-analysed → target-planned → strategy-specified → plan-created → migration-executed → options-chosen → verification-done → issues-resolved → docs-generated → task-completed]
+**Verification** — [final verifier verdict + overall compatibility verdict]
+**Fixes** — [N applied / none required / deliberately skipped]
+**Operator guide** — [generated / skipped (`docs_enabled` not enabled)]
+
+**Artifacts** — [artifact inventory: `analysis/current-state-analysis.md`, `analysis/target-state-plan.md`, `analysis/requirements.md`, `analysis/rollback-plan.md`, `implementation/spec.md`, `implementation/implementation-plan.md`, `implementation/work-log.md`, `verification/implementation-verification.md`, `verification/compatibility-test-results.md`, `documentation/migration-guide.md` (conditional)]
+```
+
+3. Use `question` — "Are these results correct?" with options: **Accept** (print follow-up suggestions: review the artifacts, commit personally — the workflow performs no commits; `/owflow:reviews-pragmatic <task-path>` if desired; then end) / **Adjust** (re-open the relevant `/owflow:migration-*` skill with the corrections) / **Discuss** (walk through the migration summary) / **Stop here** (print the resume command `/owflow:migration <task-path>` and end).
+
+Then end. No further owflow phase commands are required.
+
+---
+
+## Loop Rules
+
+- **Delegate, never inline**: the wrapper only sequences — all step work happens inside subskills. If you catch yourself analyzing/migrating outside a subskill, STOP and invoke the subskill instead.
+- **State is the truth**: gates and routing read `orchestrator-state.yml`, not memory. Re-read after every subskill returns.
+- **Same state schema as assisted mode**: `completed_phases` step slugs (`state-analysed` … `task-completed`) are identical; resume works across modes.
+- **Wrapper writes almost nothing**: step slugs, summaries, and outputs belong to the subskills — this wrapper writes ONLY `orchestrator.task_ids` (task items) and `orchestrator.updated` (timestamps); the sole exception is first-time initialization per the dispatcher's Step 3.
+- **Zero added pause points**: one full pass asks at most the 8 subskill Exit Gates + this terminal gate = 9 — fewer when the conditional `migration-fix` row is skipped; the same asks as assisted mode. There is no per-hop back-to-back `question` exception: the wrapper adds no question inside the loop, and its only wrapper-level `question` is this terminal gate (the finalize gate and the wrapper gate are the one legitimate consecutive pair).
+
+## Command Integration
+
+Invoked via:
+
+- `/owflow:goal-migration [description] [--type=TYPE] [--no-web-research]` (new)
+- `/owflow:goal-migration [task-path] [--from=<slug>]` (resume)
+
+Alternative: `/owflow:migration` — same task in assisted mode (one subskill per invocation, fresh context each step).

package/dist/skills/goal-performance/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: owflow:goal-performance
+description: Full orchestrated performance wrapper — runs ALL performance steps in one session by invoking every performance-* subskill in sequence with question gates between them. Use /owflow:performance for the same lifecycle in assisted mode — tasks can mix both modes freely.
+argument-hint: "[task description | task-path] [--from=<step-slug>]"
+user-invocable: true
+---
+
+# Orchestrated Performance Wrapper
+
+Autonomous mode for performance tasks. Initializes (or resumes) the task, then invokes every required `performance-*` subskill back-to-back via the Skill tool, pausing at gates between subskills. Shares `orchestrator-state.yml` with assisted mode (`/owflow:performance`) — tasks can mix both modes freely.
+
+Gates follow the shared contract in [Gate Contract](../orchestrator-framework/references/gate-contract.md) — orchestrated mode exception: each subskill's own Exit Gate acceptance question IS the loop gate (Accept = continue to the next subskill). **At intermediate hops the wrapper MUST NOT add a second consecutive `question`**; after the final hop, the wrapper Exit Gate below fires exactly one workflow-closure confirmation.
+
+## Input / Output Artifacts
+
+| Artifact | This wrapper | Assisted mode (`/owflow:performance`) |
+| --- | --- | --- |
+| Consumed: argument (description / path) | performance issue description (new task) or task path/identifier (resume) | same |
+| Consumed/produced: all task artifacts | owned entirely by the invoked subskills (none here — delegate, never inline) | same |
+| State write | init as the dispatcher; during the loop ONLY `orchestrator.task_ids` + `orchestrator.updated` | init + drop-only resume trim |
+
+## Entry Gate
+
+Identical to the performance dispatcher — complete ALL of its entry-gate steps first (see `../performance/SKILL.md` Entry Gate):
+
+1. Read the framework reference files NOW, exactly as the performance dispatcher's Step 1: the [Dispatcher & Handoff Pattern](../orchestrator-framework/references/dispatcher-handoff.md), the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md), and the [Orchestrator Patterns](../orchestrator-framework/references/orchestrator-patterns.md).
+2. Resolve the argument the same way the performance dispatcher does: task path or identifier (a directory, or a directory name under `.owflow/tasks/performance/`) → **resume mode** (read `orchestrator-state.yml`, run the dispatcher's drop-only resume validation, derive the next step from the dispatcher's routing table, with `--from=<step-slug>` overriding); a performance issue description (free text) → new task; nothing provided → ask via `question` — "What is slow or performance-constrained? Describe the symptom (endpoint, page, job), expected vs actual behavior, and any profiling data you have." — then WAIT. Missing state file → print `No performance task found at <path>. Run /owflow:performance <description> to start a task from scratch.` and STOP.
+3. Initialize (new task) exactly as the dispatcher: create `.owflow/tasks/performance/YYYY-MM-DD-task-name/` with `analysis/`, `analysis/user-profiling-data/`, `implementation/`, `verification/`, then `orchestrator-state.yml` from the performance template — `task.title` / `task.description` from the description, `task.status: in_progress`, `orchestrator.task_path`, `orchestrator.entry_point: "performance"`, and project docs into `performance_context.project_doc_paths`. **CRITICAL**: use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-performance.yml`.
+4. Create the six task items via `TaskCreate` exactly as the dispatcher does (one per subskill), set `addBlockedBy` chains, and record their ids in `orchestrator.task_ids`. On resume, refresh the already-evidenced items instead of re-creating them. Update item statuses as the loop progresses.
+
+**Output**:
+
+```
+🚀 Orchestrated Performance
+
+Task: [performance issue description]
+Directory: [task-path]
+Loop: performance-analyze → performance-spec → performance-plan → performance-implement → performance-verify → performance-finalize
+```
+
+---
+
+## The Loop
+
+For each subskill in the Sequence table below, execute — skipping any row whose **Runs when** condition is not met. The condition is authoritative: a multi-slug row (row 2) still runs when one of its slugs is complete but the other is pending (the audit re-entry case).
+
+1. **Announce**: 1-line step banner.
+2. **Invoke**: Skill tool with `name: "<subskill>"` and `prompt: "<task-path> [flags relevant to that subskill]"`. The subskill owns its Entry Gate, delegation, and state updates. Never run a subskill's or an agent's work inline.
+3. **Verify handback**: after the skill returns, re-read `orchestrator-state.yml` — confirm the row's expected slug(s) are present in `completed_phases`. A re-entered row may add only its pending slug, and an audit skip records `options.spec_audit_enabled: false` with no new slug — those are legitimate completions, not early stops. A subskill that stopped at its entry check (missing prerequisites, no task) ENDS the loop and its routing/blocked message is relayed to the user.
+4. **Gate (the subskill's Exit Gate IS the loop gate)**: each subskill presents its results box and fires its own results-acceptance `question` before its handoff hint (orchestrated-mode exception, [Gate Contract](../orchestrator-framework/references/gate-contract.md)). When the user answers **Accept**, treat it as "continue to the next subskill" and invoke it. Any other answer (Adjust / Discuss / Stop here) ends the loop exactly like a rejected gate. There is exactly ONE gate per hop — **the wrapper adds NO second consecutive `question` at intermediate hops**; the terminal wrapper Exit Gate (below) is the single workflow-closure confirmation after the final hop.
+
+### Sequence
+
+| Order | Subskill | Runs when (from state) | Slugs verified after |
+| --- | --- | --- | --- |
+| 1 | `performance-analyze` | new task, OR `codebase-analysed` absent, OR (`codebase-analysed` present AND `bottlenecks-identified` absent) | `codebase-analysed`, `bottlenecks-identified` |
+| 2 | `performance-spec` | `bottlenecks-identified` complete AND [ (`spec-written` absent) OR (`spec-audited` absent AND (`options.spec_audit_enabled` is null OR `true`)) ] | `spec-written` (+ `spec-audited` when the audit ran) |
+| 3 | `performance-plan` | `spec-written` complete AND `options.spec_audit_enabled` non-null — settled, NEVER `spec-audited` — AND `plan-created` absent | `plan-created` |
+| 4 | `performance-implement` | `plan-created` complete AND `implementation-done` absent | `implementation-done` |
+| 5 | `performance-verify` | `implementation-done` complete AND [ `options-chosen` absent OR `verification-done` absent ] | `options-chosen`, `verification-done` |
+| 6 | `performance-finalize` | `verification-done` complete AND `task-completed` absent | `task-completed` + `task.status: completed` |
+
+Six rows, ZERO user-choice rows: every performance conditional is an in-skill `question` owned by a subskill, never a chain decision this wrapper makes.
+
+### Decisions the wrapper never answers
+
+The six in-skill decision questions below belong to the subskill that owns them — they are NEVER auto-accepted, pre-answered, or skipped by this wrapper (decisions are never silently accepted):
+
+| Subskill | In-skill decision questions |
+| --- | --- |
+| `performance-analyze` | performance concerns / hotspots / goals (max 5); profiling-data offer |
+| `performance-spec` | bottleneck priorities / constraints / targets; run the specification audit? |
+| `performance-verify` | which additional verification checks; fix-set selection + re-run verification |
+
+`performance-plan`, `performance-implement`, and `performance-finalize` have no in-skill decision questions — their only gates are their Exit Gates (the loop gate above).
+
+**Interruptible**: at any gate the user may answer "stop" — print the standard handoff block (`/owflow:performance <task-path>` resume hint + the next command) and end the session. The task resumes later in either mode.
+
+`task-completed` already in `completed_phases` (with `task.status: completed`) → the task is TERMINAL: skip the Loop and present the wrapper Exit Gate.
+
+---
+
+## Exit Gate
+
+When `performance-finalize`'s own Exit Gate is accepted (`task-completed` recorded, `task.status: completed`):
+
+1. Mark the final task item completed via `TaskUpdate`.
+2. Present the wrapper terminal results box:
+
+```markdown
+## ✅ PERFORMANCE WORKFLOW COMPLETE — <task name>
+
+**Steps** — [executed step slugs, e.g. codebase-analysed → bottlenecks-identified → … → task-completed]
+**Bottlenecks found** — [P0/P1/P2/P3 counts]
+**Optimizations applied** — [count + key ones]
+**Verification** — [final verdict]
+**Estimated improvement** — [range from the analysis]
+
+**Artifacts**
+
+- `analysis/performance-analysis.md`
+- `implementation/work-log.md`
+- `verification/implementation-verification.md`
+```
+
+3. Use `question` — "Are these results correct?" with options: **Accept** (print the follow-up suggestions: measure the improvement, consider runtime profiling, `/owflow:standards-update "<lesson>"`, then end) / **Adjust** (re-open the affected `/owflow:performance-*` skill with the corrections) / **Discuss** (walk through the optimization summary, evidence, and measurement caveats) / **Stop here** (print the resume command `/owflow:performance <task-path>` and end).
+
+Then end. No further owflow commands are required.
+
+---
+
+## Loop Rules
+
+- **Delegate, never inline**: the wrapper only sequences — all step work happens inside subskills. If you catch yourself analyzing or implementing outside a subskill, STOP and invoke the subskill instead.
+- **State is the truth**: gates and routing read `orchestrator-state.yml`, not memory. Re-read after every subskill returns.
+- **Same state schema as assisted mode**: `completed_phases` step slugs (`codebase-analysed` … `task-completed`) are identical; resume works across modes.
+- **Wrapper writes almost nothing**: step slugs, summaries, and artifacts belong to the subskills — during the loop this wrapper writes ONLY `orchestrator.task_ids` (task items) and `orchestrator.updated` (timestamps).
+
+## Command Integration
+
+Invoked via:
+
+- `/owflow:goal-performance [description]` (new)
+- `/owflow:goal-performance [task-path] [--from=<step-slug>]` (resume)
+
+Alternative: `/owflow:performance` — same task in assisted mode (one subskill per invocation, fresh context each step).