docs: supersede the legacy workflow engine

docs/adr/0001-workflow-architecture-24AUG2026.md

@@ -1,9 +1,12 @@
 ---
-status: accepted
+status: superseded
+superseded-by: 0006-skill-led-development-workflow-04SEP2026.md
 ---
 
 # Build workflow around persisted policy gates
 
+> Superseded by [ADR 0006](./0006-skill-led-development-workflow-04SEP2026.md). Retained as the legacy custom-engine decision.
+
 `workflow` will be a new extension rather than an activation or rename of `_workflows`. It will expose one command-style tool backed by atomic revisioned snapshots, Markdown Agent Profiles, deterministic eligibility followed by planner selection, a mandatory feature pipeline, and restricted feature or read-only analysis scripts. Every feature run receives a distinct exclusive worktree. Concurrency defaults to 8 under an immutable process-wide maximum of 32. Non-trivial UI work requires at least three structurally distinct prototypes and explicit user acceptance. Before implementation, the user chooses a fresh plan-seeded session, compaction of the current session that prefers `smart_compact` and falls back to normal Pi compaction when unavailable, or unchanged current context. Review uses a fresh session and excludes every Agent Profile that mutated the reviewed diff.
 
 This keeps the caller interface small while making approval, prototype, recovery, and reviewer-independence rules enforceable in one workflow engine. We rejected unrestricted custom graphs because they could bypass policy, a general registry architecture because it adds speculative extension points, and event-sourced persistence because revisioned snapshots already provide the required recovery and audit data with less machinery.

docs/adr/0002-workflow-interaction-and-recovery-25AUG2026.md

@@ -1,10 +1,13 @@
 ---
-status: accepted
+status: superseded
 supersedes: 0001-workflow-architecture-24AUG2026.md
+superseded-by: 0006-skill-led-development-workflow-04SEP2026.md
 ---
 
 # Use drill-down overlays and bounded recovery
 
+> Superseded by [ADR 0006](./0006-skill-led-development-workflow-04SEP2026.md). Retained as legacy custom-engine UI and recovery evidence.
+
 This decision supersedes the dashboard, dirty-source, execution-timeout, and startup-ownership assumptions in [ADR 0001](./0001-workflow-architecture-24AUG2026.md). The persisted gated pipeline, worktree isolation, and independent-review decisions from ADR 0001 remain accepted.
 
 ## Context

docs/adr/0002-workflow-standard-agent-overlays-27AUG2026.md

@@ -1,3 +1,5 @@
 # Reuse standard agents through workflow role overlays
 
+> Superseded by [ADR 0006](./0006-skill-led-development-workflow-04SEP2026.md). Retained as the legacy custom-engine agent-selection decision.
+
 `workflow` will reuse standard `pi-interactive-subagents` definitions instead of duplicating their prompts and model settings in workflow-only agents. Explicit configuration maps standard agent names to workflow roles, while `workflow` retains ownership, tool-intersection, Gate, verification, and reviewer-independence policy. The default maps `scout` to Discovery and `worker` to Implementation; bundled profiles remain fallbacks for roles without a standard mapping. This keeps one source of truth for agent identity without allowing arbitrary prompt prose or agent names to imply mutability or workflow authority.

docs/adr/0004-bun-extension-workspaces-01SEP2026.md

@@ -8,7 +8,7 @@ Publish packages to the `jb` owner endpoint of the Gitea npm registry. Repositor
 
 `extensions/shared` is the publishable `@jbcode/pi-shared` library. Extensions that import it declare a normal runtime dependency so Pi's production package installation receives the required code.
 
-`extensions/_workflows` is reference code, not a package or publishable extension. `@jbcode/pi-workflow` remains a private workspace until the required reference runtime is merged under `extensions/workflow`; this prevents publishing two workflow packages or publishing an incomplete package.
+`extensions/_workflows` is reference code, not a package or publishable extension. The package-boundary decision remains valid, but [ADR 0006](./0006-skill-led-development-workflow-04SEP2026.md) supersedes the proposed runtime merge: `@jbcode/pi-workflow` now remains private, unpublished, and unexposed as historical pilot evidence.
 
 The existing `config/pi-links.json` policy remains the authority for live-development exposure. Package boundaries and publication do not automatically enable extensions globally.
 
