owflow 0.2.0 → 0.4.2

package/dist/skills/orchestrator-framework/references/dispatcher-handoff.md

@@ -0,0 +1,27 @@
+# Dispatcher & Handoff Pattern (Subskill Loop)
+
+How orchestrators delegate phase bodies to user-invocable **subskills**. Extracted from `orchestrator-patterns.md` (Section 7) so skills can link to it directly.
+
+Orchestrators MAY delegate phase bodies to user-invocable **subskills** instead of executing them inline. Two modes share one state file and one set of subskills:
+
+| Mode              | Entry point              | Behavior                                                                                                |
+| ----------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- |
+| Orchestrated mode | wrapper skill/command    | Invokes subskills back-to-back via Skill tool in sequence; pauses at `question` gates between subskills |
+| Assisted mode      | dispatcher skill/command | Derives next phase from state, prints the suggested command, and **STOPS**; user invokes each subskill  |
+
+## Rules
+
+1. **State file is canonical.** `orchestrator-state.yml` remains the single source of truth. Subskills read it on entry and write step results on exit. `completed_phases` values MUST stay stable so both modes intermix freely on the same task.
+   - **Value convention**: `completed_phases` / `failed_phases` / `auto_fix_attempts` keys are **descriptive step slugs**, not `phase-N` numbers. Canonical slugs per workflow:
+
+   | Workflow     | Slugs                                                                                                                                                                      | Routing table                    | Template                                       |
+   | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | ---------------------------------------------- |
+   | development  | `codebase-analysed`, `gap-analysed`, `tdd-red-proven`, `spec-written`, `spec-audited`, `plan-created`, `implementation-done`, `tdd-green-proven`, `options-chosen`, `verification-done`, `e2e-run`, `docs-generated`, `task-completed` | `skills/development/SKILL.md`  | `templates/orchestrator-state-development.yml` |
+   | research     | `brief-written`, `plan-created`, `findings-gathered`, `synthesis-complete`, `alternatives-generated`, `approaches-chosen`, `design-generated`, `research-completed`        | `skills/research/SKILL.md`       | `templates/orchestrator-state-research.yml`    |
+   | performance  | `phase-N` (legacy holdout — kept internally consistent)                                                                                                                     | `skills/performance/SKILL.md`    | `templates/orchestrator-state-performance.yml` |
+   | migration    | `phase-N` (legacy holdout — kept internally consistent)                                                                                                                     | `skills/migration/SKILL.md`      | `templates/orchestrator-state-migration.yml`   |
+2. **Subskills are self-contained.** Each has: an entry check (validate state + prerequisite artifacts), an execute section (delegation via Skill/Task tools per the [Delegation Rules](delegation-rules.md)), and an exit (state update + closing ritual). **State updates are per-step**: a subskill writes `orchestrator-state.yml` immediately after each of its steps completes — appending only the step slug actually performed, bumping `orchestrator.updated`, recording failures in `failed_phases`/`auto_fix_attempts`, and validating with `verify_template` — never as a single end-of-skill write.
+3. **Closing ritual (handoff) → Exit Gate.** Every subskill ends with the **Exit Gate** contract, see [Gate Contract](gate-contract.md) (results box → results-acceptance question → next-step hint on accept → STOP).
+4. **Entry checks replace phase gates in assisted mode.** A subskill invoked directly must validate the same prerequisites a phase gate would (e.g., spec exists before audit) and route to the prerequisite's command if missing — via its **Entry Gate** ([Gate Contract](gate-contract.md)).
+5. **Never chain automatically.** The orchestrated wrapper invokes; subskills only SUGGEST the next command and stop. Auto-chaining from a subskill skips user review.
+6. **Assisted mode is the gate.** In assisted mode, the user explicitly invoking the next command IS the phase gate — no additional `question` confirmation before a subskill starts.

package/dist/skills/orchestrator-framework/references/gate-contract.md

