opencode-codeops 1.7.1 → 1.8.1

package/skills/analyze-project/SKILL.md

@@ -10,7 +10,7 @@ description: Analyze the current repository and create or refresh concise CodeOp
 ## Protocol
 
 1. Resolve the Git root, current/default branch, and nested `AGENTS.md` files.
-2. Inspect manifests, build files, CI, test configuration, formatter/linter settings, source layout, package boundaries, and recent commit conventions.
+2. Inspect manifests, build files, CI, test configuration, formatter/linter settings, source layout, package boundaries, and recent commit conventions; note specialization signals (a specialized framework, DSL, codegen, protocol, or domain invariants a generic agent would miss).
 3. Derive commands only from executable configuration or documented scripts. Never invent a plausible command.
 4. Prepare a concise managed section between:
 
@@ -24,5 +24,6 @@ description: Analyze the current repository and create or refresh concise CodeOp
 7. On a non-integration branch, preview changes to repository-wide guidance and ask before writing unless repository policy explicitly permits branch-local updates.
 8. In compact mode, remove duplication and stale generated detail from the managed section only. Flag suspected hand-authored bloat; never silently rewrite it.
 9. Validate every recorded command or mark it explicitly unverified.
+10. When a specialization signal is strong and no specialist covers it, report the candidate with evidence and recommend the `setup-routing` creation flow ([../../_shared/specialist-agents.md](../../_shared/specialist-agents.md)); never write agent files here. Preserve the `<!-- CODEOPS-SPECIALISTS:START -->` / `<!-- CODEOPS-SPECIALISTS:END -->` block byte-for-byte when refreshing the managed section.
 
 Keep `AGENTS.md` small. Operational routing belongs in `codeops/codeops.json` or `opencode.json`, not prose.

package/skills/exec-plan/SKILL.md

@@ -217,7 +217,9 @@ links to them, never restates them.
 The flow: the protocol records a phase-start ref when the phase begins; after the phase's last
 task verifies, the correctness reviewer and any active auditors are dispatched **in parallel** on
 the phase diff, their findings are merged and presented in severity-grouped batches, and each
-ruling is recorded in the durable finding artifact.
+ruling is recorded in the durable finding artifact. Specialist roles listed in the plan's
+`## Specialist Agents` table dispatch per `_shared/quality-profile.md`; an unavailable specialist
+falls back to a generic packet and the fallback is reported.
 
 > **🚨 Finding gate (load-bearing).** In normal mode, 🔴 CRITICAL and 🟠 MAJOR findings PAUSE
 > execution for the user's ruling in ALL commit modes. With active auto-design, select and record

package/skills/exec-plan/execution-protocol.md

@@ -165,9 +165,10 @@ whole-task diff. Activation rules, packets, supersession, and caps are defined i
 1. **Determine activation.** Strict defaults review every non-trivial phase. Adaptive mode may
    explicitly disable independent review; announce that choice. Trivial tasks are never reviewed.
    A docs-only diff → phase-reviewer only, and the auditor skip is logged — never silent.