@@ -18,4 +18,4 @@ The existing `config/pi-links.json` policy remains the authority for live-develo
 - Catalog and workspace protocols require `bun publish` or `bun pm pack` before npm publication so concrete versions are written into package metadata.
 - Shared libraries must be published before extensions that depend on the same new version.
 - Pi packages continue shipping TypeScript source because Pi loads extension entrypoints directly.
-- The `workflow` merge is an explicit blocker for its first release.
+- ADR 0006 removes a `workflow` extension release from the active plan; archival or removal follows the skill pilot.

docs/adr/0005-imported-extension-snapshots-01SEP2026.md

@@ -22,4 +22,4 @@ Rename the private `pi-workflow` extension identity to `workflow`. Its workspace
 - Published packages use the scoped Gitea registry instead of Pi-managed Git sources.
 - Upstream movement is detected but never merged automatically; imported changes require reconciliation with monorepo-specific manifests and APIs.
 - Only `main` is tracked. Source tags, branches, and historical commits are not copied.
-- The renamed `workflow` extension remains private until its `_workflows` dependencies are merged and isolated packaging succeeds.
+- The renamed `workflow` extension remains a private historical snapshot. [ADR 0006](./0006-skill-led-development-workflow-04SEP2026.md) supersedes its merge/release prerequisite with the skill pilot and a later retirement decision.

docs/adr/0006-skill-led-development-workflow-04SEP2026.md

@@ -0,0 +1,38 @@
+---
+status: accepted
+supersedes:
+  - 0001-workflow-architecture-24AUG2026.md
+  - 0002-workflow-interaction-and-recovery-25AUG2026.md
+  - 0002-workflow-standard-agent-overlays-27AUG2026.md
+---
+
+# Replace the custom workflow engine with a skill-led workflow
+
+## Context
+
+The custom `workflow` extension encoded useful approval, isolation, verification, and reviewer-independence policy, but coupled that policy to a large state machine, child runtime, scheduler, persistence layer, and TUI. Recorded runs failed or stalled before implementation when exact planner output, child delivery, recovery state, or liveness mechanics diverged from the engine contract.
+
+Pi already provides the useful orchestration primitives: `ask_user`, task tools, direct subagents, artifact presentation, prototypes, browser/application validation, project commands, and Git worktrees. Repository Markdown and commits provide a simpler recovery boundary than a second workflow runtime.
+
+## Decision
+
+Use the model-invoked [`develop-workflow` skill](../../skills/develop/develop-workflow/SKILL.md) for feature work and other multi-step changes. Keep questions and obvious low-risk edits on lightweight paths. Add no replacement extension.
+
+The parent agent owns classification, requirements, the retained workflow record, task state, worktree, assignments, verification, commits, review, and local integration. Preserve categorical human gates for the exact implementation plan, non-trivial UI direction, and just-in-time risk. Require observable evidence rather than exact model-authored transition schemas.
+
+Keep one committed Markdown workflow record per active change. Update it atomically at meaningful checkpoints with optimistic SHA-256 concurrency and retain it after completion. Treat Git and the last committed valid record as authoritative recovery evidence.
+
+Use bounded subagent assignments with exclusive file ownership and before/after Git evidence. Exclude every mutator identity from independent standards and specification review. Require Git-capable read-only reviewer profiles to regenerate and confirm the pinned binary diff fingerprint. Reviewers report findings but never remediate them.
+
+Automate verified commits, rebase, fresh review, clean local fast-forward integration, metadata-only closure, and safe cleanup. Keep destructive actions, force operations, conflict-driven behavior changes, pushes, publishing, deployment, and production access behind explicit approval.
+
+Retain `extensions/workflow` and `extensions/_workflows` as private historical reference during the pilot. Keep them unexposed. Archive or remove them only in a separate change after three successful real-work pilots and explicit retirement approval.
+
+## Consequences
+
+- Workflow gates become procedural and testable, not technically enforced by a custom state machine.
+- Recovery depends on repository evidence and proven child liveness rather than leases or automatic replay.
+- The skill composes existing Pi capabilities and adds no runtime dependency.
+- A Git-capable reviewer profile declares no edit/write tools, while parent before/after Git checks remain necessary because shell access can mutate indirectly.
+- Existing package and imported-snapshot ADRs remain valid except for workflow-extension-specific prerequisites, which this decision supersedes.
+- The twelve scenario evaluations and three real-change pilot remain required before retiring the legacy implementation or closing the replacement TODO.