opencode-dispatcher 0.2.0 → 0.2.2

package/README.md

@@ -1,79 +1,357 @@
 # OpenCode Dispatcher
 
-## Table of Contents
-
-- [Table of Contents](#table-of-contents)
-- [What It Does](#what-it-does)
-- [Install](#install)
-- [First use in a project](#first-use-in-a-project)
-- [What gets installed](#what-gets-installed)
-- [Install safety](#install-safety)
-- [Restore or uninstall](#restore-or-uninstall)
-- [Package commands](#package-commands)
-- [Publication status](#publication-status)
-- [Limitations](#limitations)
-
-OpenCode Dispatcher is a workflow pack for OpenCode. It installs specialist agents so substantial coding work can run from explicit task specs instead of long chat history.
-
-It is useful when you want agent work to be easier to inspect, resume, and validate:
-
-- task scope in `.ai/tasks/<NNN>-<task-id>/task-spec.md`
-- durable project facts in `.ai/context.md`
-- role boundaries between planning, test writing, implementation, documentation, validation, research, and shipping work
-- short handoffs in chat, with details kept in task artifacts
-- validation reports checked against the approved scope
-
-For tiny one-off edits, plain OpenCode is often enough.
-
-## What It Does
-
-OpenCode Dispatcher replaces OpenCode's default single-agent approach with a team of specialist agents coordinated through file-based artifacts. Each agent has a defined role and boundary. The orchestrator routes work, delegates to the right agent, and synthesizes results back to you.
-
-All task state lives in `.ai/tasks/<NNN>-<task-id>/` artifacts — task specs, implementation reports, validation reports, documentation reports — rather than in chat history.
-
-| Agent | Role | When |
-|---|---|---|
-| Orchestrator | User-facing coordinator; state-machine routing | Always active |
-| Task Planner | Task specs and multi-unit decomposition | Used before implementation |
-| Test Writer | Writes tests from testable acceptance criteria | Used before implementation (test-driven) |
-| Implementer | Edits source code per approved task spec | Used after spec is approved |
-| Validator | Checks results against task spec and writes `validation-report.md` | Used after implementation |
-| Documentation | Updates docs, context, decision artifacts | Used when docs are needed |
-| Research | Gathers external facts, comparisons, best practices | Used when facts are needed |
-| Shipper | Git commit and push only | Used when explicitly requested |
-| Executor | Tiny single-file atomic edits | Used for unambiguous one-liners |
-| Init | Bootstraps `.ai/context.md` on first project use | Used once per project |
+OpenCode Dispatcher is a workflow pack for OpenCode that adds specialist development agents coordinated through file-based task artifacts.
+
+It is designed for substantial coding work where you want the agent workflow to be easier to inspect, resume, and validate.
+
+Instead of relying on long chat history, Dispatcher keeps durable task state in your project:
+
+```text
+.ai/context.md
+.ai/tasks/<NNN>-<task-id>/task-spec.md
+.ai/tasks/<NNN>-<task-id>/implementation-report.md
+.ai/tasks/<NNN>-<task-id>/validation-report.md
+.ai/tasks/<NNN>-<task-id>/documentation-report.md
+```
+
+For tiny one-off edits or quick questions, plain OpenCode is often enough.
+
+## What Dispatcher Changes
+
+Plain OpenCode is usually a general-purpose agent workflow.
+
+OpenCode Dispatcher adds a user-facing orchestrator and a set of specialist agents. The orchestrator talks with you, clarifies the request, decides how complex the work is, and routes to the smallest safe workflow.
+
+Not every agent runs every time.
+
+```mermaid
+flowchart TD
+    User[User] --> Orchestrator[Orchestrator]
+
+    Orchestrator -->|Question or review| Direct[Direct answer]
+    Orchestrator -->|Tiny exact edit| Executor[Executor]
+    Orchestrator -->|Substantial task| Planner[Task Planner]
+    Orchestrator -->|External facts needed| Research[Research]
+    Orchestrator -->|Commit or push requested| Shipper[Shipper]
+
+    Research --> Orchestrator
+    Executor --> Orchestrator
+
+    Planner --> Spec[Task Spec]
+    Spec --> TestWriter{Test-first useful?}
+    TestWriter -->|Yes| Tests[Test Writer]
+    TestWriter -->|No| Implementer[Implementer]
+    Tests --> Implementer
+    Implementer --> Validator[Validator]
+    Validator --> Orchestrator
+
+    Shipper --> Orchestrator
+```
+
+The chat is used for coordination. The `.ai/` files become the source of truth for scoped work.
+
+## Why Use It?
+
+Dispatcher is useful when you want agent work to be:
+
+* easier to inspect
+* easier to resume later
+* easier to validate against an approved scope
+* less dependent on chat history
+* separated by role boundaries
+* safer for multi-step development work
+* more suitable for git-tracked project artifacts
+
+It helps answer questions like:
+
+* What exactly was the agent asked to build?
+* What files were relevant?
+* What was explicitly out of scope?
+* What tests or checks were expected?
+* What did the implementer change?
+* Did the validator check the result against the approved task?
+
+## Compared to Plain OpenCode
+
+| Dimension    | Plain OpenCode                    | OpenCode Dispatcher                           |
+| ------------ | --------------------------------- | --------------------------------------------- |
+| Task scope   | Usually carried in chat history   | Stored in `.ai/tasks/<NNN>-<id>/task-spec.md` |
+| Agent model  | General-purpose agent             | Specialist agents with role boundaries        |
+| Validation   | Often implicit                    | Explicit validation against the task spec     |
+| Resumability | Requires reading chat history     | Read the task spec and reports                |
+| Audit trail  | Chat log                          | Git-trackable `.ai/` artifacts                |
+| Best for     | Quick edits and one-off questions | Substantial features and multi-step work      |
+
+## Core Idea
+
+Dispatcher separates live conversation from durable project state.
 
 ```mermaid
-graph TD
-    U[User] -->|request| O[Orchestrator]
-    O -->|atomic edit| EX[Executor]
-    O -->|needs facts| R[Research]
-    O -->|plan| TP[Task Planner]
-    TP -->|task-spec.md| O
-    O -->|has testable criteria| TW[Test Writer]
-    TW -->|tests| O
-    O -->|approved| I[Implementer]
-    I -->|implementation-report.md| V[Validator]
-    V -->|validation-report.md| O
-    O -->|needs docs| D[Documentation]
-    O -->|commit/push| SH[Shipper]
-    O -->|first use| IN[Init]
-    O -->|result| U
-```
-
-Compared to plain OpenCode:
-
-| Dimension | Plain OpenCode | OpenCode Dispatcher |
-|---|---|---|
-| Task scope | Chat history | File-based `.ai/tasks/<NNN>-<id>/task-spec.md` |
-| Agent model | Single agent | Specialist agents with role boundaries |
-| Validation | Implicit (trust the output) | Explicit (validator checks against spec) |
-| Resumability | Scroll chat history | Read task spec + validation report |
-| Audit trail | Chat log | Git-tracked artifacts |
-| Best for | Quick edits, one-off questions | Substantial features, multi-step work |
-
-## Install
+flowchart LR
+    Chat[Live chat] -->|Clarify and coordinate| Orchestrator[Orchestrator]
+    Orchestrator -->|Writes durable scope through agents| Artifacts[.ai task artifacts]
+    Artifacts --> Spec[task-spec.md]
+    Artifacts --> Reports[implementation / validation / documentation reports]
+    Artifacts --> Context[context.md]
+```
+
+The orchestrator stays user-facing. Specialist agents do the scoped work.
+
+## Workflow Layers
+
+Dispatcher installs several agents, but they are grouped by when they are used.
+
+### Always Active
+
+| Agent        | Role                                             | Used When     |
+| ------------ | ------------------------------------------------ | ------------- |
+| Orchestrator | User-facing coordinator and state-machine router | Always active |
+
+The orchestrator is the main entry point. It talks with you, clarifies the request, decides whether work is simple or substantial, delegates to the right specialist, and summarizes results.
+
+### Fast Path
+
+| Agent    | Role                                   | Used When                               |
+| -------- | -------------------------------------- | --------------------------------------- |
+| Executor | Performs tiny single-file atomic edits | For exact, unambiguous one-file changes |
+
+The executor is used when a full task spec would be unnecessary.
+
+Example:
+
+```text
+Change the button label in src/components/SubmitButton.tsx from "Submit" to "Save".
+```
+
+If the edit turns out to need multiple files, a new pattern, a dependency, or an architecture decision, the orchestrator escalates the work into the full task workflow.
+
+### Full Task Workflow
+
+| Agent        | Role                                                 | Used When                         |
+| ------------ | ---------------------------------------------------- | --------------------------------- |
+| Task Planner | Creates task specs and decomposes multi-unit work    | Before substantial implementation |
+| Implementer  | Edits source code according to an approved task spec | After planning                    |
+| Validator    | Checks completed work against the task spec          | After non-trivial implementation  |
+
+This is the main route for substantial development work.
+
+```mermaid
+sequenceDiagram
+    participant U as User
+    participant O as Orchestrator
+    participant P as Task Planner
+    participant I as Implementer
+    participant V as Validator
+
+    U->>O: Describe feature or fix
+    O->>U: Clarify scope if needed
+    O->>P: Create task spec
+    P-->>O: task-spec.md
+    O->>I: Implement approved spec
+    I-->>O: implementation-report.md
+    O->>V: Validate against task spec
+    V-->>O: validation-report.md
+    O-->>U: Summary and next step
+```
+
+The task planner creates the approved scope:
+
+```text
+.ai/tasks/<NNN>-<task-id>/task-spec.md
+```
+
+The implementer makes the smallest correct change according to that scope.
+
+The validator checks the completed work against the approved scope and writes:
+
+```text
+.ai/tasks/<NNN>-<task-id>/validation-report.md
+```
+
+### Conditional Agents
+
+| Agent         | Role                                                        | Used When                             |
+| ------------- | ----------------------------------------------------------- | ------------------------------------- |
+| Test Writer   | Writes tests from testable acceptance criteria              | When a test-first flow is useful      |
+| Documentation | Updates docs, context, decisions, and documentation reports | When documentation work is needed     |
+| Research      | Gathers external facts, comparisons, and best practices     | When source-backed evidence is needed |
+
+These agents are not part of every task.
+
+The test writer is used when the task has clear testable acceptance criteria and writing tests first would improve correctness.
+
+The documentation agent is used when the task needs README updates, project context updates, decision notes, changelog entries, or documentation reports.
+
+The research agent is used when a decision depends on external facts such as official documentation, vendor behaviour, pricing, APIs, or current best practices.
+
+### Bootstrap and Shipping
+
+| Agent   | Role                             | Used When                 |
+| ------- | -------------------------------- | ------------------------- |
+| Init    | Bootstraps `.ai/context.md`      | First use in a project    |
+| Shipper | Handles git commit and push only | When explicitly requested |
+
+The init agent is used when a project does not yet have `.ai/context.md`.
+
+The shipper is never used automatically. It only commits or pushes when you explicitly ask for git shipping work.
+
+## Common Routes
+
+### Ask a Question
+
+```mermaid
+flowchart LR
+    User --> Orchestrator --> Answer[Direct answer]
+```
+
+Used for explanations, reviews, comparisons, and planning advice.
+
+### Tiny Edit
+
+```mermaid
+flowchart LR
+    User --> Orchestrator --> Executor --> Orchestrator --> Summary[Summary]
+```
+
+Used for exact, single-file changes.
+
+### Substantial Feature or Fix
+
+```mermaid
+flowchart LR
+    User --> Orchestrator --> Planner[Task Planner]
+    Planner --> Spec[task-spec.md]
+    Spec --> Implementer
+    Implementer --> Report[implementation-report.md]
+    Report --> Validator
+    Validator --> Validation[validation-report.md]
+    Validation --> Orchestrator --> Summary[Summary]
+```
+
+Used for substantial implementation work with task artifacts and validation.
+
+### Test-First Feature
+
+```mermaid
+flowchart LR
+    User --> Orchestrator --> Planner[Task Planner]
+    Planner --> Spec[task-spec.md]
+    Spec --> TestWriter[Test Writer]
+    TestWriter --> Tests[Test files]
+    Tests --> Implementer
+    Implementer --> Validator
+    Validator --> Orchestrator --> Summary[Summary]
+```
+
+Used when acceptance criteria can be encoded as tests before implementation.
+
+### Research-Backed Change
+
+```mermaid
+flowchart LR
+    User --> Orchestrator --> Research
+    Research --> Findings[Findings and recommendation]
+    Findings --> Orchestrator
+    Orchestrator --> Planner[Task Planner]
+    Planner --> Implementer
+    Implementer --> Validator
+    Validator --> Orchestrator --> Summary[Summary]
+```
+
+Used when implementation depends on external facts or source-backed technical decisions.
+
+### Documentation Task
+
+```mermaid
+flowchart LR
+    User --> Orchestrator --> Planner[Task Planner]
+    Planner --> Documentation
+    Documentation --> DocReport[documentation-report.md]
+    DocReport --> Validator
+    Validator --> Orchestrator --> Summary[Summary]
+```
+
+Used for substantial documentation work that should be scoped and validated.
+
+### Commit or Push
+
+```mermaid
+flowchart LR
+    User --> Orchestrator --> Shipper --> Orchestrator --> Summary[Summary]
+```
+
+Used only when explicitly requested.
+
+## Project Artifacts
+
+Dispatcher stores durable project and task state under `.ai/`.
+
+### Project Context
+
+```text
+.ai/context.md
+```
+
+Stores durable project facts such as:
+
+* test framework
+* test runner command
+* test file patterns
+* UI framework
+* styling conventions
+* naming conventions
+* file layout
+* project-specific rules
+* stable decisions
+
+### Task Scope
+
+```text
+.ai/tasks/<NNN>-<task-id>/task-spec.md
+```
+
+Stores the approved task scope, including:
+
+* scope
+* non-goals
+* testable acceptance criteria
+* inspectable acceptance criteria
+* relevant files
+* validation plan
+
+### Task Reports
+
+```text
+.ai/tasks/<NNN>-<task-id>/implementation-report.md
+.ai/tasks/<NNN>-<task-id>/validation-report.md
+.ai/tasks/<NNN>-<task-id>/documentation-report.md
+```
+
+Reports capture what changed, what was verified, and what remains open.
+
+## First Use in a Project
+
+1. Install Dispatcher.
+2. Restart OpenCode.
+3. Open your project in OpenCode.
+4. If the project does not already have `.ai/context.md`, the orchestrator will initialize project context before substantial work.
+5. For substantial work, ask the orchestrator to create a task spec first.
+6. Review or approve the task spec.
+7. Ask the orchestrator to implement and validate the approved task.
+
+Example:
+
+```text
+Create a task spec for improving the settings page, then wait for approval.
+```
+
+After approving the spec:
+
+```text
+Implement the approved task spec at .ai/tasks/001-settings-page/task-spec.md and run validation.
+```
+
+## Installation
 
 Install from the npm registry:
 
@@ -81,9 +359,13 @@ Install from the npm registry:
 npx opencode-dispatcher install
 ```
 
-After installing, restart OpenCode so it reloads `~/.config/opencode`.
+After installing, restart OpenCode so it reloads your global configuration from:
 
-### Install from source
+```text
+~/.config/opencode
+```
+
+## Install from Source
 
 ```bash
 npm run check
@@ -103,43 +385,62 @@ The default installer command is `install`, so this is also valid:
 node ./bin/install.js
 ```
 
-## First use in a project
-
-1. Run the install command.
-2. Restart OpenCode so it reloads `~/.config/opencode`, then open the project.
-3. If the project does not already have `.ai/context.md`, the orchestrator initializes `.ai/` before substantial work.
-4. For substantial work, ask for a task spec first. Example: `Create a task spec for improving the settings page, then wait for approval.`
-5. After approving the task spec, ask the orchestrator to implement and validate it. Example: `Implement the approved task spec at .ai/tasks/001-settings-page/task-spec.md and run validation.`
-
-The workflow treats live chat as coordination. Durable details belong in `.ai/context.md`, `.ai/tasks/<NNN>-<task-id>/task-spec.md`, and task reports such as `implementation-report.md`, `documentation-report.md`, and `validation-report.md`.
+## What Gets Installed
 
-## What gets installed
-
-The installer copies this managed payload into `~/.config/opencode`:
+The installer copies Dispatcher's managed payload into:
 
 ```text
 ~/.config/opencode/agents/
 ```
 
-Current package payloads include:
+Current payloads include agents for:
+
+* orchestration
+* initialization
+* task planning
+* test writing
+* implementation
+* documentation
+* validation
+* research
+* shipping
+* tiny atomic edits
 
-- agents for orchestration, planning, test writing, implementation, documentation, validation, research, and shipping
+The installer does **not** install or manage:
 
-The installer does not install or manage provider config, model settings, secrets, dependencies, git config, `opencode.jsonc`, `node_modules`, global skills, or templates.
+* provider configuration
+* model settings
+* secrets
+* project dependencies
+* git configuration
+* `opencode.jsonc`
+* `node_modules`
+* global skills
+* project templates
 
-## Install safety
+## Install Safety
 
-Before copying a managed path, the installer backs up any existing path beside it with a timestamped `.bak-*` suffix, then copies the Dispatcher payload into that path. It does not remove existing directories first, so same-named files may be overwritten and unrelated pre-existing files may remain.
+Before copying a managed path, the installer backs up any existing path beside it using a timestamped `.bak-*` suffix.
 
-Example backup names:
+Example backup:
 
 ```text
 ~/.config/opencode/agents.bak-2026-06-07T12-34-56-789Z
 ```
 
-Your global `~/.config/opencode/AGENTS.md` is user-owned. OpenCode Dispatcher does not install, overwrite, back up, restore, remove, or rename it.
+The installer then overlays the Dispatcher payload into the managed path.
+
+This means:
+
+* same-named files may be overwritten
+* unrelated pre-existing files may remain
+* backups are kept beside the managed path
+
+Your global `~/.config/opencode/AGENTS.md` is user-owned.
+
+OpenCode Dispatcher does not install, overwrite, back up, restore, remove, or rename it.
 
-## Restore or uninstall
+## Restore or Uninstall
 
 To restore a backed-up managed path:
 
@@ -148,16 +449,18 @@ To restore a backed-up managed path:
 3. Move the matching `.bak-*` path back to its original name.
 4. Restart OpenCode.
 
-Example for agents:
+Example:
 
 ```bash
 mv ~/.config/opencode/agents ~/.config/opencode/agents.dispatcher
 mv ~/.config/opencode/agents.bak-<timestamp> ~/.config/opencode/agents
 ```
 
-To uninstall Dispatcher, restore your backups if you had pre-existing global agents. Only remove managed paths outright if you do not need any current contents, including files that may have existed before install.
+To uninstall Dispatcher, restore your backups if you had pre-existing global agents.
 
-## Package commands
+Only remove managed paths outright if you do not need any current contents, including files that may have existed before Dispatcher was installed.
+
+## Package Commands
 
 From `package.json`:
 
@@ -166,7 +469,7 @@ npm run check          # node ./bin/install.js check
 npm run install:local  # node ./bin/install.js install
 ```
 
-The package also defines this binary when installed as an npm package:
+When installed as an npm package, Dispatcher provides this binary:
 
 ```bash
 opencode-dispatcher [install|check]
@@ -174,9 +477,15 @@ opencode-dispatcher [install|check]
 
 Invalid commands print usage and exit with a non-zero status.
 
-## Publication status
+## Publication Status
+
+This package is published on the npm registry as:
+
+```text
+opencode-dispatcher
+```
 
-This package is published on the npm registry as [`opencode-dispatcher`](https://www.npmjs.com/package/opencode-dispatcher). Install from any project:
+Install it from any project with:
 
 ```bash
 npx opencode-dispatcher install
@@ -184,7 +493,21 @@ npx opencode-dispatcher install
 
 ## Limitations
 
-- Managed global `agents` paths are backed up, then overlaid with Dispatcher files; unrelated pre-existing files may remain.
-- Restart OpenCode after install, restore, or uninstall so global config is reloaded.
-- Providers, models, secrets, project dependencies, and git remotes are not configured by this package.
-- The workflow is designed for substantial tasks with scope, artifacts, and validation; it may be unnecessary overhead for tiny edits.
+* Managed global agent paths are backed up, then overlaid with Dispatcher files.
+* Unrelated pre-existing files in managed directories may remain.
+* OpenCode must be restarted after install, restore, or uninstall so global config is reloaded.
+* Providers, models, secrets, project dependencies, and git remotes are not configured by this package.
+* Dispatcher is designed for substantial tasks with scope, artifacts, and validation.
+* Dispatcher may be unnecessary overhead for tiny edits, quick questions, or exploratory coding.
+
+## When Not to Use Dispatcher
+
+Dispatcher is probably unnecessary when you only need:
+
+* a quick explanation
+* a tiny one-off edit
+* exploratory prototyping
+* casual code suggestions
+* work where formal task artifacts would slow you down
+
+Use Dispatcher when the structure is worth it. Use the fast path or plain OpenCode when it is not.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-dispatcher",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "description": "A low-context OpenCode dispatcher workflow with orchestrator agents and task artifacts.",
   "type": "module",
   "bin": {

package/workflow/agents/documentation.md

@@ -29,7 +29,7 @@ Responsibilities:
 - Update `.ai/context.md` when delegated. Do not create `.ai/context.md` from scratch — that is owned by the init agent. Write decision notes and documentation updates from approved task specs or explicit orchestrator delegation.
 - Read existing docs, `.ai/context.md`, task specs, and relevant source files before writing.
 - Write decision notes under `.ai/decisions/` for stable, non-obvious decisions when delegated.
-- Write `.ai/tasks/<task-id>/documentation-report.md` with sections: Outcome, Files Changed, Context Or Decisions Updated, Verification. Include Follow-Ups only if there are any.
+- Write `.ai/tasks/<NNN>-<task-id>/documentation-report.md` with sections: Outcome, Files Changed, Context Or Decisions Updated, Verification. Include Follow-Ups only if there are any.
 - Keep docs concise, accurate, and grounded in source files or approved decisions.
 
 Boundaries:

package/workflow/agents/executor.md

@@ -3,11 +3,11 @@ description: Executes simple single-file atomic edits that do not need a task sp
 mode: subagent
 hidden: true
 permission:
+  bash:
+    "*": allow
   edit:
     "*": allow
     ".ai/**": deny
-  bash: "*": allow
-  task: "*": deny
 ---
 
 You are the Executor Agent.

package/workflow/agents/implementer.md

@@ -15,7 +15,7 @@ permission:
 
 You are the Implementer Agent.
 
-Own implementation only after the task is specified and approved in `.ai/tasks/<task-id>/task-spec.md`. You are a custom implementation subagent used by orchestrator.
+Own implementation only after the task is specified and approved in `.ai/tasks/<NNN>-<task-id>/task-spec.md`. You are a custom implementation subagent used by orchestrator.
 
 Responsibilities:
 
@@ -24,7 +24,7 @@ Responsibilities:
 - Make the smallest correct change that satisfies the task spec.
 - Preserve unrelated user changes.
 - Run the smallest relevant verification when practical.
-- Write `.ai/tasks/<task-id>/implementation-report.md` with sections: Outcome, Files Changed, Decisions, Verification. Include Known Issues only if there are any.
+- Write `.ai/tasks/<NNN>-<task-id>/implementation-report.md` with sections: Outcome, Files Changed, Decisions, Verification. Include Known Issues only if there are any.
 - Run the project's test suite (using the test runner from `.ai/context.md`). Confirm that the task-specific tests pass. If pre-existing baseline tests fail, note them as Known Issues but do not chase them.
 
 Boundaries:

package/workflow/agents/model-config.md

@@ -0,0 +1,42 @@
+---
+description: Configures per-agent model assignments in project opencode config
+mode: subagent
+hidden: true
+permission:
+  bash:
+    "*": allow
+  edit:
+    "*": deny
+    "opencode.jsonc": allow
+    ".opencode/opencode.jsonc": allow
+  task:
+    "*": deny
+---
+
+You are the Model-Config Agent.
+
+Own per-agent model assignment in the project's opencode config. When delegated by the orchestrator, configure which model each installed Dispatcher agent uses by writing `agent.<name>.model` entries into `opencode.jsonc` or `.opencode/opencode.jsonc`.
+
+Responsibilities:
+
+- Run `opencode models` to list available models on the system.
+- Check for an existing opencode config at `opencode.jsonc` or `.opencode/opencode.jsonc` (in that order of preference).
+- Present the user with the list of installed Dispatcher agents and ask which agents they want to configure.
+- For each selected agent, ask which model to assign (from the available models list).
+- Write `agent.<name>.model` entries into the project's opencode config, preserving all existing config content exactly as-is.
+- If no opencode config exists, create one with only the `agent.<name>.model` entries.
+- Report back to the orchestrator with a summary of what was configured.
+
+Boundaries:
+
+- Do not edit any files other than the project's opencode config (`opencode.jsonc` or `.opencode/opencode.jsonc`).
+- Do not delegate to other agents (no `task` permission).
+- Do not modify code, tests, documentation, `.ai/` artifacts, or other agent definitions.
+
+Default report back:
+
+- Path of the config file edited (or created).
+- List of agents configured and their assigned models.
+- Any issues encountered (e.g., config conflicts, missing models).
+
+(End of file - total 37 lines)

package/workflow/agents/orchestrator.md

@@ -13,6 +13,7 @@ permission:
     shipper: allow
     test-writer: allow
     init: allow
+    model-config: allow
     executor: allow
 ---
 
@@ -26,7 +27,7 @@ Artifact source-of-truth rules:
 
 - Do not rely on chat-only artifacts for substantial work.
 - Project `.ai/context.md` captures durable project truth: shared language, architecture facts, conventions, constraints, and stable decisions.
-- `.ai/tasks/<task-id>/task-spec.md` captures task truth: approved scope, acceptance criteria, constraints, relevant files, and validation plan.
+- `.ai/tasks/<NNN>-<task-id>/task-spec.md` captures task truth: approved scope, acceptance criteria, constraints, relevant files, and validation plan.
 - Task reports live beside the task spec: `implementation-report.md`, `documentation-report.md`, and `validation-report.md`.
 
 Project initialization:
@@ -80,6 +81,7 @@ Choose the smallest safe path:
 - Use research when current facts, external docs, pricing, vendor behaviour, or source-backed confidence matter.
 - Use task-planner when the work is multi-file, behaviour-changing, risky, unclear, or needs acceptance criteria.
 - Use shipper only when the user explicitly asks to commit or push.
+- Use model-config when the user wants to configure per-agent models for this project.
 
 ### DELEGATE
 
@@ -90,6 +92,7 @@ Delegate to the specialist that owns the next action.
 - task-planner: task specs and decomposition
 - test-writer: tests from approved specs
 - implementer: scoped source changes
+- model-config: per-agent model assignment in opencode config
 - documentation: docs/context/decision updates
 - validator: validation against task specs
 - shipper: commit/push only

package/workflow/agents/shipper.md

@@ -50,7 +50,7 @@ Required pre-commit inspection:
 - Before any commit, inspect `git status`, `git diff`, and `git log --oneline -10`.
 - Review staged and unstaged changes before committing.
 - Stage only intended files.
-- When committing task-scoped work, include the matching `.ai/tasks/<task-id>/` artifacts in the same commit as the code, tests, docs, or config they describe.
+- When committing task-scoped work, include the matching `.ai/tasks/<NNN>-<task-id>/` artifacts in the same commit as the code, tests, docs, or config they describe.
 - If multiple task artifact folders exist, include only the folders that match the current commit scope unless the user explicitly asks to commit everything.
 - Do not use `git commit -a` or `git commit -am`; explicitly stage intended files before committing.
 - Never include secrets, credentials, generated artifacts, or unrelated changes.

package/workflow/agents/task-planner.md

@@ -12,6 +12,8 @@ permission:
 
 You are the Task Planner Agent.
 
+- Mandatory: every task directory MUST use the `<NNN>-<task-id>` naming convention. `<NNN>` is the next available zero-padded number (001, 002, …) found by scanning existing `.ai/tasks/` directories.
+
 Own task specification and decomposition, not implementation. Create or update auditable task artifacts under project `.ai/tasks/` after orchestrator has clarified the user request enough to plan safely. For complex multi-part work, decompose into independent units before writing individual task specs.
 
 On every invocation, assess whether the work is a single-unit task or a multi-unit task:
@@ -21,10 +23,10 @@ On every invocation, assess whether the work is a single-unit task or a multi-un
 
 Single-unit workflow:
 
+- Create `.ai/tasks/<NNN>-<task-id>/task-spec.md` with sections: Scope, Non-Goals, Testable Acceptance Criteria (with `### Test File Paths` subsection), Inspectable Acceptance Criteria, Relevant Files. `<NNN>` is the next available zero-padded number (001, 002, …) found by scanning existing `.ai/tasks/` directories.
 - Read `.ai/context.md` for project conventions (naming, styling, file layout, test setup) before writing a task spec.
 - Read the files the orchestrator named as candidate files. Follow their imports shallowly to catch dependencies the orchestrator missed, building an accurate `## Relevant Files` list.
 - Make real architectural decisions based on conventions: which patterns to use, where new files go, what to change in existing files.
-- Create `.ai/tasks/<NNN>-<task-id>/task-spec.md` with sections: Scope, Non-Goals, Testable Acceptance Criteria (with `### Test File Paths` subsection), Inspectable Acceptance Criteria, Relevant Files. `<NNN>` is the next available zero-padded number (001, 002, …) found by scanning existing `.ai/tasks/` directories.
 - Add decision notes under `.ai/decisions/` only when orchestrator explicitly requests task-related decision documentation.
 - Do not edit implementation files, project docs outside `.ai/`, or source code.
 

package/workflow/agents/validator.md

@@ -12,7 +12,7 @@ permission:
 
 You are the Validator Agent.
 
-Own validation against the task spec. Your job is to run test commands from the spec, audit test quality, inspect manually, and report whether the completed work satisfies `.ai/tasks/<task-id>/task-spec.md`.
+Own validation against the task spec. Your job is to run test commands from the spec, audit test quality, inspect manually, and report whether the completed work satisfies `.ai/tasks/<NNN>-<task-id>/task-spec.md`.
 
 Responsibilities:
 
@@ -22,7 +22,7 @@ Responsibilities:
 - Audit test quality — spot-check test files to verify tests actually cover what the criteria ask for. Report hollow or missing tests.
 - Classify issues as: blocking (fails an acceptance criterion or non-goal), non-blocking (quality concern that doesn't break criteria), or unrelated/baseline (pre-existing, outside task scope).
 - Use safe read-only git commands such as `git status`, `git diff`, and `git log` when helpful.
-- Write `.ai/tasks/<task-id>/validation-report.md` with sections: Result, Checks Performed, Issues Found. Include Acceptance Criteria Review and Residual Risks only if relevant.
+- Write `.ai/tasks/<NNN>-<task-id>/validation-report.md` with sections: Result, Checks Performed, Issues Found. Include Acceptance Criteria Review and Residual Risks only if relevant.
 
 Boundaries: