owflow 0.6.0 → 0.7.0

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

@@ -1,118 +1,118 @@
----
-name: owflow:dev-finalize
-description: Development — conditional E2E testing, user documentation, and workflow finalization with commit guidance.
-argument-hint: "[task-path-or-identifier]"
-user-invocable: true
----
-
-# Dev Finalize — E2E, User Docs & Finalization (e2e-run, docs-generated, task-completed)
-
-Closing phase of the development workflow. Runs optional E2E browser verification and user documentation when enabled, then finalizes the workflow.
-
-## Entry Gate
-
-Resolve the `task-path-or-identifier` argument BEFORE anything else (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)):
-
-- **Path** (absolute or project-relative) to the task directory — use as-is.
-- **Identifier** — exact directory name inside `.owflow/tasks/development/` (e.g., `2026-01-12-my-task`); resolve to its path.
-- If the argument is **missing**, the path does **not exist**, or matches **no identifier** → print the blocked block, then STOP (never guess or auto-pick a task):
-  1. Steps that must be completed first (in order), each with its command:
-     - Codebase & gap analysis (`codebase-analysed`, `gap-analysed`) → `/owflow:dev-analyze <task-path>`
-     - TDD red gate (`tdd-red-proven`) — only when a reproducible defect was detected → `/owflow:dev-tdd-red <task-path>`
-     - Requirements, specification & audit (`spec-written`, `spec-audited`) → `/owflow:dev-spec <task-path>`
-     - Implementation planning (`plan-created`) → `/owflow:dev-plan <task-path>`
-     - Implementation & TDD green gate (`implementation-done`, `tdd-green-proven`) → `/owflow:dev-implement <task-path>`
-     - Verification & issue resolution (`options-chosen`, `verification-done`) → `/owflow:dev-verify <task-path>`
-  2. List available dev-task identifiers (directories under `.owflow/tasks/development/`) to resume from, if any.
-  3. Hint: `Run /owflow:development <description> to start a task from scratch, or pass a task path/identifier to resume.`
-
-### Prerequisites
-
-| Required for this skill | Where verified                            | Produced by                        |
-| ----------------------- | ----------------------------------------- | ---------------------------------- |
-| State file exists       | `<task-path>/orchestrator-state.yml`      | `/owflow:development <desc>`       |
-| Verification done       | `verification-done` in `completed_phases` | `/owflow:dev-verify <task-path>`   |
-
-1. **Read `orchestrator-state.yml`** from the task path. If missing → mid-pipeline bootstrap ([Missing-state Bootstrap](../orchestrator-framework/references/gate-contract.md), starting slug `e2e-run`): `question` — create a fresh standard development task starting at this step, or decline → print `No development task found at <path>. Run /owflow:development <description> to start a task from scratch.` and STOP.
-2. **Prerequisite check**: `verification-done` in `completed_phases`. If missing → print the blocked block, then STOP:
-   - Steps that must be completed first: analysis (`codebase-analysed`, `gap-analysed`) → TDD red gate (`tdd-red-proven`, only when a reproducible defect was detected) → specification (`spec-written`) → implementation planning (`plan-created`) → implementation (`implementation-done`) → verification (`verification-done`).
-   - `Run /owflow:dev-verify <task-path> first` (or the command for the earliest missing earlier step).
-   - If no task exists yet: `Run /owflow:development <description> to start a task from scratch.`
-3. **Skip/resume**: if `task.status` is `completed`, report the existing finalization and STOP.
-4. **Conditional activation**: if `options.e2e_enabled: false` and `options.user_docs_enabled: false`, skip straight to Finalization.
-
-## Execute
-
-**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md).
-
-### E2E Testing (`e2e-run`, conditional)
-
-**Skip if** `options.e2e_enabled: false`.
-
-Task tool - `e2e-test-verifier`. Prompt MUST include: task_path (absolute), spec_path (`implementation/spec.md`), base_url. Report saves to `{task_path}/verification/e2e-verification-report.md` with screenshots. This is runtime browser verification via Playwright MCP tools — not test file generation.
-
-### User Documentation (`docs-generated`, conditional)
-
-**Skip if** `options.user_docs_enabled: false`.
-
-Task tool - `user-docs-generator`. Prompt MUST include: task_path (absolute), spec_path, base_url. Guide saves to `{task_path}/documentation/user-guide.md` with screenshots.
-
-### Finalization (`task-completed`, inline)
-
-1. Create workflow summary: what was built, phases executed, verification outcome, artifacts produced.
-2. Update `task.status: completed` in state.
-3. Provide commit message template (conventional style, referencing task name).
-4. Guide next steps: code review, PR, deployment.
-
-## State Update Convention (per step)
-
-Apply after EVERY phase 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 batch multiple steps into one end-of-skill write:
-   - After E2E testing (only when it ran): append `e2e-run` to `completed_phases`; record the E2E verdict; bump `orchestrator.updated`.
-   - After user documentation (only when it ran): append `docs-generated` to `completed_phases`; record the guide location; bump `orchestrator.updated`.
-   - After finalization: append `task-completed` to `completed_phases`; set `task.status: completed`; bump `orchestrator.updated`.
-2. **Timestamp** — set `orchestrator.updated` to the current UTC timestamp on every write.
-3. **Failures** — if the E2E run or documentation generation fails and cannot be recovered, do NOT append the corresponding slug to `completed_phases`; append it to `orchestrator.failed_phases` and increment `auto_fix_attempts["<slug>"]`. Ask the user whether to retry or continue to finalization without that step.
-4. **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.
-5. **Final check** — before the Exit Gate, one consolidated re-read + `verify_template` run to confirm the full state matches everything performed in this session.
-
-## Exit Gate
-
-Present results, get user confirmation, then close the workflow (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). Never auto-invoke the next skill.
-
-### Results box
-
-```markdown
-## ✅ DEVELOPMENT WORKFLOW COMPLETE — <task name>
-
-**Built** — [1-2 line summary of what was built]
-**Steps** — [executed steps, e.g. codebase-analysed → task-completed]
-**Verification** — [final verification outcome]
-**E2E verdict** — [if run] / skipped
-**User guide** — [path] / not generated
-
-**Artifacts**
-- `verification/e2e-verification-report.md` [conditional]
-- `documentation/user-guide.md` [conditional]
-```
-
-### Results-acceptance question
-
-Use `question` — "Are these results correct?" with options:
-
-- **Accept** — workflow is complete; show closing guidance.
-- **Adjust** — re-run the affected optional phase (E2E or user docs) with the user's corrections, then re-present the results box.
-- **Discuss** — walk through the finalization (summary, E2E verdict, guide contents, commit guidance) in more depth; then re-ask.
-- **Stop here** — print the resume command (`/owflow:dev-finalize <task-path>`) and end.
-
-### Next steps (after Accept)
-
-Workflow is finished; no further owflow phase command is required. All follow-ups are `optional` (post-completion quality work, none advance phases):
-
-- `/owflow:reviews-pragmatic <task-path>` — `optional` — post-completion over-engineering / pragmatism check; does not advance phases
-- `/owflow:standards-update "<lesson learned>"` — `optional` — captures any new patterns as project standards; does not advance phases
-
-**Other options**: commit the changes using the provided message template; open a PR. (Manual steps outside owflow.)
-
-Then STOP.
+---
+name: owflow:dev-finalize
+description: Development — conditional E2E testing, user documentation, and workflow finalization with commit guidance.
+argument-hint: "[task-path-or-identifier]"
+user-invocable: true
+---
+
+# Dev Finalize — E2E, User Docs & Finalization (e2e-run, docs-generated, task-completed)
+
+Closing phase of the development workflow. Runs optional E2E browser verification and user documentation when enabled, then finalizes the workflow.
+
+## Entry Gate
+
+Resolve the `task-path-or-identifier` argument BEFORE anything else (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)):
+
+- **Path** (absolute or project-relative) to the task directory — use as-is.
+- **Identifier** — exact directory name inside `.owflow/tasks/development/` (e.g., `2026-01-12-my-task`); resolve to its path.
+- If the argument is **missing**, the path does **not exist**, or matches **no identifier** → print the blocked block, then STOP (never guess or auto-pick a task):
+  1. Steps that must be completed first (in order), each with its command:
+     - Codebase & gap analysis (`codebase-analysed`, `gap-analysed`) → `/owflow:dev-analyze <task-path>`
+     - TDD red gate (`tdd-red-proven`) — only when a reproducible defect was detected → `/owflow:dev-tdd-red <task-path>`
+     - Requirements, specification & audit (`spec-written`, `spec-audited`) → `/owflow:dev-spec <task-path>`
+     - Implementation planning (`plan-created`) → `/owflow:dev-plan <task-path>`
+     - Implementation & TDD green gate (`implementation-done`, `tdd-green-proven`) → `/owflow:dev-implement <task-path>`
+     - Verification & issue resolution (`options-chosen`, `verification-done`) → `/owflow:dev-verify <task-path>`
+  2. List available dev-task identifiers (directories under `.owflow/tasks/development/`) to resume from, if any.
+  3. Hint: `Run /owflow:development <description> to start a task from scratch, or pass a task path/identifier to resume.`
+
+### Prerequisites
+
+| Required for this skill | Where verified                            | Produced by                        |
+| ----------------------- | ----------------------------------------- | ---------------------------------- |
+| State file exists       | `<task-path>/orchestrator-state.yml`      | `/owflow:development <desc>`       |
+| Verification done       | `verification-done` in `completed_phases` | `/owflow:dev-verify <task-path>`   |
+
+1. **Read `orchestrator-state.yml`** from the task path. If missing → mid-pipeline bootstrap ([Missing-state Bootstrap](../orchestrator-framework/references/gate-contract.md), starting slug `e2e-run`): `question` — create a fresh standard development task starting at this step, or decline → print `No development task found at <path>. Run /owflow:development <description> to start a task from scratch.` and STOP.
+2. **Prerequisite check**: `verification-done` in `completed_phases`. If missing → print the blocked block, then STOP:
+   - Steps that must be completed first: analysis (`codebase-analysed`, `gap-analysed`) → TDD red gate (`tdd-red-proven`, only when a reproducible defect was detected) → specification (`spec-written`) → implementation planning (`plan-created`) → implementation (`implementation-done`) → verification (`verification-done`).
+   - `Run /owflow:dev-verify <task-path> first` (or the command for the earliest missing earlier step).
+   - If no task exists yet: `Run /owflow:development <description> to start a task from scratch.`
+3. **Skip/resume**: if `task.status` is `completed`, report the existing finalization and STOP.
+4. **Conditional activation**: if `options.e2e_enabled: false` and `options.user_docs_enabled: false`, skip straight to Finalization.
+
+## Execute
+
+**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md).
+
+### E2E Testing (`e2e-run`, conditional)
+
+**Skip if** `options.e2e_enabled: false`.
+
+Task tool - `e2e-test-verifier`. Prompt MUST include: task_path (absolute), spec_path (`implementation/spec.md`), base_url. Report saves to `{task_path}/verification/e2e-verification-report.md` with screenshots. This is runtime browser verification via Playwright MCP tools — not test file generation.
+
+### User Documentation (`docs-generated`, conditional)
+
+**Skip if** `options.user_docs_enabled: false`.
+
+Task tool - `user-docs-generator`. Prompt MUST include: task_path (absolute), spec_path, base_url. Guide saves to `{task_path}/documentation/user-guide.md` with screenshots.
+
+### Finalization (`task-completed`, inline)
+
+1. Create workflow summary: what was built, phases executed, verification outcome, artifacts produced.
+2. Update `task.status: completed` in state.
+3. Provide commit message template (conventional style, referencing task name).
+4. Guide next steps: code review, PR, deployment.
+
+## State Update Convention (per step)
+
+Apply after EVERY phase 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 batch multiple steps into one end-of-skill write:
+   - After E2E testing (only when it ran): append `e2e-run` to `completed_phases`; record the E2E verdict; bump `orchestrator.updated`.
+   - After user documentation (only when it ran): append `docs-generated` to `completed_phases`; record the guide location; bump `orchestrator.updated`.
+   - After finalization: append `task-completed` to `completed_phases`; set `task.status: completed`; bump `orchestrator.updated`.
+2. **Timestamp** — set `orchestrator.updated` to the current UTC timestamp on every write.
+3. **Failures** — if the E2E run or documentation generation fails and cannot be recovered, do NOT append the corresponding slug to `completed_phases`; append it to `orchestrator.failed_phases` and increment `auto_fix_attempts["<slug>"]`. Ask the user whether to retry or continue to finalization without that step.
+4. **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.
+5. **Final check** — before the Exit Gate, one consolidated re-read + `verify_template` run to confirm the full state matches everything performed in this session.
+
+## Exit Gate
+
+Present results, get user confirmation, then close the workflow (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). Never auto-invoke the next skill.
+
+### Results box
+
+```markdown
+## ✅ DEVELOPMENT WORKFLOW COMPLETE — <task name>
+
+**Built** — [1-2 line summary of what was built]
+**Steps** — [executed steps, e.g. codebase-analysed → task-completed]
+**Verification** — [final verification outcome]
+**E2E verdict** — [if run] / skipped
+**User guide** — [path] / not generated
+
+**Artifacts**
+- `verification/e2e-verification-report.md` [conditional]
+- `documentation/user-guide.md` [conditional]
+```
+
+### Results-acceptance question
+
+Use `question` — "Are these results correct?" with options:
+
+- **Accept** — workflow is complete; show closing guidance.
+- **Adjust** — re-run the affected optional phase (E2E or user docs) with the user's corrections, then re-present the results box.
+- **Discuss** — walk through the finalization (summary, E2E verdict, guide contents, commit guidance) in more depth; then re-ask.
+- **Stop here** — print the resume command (`/owflow:dev-finalize <task-path>`) and end.
+
+### Next steps (after Accept)
+
+Workflow is finished; no further owflow phase command is required. All follow-ups are `optional` (post-completion quality work, none advance phases):
+
+- `/owflow:reviews-pragmatic <task-path>` — `optional` — post-completion over-engineering / pragmatism check; does not advance phases
+- `/owflow:standards-update "<lesson learned>"` — `optional` — captures any new patterns as project standards; does not advance phases
+
+**Other options**: commit the changes using the provided message template; open a PR. (Manual steps outside owflow.)
+
+Then STOP.

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

