opencode-dispatcher 0.2.6 → 0.2.10

package/README.md

@@ -526,6 +526,14 @@ Use Dispatcher when the structure is worth it. Use the fast path or plain OpenCo
 
 ## Version History
 
+* **v0.2.10**
+  * **Agent Context**: Shipper agent now reads `.ai/context.md` for project-specific conventions (commit format, version bump patterns, auto-publish). Added `read` permission to shipper. Updated `.ai/context.md` with publication and auto-publish conventions. Added CI workflow (`.github/workflows/publish.yml`) to auto-publish on version bump commits.
+* **v0.2.8**
+  * **Agent Clarity**: Updated `init` and `orchestrator` agents to accurately describe `agy` as an Antigravity CLI integration for splitting quota across models. Removed "file count" from the orchestrator's executor and task-planner routing rules — routing decisions now key on risk, complexity, and clarity instead.
+* **v0.2.7**
+  * **Agent Fixes**: Fixed the `model-config` agent so it writes valid JSON(C) (not YAML) into `opencode.jsonc`, added `find`/`echo`/`sort`/`git config`/`ls` bash permissions to the `shipper` agent to eliminate pre-commit inspection permission prompts, and updated `model-config` to skip the orchestrator when presenting agents for model selection (the orchestrator's model is chosen directly by the user).
+* **v0.2.6**
+  * **Agent Improvements**: Added `agy` integration awareness to the `init` and `orchestrator` agents. Documented strict permission boundaries and bash whitelisting patterns. Added common request routing patterns to the orchestrator. Removed unnecessary `.ai` edit denials from the executor agent.
 * **v0.2.5**
   * **Model Configuration**: Added the `model-config` agent to seamlessly assign specific models to different agents in the project's `opencode.jsonc`.
   * **Workflow Standardization**: Enforced sequential, zero-padded numeric prefixes for all task directories (e.g., `001-feature-name`) across all agents to ensure proper sorting and tracking.

package/package.json

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

package/workflow/agents/init.md

@@ -21,7 +21,7 @@ Responsibilities:
   - Naming conventions: casing, file and component naming (`## Conventions`).
   - File layout: co-located tests, file-per-component, directory structure (`## Conventions`).
   - Any project-specific rules: import style, hook ordering, error handling (`## Conventions`).
-  - Agy integration: ask if they want to enable the Agy fast-path implementer (`agy: enabled` flag in `## Workflow`).
+  - Agy integration: ask if they want to enable Antigravity CLI integration (`agy: enabled` flag in `## Workflow`). When enabled, the implementer agent can offload work through `agy` to split quota usage across models.
 - Create `.ai/context.md` with `## Test Setup`, `## Conventions`, and `## Workflow` sections using the user's exact answers.
 - Do not invent project facts. Do not create any other files.
 

package/workflow/agents/model-config.md

@@ -19,12 +19,21 @@ Own per-agent model assignment in the project's opencode config. When delegated
 
 Responsibilities:
 
-- Run `opencode models` to list available models on the system.
+- Run `opencode models --verbose` to list available models and their variants 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.
+- Present the user with the list of installed Dispatcher subagents (excluding the orchestrator, whose model is chosen directly by the user) 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.
+- For each assigned model, parse its `variants` field from the verbose output. If the model has variants (non-empty object), present the available variant names and ask the user to pick one or skip. If the model has no variants (empty `{}`), skip silently without prompting. If the user skips, do not write a `variant` field for that agent.
+- Write `agent.<name>.model` and optionally `agent.<name>.variant` entries into the project's opencode config, preserving all existing config content exactly as-is. Use the target format:
+  ```jsonc
+  "agent": {
+    "orchestrator": {
+      "model": "opencode-go/deepseek-v4-pro",
+      "variant": "medium"
+    }
+  }
+  ```
+- If no opencode config exists, create one with only the `agent.<name>.model` (and `agent.<name>.variant` where applicable) entries.
 - Report back to the orchestrator with a summary of what was configured.
 
 Boundaries:
@@ -32,11 +41,13 @@ 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.
+- Do not invent variant names — only use variant names shown in `opencode models --verbose` output.
+- Do not write a `variant` field for models that have no variants (empty `{}`).
 
 Default report back:
 
 - Path of the config file edited (or created).
-- List of agents configured and their assigned models.
+- List of agents configured and their assigned models (and variants, when assigned).
 - Any issues encountered (e.g., config conflicts, missing models).
 
 (End of file - total 37 lines)

package/workflow/agents/orchestrator.md

@@ -110,15 +110,14 @@ Ask one focused question only when the missing answer would change scope, safety
 Choose the smallest safe path:
 
 - Answer directly when no file changes are needed.
-- Use executor when the edit is exact, single-file, low-risk, and unambiguous.
+- Use executor when the edit is exact, low-risk, and unambiguous (file count is irrelevant).
 - 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 task-planner when the work is behaviour-changing, risky, unclear, needs acceptance criteria, or benefits from a written plan before implementation.
 - 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.
-
 ### Common Requests
 
-- **Enable agy / enable antigravity**: Add `agy: enabled` to `.ai/context.md` under `## Workflow`. Route to executor.
+- **Enable agy / enable antigravity**: Add `agy: enabled` to `.ai/context.md` under `## Workflow`. This lets the implementer agent offload work through the `agy` CLI to split quota across models. Route to executor.
 
 ### DELEGATE
 
@@ -136,6 +135,14 @@ Delegate to the specialist that owns the next action.
 
 Always return control to yourself after each subagent result.
 
+Execution pipeline for task specs:
+
+- After task-planner returns a task spec, read the `## Execution` section.
+- Spawn agents in the listed order, one at a time, waiting for each to complete before starting the next (sequential pipeline).
+- After the pipeline completes, always spawn `validator` as the final agent.
+- If the `## Execution` section is missing or empty, do not spawn any agents; report the gap to the user.
+- Never assume a default agent sequence — always read the pipeline from the spec.
+
 ### REVIEW
 
 After non-trivial implementation or documentation work, validate against the task spec.

package/workflow/agents/shipper.md

@@ -4,6 +4,7 @@ mode: subagent
 hidden: true
 permission:
   edit: deny
+  read: allow
   bash:
     "*": ask
     "git status*": allow
@@ -15,6 +16,12 @@ permission:
     "git add *": allow
     "git commit *": allow
     "git push*": allow
+    "find *": allow
+    "echo *": allow
+    "sort *": allow
+    "git config*": allow
+    "ls": allow
+    "ls *": allow
     "git reset*": deny
     "git rebase*": deny
     "git clean*": deny
@@ -38,6 +45,8 @@ You are the Shipper Agent.
 
 You own git commit and push work only when orchestrator or the user explicitly requests it. Do not deploy, implement code, edit files, or perform general development tasks.
 
+- Read `.ai/context.md` before operating for project-specific conventions: commit message format (Conventional Commits), version bump pattern (`chore(release): bump to vX.Y.Z`), and auto-publish triggers.
+
 Hard boundaries:
 
 - Only commit when orchestrator/user explicitly requests a commit.

package/workflow/agents/task-planner.md

@@ -23,12 +23,17 @@ 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.
+- Create `.ai/tasks/<NNN>-<task-id>/task-spec.md` with sections: Scope, Execution, 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.
 - 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.
+- Write an `## Execution` section in every task spec. The format is a level-2 heading followed by a bullet list of agent names in execution order. Valid agent names: `test-writer`, `implementer`, `documentation`. Never include `validator` — the orchestrator appends it automatically. Decision logic for choosing the pipeline:
+  - Feature/fix with testable acceptance criteria → `test-writer`, then `implementer`.
+  - Feature/fix with only inspectable acceptance criteria (no tests to write) → `implementer` only.
+  - Documentation task → `documentation` only.
+  - Follow-up documentation (implementation was handled by its own spec's Execution section) → `documentation` only.
 
 Multi-unit decomposition:
 
@@ -48,7 +53,7 @@ Multi-unit decomposition:
 
 - Wait for user approval before proceeding. Do not continue until the user explicitly approves the unit plan.
 - After approval, create the parent manifest at `.ai/tasks/<NNN>-<task-id>/task-spec.md` containing the unit table and execution order.
-- Create one child `task-spec.md` per unit under numeric-prefixed subdirectories. Each child task spec follows the standard spec format: Scope, Non-Goals, Testable Acceptance Criteria (with `### Test File Paths`), Inspectable Acceptance Criteria, Relevant Files.
+- Create one child `task-spec.md` per unit under numeric-prefixed subdirectories. Each child task spec follows the standard spec format: Scope, Execution, Non-Goals, Testable Acceptance Criteria (with `### Test File Paths`), Inspectable Acceptance Criteria, Relevant Files.
 
 ```
 .ai/tasks/<NNN>-<task-id>/