docs: add skill workspace monorepo migration plan

docs/implementation-roadmap.md

@@ -36,6 +36,7 @@ As of now:
 - HTTP tests now cover the initial read-only `orchd` slice, and the new frontend workspace builds successfully with `pnpm run web:build`
 - Phase 2 frontend work has now started by bootstrapping `apps/web` with copied-in `cadence-ui` tokens and foundational components for button, input, textarea, dialog, form, tabs, card, badge, and alert, with the shared token stylesheet loaded from the frontend entrypoint
 - the first real Phase 2 read-only operator UI is now implemented in `apps/web`, including routed runs list, run detail, blocked queue, and thread timeline views backed by the existing `orchd` HTTP API, plus Tailwind v4 consumer wiring so the source-owned Cadence UI components render correctly in the app
+- a repository-level skill workspace monorepo migration plan now exists under `docs/skill-workspace-monorepo.md`, defining the target split between runtime packages under `packages/`, agent-facing skill bundles under `skills/`, support apps under `apps/`, and package-based skill packaging flows
 - a repo-local `scripts/package_skill_clis.sh` packaging flow now builds bundled skill CLI assets for `inbox`, `orch`, and `council-review`
 - `orch` now implements `run init/show`, `task add`, `dep add`, `ready`, `dispatch`, `reconcile`, `wait`, `blocked`, `answer`, `retry`, `reassign`, `cancel`, `cleanup`, and `status`
 - `orch` can create runs, gate tasks through dependencies, dispatch work through `inbox`, reconcile worker thread state back into task state, answer blocked tasks, retry or reassign work, cancel tasks or runs, clean attempt worktrees, and create per-attempt Git worktrees during strict dispatch
@@ -95,8 +96,9 @@ Current implementation status:
 - `Milestone 7: Council Review` is complete
 - `Milestone 8: Web Product Phase 1 Skeleton` is complete
 - `Milestone 9: Web Product Phase 2 Read-Only Operator UI` is complete for the initial operator surface
+- `Milestone 10: Skill Workspace Monorepo Migration` is planned
 
-The council review v1 surface is complete, the first web-product skeleton now exists as a separate monorepo workspace plus read-only HTTP backend slice, and the first real operator-facing Phase 2 read-only web views now exist on top of the internal Cadence UI component library.
+The council review v1 surface is complete, the first web-product skeleton now exists as a separate monorepo workspace plus read-only HTTP backend slice, the first real operator-facing Phase 2 read-only web views now exist on top of the internal Cadence UI component library, and the repository now has an explicit migration plan for becoming a true skill workspace monorepo.
 
 ### Milestone 1: Go Skeleton
 
@@ -458,19 +460,56 @@ Remaining:
 - add council result/report views and realtime event handling on top of the current routed UI
 - install additional `cadence-ui` components on demand as the product surface expands
 
+### Milestone 10: Skill Workspace Monorepo Migration
+
+Goal:
+
+- restructure the repository into a true multi-package monorepo whose primary deliverables are skills and skill runtimes
+
+Add:
+
+- `packages/` as the source of truth for Go and future runtime implementations
+- `skills/` as the source of truth for agent-facing skill bundles and bundled assets
+- a shared coordination kernel package for the `inbox` / `orch` / `orchd` stack only
+- a package-based skill packaging flow driven by workspace metadata rather than root-path assumptions
+
+Definition of done:
+
+- `inbox`, `orch`, and other runtime-backed skills build from `packages/` rather than root-owned runtime code
+- root `skills/` bundles package from declarative bundle metadata
+- root runtime ownership under `cmd/` and `internal/` is removed or reduced to workspace orchestration only
+- support apps such as `apps/web` remain usable without being treated as the primary deliverable
+
+Status:
+
+- planned
+
+Completed so far:
+
+- the repository-level migration design is captured in `docs/skill-workspace-monorepo.md`
+- the target package split now distinguishes `coord-core`, runtime packages, skill bundles, and support apps
+- the migration plan now defines phased extraction for `coord-core`, `inbox-runtime`, `orch-runtime`, `orchd-runtime`, and `repo-memory-runtime`
+
+Remaining:
+
+- bootstrap `go.work` plus expanded workspace configuration
+- extract shared coordination code into `packages/coord-core`
+- extract `inbox`, `orch`, and `orchd` into package-owned runtimes
+- import `repo-memory` as its own runtime package and add the corresponding skill bundle
+- replace the hardcoded skill packaging script with declarative bundle metadata
+
 ## Immediate Next Task
 
 If a new agent is taking over now, the next concrete step should be:
 
-1. treat `Milestone 8: Web Product Phase 1 Skeleton` as complete unless a new user request reopens the backend skeleton itself
-2. keep the authored inbox test-plan set in `docs/tests/inbox/` synchronized if future `orch` or web work changes shared CLI-visible behavior
-3. treat `Milestone 9: Web Product Phase 2 Read-Only Operator UI` as complete for the initial operator surface and build the next web slice on top of the shipped read pages rather than replacing them
-4. start the next web phase by wiring operator write actions such as answer, retry, reassign, and cancel into the existing runs, blocked, and thread views
-5. add council result/report screens and realtime event handling after the operator write path is clear
-6. install additional `cadence-ui` components on demand when those screens need them, instead of reintroducing bespoke primitives into `apps/web`
-7. keep `api/openapi.yaml`, `api/events.md`, and `docs/web-product-monorepo.md` synchronized as the web surface expands
+1. treat `Milestone 9: Web Product Phase 2 Read-Only Operator UI` as complete for the initial operator surface and do not expand web feature scope further until the workspace split is decided package-by-package
+2. start `Milestone 10: Skill Workspace Monorepo Migration` by bootstrapping `go.work`, expanding workspace metadata, and creating the first empty `packages/` roots
+3. extract the shared coordination kernel into `packages/coord-core` before moving `inbox`, `orch`, or `orchd` into package-owned runtimes
+4. keep the authored skill forward-test plans under `docs/tests/*-skill/` synchronized as runtime ownership moves from root paths to package paths
+5. replace the hardcoded skill packaging flow with declarative bundle metadata before adding `repo-memory`
+6. import `repo-memory` only after the package-based runtime and skill packaging pattern exists
 
-The inbox implementation and its human-readable test-plan set are already in place, `orch` supports the main scheduler loop plus the complete council start/wait/tally/report workflow, and the web product now has its first real operator-facing read surfaces, so the next step should be write-capable operator workflows and council/realtime expansion rather than reopening the frontend shell or basic read pages.
+The inbox implementation and its human-readable test-plan set are already in place, `orch` supports the main scheduler loop plus the complete council start/wait/tally/report workflow, the web product now has its first real operator-facing read surfaces, and the repository now has an explicit plan to become a skill workspace monorepo, so the next step should be repository restructuring rather than continuing to accrete new root-owned runtimes.
 
 ## Recommended Driver Choices