@flumecode/runner 0.20.0 → 0.22.0

package/dist/cli.js

@@ -854,6 +854,27 @@ function errorMessage(err) {
   return err instanceof Error ? err.message : String(err);
 }
 
+// src/models.ts
+var MODEL_ROSTER = {
+  anthropic: { think: "opus", execute: "sonnet" },
+  openai: { think: "gpt-5.5", execute: "gpt-5.4-mini" }
+  // TODO: confirm vs `codex`
+};
+function rosterFor(provider) {
+  return MODEL_ROSTER[provider ?? "anthropic"] ?? MODEL_ROSTER.anthropic;
+}
+function renderRosterBlock(provider) {
+  const r = rosterFor(provider);
+  return [
+    "# Model tiers",
+    "When a skill tells you to run a subagent on a named model tier, pass the matching",
+    "concrete model id as the Task `model` argument. Use the id exactly; never pass the",
+    "tier name itself.",
+    `- \`think\`   -> \`${r.think}\`  (planning, review, high-level reasoning)`,
+    `- \`execute\` -> \`${r.execute}\`  (writing code from the plan; fast & cheap)`
+  ].join("\n");
+}
+
 // src/rules.ts
 import { readFileSync as readFileSync4 } from "node:fs";
 import { join as join3 } from "node:path";
