@rosenfan/matrix 0.1.5 → 0.1.7

package/README.md

@@ -69,7 +69,7 @@ Each phase:
 
 ## Prerequisites
 
-- [Claude Code](https://docs.anthropic.com/claude-code) and/or Codex installed as the Skill host
+- [Claude Code](https://docs.anthropic.com/claude-code), [Codex](https://openai.com/codex), or [ZCode](https://zcode.ai) installed as the Skill host (agents that read the Agent Skills open-standard `.agents/skills` directory — opencode, Kimi Code, and other compatible tools — share the Codex installation)
 - Node.js 18+ and `npm` on `PATH` (for the Matrix CLI)
 - Python is optional during the compatibility window; new installations use the bundled Node workflow runtime.
 - Git is only needed when installing from GitHub or contributing to Matrix.
@@ -93,10 +93,10 @@ matrix init
 
 The interactive setup lets you:
 
-- Choose English or Chinese, project or global Matrix discovery scope, and Claude Code, Codex, or both
+- Choose English or Chinese, project or global Matrix discovery scope, and any combination of Claude Code, Codex, and ZCode
 - Copy skills (recommended) or symlink them for local development
 - Safely reconfigure an existing installation with an automatic backup
-- Review all 25 official Matt Skills v1.2.3 roles and install the 23 compatible Skills into the target project
+- Review all 27 official Matt Skills v1.3.1 roles and install the 25 compatible Skills into the target project
 - Choose **Prim** or **Arch** as the project default without disabling the other available mode
 
 For automation and CI:
@@ -131,9 +131,11 @@ matrix update --skip-self-update
 matrix update --yes
 ```
 
-`matrix update` preserves the installation's scope, platforms, language, mode, and orchestration. It first validates a newer npm package in isolation, then re-runs the new CLI to refresh Matrix assets. It never downloads, installs, repairs, or deletes Matt Skills; after the Matrix update it reports the local Matt compatibility status and, when needed, points to `matrix init . --with-mattpocock`. npm and project assets are separate transactions: if asset refresh fails after a CLI upgrade, run `matrix update --skip-self-update` to retry.
+`matrix update` preserves the installation's scope, platforms, language, mode, and orchestration. It first validates a newer npm package in isolation, then re-runs the new CLI to refresh Matrix assets. When the local Matt Skills are incomplete or outdated, an interactive `matrix update` asks once and repairs them to the supported release in the same run — CLI upgrade, asset refresh, and Matt repair complete in a single command (`--with-mattpocock` gives non-interactive/CI the same behavior; `--force-matt` additionally replaces locally modified Matt Skills and requires that flag; Matt Skills are never removed by `matrix update`). `--all` extends the run to every indexed project (`~/.matrix/projects.json`); each project updates in isolation and missing directories are pruned from the index. npm and project assets are separate transactions: if asset refresh fails after a CLI upgrade, run `matrix update --skip-self-update` to retry. On Windows the self-update chain runs npm through Node (no shell), so one-command upgrades work without manual steps.
 
-Matrix 0.1.5 is bound to Matt Skills v1.2.3 at commit `6acc160e4e0cd062dbbbd7a1b26ae92855edf07e`. `matrix init --with-mattpocock` always uses that exact archive and its reviewed 23-Skill compatible manifest, even if upstream has a newer release. The two official but incompatible Skills, `implement` and raw `resolving-merge-conflicts`, are not Matrix-managed or installed. Matrix scope controls Matrix Skill discovery only: Matt Skills and `.matrix/matt-installation.json` are always project-local. Global Matt copies are preserved but never used to complete project readiness.
+Matrix 0.1.7 is bound to Matt Skills v1.3.1 at commit `24fe0ef7737efae15c87225755e9f6f5965e4888`. `matrix init --with-mattpocock` always uses that exact archive and its reviewed 25-Skill compatible manifest, even if upstream has a newer release. The two official but incompatible Skills, `implement` and `implement-spec`, are not Matrix-managed or installed. Matrix scope controls Matrix Skill discovery only: Matt Skills and `.matrix/matt-installation.json` are always project-local. Global Matt copies are preserved but never used to complete project readiness. Upstream v1.3.1 also renamed the domain-doc convention: Matt Skills now read `GLOSSARY.md`/`GLOSSARY-MAP.md` instead of `CONTEXT.md`/`CONTEXT-MAP.md`; rename existing files with `git mv` after updating.
+
+Matrix ships dedicated platform entries only for agents with their own skill-directory convention: Claude Code (`.claude/skills`), Codex (`.agents/skills`), and ZCode (`.zcode/skills`). Installing the Codex platform also serves every agent that reads the Agent Skills open-standard `.agents/skills` directory by default — opencode, Kimi Code, and other compatible tools pick up Matrix and Matt Skills from there without a separate Matrix platform.
 
 The language selected by `matrix init` controls the prose in new Matrix artifacts. Markdown headings required by Matrix guards remain stable English tokens; the artifact body is Chinese for `zh-CN` and English for `en`. A change freezes this language at creation time.
 
@@ -153,7 +155,7 @@ Matrix installs:
 - `matrix-hotfix/` — Shortcut for small bugs
 - `matrix-tweak/` — Shortcut for bounded changes
 - `matrix-status/` — Check current state
-- `matrix-claude/` — Optional: export for Claude Code
+- `matrix-handoff/` — Optional: export to any implementation agent (Claude Code, opencode, ...)
 
 ---
 
@@ -255,28 +257,29 @@ Hotfix and tweak reference the same internal `lightweight` transition profile. T
 
 ---
 
-## Special Feature: matrix-claude
+## Special Feature: matrix-handoff
 
-**Default usage**: Just use the main workflow (`$matrix`). Whether you're using Codex or Claude Code, the standard flow works for both:
+**Default usage**: Just use the main workflow (`$matrix`). Whether you're using Codex, Claude Code, zcode, or opencode, the standard flow works for all of them:
 
 ```
 $matrix → open → design → build → verify → archive
 ```
 
-**When to use `$matrix-claude`**: Only when you want to **split the work across tools** — use Codex for design, then hand off to Claude Code for implementation.
+**When to use `$matrix-handoff`**: Only when you want to **split the work across tools** — design in one agent, implement in another.
 
 | Scenario | What to Do |
 |----------|------------|
 | Use one tool for everything (default) | Just use `$matrix`, no extra steps |
-| Codex designs + Codex implements | Standard flow: design → build → verify |
-| Codex designs + Claude Code implements | design → `$matrix-claude` → Claude Code → verify |
+| Same agent designs and implements | Standard flow: design → build → verify |
+| Codex designs + Claude Code implements | design → `$matrix-handoff` → `export --agent claude-code` → Claude Code → verify |
+| zcode designs + opencode implements | design → `$matrix-handoff` → `export --agent opencode` → opencode → verify |
 
-### How matrix-claude Works
+### How matrix-handoff Works
 
-1. Design phase completes, guard passes
-2. Run `$matrix-claude` → exports frozen design as `artifacts/claude-task.md`
-3. Claude Code reads the task package and implements
-4. Claude Code produces evidence in `artifacts/verification.md`
+1. Design phase completes, guard passes, and you choose the implementation agent at the Design -> Build decision point
+2. Run `$matrix-handoff` → exports the frozen contract as `artifacts/handoff-task-<task-id>.md` (`export --agent <agent-id>`; `--target generic` remains as the legacy Claude Code form, `artifacts/claude-task.md`)
+3. The implementation agent reads the task package and implements
+4. The implementation agent produces evidence in `artifacts/verification.md`
 5. Return to Matrix: build guard → verify → archive
 
 The sidecar does NOT change Matrix state. It's a pure export — like taking a snapshot of the design for another tool to consume.
@@ -285,7 +288,7 @@ The sidecar does NOT change Matrix state. It's a pure export — like taking a s
 
 ## Integration with Matt Pocock's Skills
 
-Prim uses Matrix's own capability. Matrix reviews all 25 official Matt v1.2.3 roles, installs the 23 compatible Skills, and lets Arch automatically invoke only this reviewed ten-capability cohort:
+Prim uses Matrix's own capability. Matrix reviews all 27 official Matt v1.3.1 roles, installs the 25 compatible Skills, and lets Arch automatically invoke only this reviewed ten-capability cohort:
 
 | Phase | Capability | Trigger |
 |---|---|---|
@@ -300,11 +303,11 @@ Prim uses Matrix's own capability. Matrix reviews all 25 official Matt v1.2.3 ro
 | build | `/wizard` | The Contract requires generated human-run shell steps; Matrix never runs them end-to-end |
 | verify | `/code-review` | Standards and Spec review evidence is required |
 
-Matrix may recommend but never nest these user-invoked handoffs: `setup-matt-pocock-skills`, `improve-codebase-architecture`, `wayfinder`, `handoff`, and `to-questionnaire`. The user explicitly runs them outside the active phase; selected output may enter a governed Change.
+Matrix may recommend but never nest these user-invoked handoffs: `setup-matt-pocock-skills`, `improve-codebase-architecture`, `wayfinder`, `handoff`, `retro`, and `to-questionnaire`. The user explicitly runs them outside the active phase; selected output may enter a governed Change.
 
 Arch records a Runtime-managed review receipt after `code-review`, binding its fixed point and committed HEAD diff to the current Contract, review evidence, and workspace. A normal `code-review` receipt requires a clean candidate worktree outside Matrix-managed assets. When Git has no usable baseline, the committed diff is empty, staged/unstaged/untracked candidate files still exist, or the correctly installed capability fails, Matrix may perform one explicitly labelled same-capability fallback for that revision. The `uncommitted-worktree` fallback binds both the fixed point and a content hash of the complete worktree candidate. Installation-integrity failures never fall back. A heading or self-description without the matching receipt cannot advance Verify.
 
-Installed standalone Skills are `ask-matt`, `grill-with-docs`, `triage`, `to-spec`, `to-tickets`, `grill-me`, `teach`, and `wait-what`. `implement` and raw `resolving-merge-conflicts` are incompatible because they can take over TDD/review/staging/commit effects owned by Matrix, so 0.1.5 neither installs nor manages them. Pre-existing copies are preserved and reported as unmanaged extras. Installation never grants automatic invocation, and no companion may transition, commit, archive, recover, or write Matrix state.
+Installed standalone Skills are `ask-matt`, `grill-with-docs`, `triage`, `to-spec`, `to-tickets`, `grill-me`, `teach`, `wait-what`, and `pr`. `implement` and `implement-spec` are incompatible because they can take over TDD/review/staging/commit effects owned by Matrix, so 0.1.7 neither installs nor manages them. Pre-existing copies (including any legacy `resolving-merge-conflicts`) are preserved and reported as unmanaged extras. Installation never grants automatic invocation, and no companion may transition, commit, archive, recover, or write Matrix state.
 
 ---
 

package/README.zh-CN.md

@@ -69,7 +69,7 @@ verify --acceptance-or-design-gap------> design
 
 ## 前置条件
 
-- 已安装 [Claude Code](https://docs.anthropic.com/claude-code) 和/或 Codex，作为 Skill 宿主
+- 已安装 [Claude Code](https://docs.anthropic.com/claude-code)、[Codex](https://openai.com/codex) 或 [ZCode](https://zcode.ai) 之一，作为 Skill 宿主（默认读取 Agent Skills 开放标准 `.agents/skills` 目录的 agent（如 opencode、Kimi Code 等兼容工具）直接共享 Codex 平台的安装产物）
 - Node.js 18+，且 `npm` 已加入 PATH（用于 Matrix CLI）
 - Python 仅在兼容窗口内的旧适配器路径使用；新安装使用内置 Node workflow runtime
 - Git 仅在从 GitHub 安装或参与 Matrix 开发时需要
@@ -96,7 +96,7 @@ matrix init
 - 选择 Matrix Skill 发现入口安装到当前项目或全局
 - 复制 skills（推荐）或为本地开发创建符号链接
 - 安全地重新配置已有安装，并自动备份被替换的 Matrix 文件
-- 审查 Matt Skills v1.2.3 官方 25 项角色，并在目标项目安装其中 23 项兼容 Skill
+- 审查 Matt Skills v1.3.1 官方 27 项角色，并在目标项目安装其中 25 项兼容 Skill
 - 选择 Prim 或 Arch 作为项目默认值，且不禁用另一种可用模式
 
 自动化或 CI 环境可以使用：
@@ -128,9 +128,11 @@ matrix update --skip-self-update
 matrix update --yes
 ```
 
-`matrix update` 会保留既有安装的 scope、平台、语言、mode 与 orchestration。它先隔离验证 npm 新包，再由新 CLI 同步 Matrix 资产；它绝不下载、安装、修复或删除 Matt Skills。Matrix 更新完成后只读报告项目 Matt 兼容状态，必要时提示 `matrix init . --with-mattpocock`。npm 与项目资产是两个事务：若 CLI 已更新但资产同步失败，可运行 `matrix update --skip-self-update` 重试。
+`matrix update` 会保留既有安装的 scope、平台、语言、mode 与 orchestration。它先隔离验证 npm 新包，再由新 CLI 同步 Matrix 资产。当本地 Matt Skills 不完整或过期时，交互式 `matrix update` 会询问一次，并在同一轮把 Matt 修复到受支持 release——CLI 升级、资产刷新、Matt 修复一条命令完成（`--with-mattpocock` 为自动化/CI 提供等价的非交互行为；`--force-matt` 可额外替换被本地修改的 Matt Skills，且必须与 `--with-mattpocock` 同传；`matrix update` 绝不删除 Matt Skills）。`--all` 可将更新扩展到全部已索引项目（`~/.matrix/projects.json`），各项目隔离更新，失效目录自动从索引清理。npm 与项目资产是两个事务：若 CLI 已更新但资产同步失败，可运行 `matrix update --skip-self-update` 重试。Windows 上自升级链路经 Node 调用 npm（不经 shell），一条命令升级无需手动步骤。
 
-Matrix 0.1.5 固定对应 Matt Skills v1.2.3，commit 为 `6acc160e4e0cd062dbbbd7a1b26ae92855edf07e`。即使上游已有新版，`matrix init --with-mattpocock` 仍使用该确切 archive 与经过审查的 23 项兼容 manifest。官方角色中的 `implement` 与 raw `resolving-merge-conflicts` 不兼容，因此 Matrix 不安装也不管理它们。Matrix scope 只控制 Matrix Skill 的发现位置；Matt Skills 与 `.matrix/matt-installation.json` 始终属于目标项目。全局 Matt 副本会保留，但绝不用于补齐项目 readiness。
+Matrix 0.1.7 固定对应 Matt Skills v1.3.1，commit 为 `24fe0ef7737efae15c87225755e9f6f5965e4888`。即使上游已有新版，`matrix init --with-mattpocock` 仍使用该确切 archive 与经过审查的 25 项兼容 manifest。官方角色中的 `implement` 与 `implement-spec` 不兼容，因此 Matrix 不安装也不管理它们。Matrix scope 只控制 Matrix Skill 的发现位置；Matt Skills 与 `.matrix/matt-installation.json` 始终属于目标项目。全局 Matt 副本会保留，但绝不用于补齐项目 readiness。上游 v1.3.1 同时把域文档约定改名：Matt Skills 现在读取 `GLOSSARY.md`/`GLOSSARY-MAP.md`（原 `CONTEXT.md`/`CONTEXT-MAP.md`）；升级后请用 `git mv` 跟随改名。
+
+Matrix 只为拥有独立 skill 目录约定的 agent 内置平台条目：Claude Code（`.claude/skills`）、Codex（`.agents/skills`）与 ZCode（`.zcode/skills`）。安装 Codex 平台即同时覆盖所有默认读取 Agent Skills 开放标准 `.agents/skills` 目录的工具——opencode、Kimi Code 等兼容 agent 无需单独的 Matrix 平台条目即可使用 Matrix 与 Matt Skills。
 
 `matrix init` 选择的语言决定新 Matrix 产物的正文语言：`zh-CN` 使用中文、`en` 使用英文。Runtime 守卫依赖的 Markdown 英文标题 token 保持不变；每个 change 在创建时冻结该语言。
 
@@ -150,7 +152,7 @@ Matrix 将安装：
 - `matrix-hotfix/` — 小型 Bug 快捷方式
 - `matrix-tweak/` — 有界变更快捷方式
 - `matrix-status/` — 检查当前状态
-- `matrix-claude/` — 可选：导出供 Claude Code 使用
+- `matrix-handoff/` — 可选：导出给任意实现 agent（Claude Code、opencode 等）
 
 ---
 
@@ -252,28 +254,29 @@ hotfix 与 tweak 引用同一个内部 `lightweight` 迁移 profile，只在入
 
 ---
 
-## 特别功能：matrix-claude
+## 特别功能：matrix-handoff
 
-**默认用法**：直接使用主流程即可。无论你用 Codex 还是 Claude Code，标准流程都适用：
+**默认用法**：直接使用主流程即可。无论你用 Codex、Claude Code、zcode 还是 opencode，标准流程都适用：
 
 ```
 $matrix → open → design → build → verify → archive
 ```
 
-**何时使用 `$matrix-claude`**：仅当你想**跨工具拆分工作**时 —— 用 Codex 设计，然后交给 Claude Code 实现。
+**何时使用 `$matrix-handoff`**：仅当你想**跨工具拆分工作**时 —— 用一个 agent 设计，交给另一个 agent 实现。
 
 | 场景 | 操作 |
 |------|------|
 | 一个工具完成所有工作（默认） | 直接用 `$matrix`，无需额外步骤 |
-| Codex 设计 + Codex 实现 | 标准流程：design → build → verify |
-| Codex 设计 + Claude Code 实现 | design → build（批准 Contract）→ `$matrix-claude` → Claude Code → verify |
+| 同一 agent 设计 + 实现 | 标准流程：design → build → verify |
+| Codex 设计 + Claude Code 实现 | design → build（批准 Contract）→ `$matrix-handoff` → `export --agent claude-code` → Claude Code → verify |
+| zcode 设计 + opencode 实现 | design → build（批准 Contract）→ `$matrix-handoff` → `export --agent opencode` → opencode → verify |
 
-### matrix-claude 工作原理
+### matrix-handoff 工作原理
 
-1. 设计阶段完成，守卫通过
-2. 运行 `$matrix-claude` → 导出冻结的设计为 `artifacts/claude-task.md`
-3. Claude Code 读取任务包并实现
-4. Claude Code 在 `artifacts/verification.md` 中产生证据
+1. 设计阶段完成，守卫通过，并在 design→build 决策点选择实现 agent
+2. 运行 `$matrix-handoff` → 导出冻结 Contract 为 `artifacts/handoff-task-<task-id>.md`（`export --agent <agent-id>`；`--target generic` 为兼容的 Claude Code 旧形态，产出 `artifacts/claude-task.md`）
+3. 实现 agent 读取任务包并实现
+4. 实现 agent 在 `artifacts/verification.md` 中产生证据
 5. 返回 Matrix：构建守卫 → 验证 → 归档
 
 此 sidecar 不会改变 Matrix 状态。它只是纯粹的导出 —— 就像为另一个工具拍一张设计快照。
@@ -282,7 +285,7 @@ $matrix → open → design → build → verify → archive
 
 ## 与 Matt Pocock Skills 的集成
 
-Prim 使用 Matrix 自身能力。Matrix 会审查 Matt v1.2.3 官方 25 项角色，安装其中 23 项兼容 Skill，但 Arch 只自动调用以下十项经过审查的能力：
+Prim 使用 Matrix 自身能力。Matrix 会审查 Matt v1.3.1 官方 27 项角色，安装其中 25 项兼容 Skill，但 Arch 只自动调用以下十项经过审查的能力：
 
 | 阶段 | 能力 | 触发条件 |
 |---|---|---|
@@ -297,11 +300,11 @@ Prim 使用 Matrix 自身能力。Matrix 会审查 Matt v1.2.3 官方 25 项角
 | build | `/wizard` | Contract 需要生成人工执行的 shell 步骤；Matrix 不端到端运行 |
 | verify | `/code-review` | 需要 Standards 与 Spec 双轴证据 |
 
-Matrix 可以推荐但绝不嵌套以下 user-invoked handoff：`setup-matt-pocock-skills`、`improve-codebase-architecture`、`wayfinder`、`handoff`、`to-questionnaire`。它们由用户在活动阶段外显式运行，选中的结果可以再进入受治理 Change。
+Matrix 可以推荐但绝不嵌套以下 user-invoked handoff：`setup-matt-pocock-skills`、`improve-codebase-architecture`、`wayfinder`、`handoff`、`retro`、`to-questionnaire`。它们由用户在活动阶段外显式运行，选中的结果可以再进入受治理 Change。
 
 Arch 在 `code-review` 后记录由 Runtime 管理的审查回执，把 fixed point 与已提交的 HEAD diff 绑定到当前 Contract、审查正文和工作区。正常的 `code-review` 回执要求 Matrix 管理资产之外的候选工作区是干净的。无可用 Git 基线、已提交 diff 为空、仍存在 staged/unstaged/untracked 候选，或正确安装的 capability 真实失败时，Matrix 可为该 revision 执行一次明确标记的同能力 fallback；其中 `uncommitted-worktree` 会同时绑定 fixed point 与完整工作区候选的内容 hash。安装完整性失败不得 fallback。只有标题或自述、但没有匹配回执时，Verify 不能推进。
 
-安装但保持 standalone 的 Skill 是 `ask-matt`、`grill-with-docs`、`triage`、`to-spec`、`to-tickets`、`grill-me`、`teach`、`wait-what`。`implement` 与 raw `resolving-merge-conflicts` 可能接管 Matrix 所有的 TDD、review、stage 或 commit 副作用，因此 0.1.5 不安装也不管理它们；已有副本会被保留并报告为未管理额外项。安装不代表自动调用；任何 companion 都不得推进、提交、归档、恢复或写 Matrix 状态。
+安装但保持 standalone 的 Skill 是 `ask-matt`、`grill-with-docs`、`triage`、`to-spec`、`to-tickets`、`grill-me`、`teach`、`wait-what`、`pr`。`implement` 与 `implement-spec` 可能接管 Matrix 所有的 TDD、review、stage 或 commit 副作用，因此 0.1.7 不安装也不管理它们；已有副本（含遗留的 `resolving-merge-conflicts`）会被保留并报告为未管理额外项。安装不代表自动调用；任何 companion 都不得推进、提交、归档、恢复或写 Matrix 状态。
 
 ---
 

package/assets/skills/matrix/SKILL.md

@@ -33,7 +33,7 @@ An explicit mode wins; otherwise Runtime uses the project `default_orchestration
 ## Orchestration
 
 - **Prim** uses Matrix's own capability in every phase and never requires Matt Skills.
-- **Arch** conditionally invokes the ten reviewed automatic capabilities frozen by the active Change. Matrix 0.1.4 reviews all 25 official Matt Skills v1.2.3 roles and installs only the 23 compatible Skills project-locally; `implement` and raw `resolving-merge-conflicts` are excluded.
+- **Arch** conditionally invokes the ten reviewed automatic capabilities frozen by the active Change. Matrix 0.1.7 reviews all 27 official Matt Skills v1.3.1 roles and installs only the 25 compatible Skills project-locally; `implement` and `implement-spec` are excluded.
 
 Both orchestration modes use the same selected workflow profile. `full` uses `open → design → build → verify → archive`; `hotfix` and `tweak` share one internal `lightweight` profile, `open → build → verify → archive`, with different evidence policies. Companion Skills never write Matrix state, transition, commit, archive, or create competing workflow artifacts.
 
@@ -66,14 +66,14 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs doctor --repair --trans
 node <matrix-skill-directory>/scripts/matrix-runtime.mjs doctor --repair --lock <id>
 ```
 
-## Optional Claude handoff
+## Optional implementation handoff
 
-`$matrix-claude` is an optional sidecar command used after the approved Design -> Build transition. It exports the matching approved contract to a Claude Code task package. It never changes the Matrix phase, workflow, guard result, or runtime state.
-Use it only when the user explicitly chooses Codex design with Claude Code implementation; never inject it into the standard path.
+`$matrix-handoff` is an optional sidecar command used after the approved Design -> Build transition. It exports the matching approved contract as a bounded task package for the implementation agent the user chooses (`export --agent <agent-id>`, for example Codex designing and Claude Code implementing, or zcode designing and opencode implementing). It never changes the Matrix phase, workflow, guard result, or runtime state.
+Use it only when the user explicitly chooses a different implementation agent; never inject it into the standard path.
 
 ## Cross-Cutting Skills
 
-Matrix never nests user-invoked Matt Skills. When relevant, explain the reason and ask the user to invoke one explicitly: `setup-matt-pocock-skills` for one-time setup, `improve-codebase-architecture` for an out-of-band scan, `wayfinder` for generating a separate large-effort candidate, `handoff` at a context boundary, or `to-questionnaire` when another person owns blocking facts. `ask-matt`, `grill-with-docs`, `triage`, `to-spec`, `to-tickets`, `grill-me`, `teach`, and `wait-what` remain standalone. Matrix does not install or manage `implement` or raw `resolving-merge-conflicts`; preserve pre-existing copies as unmanaged extras and never suggest them inside an active Change.
+Matrix never nests user-invoked Matt Skills. When relevant, explain the reason and ask the user to invoke one explicitly: `setup-matt-pocock-skills` for one-time setup, `improve-codebase-architecture` for an out-of-band scan, `wayfinder` for generating a separate large-effort candidate, `handoff` at a context boundary, `retro` for a post-session agent-environment retrospective, or `to-questionnaire` when another person owns blocking facts. `ask-matt`, `grill-with-docs`, `triage`, `to-spec`, `to-tickets`, `grill-me`, `teach`, `wait-what`, and `pr` remain standalone. Matrix does not install or manage `implement` or `implement-spec`; preserve pre-existing copies (including any legacy `resolving-merge-conflicts`) as unmanaged extras and never suggest them inside an active Change.
 
 ## Rules
 
@@ -84,4 +84,5 @@ Matrix never nests user-invoked Matt Skills. When relevant, explain the reason a
 - `node <matrix-skill-directory>/scripts/matrix-runtime.mjs doctor` is read-only. Every transaction or stale-lock repair must explicitly bind the identity reported by doctor; do not edit or delete `.matrix/transactions/` or `.matrix/workflow.lock`.
 - Do not replace required evidence with an assertion that work is complete.
 - Pause for user confirmation at material architecture/scope decisions and before archive/commit.
+- Before entering Build (full: after the design guard; lightweight: merged into the `transition build --confirmed` pause), present the implementation-actor choice — continue with the current agent/model, switch the model in the user's client, or switch the implementation agent via `$matrix-handoff` — and record the decision with the Contract.
 - On shortcut scope expansion, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return design --reason design-gap`; Runtime upgrades the change to `full`. Never silently continue the old contract.

package/assets/skills/matrix-archive/SKILL.md

@@ -34,3 +34,5 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs return design --reason
 ```
 
 After successful commit, the change is under `.matrix/archive/` and the workflow is complete.
+
+Optionally, when the session produced findings worth keeping (repeated friction, missing guardrails, unclear pointers), recommend that the user run `retro` (a user-invoked Matt handoff) to turn them into agent-environment improvements. Recommend only; never invoke it inside the workflow.

package/assets/skills/matrix-build/SKILL.md

@@ -20,7 +20,7 @@ Use Matrix's own implementation and test discipline.
 - invoke `writing-for-agents` when the approved Contract changes agent-facing instructions;
 - invoke `wizard` only to generate and statically verify human-run shell steps required by the Contract; never execute the wizard end-to-end or collect secrets.
 
-Resolve an in-progress merge/rebase through Matrix-owned conflict handling. Do not invoke raw `resolving-merge-conflicts`, because it can stage, continue, and commit outside Matrix lifecycle ownership. Never invoke `implement` inside an active Change.
+Resolve an in-progress merge/rebase through Matrix-owned conflict handling; never hand lifecycle control to a legacy `resolving-merge-conflicts` copy or any skill that stages, continues, or commits on its own. Never invoke `implement` or `implement-spec` inside an active Change.
 
 Announce each triggered capability and reason. No companion may commit, review, transition, archive, or broaden scope. A correctly installed capability gets at most one Matrix-owned fallback for that same capability; record the Skill, failure, fallback, and evidence. Installation-integrity failure stops the phase.
 

package/assets/skills/matrix-design/SKILL.md

@@ -44,9 +44,9 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard design
 
 ## Implementation Decision Point
 
-After the design guard passes, the user chooses:
+After the design guard passes and before `transition build`, pause and present the implementation-actor choice to the user. Do not transition without an explicit choice:
 
-### Option A: Continue with Codex (default)
+### Option A: Continue with the current agent / model (default)
 
 Run transition and enter `$matrix-build`:
 
@@ -56,14 +56,18 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition build
 
 Then enter `$matrix-build` to implement directly in this session.
 
-### Option B: Use Claude Code for implementation
+### Option B: Switch the model, keep this agent
 
-First approve the frozen contract by transitioning to Build, then run `$matrix-claude` to export a bounded task package. This:
+The user switches the model in their own client (for example, a stronger model for design, an efficient one for implementation), returns to this session, and confirms. Then run transition exactly as in Option A. Matrix cannot see the client-side model; it provides the mandatory pause point only.
+
+### Option C: Switch the implementation agent
+
+First approve the frozen contract by transitioning to Build, then run `$matrix-handoff` to export a bounded task package for the chosen agent (for example Codex designs, Claude Code implements; or zcode designs, opencode implements). This:
 - Does not change the Build phase or state beyond the preceding transition
-- Creates `artifacts/claude-task.md` with all implementation details
+- Creates `artifacts/handoff-task-<task-id>.md` with all implementation details
 - Includes acceptance criteria, test seams, and required commands
 
-After Claude Code completes and returns results, run the Build guard and enter `$matrix-verify`:
+After the implementation agent completes and returns results, run the Build guard and enter `$matrix-verify`:
 
 ```powershell
 node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard build
@@ -71,3 +75,5 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition verify
 ```
 
 Then enter `$matrix-verify` to verify the implementation.
+
+Record the chosen option in `design.md` under `## Decisions` so it freezes with the Contract.

package/assets/skills/matrix-handoff/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: matrix-handoff
+description: Export an approved Matrix Contract as a bounded task package for any implementation agent (Claude Code, opencode, or another agent), without changing Matrix workflow state.
+---
+
+# Matrix Handoff (Implementation Handoff)
+
+This is an optional Matrix sidecar, not a Matrix phase. It must not call `transition`, `archive`, or write `matrix.yaml` or `events.jsonl`. It supports only a matching full or legacy-full three-artifact Contract; new lightweight hotfix/tweak changes are intentionally unsupported.
+
+Human-readable handoff text uses `artifact_language` from inspect; stable machine-readable headings and metadata keys remain unchanged.
+
+## When to Use
+
+Use `$matrix-handoff` when:
+
+- The active change is in Build and the Design -> Build transition has approved the contract
+- You want a different agent than the designing one to implement the frozen plan — for example Codex designs and Claude Code implements, or zcode designs and opencode implements
+- You need a bounded task package with all implementation details
+
+## Preconditions
+
+The exporter performs this read-only check before writing anything:
+
+```powershell
+node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard build
+```
+
+If `matrix` is genuinely absent from PATH, use the bundled runtime from the installed root Matrix Skill. Do not fall back when the primary command starts and returns an error.
+
+If the build guard reports `CONTRACT_CHANGED` or `CONTRACT_UNAPPROVED`, return to `$matrix-design` and approve a new contract through Build. The exporter reads the approved bytes of `proposal.md`, `design.md`, and `plan.md`; it does not invent missing facts.
+
+## Export
+
+The user chooses the implementation agent explicitly. Pass it with `--agent <agent-id>` (kebab-case); optionally name the designing agent with `--from <agent-id>`.
+
+```powershell
+# Generic agent handoff: writes artifacts/handoff-task-<ID>.md
+node <matrix-skill-directory>/scripts/matrix-runtime.mjs export --task-id <ID> --agent opencode
+node <matrix-skill-directory>/scripts/matrix-runtime.mjs export --task-id <ID> --agent claude-code --from codex
+
+# Legacy compatibility form (Claude Code): writes artifacts/claude-task.md
+node <matrix-skill-directory>/scripts/matrix-runtime.mjs export --task-id <ID> --target generic
+
+# FnSec: exports its formal task package. Add --apply-fnsec-board only when
+# active.md is NO_ACTIVE_OBJECTIVE; an existing task is never overwritten.
+node <matrix-skill-directory>/scripts/matrix-runtime.mjs export --task-id <ID> --target fnsec --apply-fnsec-board
+```
+
+`--agent` and `--target` are mutually exclusive. Prefer `--agent` for new handoffs; `--target generic` remains for compatibility.
+
+## Task Package Contents
+
+The exported package (`artifacts/handoff-task-<task-id>.md`) metadata records `Implementation actor` (the `--agent` value) and `Decision owner` (the `--from` value, or "Matrix change owner"), plus the approved contract hash and revision and the same frozen snapshot of proposal, design, and plan. Objective, allowed work, prohibited work, and stop conditions travel unchanged — they are agent-independent.
+
+## After the Implementation Agent Completes
+
+Verify that the following evidence is present before proceeding to `$matrix-verify`:
+
+- [ ] `artifacts/verification.md` exists with a `## Build evidence` section
+- [ ] Build evidence includes concrete commands and outcomes
+- [ ] All tests in the plan's validation section have been run
+- [ ] Any `NEEDS_DECISION` items have been resolved or documented
+
+If evidence is missing, ask the implementation agent to complete it before proceeding.
+
+## Resuming Matrix Workflow
+
+After the implementation agent completes and evidence is present:
+
+1. Run build guard to verify evidence:
+   ```powershell
+   node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard build
+   ```
+
+2. If guard passes, transition to verify:
+   ```powershell
+   node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition verify
+   ```
+
+3. Enter `$matrix-verify` to continue the verification flow
+
+If the build guard fails, return to the implementation agent to complete missing evidence.
+
+## Important Notes
+
+- This sidecar does NOT change Matrix phase, workflow, or guard result
+- The Matrix state remains in `build` phase; export itself does not advance it
+- The implementation agent must produce evidence that satisfies the build guard conditions
+- After successful transition to verify, the normal verify flow continues

package/assets/skills/matrix-handoff/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Matrix Implementation Handoff"
+  short_description: "Export an approved Matrix Contract as a bounded task package"
+  default_prompt: "Use $matrix-handoff to export the approved Contract to an implementation agent."

package/assets/skills/matrix-open/SKILL.md

@@ -16,11 +16,22 @@ Use its `artifact_language` for all proposal prose. Keep the required English he
 
 ## Prim
 
-Use Matrix's own capability to clarify the request and write the proposal.
+Use Matrix's own capability to run a structured clarification (goal, scope, non-goals, acceptance, risks, constraints) and write the proposal.
 
 ## Arch
 
-Invoke `grilling` only when material ambiguity remains or the user asks to stress-test the request. Invoke `domain-modeling` only when domain vocabulary, invariants, or an architectural decision is unclear. Announce the capability and reason before invoking it; selecting Arch already authorizes triggered capabilities.
+Announce the capability and reason, then invoke `grilling` by default at the start of Open to clarify the request. Invoke `domain-modeling` only when domain vocabulary, invariants, or an architectural decision is unclear. Selecting Arch already authorizes triggered capabilities.
+
+**Clarification exemption**: skip the clarification pass only when the user both (1) arrives with a clear execution plan and (2) explicitly states that no clarification is needed. Even then, write the exemption record into `clarification.md`.
+
+## Clarification artifact (mandatory)
+
+Before writing the proposal, produce `<change>/clarification.md` — on every path, clarification or exemption:
+
+- Clarified: `## Questions` / `## Answers` / `## Resolved scope` (English heading tokens fixed; body in `artifact_language`).
+- Exempted: `## Exemption record` (exemption reason + the user's plan highlights + how the proposal adopts it).
+
+lightweight (hotfix/tweak) applies too, with a single round of core questions. The file is Open-phase evidence: it does not participate in Contract identity and the Runtime does not check for it; changes left in open by 0.1.5 or earlier proceed without backfilling it.
 
 If progress is blocked by facts or decisions owned by another person, explain why `to-questionnaire` fits and ask the user to invoke it. Do not invoke the wrapper yourself.
 

package/assets/skills/matrix-verify/SKILL.md

@@ -13,8 +13,8 @@ Write verification prose in `artifact_language` from inspect while preserving th
 
 This phase can receive implementation from two sources:
 
-1. **Direct Codex implementation** — from `$matrix-build` phase
-2. **Claude Code implementation** — from `$matrix-claude` sidecar
+1. **Direct implementation** — from the `$matrix-build` phase in this session
+2. **Handed-off implementation** — from a `$matrix-handoff` task package executed by another implementation agent
 
 Regardless of source, the verification process is the same: check that implementation evidence meets the plan's requirements.
 
@@ -27,7 +27,7 @@ Before starting verification, ensure:
 - [ ] All commands from the plan's `## Validation` section have been run
 - [ ] Test results are recorded
 
-If these are missing (e.g., Claude Code didn't produce complete evidence), return to `$matrix-build` or ask Claude Code to补充.
+If these are missing (for example, a handed-off agent did not produce complete evidence), return to `$matrix-build` or ask the implementation agent to fill in the missing evidence.
 
 ## Orchestration
 
@@ -55,7 +55,7 @@ Never label fallback output as a successful `code-review` run. `empty-head-diff`
 ## Failure Handling
 
 If verification or review fails:
-- If the issue is in the implementation, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return build --reason verification-failed`, then enter `$matrix-build` or ask Claude Code to fix.
+- If the issue is in the implementation, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return build --reason verification-failed`, then enter `$matrix-build` or ask the implementation agent to fix it.
 - If the issue is in the acceptance criteria or design, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return design --reason acceptance-or-design-gap`, then enter `$matrix-design`.
 
 Both Return paths rotate the current `verification.md` and any `review-receipt.json` into revisioned evidence history. Do not copy stale conclusions or receipts back into the new current evidence.