@@ -1,167 +1,167 @@
----
-name: owflow:dev-implement
-description: Development — execute the implementation plan via delegation, then the TDD Green Gate when a red gate exists. --quick selects the condensed direct path (bootstrap a task here when no state file exists; direct implementation when it does).
-argument-hint: "[task-path-or-identifier | \"description\"] [--quick]"
-user-invocable: true
----
-
-# Dev Implement — Implementation & TDD Green Gate (implementation-done, tdd-green-proven)
-
-Work phase of the development workflow. Executes the implementation plan via delegation, then verifies the TDD red-gate test now passes when one exists.
-
-Supports a **quick mode** (`--quick`): a condensed path that implements **directly in the main agent** with the discovered standards — never routed through `implementation-plan-executor`. On a description argument with no existing task it first bootstraps a standard development task (state file, condensed spec + plan); on an existing task it applies `--quick` to the implementation itself (e.g., a quick plan). After the Exit Gate, the pipeline can either stop there or continue with `/owflow:dev-verify` — the task is a regular development task, resumable by any dev-* subskill.
-
-## Entry Gate
-
-Resolve the argument BEFORE anything else (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). The argument may be:
-
-- **Path** (absolute or project-relative) to the task directory — use as-is.
-- **Identifier** — exact directory name inside `.owflow/tasks/development/` (e.g., `2026-01-12-my-task`); resolve to its path.
-- **Description** — anything else (quoted free text, e.g. `"Add a logout button to the navbar"`) is treated as a new task description for quick bootstrap.
-
-Route by argument kind and flags:
-
-| Situation                                                        | Route                                        |
-| ---------------------------------------------------------------- | -------------------------------------------- |
-| Task path/identifier, no `--quick`, state + spec + plan exist (or only implementation pending) | Normal implementation below |
-| Task path/identifier, `--quick`, spec + plan exist               | Direct implementation (quick mode) — the flag selects the direct path over delegation |
-| Task path/identifier, `--quick`, spec or plan missing            | Quick prelude for the missing pieces, then direct implementation |
-| Task path/identifier of a dev-bugfix task (`entry_point: "dev-bugfix"`, implementation slugs complete, no spec/plan) | Normal implementation below — implement nothing; if `implementation-done` holds, run the green gate when a red gate exists, then Exit Gate (or suggest `/owflow:dev-verify <task-path>` for the verification pipeline) |
-| Description argument, `--quick` (or no argument after prompt)    | Quick bootstrap (create task + condensed prelude), then normal implementation |
-| Description argument, no `--quick`                               | Ask via `question`: quick condensed task / full pipeline (blocked block below) / cancel |
-| Missing argument                                                 | Prompt for input (path, identifier, or description), then re-route |
-
-If the path does **not exist** or matches **no identifier** → print the blocked block, then STOP (never guess or auto-pick a task):
-
-1. Steps that must be completed first (in order), each with its command:
-   - Codebase & gap analysis (`codebase-analysed`, `gap-analysed`) → `/owflow:dev-analyze <task-path>`
-   - TDD red gate (`tdd-red-proven`) — only when a reproducible defect was detected → `/owflow:dev-tdd-red <task-path>`
-   - Requirements, specification & audit (`spec-written`, `spec-audited`) → `/owflow:dev-spec <task-path>`
-   - Implementation planning (`plan-created`) → `/owflow:dev-plan <task-path>`
-2. List available dev-task identifiers (directories under `.owflow/tasks/development/`) to resume from, if any.
-3. Hint: `Run /owflow:development <description> to start a task from scratch, /owflow:dev-implement --quick "<description>" for a condensed quick task, or pass a task path/identifier to resume.`
-
-### Prerequisites
-
-| Required for this skill | Where verified                              | Produced by                      |
-| ----------------------- | ------------------------------------------- | -------------------------------- |
-| State file exists       | `<task-path>/orchestrator-state.yml`        | `/owflow:development <desc>` or quick bootstrap |
-| Spec approved           | `implementation/spec.md` exists             | `/owflow:dev-spec <task-path>` or quick prelude |
-| Plan approved           | `implementation/implementation-plan.md` exists | `/owflow:dev-plan <task-path>` or quick prelude |
-
-1. **Read `orchestrator-state.yml`** from the task path. If missing → quick bootstrap (see Quick Mode), otherwise mid-pipeline bootstrap ([Missing-state Bootstrap](../orchestrator-framework/references/gate-contract.md), starting slug `implementation-done`): `question` — bootstrap a fresh standard task starting at this step, or decline → print: `No development task found at <path>. Run /owflow:development <description> to start a task from scratch.` and STOP.
-2. **Skip/resume**: if `implementation-done` is in `completed_phases`, skip to the TDD green gate.
-3. **Prerequisite check**: `implementation/spec.md` AND `implementation/implementation-plan.md` exist — **unless `implementation-done` is in `completed_phases`** (dev-bugfix task or re-run: spec/plan are not required; go straight to the skip/resume TDD green gate). If missing → run the Quick prelude for the missing pieces (`--quick` or user chooses quick), otherwise print the blocked block, then STOP:
-   - Steps that must be completed first: analysis (`codebase-analysed`, `gap-analysed`) → TDD red gate (`tdd-red-proven`, only when a reproducible defect was detected) → specification (`spec-written`) → implementation planning (`plan-created`).
-   - `Run /owflow:dev-spec and /owflow:dev-plan <task-path> first` (or `/owflow:dev-analyze <task-path>` / `/owflow:dev-spec <task-path>` for the missing earlier steps).
-   - If no task exists yet: `Run /owflow:development <description> to start a task from scratch, or /owflow:dev-implement --quick "<description>" for a condensed quick task.`
-
-## Quick Mode (condensed prelude → normal implementation)
-
-Quick mode produces the same artifacts as the early pipeline phases — just condensed into one pass inside this skill. It does NOT introduce a second state format: the task gets a standard `orchestrator-state.yml` and standard artifacts, so every other dev-* subskill can pick it up afterwards.
-
-### Quick bootstrap (no state file, description argument)
-
-1. **Create Task Directory**: `.owflow/tasks/development/YYYY-MM-DD-task-name/` (3–5 kebab-case words from the description).
-2. **Initialize State**: create `orchestrator-state.yml` from the development template with `task.title` / `task.description` from the description, `task.status: in_progress`, `orchestrator.entry_point: "dev-implement --quick"`, and `task_context.task_characteristics.has_reproducible_defect` set to `true` ONLY when the description is clearly bug-shaped (symptom + expected vs actual); otherwise `false`. Bug-shaped descriptions with a reproducible defect → suggest `/owflow:dev-bugfix` instead (TDD red gate discipline, same standard state) — `/owflow:dev-bugfix "<description>"` produces this same task shape under `.owflow/tasks/development/` — unless the user insists on proceeding here.
-   - **CRITICAL**: use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-development.yml`.
-3. **Discover project documentation**: read `.owflow/docs/INDEX.md` (if exists) and extract the Project Documentation file paths into `project_context.project_doc_paths` (matching the development dispatcher's initialization).
-4. If `.owflow/docs/` does not exist, proceed without standards and note the graceful-fallback hint in the completion message: `"No AI SDLC standards found. Consider running /owflow:flow-init to initialize project documentation and coding standards."`
-
-### Quick prelude (one condensed pass)
-
-**MANDATORY order — standards before analysis, analysis before spec/plan:**
-
-1. **Standards discovery**: identify applicable standards from INDEX.md by task keywords (e.g., "API" → api/error-handling, "form" → validation/accessibility) and **READ each applicable standard file** with the Read tool — reading INDEX.md alone is NOT sufficient. Record the paths in `project_context.standards_applied` (extra state field) and reference them in the spec.
-2. **Brief codebase analysis**: explore the affected areas (Glob, Grep, Read) — enough to identify affected files/modules, existing patterns, and test strategy. Write `analysis/quick-analysis.md` (affected files, approach sketch, standards referenced). Extract a 1–2 sentence summary into `phase_summaries.quick_analysis`.
-3. **Condensed spec**: write `implementation/spec.md` — goal, scope (in/out), requirements, applicable standards with key guidelines, verification criteria. Mark `spec-written` complete (`phase_summaries.specification` summary).
-4. **Condensed plan**: write `implementation/implementation-plan.md` — 1–3 task groups, each with concrete checkable steps and tests. Use the same on-the-fly plan shape as the dev-plan quick prelude: key discoveries with `file:line` references, a "What We're NOT Doing" out-of-scope list, intent + contract per step (no code snippets unless non-obvious), automated vs manual acceptance criteria, and no open questions (resolve before finalizing). Mark `plan-created` complete.
-5. **Approval gate** — use `question`: present the mini plan (goal, approach, affected files, task groups) and ask "Proceed with implementation?" Options: **Approve and implement** / **Adjust** (rework spec/plan, re-ask) / **Run full pipeline instead** (print `/owflow:development <task-path>` and STOP — do not implement) / **Cancel**.
-6. On approval: append `codebase-analysed` and `gap-analysed` to `completed_phases` (quick analysis covers both; note the condensation in `phase_summaries.codebase_analysis` / `phase_summaries.gap_analysis`), bump `orchestrator.updated`, re-run `verify_template` on the state file.
-
-The TDD red gate is SKIPPED in quick mode (no `tdd-red-proven`), and the green gate below is therefore skipped too. `spec-audited` is skipped — the approval gate in step 5 substitutes for the audit.
-
-Then continue with **Direct Implementation (quick mode)** below.
-
-### Direct implementation (quick mode, `implementation-done`)
-
-**Trigger**: quick mode selected for this run — the `--quick` flag on this invocation, or the task bootstrapped/prelude-run in quick mode this session (`orchestrator.entry_point: "dev-implement --quick"`). Quick mode NEVER routes to `implementation-plan-executor` — the main agent implements directly, applying the standards already read in prelude step 1 (for a pre-existing plan, apply the standards listed in its "Standards Compliance" section). (Normal full-pipeline runs always delegate — see Execute below.)
-
-1. **Work through the condensed plan's task groups in order**, following each step's intent and contract.
-2. **Apply standards**: for every code change, verify it follows the applicable standards from `project_context.standards_applied`. If implementation reveals new areas (auth, database, file handling, ...) whose standards were not read in the prelude, check `.owflow/docs/INDEX.md` and READ the applicable standard files before proceeding; append their paths to `project_context.standards_applied`.
-3. **Tests**: run the plan's tests as steps specify (test-driven order per group: tests → implementation → verify). Fix failures before moving on.
-4. **Mark checkboxes** in `implementation/implementation-plan.md` immediately after each step completes (main agent responsibility — same convention as implementation-plan-executor).
-5. **Work-log**: append per-group entries and a completion entry to `implementation/work-log.md` (files changed, standards applied — prelude-read and discovered, test results).
-
-## Execute (normal runs — full pipeline)
-
-**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md).
-
-**Scope**: normal runs only — task created via the full pipeline, or a quick task resumed **without** `--quick` (e.g., a `/owflow:dev-plan --quick` task continued with `/owflow:dev-implement <task-path>`; the executor picks up uncompleted groups). Quick mode uses Direct implementation above instead of this section.
-
-### Implementation (`implementation-done`) — Skill tool
-
-**ANTI-PATTERN (normal runs) — never implement directly. "Simple enough to code inline" is NOT a reason to skip delegation.**
-
-Skill tool - `implementation-plan-executor`. Pass: task_path, task_description, task_characteristics, `phase_summaries`, research context if present in state. The skill manages its own subagents, incremental tests, and `implementation/work-log.md`.
-
-### TDD Green Gate (`tdd-green-proven`, conditional)
-
-**Skip if** `tdd-red-proven` is NOT in `completed_phases` (no red gate exists).
-
-1. Run the test written in the red gate (path recorded in `implementation/tdd-red-gate.md`).
-2. **It MUST pass** — proves the defect is fixed. On failure: fix implementation and retry (up to 5 attempts: syntax, imports, test alignment). Still failing → `question`: continue fixing, return to `/owflow:dev-implement` implementation work, or stop.
-3. Write results to `implementation/tdd-green-gate.md`; set `task_context.tdd_green_passed: true`.
-
-## State Update Convention (per step)
-
-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 batch multiple steps into one end-of-skill write:
-   - After implementation (direct quick implementation or plan execution complete): append `implementation-done` to `completed_phases`; extract 1-2 sentence summary to `phase_summaries.implementation` (task groups completed, files changed, test results, known issues); bump `orchestrator.updated`.
-   - After the green gate (only when it ran — no red gate ⇒ no `tdd-green-proven`): append `tdd-green-proven` to `completed_phases`; set `task_context.tdd_green_passed: true`; bump `orchestrator.updated`.
-2. **Timestamp** — set `orchestrator.updated` to the current UTC timestamp on every write.
-3. **Failures** — if the direct implementation or green gate ultimately fails (retries exhausted, user stops): do NOT append the corresponding slug to `completed_phases`; append it to `orchestrator.failed_phases` and increment `auto_fix_attempts["<slug>"]`. Partial progress stays documented in `phase_summaries.implementation` and `implementation/work-log.md`.
-4. **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.
-5. **Final check** — before the Exit Gate, one consolidated re-read + `verify_template` run to confirm the full state matches everything performed in this session.
-
-## Exit Gate
-
-Present results, get user confirmation, then hand off (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). Never auto-invoke the next skill.
-
-### Results box
-
-```markdown
-## ✅ DEV IMPLEMENT COMPLETE — <task name>
-
-**Task groups** — [completed groups / total]
-**Files changed** — [count + key files, 1-3 lines]
-**Tests** — [incremental test results]
-**Green gate** — [✅ PASSED / not required (no red gate)]
-**Known issues** — [deferred items / "none"]
-**Entry point** — [quick bootstrap (direct implementation) / full pipeline (delegated)]
-
-**Artifacts**
-- implemented code
-- `implementation/work-log.md`
-- `implementation/tdd-green-gate.md` [conditional]
-```
-
-### Results-acceptance question
-
-Use `question` — "Are these results correct?" with options:
-
-- **Accept** — implementation matches the plan; continue.
-- **Adjust** — re-work the affected task groups (fix code, re-run their tests), update state and work-log, re-present the results box.
-- **Discuss** — walk through implementation details (decisions made, files changed, deferred items) in more depth; then re-ask.
-- **Stop here** — print the resume command (`/owflow:dev-implement <task-path>`) and end. The task is a regular development task; `/owflow:dev-verify <task-path>` (or `/owflow:development <task-path>`) continues the pipeline later.
-
-### Next steps (after Accept)
-
-- `→ /owflow:dev-verify <task-path>` — `required` before commit: runs the verification pipeline (completeness, code review with a bounded fix loop) and must pass before finalization. Remaining after: finalize.
-
-**Other options**:
-
-- `/owflow:goal-development <task-path>` — `optional` shortcut: runs all remaining phases in one loop (verify → finalize)
-
-Then STOP.
+---
+name: owflow:dev-implement
+description: Development — execute the implementation plan via delegation, then the TDD Green Gate when a red gate exists. --quick selects the condensed direct path (bootstrap a task here when no state file exists; direct implementation when it does).
+argument-hint: "[task-path-or-identifier | \"description\"] [--quick]"
+user-invocable: true
+---
+
+# Dev Implement — Implementation & TDD Green Gate (implementation-done, tdd-green-proven)
+
+Work phase of the development workflow. Executes the implementation plan via delegation, then verifies the TDD red-gate test now passes when one exists.
+
+Supports a **quick mode** (`--quick`): a condensed path that implements **directly in the main agent** with the discovered standards — never routed through `implementation-plan-executor`. On a description argument with no existing task it first bootstraps a standard development task (state file, condensed spec + plan); on an existing task it applies `--quick` to the implementation itself (e.g., a quick plan). After the Exit Gate, the pipeline can either stop there or continue with `/owflow:dev-verify` — the task is a regular development task, resumable by any dev-* subskill.
+
+## Entry Gate
+
+Resolve the argument BEFORE anything else (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). The argument may be:
+
+- **Path** (absolute or project-relative) to the task directory — use as-is.
+- **Identifier** — exact directory name inside `.owflow/tasks/development/` (e.g., `2026-01-12-my-task`); resolve to its path.
+- **Description** — anything else (quoted free text, e.g. `"Add a logout button to the navbar"`) is treated as a new task description for quick bootstrap.
+
+Route by argument kind and flags:
+
+| Situation                                                        | Route                                        |
+| ---------------------------------------------------------------- | -------------------------------------------- |
+| Task path/identifier, no `--quick`, state + spec + plan exist (or only implementation pending) | Normal implementation below |
+| Task path/identifier, `--quick`, spec + plan exist               | Direct implementation (quick mode) — the flag selects the direct path over delegation |
+| Task path/identifier, `--quick`, spec or plan missing            | Quick prelude for the missing pieces, then direct implementation |
+| Task path/identifier of a dev-bugfix task (`entry_point: "dev-bugfix"`, implementation slugs complete, no spec/plan) | Normal implementation below — implement nothing; if `implementation-done` holds, run the green gate when a red gate exists, then Exit Gate (or suggest `/owflow:dev-verify <task-path>` for the verification pipeline) |
+| Description argument, `--quick` (or no argument after prompt)    | Quick bootstrap (create task + condensed prelude), then normal implementation |
+| Description argument, no `--quick`                               | Ask via `question`: quick condensed task / full pipeline (blocked block below) / cancel |
+| Missing argument                                                 | Prompt for input (path, identifier, or description), then re-route |
+
+If the path does **not exist** or matches **no identifier** → print the blocked block, then STOP (never guess or auto-pick a task):
+
+1. Steps that must be completed first (in order), each with its command:
+   - Codebase & gap analysis (`codebase-analysed`, `gap-analysed`) → `/owflow:dev-analyze <task-path>`
+   - TDD red gate (`tdd-red-proven`) — only when a reproducible defect was detected → `/owflow:dev-tdd-red <task-path>`
+   - Requirements, specification & audit (`spec-written`, `spec-audited`) → `/owflow:dev-spec <task-path>`
+   - Implementation planning (`plan-created`) → `/owflow:dev-plan <task-path>`
+2. List available dev-task identifiers (directories under `.owflow/tasks/development/`) to resume from, if any.
+3. Hint: `Run /owflow:development <description> to start a task from scratch, /owflow:dev-implement --quick "<description>" for a condensed quick task, or pass a task path/identifier to resume.`
+
+### Prerequisites
+
+| Required for this skill | Where verified                              | Produced by                      |
+| ----------------------- | ------------------------------------------- | -------------------------------- |
+| State file exists       | `<task-path>/orchestrator-state.yml`        | `/owflow:development <desc>` or quick bootstrap |
+| Spec approved           | `implementation/spec.md` exists             | `/owflow:dev-spec <task-path>` or quick prelude |
+| Plan approved           | `implementation/implementation-plan.md` exists | `/owflow:dev-plan <task-path>` or quick prelude |
+
+1. **Read `orchestrator-state.yml`** from the task path. If missing → quick bootstrap (see Quick Mode), otherwise mid-pipeline bootstrap ([Missing-state Bootstrap](../orchestrator-framework/references/gate-contract.md), starting slug `implementation-done`): `question` — bootstrap a fresh standard task starting at this step, or decline → print: `No development task found at <path>. Run /owflow:development <description> to start a task from scratch.` and STOP.
+2. **Skip/resume**: if `implementation-done` is in `completed_phases`, skip to the TDD green gate.
+3. **Prerequisite check**: `implementation/spec.md` AND `implementation/implementation-plan.md` exist — **unless `implementation-done` is in `completed_phases`** (dev-bugfix task or re-run: spec/plan are not required; go straight to the skip/resume TDD green gate). If missing → run the Quick prelude for the missing pieces (`--quick` or user chooses quick), otherwise print the blocked block, then STOP:
+   - Steps that must be completed first: analysis (`codebase-analysed`, `gap-analysed`) → TDD red gate (`tdd-red-proven`, only when a reproducible defect was detected) → specification (`spec-written`) → implementation planning (`plan-created`).
+   - `Run /owflow:dev-spec and /owflow:dev-plan <task-path> first` (or `/owflow:dev-analyze <task-path>` / `/owflow:dev-spec <task-path>` for the missing earlier steps).
+   - If no task exists yet: `Run /owflow:development <description> to start a task from scratch, or /owflow:dev-implement --quick "<description>" for a condensed quick task.`
+
+## Quick Mode (condensed prelude → normal implementation)
+
+Quick mode produces the same artifacts as the early pipeline phases — just condensed into one pass inside this skill. It does NOT introduce a second state format: the task gets a standard `orchestrator-state.yml` and standard artifacts, so every other dev-* subskill can pick it up afterwards.
+
+### Quick bootstrap (no state file, description argument)
+
+1. **Create Task Directory**: `.owflow/tasks/development/YYYY-MM-DD-task-name/` (3–5 kebab-case words from the description).
+2. **Initialize State**: create `orchestrator-state.yml` from the development template with `task.title` / `task.description` from the description, `task.status: in_progress`, `orchestrator.entry_point: "dev-implement --quick"`, and `task_context.task_characteristics.has_reproducible_defect` set to `true` ONLY when the description is clearly bug-shaped (symptom + expected vs actual); otherwise `false`. Bug-shaped descriptions with a reproducible defect → suggest `/owflow:dev-bugfix` instead (TDD red gate discipline, same standard state) — `/owflow:dev-bugfix "<description>"` produces this same task shape under `.owflow/tasks/development/` — unless the user insists on proceeding here.
+   - **CRITICAL**: use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-development.yml`.
+3. **Discover project documentation**: read `.owflow/docs/INDEX.md` (if exists) and extract the Project Documentation file paths into `project_context.project_doc_paths` (matching the development dispatcher's initialization).
+4. If `.owflow/docs/` does not exist, proceed without standards and note the graceful-fallback hint in the completion message: `"No AI SDLC standards found. Consider running /owflow:flow-init to initialize project documentation and coding standards."`
+
+### Quick prelude (one condensed pass)
+
+**MANDATORY order — standards before analysis, analysis before spec/plan:**
+
+1. **Standards discovery**: identify applicable standards from INDEX.md by task keywords (e.g., "API" → api/error-handling, "form" → validation/accessibility) and **READ each applicable standard file** with the Read tool — reading INDEX.md alone is NOT sufficient. Record the paths in `project_context.standards_applied` (extra state field) and reference them in the spec.
+2. **Brief codebase analysis**: explore the affected areas (Glob, Grep, Read) — enough to identify affected files/modules, existing patterns, and test strategy. Write `analysis/quick-analysis.md` (affected files, approach sketch, standards referenced). Extract a 1–2 sentence summary into `phase_summaries.quick_analysis`.
+3. **Condensed spec**: write `implementation/spec.md` — goal, scope (in/out), requirements, applicable standards with key guidelines, verification criteria. Mark `spec-written` complete (`phase_summaries.specification` summary).
+4. **Condensed plan**: write `implementation/implementation-plan.md` — 1–3 task groups, each with concrete checkable steps and tests. Use the same on-the-fly plan shape as the dev-plan quick prelude: key discoveries with `file:line` references, a "What We're NOT Doing" out-of-scope list, intent + contract per step (no code snippets unless non-obvious), automated vs manual acceptance criteria, and no open questions (resolve before finalizing). Mark `plan-created` complete.
+5. **Approval gate** — use `question`: present the mini plan (goal, approach, affected files, task groups) and ask "Proceed with implementation?" Options: **Approve and implement** / **Adjust** (rework spec/plan, re-ask) / **Run full pipeline instead** (print `/owflow:development <task-path>` and STOP — do not implement) / **Cancel**.
+6. On approval: append `codebase-analysed` and `gap-analysed` to `completed_phases` (quick analysis covers both; note the condensation in `phase_summaries.codebase_analysis` / `phase_summaries.gap_analysis`), bump `orchestrator.updated`, re-run `verify_template` on the state file.
+
+The TDD red gate is SKIPPED in quick mode (no `tdd-red-proven`), and the green gate below is therefore skipped too. `spec-audited` is skipped — the approval gate in step 5 substitutes for the audit.
+
+Then continue with **Direct Implementation (quick mode)** below.
+
+### Direct implementation (quick mode, `implementation-done`)
+
+**Trigger**: quick mode selected for this run — the `--quick` flag on this invocation, or the task bootstrapped/prelude-run in quick mode this session (`orchestrator.entry_point: "dev-implement --quick"`). Quick mode NEVER routes to `implementation-plan-executor` — the main agent implements directly, applying the standards already read in prelude step 1 (for a pre-existing plan, apply the standards listed in its "Standards Compliance" section). (Normal full-pipeline runs always delegate — see Execute below.)
+
+1. **Work through the condensed plan's task groups in order**, following each step's intent and contract.
+2. **Apply standards**: for every code change, verify it follows the applicable standards from `project_context.standards_applied`. If implementation reveals new areas (auth, database, file handling, ...) whose standards were not read in the prelude, check `.owflow/docs/INDEX.md` and READ the applicable standard files before proceeding; append their paths to `project_context.standards_applied`.
+3. **Tests**: run the plan's tests as steps specify (test-driven order per group: tests → implementation → verify). Fix failures before moving on.
+4. **Mark checkboxes** in `implementation/implementation-plan.md` immediately after each step completes (main agent responsibility — same convention as implementation-plan-executor).
+5. **Work-log**: append per-group entries and a completion entry to `implementation/work-log.md` (files changed, standards applied — prelude-read and discovered, test results).
+
+## Execute (normal runs — full pipeline)
+
+**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md).
+
+**Scope**: normal runs only — task created via the full pipeline, or a quick task resumed **without** `--quick` (e.g., a `/owflow:dev-plan --quick` task continued with `/owflow:dev-implement <task-path>`; the executor picks up uncompleted groups). Quick mode uses Direct implementation above instead of this section.
+
+### Implementation (`implementation-done`) — Skill tool
+
+**ANTI-PATTERN (normal runs) — never implement directly. "Simple enough to code inline" is NOT a reason to skip delegation.**
+
+Skill tool - `implementation-plan-executor`. Pass: task_path, task_description, task_characteristics, `phase_summaries`, research context if present in state. The skill manages its own subagents, incremental tests, and `implementation/work-log.md`.
+
+### TDD Green Gate (`tdd-green-proven`, conditional)
+
+**Skip if** `tdd-red-proven` is NOT in `completed_phases` (no red gate exists).
+
+1. Run the test written in the red gate (path recorded in `implementation/tdd-red-gate.md`).
+2. **It MUST pass** — proves the defect is fixed. On failure: fix implementation and retry (up to 5 attempts: syntax, imports, test alignment). Still failing → `question`: continue fixing, return to `/owflow:dev-implement` implementation work, or stop.
+3. Write results to `implementation/tdd-green-gate.md`; set `task_context.tdd_green_passed: true`.
+
+## State Update Convention (per step)
+
+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 batch multiple steps into one end-of-skill write:
+   - After implementation (direct quick implementation or plan execution complete): append `implementation-done` to `completed_phases`; extract 1-2 sentence summary to `phase_summaries.implementation` (task groups completed, files changed, test results, known issues); bump `orchestrator.updated`.
+   - After the green gate (only when it ran — no red gate ⇒ no `tdd-green-proven`): append `tdd-green-proven` to `completed_phases`; set `task_context.tdd_green_passed: true`; bump `orchestrator.updated`.
+2. **Timestamp** — set `orchestrator.updated` to the current UTC timestamp on every write.
+3. **Failures** — if the direct implementation or green gate ultimately fails (retries exhausted, user stops): do NOT append the corresponding slug to `completed_phases`; append it to `orchestrator.failed_phases` and increment `auto_fix_attempts["<slug>"]`. Partial progress stays documented in `phase_summaries.implementation` and `implementation/work-log.md`.
+4. **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.
+5. **Final check** — before the Exit Gate, one consolidated re-read + `verify_template` run to confirm the full state matches everything performed in this session.
+
+## Exit Gate
+
+Present results, get user confirmation, then hand off (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). Never auto-invoke the next skill.
+
+### Results box
+
+```markdown
+## ✅ DEV IMPLEMENT COMPLETE — <task name>
+
+**Task groups** — [completed groups / total]
+**Files changed** — [count + key files, 1-3 lines]
+**Tests** — [incremental test results]
+**Green gate** — [✅ PASSED / not required (no red gate)]
+**Known issues** — [deferred items / "none"]
+**Entry point** — [quick bootstrap (direct implementation) / full pipeline (delegated)]
+
+**Artifacts**
+- implemented code
+- `implementation/work-log.md`
+- `implementation/tdd-green-gate.md` [conditional]
+```
+
+### Results-acceptance question
+
+Use `question` — "Are these results correct?" with options:
+
+- **Accept** — implementation matches the plan; continue.
+- **Adjust** — re-work the affected task groups (fix code, re-run their tests), update state and work-log, re-present the results box.
+- **Discuss** — walk through implementation details (decisions made, files changed, deferred items) in more depth; then re-ask.
+- **Stop here** — print the resume command (`/owflow:dev-implement <task-path>`) and end. The task is a regular development task; `/owflow:dev-verify <task-path>` (or `/owflow:development <task-path>`) continues the pipeline later.
+
+### Next steps (after Accept)
+
+- `→ /owflow:dev-verify <task-path>` — `required` before commit: runs the verification pipeline (completeness, code review with a bounded fix loop) and must pass before finalization. Remaining after: finalize.
+
+**Other options**:
+
+- `/owflow:goal-development <task-path>` — `optional` shortcut: runs all remaining phases in one loop (verify → finalize)
+
+Then STOP.