@@ -906,6 +927,7 @@ function buildPrompt(ctx) {
     LANGUAGE_DIRECTIVE
   ];
   if (ctx.permissionMode !== "plan") {
+    lines2.push("", renderRosterBlock(ctx.provider));
     lines2.push(
       "",
       "These coding guidelines apply to all code produced in this run:",
@@ -937,6 +959,8 @@ function buildRevisePrompt(ctx) {
     widgets,
     LANGUAGE_DIRECTIVE,
     "",
+    renderRosterBlock(ctx.provider),
+    "",
     "These coding guidelines apply to all code produced in this run:",
     "",
     loadRule("coding-guideline"),
@@ -1041,56 +1065,35 @@ function buildRepairPrompt(ctx, hookLog) {
   ];
   return lines2.join("\n");
 }
-function buildReleasePrompt(ctx, baseChecks) {
-  const task = `Use the \`flumecode:create-release\` skill to handle this turn. You are driving a release: first analyse commits since the last tag, propose version bumps, and ask the user to confirm via widgets (Phase 1); once the user's widget answers appear in the thread, apply the bumps to package.json files and update CHANGELOG.md (Phase 2). Do NOT commit or push \u2014 the runner handles that and opens the bump PR.`;
+function buildReleasePrompt(ctx) {
+  const task = `Use the \`flumecode:create-release\` skill to handle this turn. You are driving a release: first analyse commits since the last tag, propose version bumps, and ask the user to confirm via widgets (Phase 1); once the user's widget answers appear in the thread, emit the final report with the confirmed versions (Phase 2). Do NOT edit package.json or CHANGELOG.md, do NOT commit, push, or open a PR.`;
   const orient = `Before investigating raw source, check for a FlumeCode wiki at \`.flumecode/wiki/\`. If it exists, read \`.flumecode/wiki/README.md\` first \u2014 it is the index \u2014 and follow its links to the pages and source paths relevant to this release. If there is no wiki, work from the code directly.`;
   const widgets = `When you need the user to choose, ask it as a widget rather than writing the options as prose: call \`single_select\` for a one-of-N choice (radio buttons) or \`multi_select\` for a "select all that apply" choice (checkboxes). Don't add your own "Other" option \u2014 the UI always provides one. After calling a widget tool, end your turn \u2014 the user's answer comes back as their next message and starts a fresh run.`;
   const lines2 = [
     `You are "${ctx.agentName}", an autonomous coding agent driving a FlumeCode release.`,
-    `The repository ${ctx.repo.fullName} is checked out in your current working directory on the release bump branch "${ctx.repo.checkoutBranch}".`,
+    `The repository ${ctx.repo.fullName} is checked out in your current working directory at the frozen release commit (branch "${ctx.repo.checkoutBranch}").`,
     task,
     orient,
     widgets,
     LANGUAGE_DIRECTIVE,
     "",
-    "These coding guidelines apply to all code produced in this run:",
-    "",
-    loadRule("coding-guideline"),
-    "",
     `# Release: ${ctx.request?.title ?? ""}`
   ];
   if (ctx.request?.body) {
     lines2.push("", ctx.request.body);
   }
-  if (baseChecks && !baseChecks.ok) {
-    lines2.push(
-      "",
-      "# Pre-release check status",
-      "",
-      "\u26A0\uFE0F The repository's pre-commit checks (lint / typecheck / tests) are currently FAILING on the base branch, independently of any version bump. A release must not ship a broken base:",
-      "",
-      "- **Phase 1 (propose):** tell the user, in your reply, that the base currently fails these checks and that the release will fix them as part of the bump.",
-      "- **Phase 2 (apply):** fix the failing code at its root so the checks pass, THEN apply the version bumps and CHANGELOG. Do NOT delete/skip tests or weaken assertions. The fixes ship in the same bump PR. Still do NOT commit or push \u2014 the runner does.",
-      "",
-      "Failing check output:",
-      "",
-      "```",
-      baseChecks.log,
-      "```"
-    );
-  }
   if (ctx.prerelease) {
     lines2.push(
       "",
       "# Pre-release",
       "",
-      "This is a PRE-RELEASE. When proposing and applying versions, use a semver pre-release version string (e.g. `0.9.0-beta.1`): take the next stable version you would otherwise pick and append `-beta.N`, where N is the next unused beta number for that version (check existing `v<version>-beta.*` tags). Offer these pre-release strings in the version-confirmation widgets, and write them to package.json, CHANGELOG.md, and the `flumecode:versions` comment as usual."
+      "This is a PRE-RELEASE. When proposing versions, use a semver pre-release version string (e.g. `0.9.0-beta.1`): take the next stable version you would otherwise pick and append `-beta.N`, where N is the next unused beta number for that version (check existing `v<version>-beta.*` tags). Offer these pre-release strings in the version-confirmation widgets, and include them in the `flumecode:versions` comment as usual."
     );
   }
   appendThread(lines2, ctx);
   lines2.push(
     "",
-    "Your final reply is posted verbatim as your comment in the release thread \u2014 if you called widgets (Phase 1), your reply text accompanies the questions; if you applied the bumps (Phase 2), make it the report the skill produced. The runner appends the pull-request link."
+    "Your final reply is posted verbatim as your comment in the release thread \u2014 if you called widgets (Phase 1), your reply text accompanies the questions; if you emitted the final report (Phase 2), make it the report the skill produced."
   );
   return lines2.join("\n");
 }
@@ -1287,27 +1290,6 @@ function commitFailureLog(err) {
   const parts = [e.stdout, e.stderr].map((s) => typeof s === "string" ? s.trim() : "").filter((s) => s.length > 0);
   return parts.length > 0 ? parts.join("\n") : e.message ?? String(err);
 }
-function isUnsupportedGitSubcommand(err) {
-  const e = err;
-  const text = `${typeof e.stderr === "string" ? e.stderr : ""}
-${e.message ?? ""}`;
-  return /is not a git command|unknown subcommand|usage: git hook/i.test(text);
-}
-async function runRepoChecks(dir) {
-  try {
-    await git(["-C", dir, "hook", "run", "pre-commit"]);
-    logEvent("checks", "pre-commit hook passed");
-    return { ok: true, log: "", skipped: false };
-  } catch (err) {
-    if (isUnsupportedGitSubcommand(err)) {
-      logEvent("checks", "pre-commit hook skipped (git too old)");
-      return { ok: true, log: "", skipped: true };
-    }
-    const log = commitFailureLog(err);
-    logEvent("checks:err", log);
-    return { ok: false, log, skipped: false };
-  }
-}
 async function commitChanges(ctx, dir) {
   if (!await hasChanges(dir)) return false;
   try {
@@ -1404,10 +1386,9 @@ async function openPullRequest(ctx) {
     return { number: data.number, url: data.html_url };
   }
   if (res.status === 422) {
-    const list = await fetch(
-      `${apiBase}/pulls?state=open&head=${owner}:${checkoutBranch}&base=${mergeBranch}`,
-      { headers }
-    );
+    const list = await fetch(`${apiBase}/pulls?state=open&head=${owner}:${checkoutBranch}`, {
+      headers
+    });
     if (list.ok) {
       const open = await list.json();
       if (open[0]) return { number: open[0].number, url: open[0].html_url };
@@ -1478,7 +1459,7 @@ async function prNumbersForCommit(ctx, sha) {
 // src/run.ts
 var IDLE_MS = 5e3;
 var CANCEL_POLL_MS = 2500;
-var ORCHESTRATOR_MODEL = "sonnet";
+var orchestratorModel = (ctx) => rosterFor(ctx.provider).think;
 var ORCHESTRATOR_MAX_TURNS = 80;
 var MAX_COMMIT_REPAIRS = 2;
 var MAX_IMPLEMENT_RETRIES = 1;
@@ -1524,7 +1505,7 @@ async function mergeAndResolveConflicts(ctx, dir, config, abort) {
     cwd: dir,
     prompt: buildResolvePrompt(ctx, related),
     permissionMode: ctx.permissionMode,
-    model: ORCHESTRATOR_MODEL,
+    model: orchestratorModel(ctx),
     maxTurns: ORCHESTRATOR_MAX_TURNS,
     abortController: abort
   });
@@ -1549,7 +1530,7 @@ async function commitWithRepair(ctx, dir, abort) {
         cwd: dir,
         prompt: buildRepairPrompt(ctx, err.log),
         permissionMode: ctx.permissionMode,
-        model: ORCHESTRATOR_MODEL,
+        model: orchestratorModel(ctx),
         maxTurns: ORCHESTRATOR_MAX_TURNS,
         abortController: abort
       });
@@ -1653,7 +1634,7 @@ async function processChatJob(ctx, dir, config, abort) {
     prompt: buildPrompt(ctx),
     permissionMode: ctx.permissionMode,
     abortController: abort,
-    ...orchestrating ? { model: ORCHESTRATOR_MODEL, maxTurns: ORCHESTRATOR_MAX_TURNS } : {}
+    ...orchestrating ? { model: orchestratorModel(ctx), maxTurns: ORCHESTRATOR_MAX_TURNS } : {}
   });
   const summary = result.text.trim();
   let reply = summary || "(the agent produced no summary)";
@@ -1719,7 +1700,7 @@ async function processImplementJob(ctx, dir, resumed, config, abort) {
       cwd: dir,
       prompt: buildPrompt(ctx),
       permissionMode: ctx.permissionMode,
-      model: ORCHESTRATOR_MODEL,
+      model: orchestratorModel(ctx),
       maxTurns: ORCHESTRATOR_MAX_TURNS,
       abortController: abort
     });
@@ -1798,7 +1779,7 @@ async function processReviseJob(ctx, dir, resumed, config, abort) {
     cwd: dir,
     prompt: buildRevisePrompt(ctx),
     permissionMode: ctx.permissionMode,
-    model: ORCHESTRATOR_MODEL,
+    model: orchestratorModel(ctx),
     maxTurns: ORCHESTRATOR_MAX_TURNS,
     abortController: abort
   });
@@ -1873,48 +1854,26 @@ async function processResolveJob(ctx, dir, config, abort) {
   reply += outcomeBanner(outcome, { branch: ctx.repo.checkoutBranch });
   return { text: reply, widgets: [], ...report ? { report } : {}, ...pr ? { pr } : {} };
 }
-async function processReleaseJob(ctx, dir, resumed, config, abort) {
+async function processReleaseJob(ctx, dir, _resumed, _config, abort) {
   console.log(`
 \u25B6 Release ${ctx.jobId} \u2014 ${ctx.repo.fullName}: "${jobTitle(ctx)}"`);
-  const installResult = await installDependencies(dir);
-  const checks = await runRepoChecks(dir);
-  if (checks.skipped) {
-    console.log(`  \u2026release ${ctx.jobId}: pre-release checks skipped (git too old for 'hook run')`);
-  } else {
-    console.log(`  \u2026release ${ctx.jobId}: pre-release checks ${checks.ok ? "passed" : "FAILED"}`);
-  }
-  const baseChecks = checks.ok ? void 0 : { ok: false, log: trimHookLog(checks.log) };
+  await installDependencies(dir);
   const result = await runClaudeCode({
     cwd: dir,
-    prompt: buildReleasePrompt(ctx, baseChecks),
+    prompt: buildReleasePrompt(ctx),
     permissionMode: ctx.permissionMode,
-    model: ORCHESTRATOR_MODEL,
+    model: orchestratorModel(ctx),
     maxTurns: ORCHESTRATOR_MAX_TURNS,
     abortController: abort
   });
-  let reply = result.text.trim() || "(the agent produced no reply)";
-  if (installResult.status === "failed") {
-    reply += `
-
-> \u26A0\uFE0F Dependencies failed to install (\`${installResult.manager}\`); tests may not have run.`;
-  }
+  const reply = result.text.trim() || "(the agent produced no reply)";
   if (result.widgets.length > 0) {
     console.log(
       `  \u2026release ${ctx.jobId} posted ${result.widgets.length} widget(s); awaiting reply`
     );
     return { text: reply, widgets: result.widgets };
   }
-  const { outcome, autoMerged } = await pushAndOpenPr(ctx, dir, config, abort, {
-    rebase: !resumed
-  });
-  if (outcome.kind !== "none") {
-    reply += outcomeBanner(outcome, { branch: ctx.repo.checkoutBranch, autoMerged });
-  }
-  return {
-    text: reply,
-    widgets: [],
-    ...outcome.kind === "pr" ? { pr: outcome.pr } : {}
-  };
+  return { text: reply, widgets: [] };
 }
 async function heartbeat(config) {
   const health = await checkClaudeCode();
@@ -2051,7 +2010,7 @@ ${trimmed}` : trimmed;
 }
 function formatJobError(ctx, err) {
   if (!(err instanceof PreCommitError)) return errorMessage2(err);
-  const nextStep = ctx.kind === "release" ? `These checks are failing on \`${ctx.repo.mergeBranch}\` independently of the version bump, and the release couldn't fix them after ${MAX_COMMIT_REPAIRS} automatic attempts. Open a request on **${ctx.repo.fullName}** to fix the failing checks above, then start the release again once that fix has merged.` : `The agent couldn't get its change past these checks after ${MAX_COMMIT_REPAIRS} automatic repair attempts. Open a request on **${ctx.repo.fullName}** describing the failing checks above so the agent can fix them at their root, then try again.`;
+  const nextStep = ctx.kind === "release" ? `These checks are failing on \`${ctx.repo.mergeBranch}\` independently of this release, and the release couldn't fix them after ${MAX_COMMIT_REPAIRS} automatic attempts. Open a request on **${ctx.repo.fullName}** to fix the failing checks above, then start the release again once that fix has merged.` : `The agent couldn't get its change past these checks after ${MAX_COMMIT_REPAIRS} automatic repair attempts. Open a request on **${ctx.repo.fullName}** describing the failing checks above so the agent can fix them at their root, then try again.`;
   return [
     "\u274C **Blocked by failing pre-commit checks.**",
     "",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flumecode/runner",
-  "version": "0.20.0",
+  "version": "0.22.0",
   "type": "module",
   "description": "FlumeCode local runner — claims jobs and drives your local Claude Code against a real checkout.",
   "bin": {

package/skills-plugin/skills/create-release/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: create-release
 description: >-
-  Draft release notes and version suggestions for a release, then (after the
-  user confirms) open a bump PR that updates package.json version(s) and
-  CHANGELOG.md. Two-turn flow: first turn asks the user to confirm versions via
-  widgets; second turn (answers in thread) writes the bumps and opens the PR.
+  Draft release notes and version suggestions for a release. Two-turn flow:
+  first turn asks the user to confirm versions via widgets; second turn (answers
+  in thread) emits the structured report with confirmed versions and notes. Does
+  NOT edit package.json or CHANGELOG.md, and does NOT commit, push, or open a PR.
 ---
 
 # create-release
@@ -17,7 +17,7 @@ which one applies before acting.
 Check the thread (`# Conversation so far` in the prompt). If **no widget answers**
 appear in any prior agent turn, this is **Phase 1** — propose versions and ask.
 If a prior turn contains widget-answer selections (the user picked a version), this
-is **Phase 2** — apply the bumps and report.
+is **Phase 2** — emit the final report.
 
 ---
 
@@ -99,11 +99,11 @@ can read them inside the question widget:
 - `options`: `Yes, use these notes`, `I'll edit them in the PR`
   (You may still summarise in the reply text, but the notes MUST be in the widget `body`.)
 
-**After calling widgets, end your turn.** Do NOT open a PR in Phase 1.
+**After calling widgets, end your turn.** Do NOT edit any files in Phase 1.
 
 ---
 
-## Phase 2 — Apply the bumps and report
+## Phase 2 — Emit the final report
 
 ### 1. Read the widget answers
 
@@ -111,52 +111,19 @@ The user's confirmed version selections appear in the `# Conversation so far`
 thread as agent messages (the widget-answer turn). Extract the chosen version for
 each package from those selections.
 
-### 2. Update package.json files
+### 2. Emit the structured report
 
-For each package whose version changed, edit the `"version"` field in:
-
-- `apps/web/package.json` — for `@flumecode/web`
-- `apps/runner/package.json` — for `@flumecode/runner`
-
-Change only the `"version"` line; do not reformat the file.
-
-### 3. Update CHANGELOG.md
-
-Edit (or create) `CHANGELOG.md` at the repo root. Insert a new section at the
-top, below any existing `# Changelog` title line:
+Your final message must match this shape (adjust versions and notes to match what
+was confirmed):
 
 ```
-## [X.Y.Z / runner-X.Y.Z] - YYYY-MM-DD
+**Confirmed versions:**
+- `@flumecode/web`: `0.9.0`
+- `@flumecode/runner`: `0.5.0`
 
+**Release notes:**
 - Bullet point from release notes
 - Another bullet point
-```
-
-Use the ISO date format (`YYYY-MM-DD`). Preserve all existing entries — do not
-delete or rewrite prior sections.
-
-If both packages are bumped, list both versions in the heading (e.g.
-`## [0.9.0 / runner-0.5.0] - 2026-06-06`). If only one package is bumped, list
-only that version in the heading.
-
-### 4. Stop — do not commit or push
-
-Leave the edited files in the working tree. The runner commits them and opens the
-pull request.
-
-### 5. End with this exact report format
-
-Your final message must match this shape (adjust versions and files to match what
-actually changed):
-
-```
-**Bumped versions:**
-- `@flumecode/web`: `0.8.0` → `0.9.0`
-- `@flumecode/runner`: `0.4.0` → `0.5.0`
-
-**CHANGELOG updated** with release notes.
-
-**Files changed:** `apps/web/package.json`, `apps/runner/package.json`, `CHANGELOG.md`
 
 <!-- flumecode:versions {"@flumecode/web":"0.9.0","@flumecode/runner":"0.5.0"} -->
 ```
@@ -167,21 +134,20 @@ reads it to persist the confirmed versions on the release entity. Use the exact
 JSON key names `@flumecode/web` and `@flumecode/runner`; omit a package if its
 version did not change.
 
+**Do NOT edit package.json, CHANGELOG.md, or any other file. Do NOT commit,
+push, or open a pull request.** The GitHub Release is cut directly from the
+frozen commit by the web interface.
+
 ---
 
 ## Notes
 
-- **Runner-only bump:** if only `apps/runner/` has commits, bump only
-  `apps/runner/package.json`. Leave `apps/web/package.json` unchanged.
+- **Runner-only bump:** if only `apps/runner/` has commits, include only
+  `apps/runner/package.json`'s version in the `flumecode:versions` comment.
 - **Clear Phase 1 text:** be explicit about what changed since the last tag so the
   user can confidently confirm or override your suggestions.
-- **Edit only version files — with one exception.** Normally edit only
-  `apps/web/package.json`, `apps/runner/package.json`, and `CHANGELOG.md`. The sole
-  exception: when the prompt includes a **`# Pre-release check status`** section
-  reporting failing checks, you must also fix the failing code (any file needed) so
-  the tree is green — see "Pre-release checks" below. Never weaken or skip checks to
-  silence them.
-- **Never commit, push, or open a PR** — the runner does that.
+- **Read-only:** do not edit any files at any point. This skill is purely
+  analytical — it reads the repo, proposes versions, and emits a report.
 
 ## Pre-release
 
@@ -202,27 +168,6 @@ pre-release version strings instead of stable ones:
   `0.9.0-beta.1`) in the version-confirmation widgets instead of the stable
   version.
 
-- **Phase 2 (apply):** write the pre-release version string (e.g.
-  `0.9.0-beta.1`) to `package.json`, `CHANGELOG.md`, and the
-  `<!-- flumecode:versions {...} -->` comment — exactly as you would for a
-  stable release, just with the pre-release suffix included.
-
----
-
-## Pre-release checks
-
-We cannot release code with failing checks. Before this turn, the runner ran the
-repository's own pre-commit hook (lint / typecheck / tests). If the prompt contains
-a **`# Pre-release check status`** section, the base branch is currently broken
-_independently of the version bump_:
-
-- **Phase 1:** state plainly in your reply that the base currently fails these
-  checks and that the release will fix them as part of the bump, then ask the
-  version questions as usual.
-- **Phase 2:** fix the failing code at its root **first** (so the checks pass),
-  **then** apply the version bumps and CHANGELOG. The fixes ship in the same bump
-  PR. Do not delete or skip tests, weaken assertions, or disable checks. Still do
-  not commit or push — the runner commits everything together.
-
-If there is no `# Pre-release check status` section, the base is clean (or the check
-was skipped); proceed normally and edit only the version files.
+- **Phase 2 (emit):** include the pre-release version string (e.g.
+  `0.9.0-beta.1`) in the `<!-- flumecode:versions {...} -->` comment — exactly
+  as you would for a stable release, just with the pre-release suffix included.

package/skills-plugin/skills/implement-plan/SKILL.md

@@ -12,7 +12,7 @@ description: >-
 
 # implement-plan
 
-You are the **orchestrator**. You run on a medium model and your job is to
+You are the **orchestrator**. You run on the `think` model and your job is to
 _coordinate_, not to write the implementation. You delegate each phase to a
 subagent through the **Task** tool, choosing the model that phase needs, and you
 stitch their results into one report. Doing the implementation yourself defeats
@@ -30,10 +30,9 @@ put it in the prompt, the subagent doesn't have it.
 ## How you delegate
 
 - Spawn each phase with the **Task** tool, `subagent_type: "general-purpose"`.
-- **Model per phase** (pass it as the Task `model` argument):
-  - `"sonnet"` — implementation, fixes, and the Verify step (mechanical
-    command-running; Verify is read-only even though it uses sonnet).
-  - `"opus"` — acceptance-criteria review, code-quality review, and the report.
+- **Model per phase** (pass the concrete id from the Model tiers block as the Task `model` argument):
+  - `execute` — implementation, fixes, and the Verify step (mechanical command-running; Verify is read-only).
+  - `think` — acceptance-criteria review, code-quality review, and the report.
 - **Read-only phases.** Tell every review, Verify, and report subagent to _inspect
   and report only — never edit, create, or delete files_. Only implementation/fix
   subagents may change the working tree.
@@ -68,7 +67,7 @@ the next step.
    it in the prompts you write for the Implement, Verify, and Fix-loop subagents
    so none of them re-derive it. Do not implement.
 
-2. **Implement** — Task, `model: "sonnet"`. Give the subagent: the plan steps, a
+2. **Implement** — Task, `model: execute`. Give the subagent: the plan steps, a
    pointer to the wiki/orientation, the coding guidelines (verbatim), and the
    explicit verification command list the orchestrator discovered in the Orient
    step. Tell it to make all the code changes in the working tree to satisfy the
@@ -83,7 +82,7 @@ the next step.
    the verification commands it ran and their pass/fail results, which files it
    changed, and how each plan step was addressed. It must not commit or push.
 
-3. **Verify (build & tests)** — Task, `model: "sonnet"`, read-only. This step
+3. **Verify (build & tests)** — Task, `model: execute`, read-only. This step
    gives the orchestrator an objective, independent build/test signal before the
    subjective AC and quality reviews. Tell the subagent to:
    - Run the verification commands provided by the orchestrator in the task
@@ -100,7 +99,7 @@ the next step.
      excerpt (if any).
    - Must not edit, create, or delete any files.
 
-4. **Acceptance-criteria review** — Task, `model: "opus"`, read-only. Give the
+4. **Acceptance-criteria review** — Task, `model: think`, read-only. Give the
    subagent the full AC list and tell it to verify each one against the actual
    changes (run `git --no-pager diff`, read the changed files, run tests/build if
    useful). For **each** AC it must return: the criterion text verbatim, a verdict
@@ -117,7 +116,7 @@ the next step.
    note any files or areas that appear changed but don't map to any AC as a coverage
    gap (signalling a missing AC or an out-of-scope change).
 
-5. **Code-quality review** — Task, `model: "opus"`, read-only. Give the subagent
+5. **Code-quality review** — Task, `model: think`, read-only. Give the subagent
    the coding guidelines (verbatim) and tell it to review the changes for
    violations and quality problems, returning concrete findings as
    `file:line — what — why`, each marked **must-fix** or **nice-to-have**.
@@ -125,7 +124,7 @@ the next step.
 6. **Fix loop.** If the Verify step (step 3) reports any failing check, the AC
    review (step 4) reports any _not met_ AC, or the quality review (step 5)
    reports any _must-fix_ finding: spawn an **Implement/fix** subagent (Task,
-   `model: "sonnet"`) whose prompt lists exactly those findings and tells it to
+   `model: execute`) whose prompt lists exactly those findings and tells it to
    resolve them without regressing the rest. Include the verification command list
    from the Orient step in the fix subagent's prompt (the same list passed to
    Implement and Verify), so the fix subagent does not need to re-derive it. When
@@ -135,7 +134,7 @@ the next step.
    times. If something still fails after that, stop looping and record the gap
    honestly in the report — do not hide it.
 
-7. **Report** — Task, `model: "opus"`, read-only. Give the subagent the AC
+7. **Report** — Task, `model: think`, read-only. Give the subagent the AC
    verdicts (with criterion text, from step 4), the Verify results (from step 3),
    and the quality findings, and tell it to run `git --no-pager diff` itself as
    the **single source of truth** for the report. Pass the Verify results as the
@@ -191,7 +190,7 @@ The report subagent calls `submit_report` with these fields:
 
 - Delegate through Task subagents; don't implement, review, or write the report
   yourself.
-- Right model per phase: `sonnet` to implement/fix/verify (Verify is read-only), `opus` to review/report.
+- Right model per phase: `execute` to implement/fix/verify (Verify is read-only), `think` to review/report.
 - Make every Task prompt self-contained — subagents see only what you give them.
 - Reviewers and the report writer never modify files.
 - Never commit, push, or open a PR.

package/skills-plugin/skills/revise-implementation/SKILL.md

@@ -67,9 +67,9 @@ essentials:
   implementation, not a rebuild. Change only what the user asked for plus what that
   change strictly requires; don't regress the rest of the plan.
 - **Pipeline:** Implement (self-runs build/tests & fixes its own errors, Task
-  `model: "sonnet"`) → Verify (build/tests, read-only, Task `model: "sonnet"`) →
-  acceptance/quality review (Task `model: "opus"`, read-only) → fix loop if needed
-  (≤2, re-run Verify after each fix) → report (Task `model: "opus"`, read-only).
+  `model: execute`) → Verify (build/tests, read-only, Task `model: execute`) →
+  acceptance/quality review (Task `model: think`, read-only) → fix loop if needed
+  (≤2, re-run Verify after each fix) → report (Task `model: think`, read-only).
   Detailed mechanics (command discovery, Verify step spec, fix-loop trigger
   conditions) are in `implement-plan/SKILL.md` — read it for the full pipeline.
 - **No git side effects.** Never commit, push, or open a PR — leave the changes in