@@ -0,0 +1,112 @@
+# Gate Contract — Entry Gate & Exit Gate (Skill Contract)
+
+Shared contract for how every user-invocable skill opens and closes. Extracted from `orchestrator-patterns.md` (Section 9) so skills can link to it directly.
+
+Every **user-invocable** skill (orchestrators, subskills, dispatchers, utility commands) opens with an **Entry Gate** and closes with an **Exit Gate**. Internal skills (subagent-invoked, `user-invocable: false`) use lightweight input/structured-output contracts instead and never call `question`.
+
+## Entry Gate
+
+The Entry Gate runs BEFORE any phase work. It validates that this skill is allowed to run and routes to what is missing instead of guessing.
+
+1. **Argument resolution** — resolve the argument in priority order: full path → identifier (directory name under the workflow's task type) → fresh description. If missing, ambiguous, or unmatched:
+   - Print a structured ask: the exact inputs accepted, with format examples, then WAIT.
+   - NEVER guess, auto-pick a task, or proceed with a resolved-by-hope path.
+2. **Prerequisite check** — verify each required upstream artifact, expressed as a table the skill keeps at the top of its body:
+
+   | Required for this skill | Where verified                                                      | Produced by                  |
+   | ----------------------- | ------------------------------------------------------------------- | ---------------------------- |
+   | State file exists       | `<task-path>/orchestrator-state.yml`                                | `/owflow:development <desc>` |
+   | Analysis done           | `gap-analysed` in `completed_phases` + `analysis/gap-analysis.md` exists | `/owflow:dev-analyze`        |
+   | Spec approved           | `implementation/spec.md` exists                                     | `/owflow:dev-spec`           |
+
+   Verify **presence and, where cheap, content** (state field values like `has_reproducible_defect`, marker artifacts like `implementation/tdd-red-gate.md`), not just file existence.
+
+3. **Blocked output** — when a prerequisite is unmet, print the blocked block and STOP:
+   1. Numbered "Steps that must be completed first (in order)", each with its exact prefixed command (`/owflow:dev-analyze <task-path>`).
+   2. List of resumable task identifiers (directories under the workflow's task type), if any exist.
+   3. Fresh-start hint: `Run /owflow:<entry-command> <description> to start a task from scratch.`
+4. **Skip/resume semantics** — when the skill's steps are already in `completed_phases` (validate artifacts before trusting state): report the existing results briefly and route to the Exit Gate instead of re-executing.
+5. **Conditional activation** — skills that only apply under a state condition (e.g., TDD red gate requires `has_reproducible_defect: true`) check it as part of the Entry Gate and route to the correct alternative command when inactive.
+
+### Missing-state bootstrap (mid-pipeline entry)
+
+When a subskill is invoked with a task path/identifier whose `orchestrator-state.yml` exists nowhere (no task, no state file) and the ONLY unmet prerequisite is the state file itself, the skill does not blindly send the user back to the full pipeline — the user chose to enter mid-pipeline. Instead:
+
+1. **Ask** via `question`: "No task exists at this path. Create a fresh standard task and start at `<this skill's first step slug>`?"
+2. **On confirm (bootstrap)**:
+   - Create the task directory `.owflow/tasks/<workflow-type>/YYYY-MM-DD-task-name/` (name derived from the argument or the user's input) — mark `orchestrator.entry_point: "<skill> (mid-pipeline bootstrap)"` and `started_phase` with this skill's starting step slug.
+   - Create `orchestrator-state.yml` from the workflow's template, honoring any of the skill's command flags into their state fields; leave `completed_phases` empty (upstream steps stay unrecorded).
+   - Run `verify_template` against the workflow's template.
+   - Then continue into Execute. Because bootstrapping creates **state only — never upstream artifacts**, later artifact prerequisites (e.g., `implementation/spec.md` before planning) still block with the normal precondition loop, so an incorrectly early bootstrap cannot silently skip work.
+3. **On decline** — print the blocked block with the fresh-start hint and STOP.
+
+#### dev-* bootstrap
+
+- Task directory under `.owflow/tasks/development/`; template `orchestrator-state-development.yml`; fresh-start hint: `Run /owflow:development <description> to start a task from scratch.`
+- Skill starting points (used for the bootstrap question and `started_phase`): dev-analyze → `codebase-analysed`; dev-tdd-red → `tdd-red-proven`; dev-spec → `spec-written`; dev-plan → `plan-created`; dev-implement → `implementation-done`; dev-verify → `options-chosen`; dev-finalize → `e2e-run`.
+
+#### research-* bootstrap
+
+- Task directory under `.owflow/tasks/research/`; template `orchestrator-state-research.yml`; fresh-start hint: `Run /owflow:research <question> to start a task from scratch.`
+- Skill starting points (used for the bootstrap question and `started_phase`): research-plan → `brief-written`; research-gather → `findings-gathered`; research-synthesize → `synthesis-complete`; research-brainstorm → `alternatives-generated`; research-converge → `approaches-chosen`; research-design → `design-generated`; research-finalize → `research-completed`.
+
+### Deterministic entry checks (future)
+
+Entry-gate checks above are currently executed by the agent reading state. For more deterministic routing, future work considers (a) a small script that checks whether `orchestrator-state.yml` exists, parses it, and answers slug/next-step queries, and (b) an OpenCode lifecycle hook that automates these entry-gate checks for dev-* skills before they run. Until then, follow the rules above exactly as written.
+
+## Exit Gate
+
+The Exit Gate runs after all phase work and state updates are final. It presents results, asks the user to confirm them, and only then hands off.
+
+1. **Results box** — one-screen markdown summary (no ASCII borders, markdown headings/bold carry the emphasis):
+
+   ```markdown
+   ## ✅ <SKILL> COMPLETE — <task name>
+
+   **<Field 1>** — [key outcome]
+   **<Field 2>** — [key outcome]
+
+   **Artifacts**
+
+   - `relative/path/to/artifact.md`
+
+   **Next ▸** `/owflow:<next-skill> <task-path>`
+   ```
+
+   Conventions:
+   - Status glyphs follow the outcome: ✅ pass/success, ⚠ pass-with-concerns/partial, ❌ fail.
+   - Set the **Next ▸** line to the suggested next command for this skill; omit it when the next-step hint depends on the Accept response (the handoff block is printed after Accept anyway).
+
+2. **Results-acceptance question** (MANDATORY, fires before any handoff hint):
+
+   Use `question` — "Are these results correct?" with options:
+   - **Accept** — results are good; proceed to the next-step hint.
+   - **Adjust** — user specifies what to change; re-work ONLY the affected parts, update artifacts/state, then re-present the results box and re-ask.
+   - **Discuss** — walk through a specific result in more depth (evidence, reasoning, alternatives); after the discussion, re-ask.
+   - **Stop here** — artifacts persist; print the resume command (`/owflow:<this-skill> <task-path>` or the next phase command) and end.
+
+3. **Next-step hint** — only after Accept: print the suggested next command derived from state, plus an "Other options" block of alternative valid commands. Every suggested command is a **compact annotated entry**:
+   - **Purpose** — one line stating what the proposed skill does.
+   - **Requirement tag** — `required` (mandatory next phase) or `optional` (shortcut, standalone utility, or conditional step) with its activation condition, e.g. `optional — only when has_reproducible_defect: true`.
+   - **Remaining plan** (for optional/alternative paths) — one compact line listing the phases still ahead in execution order, marking which are optional.
+   - Standalone review/utility commands are annotated `optional — does not advance phases`.
+
+   Example shape (~5 lines):
+
+   ```
+   → /owflow:dev-verify <task-path>
+     What: runs the verification pipeline (completeness, code review, fixes) — required before commit. Remaining after: /owflow:dev-finalize (required).
+   Other options:
+   /owflow:reviews-code <task-path> — optional, does not advance phases (standalone re-run of code review)
+   /owflow:goal-development <task-path> — optional shortcut: runs all remaining phases in one loop (… → verify → finalize)
+   ```
+
+   Then STOP. Never auto-invoke the next skill.
+
+4. **Gate ordering** — per the Phase Gate Behavior state ordering rule in `orchestrator-patterns.md`: finish phase work → present results box → acceptance question → user responds → THEN the state is already consistent (per-step writes happened during Execute); the Exit Gate never mutates phase state on its own except recording the user's acceptance decision where the state schema has a field for it.
+
+## Exceptions
+
+- **Dispatchers** (`development`, `research`): the Exit Gate's acceptance question is adapted — the results box is the handoff block, and the question asks how to proceed (hand off to the suggested subskill / switch to autonomous mode / adjust / stop).
+- **Utility skills with explicit no-follow-up contracts** (`agents-md-generator`, `rule-reviewer`): the acceptance question is confirm-or-revise only; follow-up suggestions stay prohibited unless the user asks. See [confirm-or-revise exception](confirm-or-revise-exception.md).
+- **Orchestrated mode** (`goal-development`, `goal-research`): the subskill's own Exit Gate acceptance question IS the loop gate — Accept means "continue to the next subskill". The wrapper MUST NOT add a second consecutive `question`.

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

@@ -9,6 +9,8 @@ Use when creating NEW orchestrators or auditing existing ones. Not loaded during
 Before considering an orchestrator complete, verify ALL items:
 
 - [ ] **Step 0: Load Framework** — Initialization reads `orchestrator-patterns.md`
+- [ ] **Entry Gate** — Skill body opens with the Entry Gate contract (argument resolution, prerequisite table, blocked output, skip/resume semantics — see [Gate Contract](gate-contract.md))
+- [ ] **Exit Gate** — Skill body closes with the Exit Gate contract (results box, results-acceptance question, next-step hint on Accept, STOP — see [Gate Contract](gate-contract.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`)
@@ -39,6 +41,7 @@ Before considering an orchestrator complete, verify ALL items:
 | Stopping at AUTO-CONTINUE transitions   | Brief summary is fine, but must proceed immediately |
 | Missing standards references            | INDEX.md must be referenced in relevant phases      |
 | Auto-accepting subagent decisions       | User must consent via question                      |
+| Ending without results-acceptance       | Exit Gate question MUST fire before next-step hint  |
 
 ---
 

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

@@ -2,58 +2,14 @@
 
 Shared execution rules, schemas, and patterns for all workflow orchestrators.
 
----
-
-## 1. Delegation Rules
-
-**Always use Skill/Task tools to delegate. Never execute delegated work inline.**
-
-When a phase requires delegation:
-
-1. Use the **Skill tool** for **skills** — loads SKILL.md instructions into the main agent's context; the main agent executes the skill's instructions and continues with the orchestrator workflow afterward
-2. Use the **Task tool** for **subagents/agents** — spawns an isolated subprocess that returns results when complete
-3. Wait for completion before continuing
-
-**Skills and agents are NOT interchangeable.** Skills always use Skill tool; agents always use Task tool. Never invoke a skill via Task tool (`subagent_type`) — it will fail with "Agent type not found."
-
-**Why skills MUST use Skill tool**: Skills like `codebase-analyzer`, `implementation-plan-executor`, and `implementation-verifier` spawn their own subagents (Explore agents, reporters, planners). Subagents cannot spawn other subagents — so these skills must run in the main agent context via Skill tool.
-
-**Companion agent pattern** (e.g., `docs-operator`): Only works for skills that do NOT spawn subagents (like `docs-manager` which only does file operations). A companion agent preloads the skill via the `skills` frontmatter field and is invoked via Task tool. This pattern fails for any skill that needs to spawn subagents.
-
-### Anti-Patterns
-
-| Anti-Pattern                            | Why It's Wrong                              | Correct Approach                                      |
-| --------------------------------------- | ------------------------------------------- | ----------------------------------------------------- |
-| "I'll analyze the codebase..."          | Bypasses codebase-analyzer skill            | Use `Skill` tool with `codebase-analyzer`             |
-| "Let me create the specification..."    | Bypasses specification-creator              | Use `Task` tool with `specification-creator` subagent |
-| "Looking at the gaps between..."        | Bypasses gap-analyzer subagent              | Use `Task` tool with `gap-analyzer`                   |
-| "I'll implement this by..."             | Bypasses implementation-plan-executor skill | Use `Skill` tool with `implementation-plan-executor`  |
-| Reading a SKILL.md then doing the work  | Skill files are instructions FOR skills     | Use Skill tool to invoke                              |
-| Spawning Explore agents in orchestrator | Codebase-analyzer manages its own agents    | Invoke skill, let IT spawn agents                     |
-
-### When Inline Execution is Acceptable
-
-These do NOT require delegation:
-
-1. **Clarifying questions phases** — question is direct
-2. **State updates** — Reading/writing orchestrator-state.yml
-3. **Phase announcements** — Outputting status messages
-4. **Simple decisions** — Enabling/disabling optional phases
-5. **Finalization** — Creating summary, updating metadata
+Some heavily cross-referenced sections live in their own reference files:
 
-For all analysis, planning, implementation, and verification phases: **ALWAYS DELEGATE**.
+- [Delegation Rules](delegation-rules.md) — Skill/Task tool delegation contract (was Section 1)
+- [Dispatcher & Handoff Pattern](dispatcher-handoff.md) — subskill loop, mode table, per-step state writes (was Section 7)
+- [Command Namespacing](command-namespacing.md) — `owflow:` prefix rules (was Section 8)
+- [Gate Contract](gate-contract.md) — Entry Gate & Exit Gate skill contract, incl. exceptions (was Section 9)
 
-**Never acceptable inline** (regardless of perceived task simplicity):
-
-- Specification creation → always delegate to `specification-creator` subagent
-- Implementation planning → always delegate to `implementation-planner` subagent
-- Gap analysis → always delegate to `gap-analyzer` subagent
-- Codebase analysis → always delegate to `codebase-analyzer` skill
-- Code review → always delegate to `code-reviewer` subagent
-- Test execution → always delegate to `test-suite-runner` subagent
-- Implementation completeness → always delegate to `implementation-completeness-checker` subagent
-
-"The task is simple" is NOT a valid reason to skip delegation.
+Section numbering below is kept as-is so existing cross-references stay valid.
 
 ---
 
@@ -272,3 +228,5 @@ If prerequisites missing, use question: "Start from Phase 1", "Specify different
 | User chooses "Proceed with known issues" | Proceed with warning logged                        |
 | Max iterations (3) reached               | Ask user how to proceed                            |
 | Critical issues remain unresolved        | **MUST NOT proceed** — require user approval first |
+
+---

package/dist/skills/performance/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: performance
+name: owflow:performance
 description: Orchestrates performance optimization workflows using static code analysis to identify bottlenecks (N+1 queries, missing indexes, O(n^2) algorithms, blocking I/O, memory leaks). Accepts optional user-provided profiling data. Reuses standard specification, planning, implementation, and verification phases.
 user-invocable: true
 ---
@@ -8,24 +8,36 @@ user-invocable: true
 
 Static-analysis-first performance optimization workflow. Identifies bottlenecks by reading code, then uses the standard specification/planning/implementation/verification pipeline to fix them.
 
-## Initialization
+Gates follow the shared contract in [Gate Contract](../orchestrator-framework/references/gate-contract.md).
+
+## Entry Gate
 
 **BEFORE executing any phase, you MUST complete these steps:**
 
-### Step 1: Load Framework Patterns
+### Argument resolution
+
+- **Performance issue description provided** → use it as the task description.
+- **Task path / identifier** (directory under `.owflow/tasks/performance/`) → resume mode: read `orchestrator-state.yml`, find the first incomplete phase (`--from=PHASE` overrides), validate existing artifacts, then continue from there.
+- **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." — collect the description, plus optional profiling data paths, before proceeding.
+
+### Prerequisites
 
-**Read the framework reference file NOW using the Read tool:**
+| Required for this skill | Where verified                                        | Produced by                  |
+| ----------------------- | ----------------------------------------------------- | ---------------------------- |
+| State file exists       | `<task-path>/orchestrator-state.yml` (resume mode)    | prior `/owflow:performance` run |
 
-1. `../orchestrator-framework/references/orchestrator-patterns.md` - Delegation rules, interactive mode, state schema, initialization, context passing, issue resolution
+On resume, if the state file is missing → print: `No performance task found at <path>. Run /owflow:performance <description> to start from scratch.` and STOP. Validate expected artifacts for completed phases (remove entries with missing artifacts).
 
-### Step 2: Initialize Workflow
+### Execution steps
 
-1. **Create Task Items**: Use `TaskCreate` for all phases (see Phase Configuration), then set dependencies with `TaskUpdate addBlockedBy`
-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.
+1. **Load framework patterns** — Read `../orchestrator-framework/references/orchestrator-patterns.md` NOW: delegation rules, interactive mode, state schema, initialization, context passing, issue resolution.
+2. **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/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**:
 
@@ -326,11 +338,11 @@ question - Display executive summary: total issues found, issues fixed, issues r
 
 ---
 
-### Phase 9: Finalization
+### Phase 9: Finalization → Exit Gate
 
 > **Phase gate**: Requires `question` confirmation from Phase 8 before executing.
 
-**Purpose**: Complete workflow and provide next steps
+**Purpose**: Present optimization results, confirm correctness with the user, and close the workflow (Exit Gate contract, [Gate Contract](../orchestrator-framework/references/gate-contract.md))
 **Execute**: Direct - create summary, update state, guide commit
 **Output**: Workflow summary
 **State**: Set `task.status: completed`
@@ -339,12 +351,34 @@ question - Display executive summary: total issues found, issues fixed, issues r
 
 1. Create workflow summary (bottlenecks found, optimizations implemented, verification result)
 2. Update task status to "completed"
-3. Provide commit message template
-4. Guide performance-specific next steps:
+3. **Results box**:
+
+```markdown
+## ✅ PERFORMANCE WORKFLOW COMPLETE — <task name>
+
+**Bottlenecks found** — [count by severity]
+**Optimizations applied** — [count + key ones]
+**Verification** — [final verdict]
+**Estimated improvement** — [range from analysis]
+
+**Artifacts**
+- `analysis/performance-analysis.md`
+- `implementation/work-log.md`
+- `verification/implementation-verification.md`
+```
+
+4. **Results-acceptance question** — use `question` — "Are these results correct?" with options:
+   - **Accept** — workflow is complete; print next steps below.
+   - **Adjust** — re-run the affected phase (additional optimizations, re-verification) with the user's corrections, then re-present the results box.
+   - **Discuss** — walk through bottleneck findings, optimization rationale, and measurement caveats in more depth; then re-ask.
+   - **Stop here** — print the resume command (`/owflow:performance <task-path>`) and end.
+
+5. **Next steps (after Accept)** — performance-specific guidance:
    - Run the application and verify improvements manually
    - Consider profiling with runtime tools to measure actual impact
    - Monitor production metrics after deployment
    - Address remaining P2/P3 bottlenecks if needed
+   - `/owflow:standards-update "<lesson learned>"` — capture optimization patterns as standards
 
 → End of workflow
 
@@ -396,7 +430,7 @@ Refer to the template [src/templates/orchestrator-state-performance.yml](../../t
 
 Invoked via:
 
-- `/performance [description]` (new)
-- `/performance [task-path] [--from=PHASE]` (resume)
+- `/owflow:performance [description]` (new)
+- `/owflow:performance [task-path] [--from=PHASE]` (resume)
 
 Task directory: `.owflow/tasks/performance/YYYY-MM-DD-task-name/`