-2. **Dispatch in parallel:** the correctness reviewer plus every risk-selected auditor (security,
-   financial integrity, concurrency, performance, semantics, or migration), each with the
-   dispatch header on line 1 of its prompt and its packet
+2. **Dispatch in parallel:** the correctness reviewer, every risk-selected auditor (security,
+   financial integrity, concurrency, performance, semantics, or migration), and any specialist
+   reviewer listed in the plan's `## Specialist Agents` table, each with the dispatch header on
+   line 1 of its prompt and its packet (`_shared/quality-profile.md`)
    Create the review diff with:
 
    ```bash
@@ -177,7 +178,7 @@ whole-task diff. Activation rules, packets, supersession, and caps are defined i
 
    This includes committed, staged, unstaged, and newly created files while excluding changes that
    existed at phase start.
-3. **Merge findings** (RV/SA/PE) and present them in severity-grouped batches (reuse the
+3. **Merge findings** (RV/SA/PE/SR) and present them in severity-grouped batches (reuse the
    preflight skill's batch pacing). In normal mode, 🔴 CRITICAL / 🟠 MAJOR findings PAUSE
    execution for the user's ruling in ALL commit modes. With active auto-design, an eligible
    technical fix may be selected and recorded, but risk may never be waived and a critical/major

package/skills/make-plan/SKILL.md

@@ -61,6 +61,8 @@ with active scope exploration.
 
 Re-run [../../references/domains/selection.md](../../references/domains/selection.md) before component decomposition. Requirements-stage lens selection is evidence, not a permanent assumption. Apply every selected lens to specifications, acceptance criteria, failure narratives, and test strategy.
 
+After lens selection and phase decomposition, run the specialist-gap check in [../../_shared/specialist-agents.md](../../_shared/specialist-agents.md). Record the outcome in `00-index.md` under `## Specialist Agents` — always, including `None` with its reason and evidence. Candidate creation is reserved authority: `--auto-design` may not approve it, and approved roles are created through `setup-routing`.
+
 A folder `plans/<feature-name>/` containing:
 
 ```

package/skills/make-plan/templates.md

@@ -85,6 +85,16 @@ excerpt at dispatch time — excerpting for a handoff packet is not restatement)
 | ------------ | --------- |
 | [Decision 1] | [Outcome] |
 
+## Specialist Agents
+
+| Role | Kind | Use | AR Ref |
+| ---- | ---- | --- | ------ |
+| [role] | [reviewer/executor] | [phase or use] | [AR ref] |
+
+[Or: `**None**` — the capability-gap check found no gap a standing specialist would close.]
+
+_Detection evidence: [repository facts with `file:line`, or the negative-check evidence]_
+
 ## Related Files
 
 [List of key files that will be created or modified]

package/skills/make-requirements/SKILL.md

@@ -45,6 +45,8 @@ than stored as a second mutable status.
 
 Before discovery, read [../../references/domains/selection.md](../../references/domains/selection.md), select every applicable system lens, and read those lens files completely. Record selected lenses and evidence in the requirements index. Re-evaluate selection when discovery reveals another domain; a financial web service, for example, requires financial, web, distributed/concurrent, and data/migration lenses.
 
+After lens selection and scope confirmation, run the specialist-gap check in [../../_shared/specialist-agents.md](../../_shared/specialist-agents.md). Propose at most two candidates in one batch, each through the Complexity Escalation Gate; creation is reserved authority (`--auto-design` may never approve it). Record the check outcome — including "none" — in the final summary.
+
 You are NOT a passive interviewer. You are a **domain-aware consultant** that:
 
 1. **Absorbs** — takes whatever the user provides (brain dump, bullets, vague idea) as seed material

package/skills/setup-routing/SKILL.md

@@ -59,7 +59,7 @@ Model names are implementation choices, not policy names. Default to the current
 
 ## Structured policy
 
-Store CodeOps policy in `codeops/codeops.json`, not in `AGENTS.md`. `AGENTS.md` receives only a concise instruction that CodeOps routing is configured and that material ambiguity and verification gates may not be bypassed.
+Store CodeOps policy in `codeops/codeops.json`, not in `AGENTS.md`. When project specialists exist, `AGENTS.md` additionally carries the managed `<!-- CODEOPS-SPECIALISTS:START -->` … `<!-- CODEOPS-SPECIALISTS:END -->` index rendered by `install_agents.py --sync-agents-md`; this skill is its only writer, and material ambiguity and verification gates may not be bypassed.
 
 Example policy fields are documented in [routing.md](routing.md).
 
@@ -80,6 +80,20 @@ The installer:
 - writes complete developer instructions; and
 - never modifies global OpenCode configuration.
 
+### Specialist creation and removal
+
+Project specialists follow the shared protocol in [../../_shared/specialist-agents.md](../../_shared/specialist-agents.md); creation is reserved authority and requires the user's direct approval of the gate packet.
+
+Creation, after approval:
+
+1. Draft the brief at `codeops/specialists/<role>.md` from the candidate packet and present it for a final review — the brief is the actual prompt.
+2. Write `routing.roles.<role>` policy first when a model/effort/sandbox/reasoning override is needed: routing wins over the brief, and a policy written later makes the generated agent immediately stale.
+3. Generate the agent: `python3 "${CODEOPS_PLUGIN_ROOT}/scripts/install_agents.py" --project . --custom <role>`.
+4. Sync the index: `... --sync-agents-md`.
+5. Verify last with `... --check`, then tell the user the agent is available as soon as its generated file exists (discovery timing follows the running OpenCode build).
+
+Removal: confirm, run `--remove-custom <role> --yes` (it deletes the agent and brief and syncs the index), drop the routing entry, warn when an active plan references the role, and report that `exec-plan` will fall back to a dynamic packet.
+
 ## Runtime dispatch rule
 
 For every dispatch, send a bounded packet containing scope, authoritative excerpts, relevant decisions, target paths, verification command, forbidden actions, and required output schema. Do not assume a custom agent inherits the conversation's system model.

package/skills/setup-routing/routing.md

@@ -27,6 +27,14 @@ CodeOps routing lives under the optional `routing` and `quality` fields in `code
 
 Allowed effort values follow the active OpenCode release. Prefer `medium` for bounded reconnaissance, `high` for correctness/security review, and higher supported levels only for genuinely demanding semantic or architectural work.
 
+An optional per-role `reasoning` field sets the provider reasoning-effort passthrough (`none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`). Generated project specialists default to `max` through their brief or the embedded `reasoningEffort`; a routing value wins over the brief. A model that rejects the option is overridden here — there is no automatic provider-capability detection.
+
+```json
+"roles": {
+  "pg-migration-reviewer": {"reasoning": "max"}
+}
+```
+
 Model pins are optional per role. When omitted, OpenCode resolves the model from the explicit spawn, project defaults, and parent session. A missing pin must never block the workflow.
 
 Reviewer selection is driven by risk tags: