github-router 0.3.322 → 0.3.324

package/dist/{attribution-settings-z-U2L7ab.js → attribution-settings-sTUXqFzx.js}

@@ -1,12 +1,12 @@
-import { An as oneMContextDisabled, Fn as CHEAPEST_PROFILE_NATIVE_AGENT_NAMES, Hn as CHEAP_PROFILE_NATIVE_EFFORTS, In as CHEAPEST_PROFILE_NATIVE_EFFORTS, Vn as CHEAP_PROFILE_NATIVE_AGENT_NAMES, a as buildAgentPrompt, jn as withOneMSuffix, l as maxPersonasFor, ln as CONDENSED_OPERATING_SEQUENCE, n as MCP_GROUPS, t as GROUP_META, u as personasFor, un as DEFINITION_OF_GREATNESS } from "./peer-mcp-personas-Gb0LfII0.js";
-import { a as isUnderClaudeConfigMirror, f as writeRuntimeFileSecure, t as PATHS } from "./paths-CHBAj_t9.js";
-import { S as LUNA_SCOUT_ALIAS_ID, _ as CHEAP_EXPLORE_ALIAS_ID, b as CHEAP_PLAN_ALIAS_ID, f as CHEAPEST_EXPLORE_ALIAS_ID, g as CHEAPEST_REVIEWER_ALIAS_ID, h as CHEAPEST_PLAN_ALIAS_ID, m as CHEAPEST_IMPLEMENTER_ALIAS_ID, p as CHEAPEST_GENERAL_PURPOSE_ALIAS_ID, v as CHEAP_GENERAL_PURPOSE_ALIAS_ID, x as CHEAP_REVIEWER_ALIAS_ID, y as CHEAP_IMPLEMENTER_ALIAS_ID } from "./server-setup-DQVRJluz.js";
-import { c as FAST_PROFILE_MODELS, d as FAST_PROFILE_NATIVE_MODELS, l as FAST_PROFILE_NATIVE_AGENT_NAMES, u as FAST_PROFILE_NATIVE_EFFORTS } from "./fast-profile-contract-_DhIWank.js";
+import { Ln as BALANCED_PROFILE_NATIVE_AGENT_NAMES, Nn as oneMContextDisabled, Pn as withOneMSuffix, Rn as BALANCED_PROFILE_NATIVE_EFFORTS, Un as CHEAPEST_PROFILE_NATIVE_AGENT_NAMES, Wn as CHEAPEST_PROFILE_NATIVE_EFFORTS, Xn as CHEAP_PROFILE_NATIVE_EFFORTS, Yn as CHEAP_PROFILE_NATIVE_AGENT_NAMES, a as buildAgentPrompt, fn as CONDENSED_OPERATING_SEQUENCE, l as maxPersonasFor, n as MCP_GROUPS, pn as DEFINITION_OF_GREATNESS, t as GROUP_META, u as personasFor } from "./peer-mcp-personas-DcAErb_d.js";
+import { a as isUnderClaudeConfigMirror, f as writeRuntimeFileSecure, t as PATHS } from "./paths-BnZwolac.js";
+import { C as CHEAP_REVIEWER_ALIAS_ID, S as CHEAP_PLAN_ALIAS_ID, _ as CHEAPEST_GENERAL_PURPOSE_ALIAS_ID, b as CHEAP_EXPLORE_ALIAS_ID, f as BALANCED_EXPLORE_ALIAS_ID, g as CHEAPEST_EXPLORE_ALIAS_ID, h as BALANCED_REVIEWER_ALIAS_ID, m as BALANCED_PLAN_ALIAS_ID, p as BALANCED_GENERAL_PURPOSE_ALIAS_ID, v as CHEAPEST_PLAN_ALIAS_ID, w as LUNA_SCOUT_ALIAS_ID, x as CHEAP_GENERAL_PURPOSE_ALIAS_ID, y as CHEAPEST_REVIEWER_ALIAS_ID } from "./server-setup-CZ3tEsgq.js";
+import { c as FAST_PROFILE_MODELS, d as FAST_PROFILE_NATIVE_MODELS, l as FAST_PROFILE_NATIVE_AGENT_NAMES, u as FAST_PROFILE_NATIVE_EFFORTS } from "./fast-profile-contract-DmsyQQrw.js";
 import { C as MAX_PARALLELISM_RULE, S as MAX_COORDINATOR_PROMPT, T as maxNativePrompt, a as MAX_PROFILE_NATIVE_AGENT_NAMES, i as MAX_PROFILE_MODELS, o as MAX_PROFILE_NATIVE_EFFORTS, s as MAX_PROFILE_NATIVE_MODELS, w as maxNativeDescription, x as MAX_COORDINATOR_DESCRIPTION } from "./max-profile-contract-Bl7I_EOC.js";
-import "./self-invocation-DahN1gw9.js";
-import { a as STRIPPED_AUTH_ROUTING_ENV_KEYS, n as buildCodexProviderConfigFlags } from "./provision-DagZEkdZ.js";
-import { n as buildWorkspaceHeaderHelperCommand } from "./mcp-workspace-header-mXRLE8kg.js";
-import { a as dispatcherAgentName, c as dispatcherTools, n as activeDispatchModes, o as dispatcherDescription, s as dispatcherPrompt } from "./worker-dispatch-B-OA7tvU.js";
+import "./self-invocation-opSXHEs0.js";
+import { a as STRIPPED_AUTH_ROUTING_ENV_KEYS, n as buildCodexProviderConfigFlags } from "./provision-B-a5KUCL.js";
+import { n as buildWorkspaceHeaderHelperCommand } from "./mcp-workspace-header-BIW0SRgs.js";
+import { a as dispatcherAgentName, c as dispatcherTools, n as activeDispatchModes, o as dispatcherDescription, s as dispatcherPrompt } from "./worker-dispatch-CcQygiAA.js";
 import consola from "consola";
 import path from "node:path";
 import { randomBytes } from "node:crypto";
@@ -222,12 +222,15 @@ function nonEmptyModel(id) {
 function fileToolSteer(bashUses) {
 	return `Use the dedicated Edit/Write/Read tools for file changes and Grep/Glob for search; reserve Bash for running ${bashUses}, tests, and git. Do not shell out (sed/awk/python/here-docs) to read or edit files.`;
 }
-/** The read-only half of `fileToolSteer`, for agents that never write. */
-function readOnlyToolSteer() {
-	return "Use Read to read files and Grep/Glob plus the semantic code search tool to find them; Bash is for read-only inspection such as git log, git blame, and git show. Do not modify any file, and do not run mutating commands.";
+/** The read-only half of `fileToolSteer`, for agents that never write.
+*  Names the semantic code-search tool only when the launch enabled it;
+*  otherwise the `code` tool is lexical-only and naming semantic search
+*  would send the agent at a mode that just degrades to lexical. */
+function readOnlyToolSteer(semanticAvailable = true) {
+	return `Use Read to read files and ${semanticAvailable ? "Grep/Glob plus the semantic code search tool" : "Grep/Glob"} to find them; Bash is for read-only inspection such as git log, git blame, and git show. Do not modify any file, and do not run mutating commands.`;
 }
-function reviewerToolSteer() {
-	return "Use Read to read files and Grep/Glob plus the semantic code search tool to find them. Use Bash for builds, tests, reproductions, and read-only git inspection; do not modify source-controlled files or use the shell to edit them.";
+function reviewerToolSteer(semanticAvailable = true) {
+	return `Use Read to read files and ${semanticAvailable ? "Grep/Glob plus the semantic code search tool" : "Grep/Glob"} to find them. Use Bash for builds, tests, reproductions, and read-only git inspection; do not modify source-controlled files or use the shell to edit them.`;
 }
 /**
 * `tools:` allowlist for read-only natives (`scout`, fast `Explore`, `brainstorm`), modelled
@@ -375,15 +378,103 @@ function buildMaxProfileAgentDefinitions(opts) {
 	for (const name of Object.keys(out)) if (name !== "worker-browse" && !roster.has(name)) delete out[name];
 	return out;
 }
+/**
+* Shared prompt bodies for the pinned four-agent profiles
+* (`fast`/`cheap`/`cheap1m`/`cheapest`/`balanced`).
+*
+* Cost doctrine, cheapest to most expensive:
+*   1. LEXICAL code search (`mode:"lexical"`/`"exact"`) — zero model cost,
+*      exact symbols, filenames, errors, routes, config keys. Always first.
+*   2. SEMANTIC code search (`mode:"semantic"`) — meaning-ranked via ColBERT,
+*      for concepts and intent questions. Mentioned ONLY when the launch
+*      enabled it (`semanticSearchAvailable`); otherwise the `code` tool is
+*      lexical-only and agents must not be told to reach for semantic.
+*   3. `Explore` (budget model) — reads the narrowed files and synthesizes a
+*      file:line evidence report. Only the conclusion flows upward.
+*   4. `Plan` (Sol) / `reviewer` (Sonnet/Luna/Gemini) / `oracle` — expensive
+*      models see ONLY the synthesized subset, never raw search output.
+*
+* Per-mode tuning:
+*   - `cheapest` (straightforward tasks): implicit delegation. The lead
+*     handles simple work inline; role descriptions carry no "use
+*     proactively" push and no fan-out instruction, so the lead does not pay
+*     handoff overhead for work it already holds context for.
+*   - `fast`/`cheap`/`cheap1m`/`balanced` (complex tasks): explicit
+*     delegation. Descriptions push proactive parallel `Explore` fan-out,
+*     `Plan`-first architecture, `General-Purpose` mixed execution, and
+*     post-integration `reviewer` verification.
+*/
+function pinnedSearchGuidance(semanticAvailable, capitalize = true) {
+	const lexical = `${capitalize ? "Start with" : "start with"} exact lexical and symbol search (\`code\` with mode:"lexical" or "exact", plus Grep/Glob) for symbols, filenames, errors, routes, flags, and config keys — it costs no model call`;
+	if (!semanticAvailable) return `${lexical}. Pair it with surrounding context lines so callers, guards, and types are visible without a second round trip, and inspect the file whenever the surrounding logic determines the answer.`;
+	return `${lexical}; pair semantic search (meaning-ranked, best for intent/concept questions where literal keywords may not appear) with exact lexical and symbol search so that neither naming drift nor synonym mismatch hides a result. Include surrounding context lines in your search results so that callers, guards, and types are visible without a second round trip, and inspect the file whenever the surrounding logic determines the answer.`;
+}
+/**
+* Implicit (cheapest) tuning is composed from the SAME shared remainder as
+* the explicit base — only the proactive-delegation head sentences differ.
+* The tails below are each written once and copied by both variants, so a
+* fix to shared wording lands everywhere and the implicit/explicit diff
+* stays exactly the few sentences that carry the tuning.
+*/
+const EXPLORE_DESC_TAIL = "Use when the question spans more than a couple of files. Do not use for planning, edits, or single-file reads. Returns a structured evidence report with file:line citations. Never edits files.";
+function pinnedExploreDescription(explicit) {
+	return (explicit ? "Read-only codebase exploration specialist. Use proactively, and launch several in parallel via `Task(subagent_type:\"Explore\")`, to map architecture, trace call chains, or locate the files and symbols a task will touch. " : "Read-only codebase exploration specialist for mapping architecture, tracing call chains, or locating the files and symbols a task touches. ") + EXPLORE_DESC_TAIL;
+}
+function pinnedExplorePrompt(opts) {
+	const searchGuidance = pinnedSearchGuidance(opts.semanticAvailable, !opts.explicit);
+	return `You are a codebase exploration specialist. Your mission is to map repository structure, discover implementation patterns, trace call chains, and locate the exact files, symbols, and declarations that are relevant to the request. This is read-only work. Do not modify files, do not propose diffs, and do not delegate to other agents. You cannot ask clarifying questions mid-run: ground every answer in repository evidence. If the request is ambiguous, explore the most probable interpretations and record the ambiguity in your report. Start broad, then converge. ${opts.explicit ? "Issue independent searches in parallel in one turn rather than one at a time, and " : ""}${searchGuidance} Confirm every claim at the source before you report it. Stop when further searching stops changing your answer. When you can name the exact files and lines a change would touch, you are done. Report what the repository contains, not what it ought to contain. Do not design a solution or recommend an approach. Return a self-contained result the lead can act on immediately without needing to re-run your discovery.
+
+Return format:
+Answer: a direct response to what was asked, in a few sentences.
+Inventory: each relevant file and symbol as file:line, with a one-line description of its role.
+Entry points: where control enters this area, as file:line.
+Conventions in use: the patterns, idioms, error handling, and test style that any change here would be expected to follow, each with a file:line example.
+Gaps and unknowns: what you could not confirm, and where you would look next.
+
+` + readOnlyToolSteer(opts.semanticAvailable);
+}
+const PLAN_DESC_HEAD = "Architecture and implementation planning specialist";
+const PLAN_DESC_TAIL = " Returns a decision-complete, ordered implementation plan with runnable acceptance criteria. Never edits files.";
+function pinnedPlanDescription(explicit) {
+	return PLAN_DESC_HEAD + (explicit ? ". Use proactively in plan mode, and whenever sequencing, cross-boundary interfaces, invariants, migration risk, or acceptance criteria deserve a dedicated pass before any code is written. Delegates repository discovery to `Explore` rather than reading broadly itself." : " for sequencing, cross-boundary interfaces, invariants, migration risk, and acceptance criteria before any code is written.") + PLAN_DESC_TAIL;
+}
+function pinnedPlanPrompt(opts) {
+	return `You are a software architect and planning specialist. Your mission is to turn a request into a decision-complete implementation plan: an ordered sequence of changes, the invariants that must hold throughout, and acceptance criteria a reviewer can actually run. This is read-only work. Do not modify repository files. Produce the architecture, sequencing, and acceptance criteria for the lead to synthesize and execute. Plan is an advisory planning capability, not an approval gate. Separate discoverable facts from genuine choices. ${opts.explicit ? "Do not sweep the repository yourself: delegate discovery to `Explore`, launching one or more `Explore` subagents in parallel with scoped evidence questions, then read directly only the files needed to resolve trade-offs and write executable steps. " : "Do not sweep the repository broadly yourself: keep discovery narrow, read directly only the files needed to resolve trade-offs and write executable steps, and record any repository fact you could not confirm as an explicit gap. "}Escalate only genuine product or architectural trade-offs, and escalate them as explicit options with consequences and a recommendation, never as an open question. For low-risk details, choose the reading most consistent with the codebase, proceed, and record it as an assumption. When a design trade-off has more than one viable answer and repository evidence cannot settle it, consult Oracle tool with one self-contained brief that states the constraints, the candidate designs, and the evidence you already gathered plus one precise question. If Oracle does not settle it, carry the options and the remaining gap into the plan rather than silently picking one. Delegation: you may invoke Explore and \`reviewer\` for discovery and verification; do not invoke any other subagent. Behavior and code verification belongs to post-implementation review. Write the plan for a General-Purpose execution agent who cannot see your reasoning. Every step must be executable without rediscovering what you already found: name the files, name the interfaces, and state the condition that means the step is done. Prefer the smallest design that satisfies the requirement and fits the conventions already in the codebase. Mark steps that are independent of each other and can run concurrently.
+
+Return format:
+Objective: what will be true when this is complete.
+Architectural invariants: what must hold before, during, and after every step.
+Interface contracts: signatures, types, error and edge-case behaviour at each boundary the change crosses.
+Execution steps: ordered. Each names the files it touches, the change it makes, and its done condition. Mark steps that are independent of each other and can run concurrently.
+Acceptance criteria: the exact commands to run and the observable result that counts as passing.
+Critical files: the files an executor must read before starting, as file:line, with why each matters.
+Open questions: any unresolved trade-off, as options with a recommendation. Omit this section if there are none.
+
+` + readOnlyToolSteer(opts.semanticAvailable);
+}
+const GENERAL_PURPOSE_DESC_TAIL = "Drives to a verified end state with changed files and evidence. Do not use for pure discovery (use Explore) or verification-only (use reviewer).";
+function pinnedGeneralPurposeDescription(explicit) {
+	return (explicit ? "Autonomous multi-step execution agent. Use proactively for open-ended or mixed tasks combining investigation, tool workflows, and code changes where the approach emerges during work. Follows a Plan handoff when one exists and otherwise investigates before acting. " : "Autonomous multi-step execution agent for open-ended or mixed tasks combining investigation, tool workflows, and code changes where the approach emerges during work. ") + GENERAL_PURPOSE_DESC_TAIL;
+}
+function pinnedGeneralPurposePrompt() {
+	return "You are an autonomous execution specialist for mixed, multi-step work. Your mission is to take an open-ended task from investigation through implementation to a verified end state within this turn. Keep going until the task is genuinely done. Do not stop at a diagnosis, a partial fix, or a plan when the request asked for a change. Ground discovery in repository truth. For low-risk ambiguities, choose the interpretation most consistent with the repository, proceed, and record it as an assumption in your report. For material intent gaps that would alter product behavior or security, surface concrete options and a recommendation to the lead. When a Plan handoff exists, follow its ordered steps and acceptance criteria; do not rediscover what the plan already settled — read the critical files it names, execute each step's done condition, and report any step whose premise proves wrong instead of silently replanning. Investigate before you act. Confirm your assumptions against the actual code rather than against the request's description of it. After every command, read the real output and let it decide the next step. When something fails, diagnose the specific cause before trying again. If repeated attempts fail for the same reason and no new information has emerged, stop retrying: re-examine the underlying assumption and take a different path. Escalate rather than expand. If the task turns out to require a change the lead did not sanction, complete the sanctioned part and report the rest as a recommendation. If the task collapses to pure discovery or a single settled edit, do that slice and report the remainder as a recommendation. Do not expand scope. Match the conventions, structure, and test style already present in the files you touch. The lead owns final integration. Verify before you report. Run the builds, linters, or test commands relevant to what you changed. Quote the command run, exit status, and concise decisive output verbatim; if output is long, summarize the middle and quote the pass/fail lines. Report your changes and test output directly to the caller. Post-integration review is owned by the lead. Return a self-contained result the lead can act on immediately.\n\nReturn format:\nOutcome: what is now true, and whether the task is complete.\nActions taken: what you did, in order.\nChanged files: each as file:line, with a one-line description of the change.\nVerification: the commands you ran, exit status, and decisive output.\nAssumptions: every interpretation you had to choose.\nRemaining items: anything deliberately not done, and why.\n\n" + fileToolSteer("builds");
+}
+const REVIEWER_DESC_TAIL = "Runs builds/tests itself rather than assuming them. Returns SHIP / FIX / BLOCK with reproducible evidence. Never edits source.";
+function pinnedReviewerDescription(explicit) {
+	return (explicit ? "Adversarial evidence-based reviewer. Use proactively post-integration after behavior-changing, cross-boundary, or risk-sensitive changes, before done. " : "Adversarial evidence-based reviewer for behavior-changing, cross-boundary, or risk-sensitive changes. ") + REVIEWER_DESC_TAIL;
+}
+function pinnedReviewerPrompt(semanticAvailable = true) {
+	return "You are an adversarial code reviewer. Your job is not to confirm that the change works. Your job is to find the conditions under which it does not. Think carefully about the plausible failure modes of this change before you start running commands, so that what you run is chosen to expose them. Read before you judge. Inspect the changed files and relevant surrounding context, callers of affected call sites, and tests that claim to cover the change, sized to the identified risks of the change. Then verify by execution. Run the builds, linters, or test suites relevant to what changed, and any command that would surface the specific failure you suspect. Verification means output you observed. Never state that something passes, compiles, or is covered unless you ran it and read the result; where you could not run something, say so explicitly rather than inferring the outcome. Probe deliberately: boundary and empty inputs, error and early-return paths, concurrency and ordering, resource acquisition and cleanup on the failure path, partial failure and retry, backward compatibility of any changed interface, handling of untrusted input, and whether the new tests would actually fail if the change were reverted. Judge against the bar the repository already holds itself to, not an abstract ideal. Do not soften a real finding, and do not manufacture findings to appear thorough. If the change is correct and verified, say so. Do not modify source code and do not delegate to other agents. You may run build, test, and read-only inspection commands; do not run commands that alter tracked source files or touch remote infrastructure (transient build cache or test runner side effects are expected). Return a self-contained result the lead can act on immediately.\n\nReturn format. Line one must be exactly one of:\nVERDICT: SHIP\nVERDICT: FIX\nVERDICT: BLOCK\n\nSHIP means you found no blocking defect and your verification ran clean. FIX means the approach is sound but specific defects must be corrected. BLOCK means the approach itself is wrong, or verification could not be run at all.\n\nThen, using the repository's severity taxonomy:\nCritical: blocking defects (correctness, security, data loss). Each with file:line, the concrete scenario in which it fails, and how you confirmed it.\nImportant: non-blocking issues that should be fixed before shipping. Each with file:line and impact.\nSuggestion: non-blocking improvements or stylistic suggestions.\nEvidence: the commands you ran, exit status, and decisive output.\nUnverified surface: what you could not exercise, and why.\n\n" + reviewerToolSteer(semanticAvailable);
+}
 /** Build the literal `-m fast` native roster. This is intentionally separate
 * from the standard definitions: the names overlap, but their role bodies,
 * fixed model assignments, and efforts are profile contracts. */
 function buildFastProfileAgentDefinitions(opts) {
 	const modelFor = (value, fallback) => nonEmptyModel(value) ?? fallback;
 	const planModel = modelFor(opts.fastPlanModel, FAST_PROFILE_NATIVE_MODELS.Plan);
-	const generalModel = modelFor(opts.fastGeneralPurposeModel, FAST_PROFILE_NATIVE_MODELS["general-purpose"]);
-	const implementerModel = modelFor(opts.fastImplementerModel, FAST_PROFILE_NATIVE_MODELS.implementer);
+	const generalModel = modelFor(opts.fastGeneralPurposeModel, FAST_PROFILE_NATIVE_MODELS["General-Purpose"]);
 	const reviewerModel = modelFor(opts.fastReviewerModel, FAST_PROFILE_NATIVE_MODELS.reviewer);
+	const semanticAvailable = opts.semanticSearchAvailable === true;
 	const searchKey = opts.groupKeys.search ?? GROUP_META.search.preferredKey;
 	const peersKey = peersKeyOf(opts.groupKeys);
 	const searchMcpServers = opts.serverUrl ? { [searchKey]: httpEntryFor(opts.serverUrl, "search", opts.nonce, opts.workspaceHeaderCmd) } : void 0;
@@ -407,16 +498,22 @@ function buildFastProfileAgentDefinitions(opts) {
 	const effort = (name) => FAST_PROFILE_NATIVE_EFFORTS[name];
 	const out = {
 		Explore: {
-			description: "Read-only codebase exploration specialist. Use proactively, and launch several in parallel via `Task(subagent_type:\"Explore\")`, to map architecture, trace call chains, or locate the files and symbols a task will touch. Use when the question spans more than a couple of files. Do not use for planning, edits, or single-file reads. Returns a structured evidence report with file:line citations. Never edits files.",
-			prompt: "You are a codebase exploration specialist. Your mission is to map repository structure, discover implementation patterns, trace call chains, and locate the exact files, symbols, and declarations that are relevant to the request. This is read-only work. Do not modify files, do not propose diffs, and do not delegate to other agents. You cannot ask clarifying questions mid-run: ground every answer in repository evidence. If the request is ambiguous, explore the most probable interpretations and record the ambiguity in your report. Start broad, then converge. Issue independent searches in parallel in one turn rather than one at a time, and pair semantic search with exact lexical and symbol search so that neither naming drift nor synonym mismatch hides a result. Include surrounding context lines in your search results so that callers, guards, and types are visible without a second round trip, and inspect the file whenever the surrounding logic determines the answer. Confirm every claim at the source before you report it. Stop when further searching stops changing your answer. When you can name the exact files and lines a change would touch, you are done. Report what the repository contains, not what it ought to contain. Do not design a solution or recommend an approach. Return a self-contained result the lead can act on immediately without needing to re-run your discovery.\n\nReturn format:\nAnswer: a direct response to what was asked, in a few sentences.\nInventory: each relevant file and symbol as file:line, with a one-line description of its role.\nEntry points: where control enters this area, as file:line.\nConventions in use: the patterns, idioms, error handling, and test style that any change here would be expected to follow, each with a file:line example.\nGaps and unknowns: what you could not confirm, and where you would look next.\n\n" + readOnlyToolSteer(),
+			description: pinnedExploreDescription(true),
+			prompt: pinnedExplorePrompt({
+				explicit: true,
+				semanticAvailable
+			}),
 			tools: readSearchTools,
 			model: decorateGuaranteedOneM(LUNA_SCOUT_ALIAS_ID),
 			effort: effort("Explore"),
 			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
 		},
 		Plan: {
-			description: "Architecture and implementation planning specialist. Use proactively in plan mode, and whenever sequencing, cross-boundary interfaces, invariants, migration risk, or acceptance criteria deserve a dedicated pass before any code is written. Delegates repository discovery to `Explore` rather than reading broadly itself. Returns a decision-complete, ordered implementation plan with runnable acceptance criteria. Never edits files.",
-			prompt: "You are a software architect and planning specialist. Your mission is to turn a request into a decision-complete implementation plan: an ordered sequence of changes, the invariants that must hold throughout, and acceptance criteria a reviewer can actually run. This is read-only work. Do not modify repository files. Produce the architecture, sequencing, and acceptance criteria for the lead to synthesize and execute. Plan is an advisory planning capability, not an approval gate. Separate discoverable facts from genuine choices. Do not sweep the repository yourself: delegate discovery to `Explore`, launching one or more `Explore` subagents in parallel with scoped evidence questions, then read directly only the files needed to resolve trade-offs and write executable steps. Escalate only genuine product or architectural trade-offs, and escalate them as explicit options with consequences and a recommendation, never as an open question. For low-risk details, choose the reading most consistent with the codebase, proceed, and record it as an assumption. When a design trade-off has more than one viable answer and repository evidence cannot settle it, consult Oracle tool with one self-contained brief that states the constraints, the candidate designs, and the evidence you already gathered plus one precise question. If Oracle does not settle it, carry the options and the remaining gap into the plan rather than silently picking one. Delegation: you may invoke Explore and `reviewer` for discovery and verification; do not invoke any other subagent. Behavior and code verification belongs to post-implementation review. Write the plan for an implementer who cannot see your reasoning. Every step must be executable without rediscovering what you already found: name the files, name the interfaces, and state the condition that means the step is done. Prefer the smallest design that satisfies the requirement and fits the conventions already in the codebase. Mark steps that are independent of each other and can run concurrently.\n\nReturn format:\nObjective: what will be true when this is complete.\nArchitectural invariants: what must hold before, during, and after every step.\nInterface contracts: signatures, types, error and edge-case behaviour at each boundary the change crosses.\nExecution steps: ordered. Each names the files it touches, the change it makes, and its done condition. Mark steps that are independent of each other and can run concurrently.\nAcceptance criteria: the exact commands to run and the observable result that counts as passing.\nCritical files: the files an implementer must read before starting, as file:line, with why each matters.\nOpen questions: any unresolved trade-off, as options with a recommendation. Omit this section if there are none.\n\n" + readOnlyToolSteer(),
+			description: pinnedPlanDescription(true),
+			prompt: pinnedPlanPrompt({
+				explicit: true,
+				semanticAvailable
+			}),
 			tools: planTools,
 			model: oneM(planModel),
 			effort: effort("Plan"),
@@ -425,23 +522,16 @@ function buildFastProfileAgentDefinitions(opts) {
 				...peersMcpServers ?? {}
 			}
 		},
-		"general-purpose": {
-			description: "Autonomous multi-step execution agent. Use proactively for open-ended or mixed tasks combining investigation, tool workflows, and code changes where the approach emerges during work. Drives to a verified end state with changed files and evidence. Do not use for pure discovery (use Explore), settled bounded edits (use implementer), or verification-only (use reviewer).",
-			prompt: "You are an autonomous execution specialist for mixed, multi-step work. Your mission is to take an open-ended task from investigation through implementation to a verified end state within this turn. Keep going until the task is genuinely done. Do not stop at a diagnosis, a partial fix, or a plan when the request asked for a change. Ground discovery in repository truth. For low-risk ambiguities, choose the interpretation most consistent with the repository, proceed, and record it as an assumption in your report. For material intent gaps that would alter product behavior or security, surface concrete options and a recommendation to the lead. Investigate before you act. Confirm your assumptions against the actual code rather than against the request's description of it. After every command, read the real output and let it decide the next step. When something fails, diagnose the specific cause before trying again. If repeated attempts fail for the same reason and no new information has emerged, stop retrying: re-examine the underlying assumption and take a different path. Escalate rather than expand. If the task turns out to require a change the lead did not sanction, complete the sanctioned part and report the rest as a recommendation. If the task collapses to pure discovery or a single settled edit, do that slice and report the remainder as a recommendation. Do not expand scope. Match the conventions, structure, and test style already present in the files you touch. The lead owns final integration. Verify before you report. Run the builds, linters, or test commands relevant to what you changed. Quote the command run, exit status, and concise decisive output verbatim; if output is long, summarize the middle and quote the pass/fail lines. Report your changes and test output directly to the caller. Post-integration review is owned by the lead. Return a self-contained result the lead can act on immediately.\n\nReturn format:\nOutcome: what is now true, and whether the task is complete.\nActions taken: what you did, in order.\nChanged files: each as file:line, with a one-line description of the change.\nVerification: the commands you ran, exit status, and decisive output.\nAssumptions: every interpretation you had to choose.\nRemaining items: anything deliberately not done, and why.\n\n" + fileToolSteer("builds, tests, and git"),
+		"General-Purpose": {
+			description: pinnedGeneralPurposeDescription(true),
+			prompt: pinnedGeneralPurposePrompt(),
 			model: oneM(generalModel),
-			effort: effort("general-purpose"),
-			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
-		},
-		implementer: {
-			description: "Surgical implementation specialist for bounded changes with settled scope. Use proactively when what and where are decided, to make the change cleanly, match conventions, and verify it. Use Plan first if the approach is still open. Returns modified files with verbatim verification. Keeps the diff tight.",
-			prompt: "You are an implementation specialist. Your mission is to make bounded, surgical code changes that satisfy a settled requirement and look as though they were always part of the codebase. Before you edit, inspect the target files and relevant adjacent code, so that your change matches the existing idioms, error handling, logging, and test style. For a bug fix, reproduce the failure first and keep that reproduction as your success signal. While you edit, keep the change inside the requested scope and keep the diff tight and focused. Apply changes with the file editing tools; printing a patch in your response does not modify the file. Match the surrounding formatting, naming, and structure. Write a comment only where the reason for the code is non-obvious, and let well-named identifiers carry what the code does. If the requirement turns out to need work outside the agreed scope, implement the agreed change and report the additional work as a recommendation. For low-risk ambiguities, choose the interpretation most consistent with the surrounding code, proceed, and state the assumption in your report. For material intent gaps, surface concrete options and a recommendation to the lead. After you edit, run the builds, linters, or tests relevant to what you changed. Report the command, exit code, and decisive output verbatim. If a check fails, diagnose the cause before retrying; do not retry the same failing action without new information. Never claim something passes, compiles, or is covered unless you ran it and read the result. Report your changes and test output directly to the caller. Post-integration review is owned by the lead. Return a self-contained result the lead can act on immediately.\n\nReturn format:\nModified files: each as file:line, with a one-line description of the change.\nVerification: each command you ran, exit status, and decisive output.\nAssumptions and deferred work: interpretations you chose, and anything you deliberately left undone.\n\n" + fileToolSteer("builds, tests, and git"),
-			model: oneM(implementerModel),
-			effort: effort("implementer"),
+			effort: effort("General-Purpose"),
 			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
 		},
 		reviewer: {
-			description: "Adversarial evidence-based reviewer. Use proactively post-integration after behavior-changing, cross-boundary, or risk-sensitive changes, and always after `implementer`, before done. Runs builds/tests itself rather than assuming them. Returns SHIP / FIX / BLOCK with reproducible evidence. Never edits source.",
-			prompt: "You are an adversarial code reviewer. Your job is not to confirm that the change works. Your job is to find the conditions under which it does not. Think carefully about the plausible failure modes of this change before you start running commands, so that what you run is chosen to expose them. Read before you judge. Inspect the changed files and relevant surrounding context, callers of affected call sites, and tests that claim to cover the change, sized to the identified risks of the change. Then verify by execution. Run the builds, linters, or test suites relevant to what changed, and any command that would surface the specific failure you suspect. Verification means output you observed. Never state that something passes, compiles, or is covered unless you ran it and read the result; where you could not run something, say so explicitly rather than inferring the outcome. Probe deliberately: boundary and empty inputs, error and early-return paths, concurrency and ordering, resource acquisition and cleanup on the failure path, partial failure and retry, backward compatibility of any changed interface, handling of untrusted input, and whether the new tests would actually fail if the change were reverted. Judge against the bar the repository already holds itself to, not an abstract ideal. Do not soften a real finding, and do not manufacture findings to appear thorough. If the change is correct and verified, say so. Do not modify source code and do not delegate to other agents. You may run build, test, and read-only inspection commands; do not run commands that alter tracked source files or touch remote infrastructure (transient build cache or test runner side effects are expected). Return a self-contained result the lead can act on immediately.\n\nReturn format. Line one must be exactly one of:\nVERDICT: SHIP\nVERDICT: FIX\nVERDICT: BLOCK\n\nSHIP means you found no blocking defect and your verification ran clean. FIX means the approach is sound but specific defects must be corrected. BLOCK means the approach itself is wrong, or verification could not be run at all.\n\nThen, using the repository's severity taxonomy:\nCritical: blocking defects (correctness, security, data loss). Each with file:line, the concrete scenario in which it fails, and how you confirmed it.\nImportant: non-blocking issues that should be fixed before shipping. Each with file:line and impact.\nSuggestion: non-blocking improvements or stylistic suggestions.\nEvidence: the commands you ran, exit status, and decisive output.\nUnverified surface: what you could not exercise, and why.\n\n" + reviewerToolSteer(),
+			description: pinnedReviewerDescription(true),
+			prompt: pinnedReviewerPrompt(semanticAvailable),
 			model: oneM(reviewerModel),
 			effort: effort("reviewer"),
 			tools: readSearchTools,
@@ -463,7 +553,7 @@ function buildFastProfileAgentDefinitions(opts) {
 	for (const name of Object.keys(out)) if (name !== "worker-browse" && !roster.has(name)) delete out[name];
 	return out;
 }
-/** Build the literal `-m cheap` native roster. Identical fixed five-agent
+/** Build the literal `-m cheap` native roster. Identical fixed four-agent
 * surface and roles to `-m fast`, but every SUBAGENT model is a BARE
 * router-owned alias (`gh-router-cheap-*`, no `[1m]` bracket) rather than a
 * real catalog id. A bare real id is resolved by Claude Code against the live
@@ -477,8 +567,8 @@ function buildCheapProfileAgentDefinitions(opts) {
 	const exploreModel = CHEAP_EXPLORE_ALIAS_ID;
 	const planModel = CHEAP_PLAN_ALIAS_ID;
 	const generalModel = CHEAP_GENERAL_PURPOSE_ALIAS_ID;
-	const implementerModel = CHEAP_IMPLEMENTER_ALIAS_ID;
 	const reviewerModel = CHEAP_REVIEWER_ALIAS_ID;
+	const semanticAvailable = opts.semanticSearchAvailable === true;
 	const searchKey = opts.groupKeys.search ?? GROUP_META.search.preferredKey;
 	const peersKey = peersKeyOf(opts.groupKeys);
 	const searchMcpServers = opts.serverUrl ? { [searchKey]: httpEntryFor(opts.serverUrl, "search", opts.nonce, opts.workspaceHeaderCmd) } : void 0;
@@ -501,16 +591,22 @@ function buildCheapProfileAgentDefinitions(opts) {
 	const effort = (name) => CHEAP_PROFILE_NATIVE_EFFORTS[name];
 	const out = {
 		Explore: {
-			description: "Read-only codebase exploration specialist. Use proactively, and launch several in parallel via `Task(subagent_type:\"Explore\")`, to map architecture, trace call chains, or locate the files and symbols a task will touch. Use when the question spans more than a couple of files. Do not use for planning, edits, or single-file reads. Returns a structured evidence report with file:line citations. Never edits files.",
-			prompt: "You are a codebase exploration specialist. Your mission is to map repository structure, discover implementation patterns, trace call chains, and locate the exact files, symbols, and declarations that are relevant to the request. This is read-only work. Do not modify files, do not propose diffs, and do not delegate to other agents. You cannot ask clarifying questions mid-run: ground every answer in repository evidence. If the request is ambiguous, explore the most probable interpretations and record the ambiguity in your report. Start broad, then converge. Issue independent searches in parallel in one turn rather than one at a time, and pair semantic search with exact lexical and symbol search so that neither naming drift nor synonym mismatch hides a result. Include surrounding context lines in your search results so that callers, guards, and types are visible without a second round trip, and inspect the file whenever the surrounding logic determines the answer. Confirm every claim at the source before you report it. Stop when further searching stops changing your answer. When you can name the exact files and lines a change would touch, you are done. Report what the repository contains, not what it ought to contain. Do not design a solution or recommend an approach. Return a self-contained result the lead can act on immediately without needing to re-run your discovery.\n\nReturn format:\nAnswer: a direct response to what was asked, in a few sentences.\nInventory: each relevant file and symbol as file:line, with a one-line description of its role.\nEntry points: where control enters this area, as file:line.\nConventions in use: the patterns, idioms, error handling, and test style that any change here would be expected to follow, each with a file:line example.\nGaps and unknowns: what you could not confirm, and where you would look next.\n\n" + readOnlyToolSteer(),
+			description: pinnedExploreDescription(true),
+			prompt: pinnedExplorePrompt({
+				explicit: true,
+				semanticAvailable
+			}),
 			tools: readSearchTools,
 			model: exploreModel,
 			effort: effort("Explore"),
 			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
 		},
 		Plan: {
-			description: "Architecture and implementation planning specialist. Use proactively in plan mode, and whenever sequencing, cross-boundary interfaces, invariants, migration risk, or acceptance criteria deserve a dedicated pass before any code is written. Delegates repository discovery to `Explore` rather than reading broadly itself. Returns a decision-complete, ordered implementation plan with runnable acceptance criteria. Never edits files.",
-			prompt: "You are a software architect and planning specialist. Your mission is to turn a request into a decision-complete implementation plan: an ordered sequence of changes, the invariants that must hold throughout, and acceptance criteria a reviewer can actually run. This is read-only work. Do not modify repository files. Produce the architecture, sequencing, and acceptance criteria for the lead to synthesize and execute. Plan is an advisory planning capability, not an approval gate. Separate discoverable facts from genuine choices. Do not sweep the repository yourself: delegate discovery to `Explore`, launching one or more `Explore` subagents in parallel with scoped evidence questions, then read directly only the files needed to resolve trade-offs and write executable steps. Escalate only genuine product or architectural trade-offs, and escalate them as explicit options with consequences and a recommendation, never as an open question. For low-risk details, choose the reading most consistent with the codebase, proceed, and record it as an assumption. When a design trade-off has more than one viable answer and repository evidence cannot settle it, consult Oracle tool with one self-contained brief that states the constraints, the candidate designs, and the evidence you already gathered plus one precise question. If Oracle does not settle it, carry the options and the remaining gap into the plan rather than silently picking one. Delegation: you may invoke Explore and `reviewer` for discovery and verification; do not invoke any other subagent. Behavior and code verification belongs to post-implementation review. Write the plan for an implementer who cannot see your reasoning. Every step must be executable without rediscovering what you already found: name the files, name the interfaces, and state the condition that means the step is done. Prefer the smallest design that satisfies the requirement and fits the conventions already in the codebase. Mark steps that are independent of each other and can run concurrently.\n\nReturn format:\nObjective: what will be true when this is complete.\nArchitectural invariants: what must hold before, during, and after every step.\nInterface contracts: signatures, types, error and edge-case behaviour at each boundary the change crosses.\nExecution steps: ordered. Each names the files it touches, the change it makes, and its done condition. Mark steps that are independent of each other and can run concurrently.\nAcceptance criteria: the exact commands to run and the observable result that counts as passing.\nCritical files: the files an implementer must read before starting, as file:line, with why each matters.\nOpen questions: any unresolved trade-off, as options with a recommendation. Omit this section if there are none.\n\n" + readOnlyToolSteer(),
+			description: pinnedPlanDescription(true),
+			prompt: pinnedPlanPrompt({
+				explicit: true,
+				semanticAvailable
+			}),
 			tools: planTools,
 			model: planModel,
 			effort: effort("Plan"),
@@ -519,23 +615,16 @@ function buildCheapProfileAgentDefinitions(opts) {
 				...peersMcpServers ?? {}
 			}
 		},
-		"general-purpose": {
-			description: "Autonomous multi-step execution agent. Use proactively for open-ended or mixed tasks combining investigation, tool workflows, and code changes where the approach emerges during work. Drives to a verified end state with changed files and evidence. Do not use for pure discovery (use Explore), settled bounded edits (use implementer), or verification-only (use reviewer).",
-			prompt: "You are an autonomous execution specialist for mixed, multi-step work. Your mission is to take an open-ended task from investigation through implementation to a verified end state within this turn. Keep going until the task is genuinely done. Do not stop at a diagnosis, a partial fix, or a plan when the request asked for a change. Ground discovery in repository truth. For low-risk ambiguities, choose the interpretation most consistent with the repository, proceed, and record it as an assumption in your report. For material intent gaps that would alter product behavior or security, surface concrete options and a recommendation to the lead. Investigate before you act. Confirm your assumptions against the actual code rather than against the request's description of it. After every command, read the real output and let it decide the next step. When something fails, diagnose the specific cause before trying again. If repeated attempts fail for the same reason and no new information has emerged, stop retrying: re-examine the underlying assumption and take a different path. Escalate rather than expand. If the task turns out to require a change the lead did not sanction, complete the sanctioned part and report the rest as a recommendation. If the task collapses to pure discovery or a single settled edit, do that slice and report the remainder as a recommendation. Do not expand scope. Match the conventions, structure, and test style already present in the files you touch. The lead owns final integration. Verify before you report. Run the builds, linters, or test commands relevant to what you changed. Quote the command run, exit status, and concise decisive output verbatim; if output is long, summarize the middle and quote the pass/fail lines. Report your changes and test output directly to the caller. Post-integration review is owned by the lead. Return a self-contained result the lead can act on immediately.\n\nReturn format:\nOutcome: what is now true, and whether the task is complete.\nActions taken: what you did, in order.\nChanged files: each as file:line, with a one-line description of the change.\nVerification: the commands you ran, exit status, and decisive output.\nAssumptions: every interpretation you had to choose.\nRemaining items: anything deliberately not done, and why.\n\n" + fileToolSteer("builds, tests, and git"),
+		"General-Purpose": {
+			description: pinnedGeneralPurposeDescription(true),
+			prompt: pinnedGeneralPurposePrompt(),
 			model: generalModel,
-			effort: effort("general-purpose"),
-			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
-		},
-		implementer: {
-			description: "Surgical implementation specialist for bounded changes with settled scope. Use proactively when what and where are decided, to make the change cleanly, match conventions, and verify it. Use Plan first if the approach is still open. Returns modified files with verbatim verification. Keeps the diff tight.",
-			prompt: "You are an implementation specialist. Your mission is to make bounded, surgical code changes that satisfy a settled requirement and look as though they were always part of the codebase. Before you edit, inspect the target files and relevant adjacent code, so that your change matches the existing idioms, error handling, logging, and test style. For a bug fix, reproduce the failure first and keep that reproduction as your success signal. While you edit, keep the change inside the requested scope and keep the diff tight and focused. Apply changes with the file editing tools; printing a patch in your response does not modify the file. Match the surrounding formatting, naming, and structure. Write a comment only where the reason for the code is non-obvious, and let well-named identifiers carry what the code does. If the requirement turns out to need work outside the agreed scope, implement the agreed change and report the additional work as a recommendation. For low-risk ambiguities, choose the interpretation most consistent with the surrounding code, proceed, and state the assumption in your report. For material intent gaps, surface concrete options and a recommendation to the lead. After you edit, run the builds, linters, or tests relevant to what you changed. Report the command, exit code, and decisive output verbatim. If a check fails, diagnose the cause before retrying; do not retry the same failing action without new information. Never claim something passes, compiles, or is covered unless you ran it and read the result. Report your changes and test output directly to the caller. Post-integration review is owned by the lead. Return a self-contained result the lead can act on immediately.\n\nReturn format:\nModified files: each as file:line, with a one-line description of the change.\nVerification: each command you ran, exit status, and decisive output.\nAssumptions and deferred work: interpretations you chose, and anything you deliberately left undone.\n\n" + fileToolSteer("builds, tests, and git"),
-			model: implementerModel,
-			effort: effort("implementer"),
+			effort: effort("General-Purpose"),
 			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
 		},
 		reviewer: {
-			description: "Adversarial evidence-based reviewer. Use proactively post-integration after behavior-changing, cross-boundary, or risk-sensitive changes, and always after `implementer`, before done. Runs builds/tests itself rather than assuming them. Returns SHIP / FIX / BLOCK with reproducible evidence. Never edits source.",
-			prompt: "You are an adversarial code reviewer. Your job is not to confirm that the change works. Your job is to find the conditions under which it does not. Think carefully about the plausible failure modes of this change before you start running commands, so that what you run is chosen to expose them. Read before you judge. Inspect the changed files and relevant surrounding context, callers of affected call sites, and tests that claim to cover the change, sized to the identified risks of the change. Then verify by execution. Run the builds, linters, or test suites relevant to what changed, and any command that would surface the specific failure you suspect. Verification means output you observed. Never state that something passes, compiles, or is covered unless you ran it and read the result; where you could not run something, say so explicitly rather than inferring the outcome. Probe deliberately: boundary and empty inputs, error and early-return paths, concurrency and ordering, resource acquisition and cleanup on the failure path, partial failure and retry, backward compatibility of any changed interface, handling of untrusted input, and whether the new tests would actually fail if the change were reverted. Judge against the bar the repository already holds itself to, not an abstract ideal. Do not soften a real finding, and do not manufacture findings to appear thorough. If the change is correct and verified, say so. Do not modify source code and do not delegate to other agents. You may run build, test, and read-only inspection commands; do not run commands that alter tracked source files or touch remote infrastructure (transient build cache or test runner side effects are expected). Return a self-contained result the lead can act on immediately.\n\nReturn format. Line one must be exactly one of:\nVERDICT: SHIP\nVERDICT: FIX\nVERDICT: BLOCK\n\nSHIP means you found no blocking defect and your verification ran clean. FIX means the approach is sound but specific defects must be corrected. BLOCK means the approach itself is wrong, or verification could not be run at all.\n\nThen, using the repository's severity taxonomy:\nCritical: blocking defects (correctness, security, data loss). Each with file:line, the concrete scenario in which it fails, and how you confirmed it.\nImportant: non-blocking issues that should be fixed before shipping. Each with file:line and impact.\nSuggestion: non-blocking improvements or stylistic suggestions.\nEvidence: the commands you ran, exit status, and decisive output.\nUnverified surface: what you could not exercise, and why.\n\n" + reviewerToolSteer(),
+			description: pinnedReviewerDescription(true),
+			prompt: pinnedReviewerPrompt(semanticAvailable),
 			model: reviewerModel,
 			effort: effort("reviewer"),
 			tools: readSearchTools,
@@ -557,22 +646,22 @@ function buildCheapProfileAgentDefinitions(opts) {
 	for (const name of Object.keys(out)) if (name !== "worker-browse" && !roster.has(name)) delete out[name];
 	return out;
 }
-/** Build the literal `-m cheapest` native roster. Same fixed five-agent
+/** Build the literal `-m cheapest` native roster. Same fixed four-agent
 * surface and roles as `-m cheap`, but Luna-led with a Gemini reviewer —
 * every SUBAGENT model is a BARE router-owned alias
 * (`gh-router-cheapest-*`, no `[1m]`) rather than a real catalog id, for the
-* same client catalog-resolution reason as the cheap builder below: a bare
+* same client catalog-resolution reason as the cheap builder above: a bare
 * real id is upgraded to `[1m]` accounting by Claude Code whenever the entry
 * advertises >=1M. Caller-supplied `opts.cheapest*Model` values are
-* deliberately ignored. The Plan prompt additionally directs the planner to
-* do the minimal synthesis itself and delegate discovery/execution heavily to
-* `Explore` and `general-purpose`. */
+* deliberately ignored. Cheapest is tuned for straightforward tasks: role
+* descriptions carry no proactive fan-out push, so the lead handles simple
+* work inline instead of paying handoff overhead. */
 function buildCheapestProfileAgentDefinitions(opts) {
 	const exploreModel = CHEAPEST_EXPLORE_ALIAS_ID;
 	const planModel = CHEAPEST_PLAN_ALIAS_ID;
 	const generalModel = CHEAPEST_GENERAL_PURPOSE_ALIAS_ID;
-	const implementerModel = CHEAPEST_IMPLEMENTER_ALIAS_ID;
 	const reviewerModel = CHEAPEST_REVIEWER_ALIAS_ID;
+	const semanticAvailable = opts.semanticSearchAvailable === true;
 	const searchKey = opts.groupKeys.search ?? GROUP_META.search.preferredKey;
 	const peersKey = peersKeyOf(opts.groupKeys);
 	const searchMcpServers = opts.serverUrl ? { [searchKey]: httpEntryFor(opts.serverUrl, "search", opts.nonce, opts.workspaceHeaderCmd) } : void 0;
@@ -595,16 +684,22 @@ function buildCheapestProfileAgentDefinitions(opts) {
 	const effort = (name) => CHEAPEST_PROFILE_NATIVE_EFFORTS[name];
 	const out = {
 		Explore: {
-			description: "Read-only codebase exploration specialist. Use proactively, and launch several in parallel via `Task(subagent_type:\"Explore\")`, to map architecture, trace call chains, or locate the files and symbols a task will touch. Use when the question spans more than a couple of files. Do not use for planning, edits, or single-file reads. Returns a structured evidence report with file:line citations. Never edits files.",
-			prompt: "You are a codebase exploration specialist. Your mission is to map repository structure, discover implementation patterns, trace call chains, and locate the exact files, symbols, and declarations that are relevant to the request. This is read-only work. Do not modify files, do not propose diffs, and do not delegate to other agents. You cannot ask clarifying questions mid-run: ground every answer in repository evidence. If the request is ambiguous, explore the most probable interpretations and record the ambiguity in your report. Start broad, then converge. Issue independent searches in parallel in one turn rather than one at a time, and pair semantic search with exact lexical and symbol search so that neither naming drift nor synonym mismatch hides a result. Include surrounding context lines in your search results so that callers, guards, and types are visible without a second round trip, and inspect the file whenever the surrounding logic determines the answer. Confirm every claim at the source before you report it. Stop when further searching stops changing your answer. When you can name the exact files and lines a change would touch, you are done. Report what the repository contains, not what it ought to contain. Do not design a solution or recommend an approach. Return a self-contained result the lead can act on immediately without needing to re-run your discovery.\n\nReturn format:\nAnswer: a direct response to what was asked, in a few sentences.\nInventory: each relevant file and symbol as file:line, with a one-line description of its role.\nEntry points: where control enters this area, as file:line.\nConventions in use: the patterns, idioms, error handling, and test style that any change here would be expected to follow, each with a file:line example.\nGaps and unknowns: what you could not confirm, and where you would look next.\n\n" + readOnlyToolSteer(),
+			description: pinnedExploreDescription(false),
+			prompt: pinnedExplorePrompt({
+				explicit: false,
+				semanticAvailable
+			}),
 			tools: readSearchTools,
 			model: exploreModel,
 			effort: effort("Explore"),
 			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
 		},
 		Plan: {
-			description: "Architecture and implementation planning specialist. Use proactively in plan mode, and whenever sequencing, cross-boundary interfaces, invariants, migration risk, or acceptance criteria deserve a dedicated pass before any code is written. Delegates repository discovery to `Explore` and mixed execution to `general-purpose` rather than doing that work itself; does the minimal synthesis to produce the plan. Returns a decision-complete, ordered implementation plan with runnable acceptance criteria. Never edits files.",
-			prompt: "You are a software architect and planning specialist. Your mission is to turn a request into a decision-complete implementation plan: an ordered sequence of changes, the invariants that must hold throughout, and acceptance criteria a reviewer can actually run. This is read-only work. Do not modify repository files. Produce the architecture, sequencing, and acceptance criteria for the lead to synthesize and execute. Plan is an advisory planning capability, not an approval gate. Do the minimal planning work yourself and delegate heavily: launch one or more `Explore` subagents in parallel with scoped evidence questions for repository discovery, and lean on `general-purpose` for any mixed investigation/execution needed to settle a choice — then read directly only the files needed to resolve trade-offs and write executable steps. Do not sweep the repository yourself. Escalate only genuine product or architectural trade-offs, and escalate them as explicit options with consequences and a recommendation, never as an open question. For low-risk details, choose the reading most consistent with the codebase, proceed, and record it as an assumption. When a design trade-off has more than one viable answer and repository evidence cannot settle it, consult Oracle tool with one self-contained brief that states the constraints, the candidate designs, and the evidence you already gathered plus one precise question. If Oracle does not settle it, carry the options and the remaining gap into the plan rather than silently picking one. Delegation: you may invoke Explore and `reviewer` for discovery and verification; do not invoke any other subagent. Behavior and code verification belongs to post-implementation review. Write the plan for an implementer who cannot see your reasoning. Every step must be executable without rediscovering what you already found: name the files, name the interfaces, and state the condition that means the step is done. Prefer the smallest design that satisfies the requirement and fits the conventions already in the codebase. Mark steps that are independent of each other and can run concurrently.\n\nReturn format:\nObjective: what will be true when this is complete.\nArchitectural invariants: what must hold before, during, and after every step.\nInterface contracts: signatures, types, error and edge-case behaviour at each boundary the change crosses.\nExecution steps: ordered. Each names the files it touches, the change it makes, and its done condition. Mark steps that are independent of each other and can run concurrently.\nAcceptance criteria: the exact commands to run and the observable result that counts as passing.\nCritical files: the files an implementer must read before starting, as file:line, with why each matters.\nOpen questions: any unresolved trade-off, as options with a recommendation. Omit this section if there are none.\n\n" + readOnlyToolSteer(),
+			description: pinnedPlanDescription(false),
+			prompt: pinnedPlanPrompt({
+				explicit: false,
+				semanticAvailable
+			}),
 			tools: planTools,
 			model: planModel,
 			effort: effort("Plan"),
@@ -613,23 +708,108 @@ function buildCheapestProfileAgentDefinitions(opts) {
 				...peersMcpServers ?? {}
 			}
 		},
-		"general-purpose": {
-			description: "Autonomous multi-step execution agent. Use proactively for open-ended or mixed tasks combining investigation, tool workflows, and code changes where the approach emerges during work. Drives to a verified end state with changed files and evidence. Do not use for pure discovery (use Explore), settled bounded edits (use implementer), or verification-only (use reviewer).",
-			prompt: "You are an autonomous execution specialist for mixed, multi-step work. Your mission is to take an open-ended task from investigation through implementation to a verified end state within this turn. Keep going until the task is genuinely done. Do not stop at a diagnosis, a partial fix, or a plan when the request asked for a change. Ground discovery in repository truth. For low-risk ambiguities, choose the interpretation most consistent with the repository, proceed, and record it as an assumption in your report. For material intent gaps that would alter product behavior or security, surface concrete options and a recommendation to the lead. Investigate before you act. Confirm your assumptions against the actual code rather than against the request's description of it. After every command, read the real output and let it decide the next step. When something fails, diagnose the specific cause before trying again. If repeated attempts fail for the same reason and no new information has emerged, stop retrying: re-examine the underlying assumption and take a different path. Escalate rather than expand. If the task turns out to require a change the lead did not sanction, complete the sanctioned part and report the rest as a recommendation. If the task collapses to pure discovery or a single settled edit, do that slice and report the remainder as a recommendation. Do not expand scope. Match the conventions, structure, and test style already present in the files you touch. The lead owns final integration. Verify before you report. Run the builds, linters, or test commands relevant to what you changed. Quote the command run, exit status, and concise decisive output verbatim; if output is long, summarize the middle and quote the pass/fail lines. Report your changes and test output directly to the caller. Post-integration review is owned by the lead. Return a self-contained result the lead can act on immediately.\n\nReturn format:\nOutcome: what is now true, and whether the task is complete.\nActions taken: what you did, in order.\nChanged files: each as file:line, with a one-line description of the change.\nVerification: the commands you ran, exit status, and decisive output.\nAssumptions: every interpretation you had to choose.\nRemaining items: anything deliberately not done, and why.\n\n" + fileToolSteer("builds, tests, and git"),
+		"General-Purpose": {
+			description: pinnedGeneralPurposeDescription(false),
+			prompt: pinnedGeneralPurposePrompt(),
 			model: generalModel,
-			effort: effort("general-purpose"),
+			effort: effort("General-Purpose"),
 			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
 		},
-		implementer: {
-			description: "Surgical implementation specialist for bounded changes with settled scope. Use proactively when what and where are decided, to make the change cleanly, match conventions, and verify it. Use Plan first if the approach is still open. Returns modified files with verbatim verification. Keeps the diff tight.",
-			prompt: "You are an implementation specialist. Your mission is to make bounded, surgical code changes that satisfy a settled requirement and look as though they were always part of the codebase. Before you edit, inspect the target files and relevant adjacent code, so that your change matches the existing idioms, error handling, logging, and test style. For a bug fix, reproduce the failure first and keep that reproduction as your success signal. While you edit, keep the change inside the requested scope and keep the diff tight and focused. Apply changes with the file editing tools; printing a patch in your response does not modify the file. Match the surrounding formatting, naming, and structure. Write a comment only where the reason for the code is non-obvious, and let well-named identifiers carry what the code does. If the requirement turns out to need work outside the agreed scope, implement the agreed change and report the additional work as a recommendation. For low-risk ambiguities, choose the interpretation most consistent with the surrounding code, proceed, and state the assumption in your report. For material intent gaps, surface concrete options and a recommendation to the lead. After you edit, run the builds, linters, or tests relevant to what you changed. Report the command, exit code, and decisive output verbatim. If a check fails, diagnose the cause before retrying; do not retry the same failing action without new information. Never claim something passes, compiles, or is covered unless you ran it and read the result. Report your changes and test output directly to the caller. Post-integration review is owned by the lead. Return a self-contained result the lead can act on immediately.\n\nReturn format:\nModified files: each as file:line, with a one-line description of the change.\nVerification: each command you ran, exit status, and decisive output.\nAssumptions and deferred work: interpretations you chose, and anything you deliberately left undone.\n\n" + fileToolSteer("builds, tests, and git"),
-			model: implementerModel,
-			effort: effort("implementer"),
+		reviewer: {
+			description: pinnedReviewerDescription(false),
+			prompt: pinnedReviewerPrompt(semanticAvailable),
+			model: reviewerModel,
+			effort: effort("reviewer"),
+			tools: readSearchTools,
+			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
+		}
+	};
+	if (opts.browseAvailable && opts.groupKeys.workers) {
+		const workersKey = workersKeyOf(opts.groupKeys);
+		out["worker-browse"] = {
+			description: dispatcherDescription("browse"),
+			prompt: dispatcherPrompt("browse", workersKey),
+			model: exploreModel,
+			effort: "high",
+			tools: dispatcherTools("browse", workersKey),
+			...opts.serverUrl ? { mcpServers: { [workersKey]: httpEntryFor(opts.serverUrl, "workers", opts.nonce, opts.workspaceHeaderCmd) } } : {}
+		};
+	}
+	const roster = opts.nativeRoster == null ? new Set(CHEAPEST_PROFILE_NATIVE_AGENT_NAMES) : opts.nativeRoster instanceof Set ? opts.nativeRoster : new Set(opts.nativeRoster);
+	for (const name of Object.keys(out)) if (name !== "worker-browse" && !roster.has(name)) delete out[name];
+	return out;
+}
+/** Build the literal `-m balanced` native roster. Same fixed four-agent
+* surface and roles as `-m cheap`, but Sol-led at the 200K default window
+* for the most complex tasks — every SUBAGENT model is a BARE router-owned
+* alias (`gh-router-balanced-*`, no `[1m]`) rather than a real catalog id,
+* for the same client catalog-resolution reason as the cheap builder above.
+* Caller-supplied `opts.balanced*Model` values are deliberately ignored.
+* Explicit delegation tuning matches cheap: proactive parallel `Explore`
+* fan-out, `Plan`-first architecture, `General-Purpose` mixed execution, and
+* post-integration `reviewer` verification. */
+function buildBalancedProfileAgentDefinitions(opts) {
+	const exploreModel = BALANCED_EXPLORE_ALIAS_ID;
+	const planModel = BALANCED_PLAN_ALIAS_ID;
+	const generalModel = BALANCED_GENERAL_PURPOSE_ALIAS_ID;
+	const reviewerModel = BALANCED_REVIEWER_ALIAS_ID;
+	const semanticAvailable = opts.semanticSearchAvailable === true;
+	const searchKey = opts.groupKeys.search ?? GROUP_META.search.preferredKey;
+	const peersKey = peersKeyOf(opts.groupKeys);
+	const searchMcpServers = opts.serverUrl ? { [searchKey]: httpEntryFor(opts.serverUrl, "search", opts.nonce, opts.workspaceHeaderCmd) } : void 0;
+	const peersMcpServers = opts.serverUrl && opts.groupKeys.peers ? { [peersKey]: httpEntryFor(opts.serverUrl, "peers", opts.nonce, opts.workspaceHeaderCmd) } : void 0;
+	const oracleTool = opts.groupKeys.peers ? `mcp__${peersKey}__oracle` : void 0;
+	const readSearchTools = [
+		"Read",
+		"Grep",
+		"Glob",
+		"Bash",
+		"WebFetch",
+		"WebSearch",
+		`mcp__${searchKey}__*`
+	];
+	const planTools = [
+		...readSearchTools,
+		...oracleTool ? [oracleTool] : [],
+		"Agent"
+	];
+	const effort = (name) => BALANCED_PROFILE_NATIVE_EFFORTS[name];
+	const out = {
+		Explore: {
+			description: pinnedExploreDescription(true),
+			prompt: pinnedExplorePrompt({
+				explicit: true,
+				semanticAvailable
+			}),
+			tools: readSearchTools,
+			model: exploreModel,
+			effort: effort("Explore"),
+			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
+		},
+		Plan: {
+			description: pinnedPlanDescription(true),
+			prompt: pinnedPlanPrompt({
+				explicit: true,
+				semanticAvailable
+			}),
+			tools: planTools,
+			model: planModel,
+			effort: effort("Plan"),
+			mcpServers: {
+				...searchMcpServers ?? {},
+				...peersMcpServers ?? {}
+			}
+		},
+		"General-Purpose": {
+			description: pinnedGeneralPurposeDescription(true),
+			prompt: pinnedGeneralPurposePrompt(),
+			model: generalModel,
+			effort: effort("General-Purpose"),
 			...searchMcpServers ? { mcpServers: searchMcpServers } : {}
 		},
 		reviewer: {
-			description: "Adversarial evidence-based reviewer. Use proactively post-integration after behavior-changing, cross-boundary, or risk-sensitive changes, and always after `implementer`, before done. Runs builds/tests itself rather than assuming them. Returns SHIP / FIX / BLOCK with reproducible evidence. Never edits source.",
-			prompt: "You are an adversarial code reviewer. Your job is not to confirm that the change works. Your job is to find the conditions under which it does not. Think carefully about the plausible failure modes of this change before you start running commands, so that what you run is chosen to expose them. Read before you judge. Inspect the changed files and relevant surrounding context, callers of affected call sites, and tests that claim to cover the change, sized to the identified risks of the change. Then verify by execution. Run the builds, linters, or test suites relevant to what changed, and any command that would surface the specific failure you suspect. Verification means output you observed. Never state that something passes, compiles, or is covered unless you ran it and read the result; where you could not run something, say so explicitly rather than inferring the outcome. Probe deliberately: boundary and empty inputs, error and early-return paths, concurrency and ordering, resource acquisition and cleanup on the failure path, partial failure and retry, backward compatibility of any changed interface, handling of untrusted input, and whether the new tests would actually fail if the change were reverted. Judge against the bar the repository already holds itself to, not an abstract ideal. Do not soften a real finding, and do not manufacture findings to appear thorough. If the change is correct and verified, say so. Do not modify source code and do not delegate to other agents. You may run build, test, and read-only inspection commands; do not run commands that alter tracked source files or touch remote infrastructure (transient build cache or test runner side effects are expected). Return a self-contained result the lead can act on immediately.\n\nReturn format. Line one must be exactly one of:\nVERDICT: SHIP\nVERDICT: FIX\nVERDICT: BLOCK\n\nSHIP means you found no blocking defect and your verification ran clean. FIX means the approach is sound but specific defects must be corrected. BLOCK means the approach itself is wrong, or verification could not be run at all.\n\nThen, using the repository's severity taxonomy:\nCritical: blocking defects (correctness, security, data loss). Each with file:line, the concrete scenario in which it fails, and how you confirmed it.\nImportant: non-blocking issues that should be fixed before shipping. Each with file:line and impact.\nSuggestion: non-blocking improvements or stylistic suggestions.\nEvidence: the commands you ran, exit status, and decisive output.\nUnverified surface: what you could not exercise, and why.\n\n" + reviewerToolSteer(),
+			description: pinnedReviewerDescription(true),
+			prompt: pinnedReviewerPrompt(semanticAvailable),
 			model: reviewerModel,
 			effort: effort("reviewer"),
 			tools: readSearchTools,
@@ -647,7 +827,7 @@ function buildCheapestProfileAgentDefinitions(opts) {
 			...opts.serverUrl ? { mcpServers: { [workersKey]: httpEntryFor(opts.serverUrl, "workers", opts.nonce, opts.workspaceHeaderCmd) } } : {}
 		};
 	}
-	const roster = opts.nativeRoster == null ? new Set(CHEAPEST_PROFILE_NATIVE_AGENT_NAMES) : opts.nativeRoster instanceof Set ? opts.nativeRoster : new Set(opts.nativeRoster);
+	const roster = opts.nativeRoster == null ? new Set(BALANCED_PROFILE_NATIVE_AGENT_NAMES) : opts.nativeRoster instanceof Set ? opts.nativeRoster : new Set(opts.nativeRoster);
 	for (const name of Object.keys(out)) if (name !== "worker-browse" && !roster.has(name)) delete out[name];
 	return out;
 }
@@ -665,6 +845,7 @@ function buildPeerAgentDefinitions(opts) {
 	if (opts.fastProfile) return buildFastProfileAgentDefinitions(opts);
 	if (opts.cheapProfile) return buildCheapProfileAgentDefinitions(opts);
 	if (opts.cheapestProfile) return buildCheapestProfileAgentDefinitions(opts);
+	if (opts.balancedProfile) return buildBalancedProfileAgentDefinitions(opts);
 	const out = {};
 	const personas = personasFor({
 		codexCli: opts.codexCli,
@@ -1119,6 +1300,11 @@ async function writePeerMcpRuntimeFiles(serverUrl, opts) {
 		cheapestGeneralPurposeModel: opts.cheapestGeneralPurposeModel,
 		cheapestImplementerModel: opts.cheapestImplementerModel,
 		cheapestReviewerModel: opts.cheapestReviewerModel,
+		balancedExploreModel: opts.balancedExploreModel,
+		balancedPlanModel: opts.balancedPlanModel,
+		balancedGeneralPurposeModel: opts.balancedGeneralPurposeModel,
+		balancedReviewerModel: opts.balancedReviewerModel,
+		semanticSearchAvailable: opts.semanticSearchAvailable,
 		nativeRoster: opts.nativeRoster,
 		personaAllowlist: opts.personaAllowlist,
 		includeCoordinator: opts.includeCoordinator,
@@ -1128,6 +1314,7 @@ async function writePeerMcpRuntimeFiles(serverUrl, opts) {
 		fastProfile: opts.fastProfile,
 		cheapProfile: opts.cheapProfile,
 		cheapestProfile: opts.cheapestProfile,
+		balancedProfile: opts.balancedProfile,
 		implementerEffort: opts.implementerEffort,
 		reviewerEffort: opts.reviewerEffort,
 		maxProfile: opts.maxProfile,
@@ -1882,6 +2069,176 @@ Return a compact final checkpoint:
 `
 };
 //#endregion
+//#region src/lib/injected-skills/gather-context-skill.ts
+const GATHER_CONTEXT_SKILL = {
+	name: "gh-gather-context",
+	md: `---
+name: gh-gather-context
+description: Bounded context gathering for non-trivial asks: decomposes the ask, runs lexical code searches to identify relevant files, dispatches bounded parallel explore workers to gather evidence, stitches results into a freshness-stamped context brief plus a compact version. Use when grounded context is needed before planning or changing code.
+user-invocable: true
+---
+
+# gh-gather-context: bounded context gathering
+
+Use this skill when a non-trivial ask needs grounded context before planning.
+All reasoning runs at the 200K default window: the lead and every explore
+worker use the Luna model at high effort with bare slugs (no 1M accounting).
+Output is a durable full brief plus a compact downstream version.
+
+## Hard bounds
+
+- Maximum rounds: 3.
+- Maximum parallel explore workers per round: 6.
+- Maximum lexical searches per round: 10.
+- Maximum follow-up reads per round: 5.
+- Terminate at the first of saturation or a cap.
+- On cap-hit, return with open unknowns flagged as residual. Do not loop forever.
+
+## Evidence tags
+
+Use these exact tags on every finding and claim:
+
+- verified-executable: reproduced the symptom, ran the failing test, or ran a check that directly proves the claim. This is the only deterministic confidence tag.
+- verified-source: read the actual source, config, logs, docs, or primary artifact and cited the relevant locations. This is model-mediated and can still be wrong.
+- cross-lab-agreed: a different-lab reviewer independently agreed with the claim. This reduces correlated blind spots but is advisory.
+- unverified: plausible but not confirmed; treat as residual risk.
+
+## Procedure
+
+1. Restate the ask and define the research target.
+   - Identify whether this is a bug, feature, refactor, incident, or design question.
+   - Name the expected downstream consumer: planner, implementer, or user.
+
+2. Decompose the ask into searchable entities.
+   - Extract symbols, filenames, error strings, routes, flags, config keys, and types.
+   - Define what must be true for a correct implementation.
+
+3. Run lexical search first, in parallel, in a single turn.
+   - Use mcp__search__code lexically for exact symbols, filenames, errors, routes, flags, and config keys.
+   - Use mcp__search__code semantically only to find concepts, then refine to lexical.
+   - Use git log and git blame when authorship, regression timing, or intent matters.
+   - Use mcp__search__web for upstream APIs, package behavior, protocol docs, or public issues.
+
+4. Decompose into bounded explore workers.
+   - Cluster search results into at most 6 coherent investigation areas.
+   - For each area, write a narrow brief: the specific question, the expected artifact, and the files to focus on.
+   - Dispatch ALL explore workers in a single turn via the Agent tool (subagent_type worker-explore). Each runs read-only at the 200K default window and returns a summary with an evidence table and file:line citations. Pass maxWallClockMs 180000 on every worker call so a hung worker is reaped after 3 minutes instead of blocking its slot.
+   - Keep worker results summarized; do not paste every detail into the main context.
+
+5. Stitch and verify.
+   - Collect all explore results and deduplicate file references.
+   - Run at most 5 targeted follow-up reads for gaps, in parallel.
+   - Dispatch the worker-review subagent (via the Agent tool, maxWallClockMs 300000) to confirm source-reading for load-bearing claims.
+   - Form a root-cause hypothesis or integration map, and state what would falsify it.
+
+6. Run a completeness pass.
+   - Ask: what do we still not know?
+   - Ask: what claim, if false, would break the conclusion?
+   - Ask: have we checked primary sources for every load-bearing claim?
+   - If no material unknowns remain and the root cause is at least verified-source, stop for saturation.
+
+7. Persist two outputs under .github-router/context/<slug>/.
+   - context.md: full brief with the ask decomposition, searches run, worker reports, evidence table, hypothesis, freshness metadata (HEAD commit, working-tree diff hash, timestamp, repo path), residuals, and full citations.
+   - context.compact.md: downstream consumable with a one-paragraph ask summary, key files with one-line purposes, critical constraints (APIs, types, patterns, forbidden changes), integration seams, and residual risks.
+   - Downstream phases read by pointer and check freshness instead of re-injecting the whole brief.
+
+## Return format
+
+Return a compact brief, not the whole dump:
+
+- Context files: paths to context.md and context.compact.md.
+- Freshness: HEAD commit, diff hash, timestamp.
+- Termination: saturated or cap-hit; if cap-hit, name the cap.
+- Summary: 3-8 bullets with confidence tags.
+- Evidence table: claim, tag, primary source or command, reviewer status.
+- Residual unknowns: explicit list, or none.
+- Downstream guidance: recommended next action and what must be rechecked if the tree changes.
+
+## Non-goals
+
+- Do not present verified-source or cross-lab-agreed as deterministic.
+- Do not hide open unknowns because the answer looks useful.
+- Do not keep searching after the cap.
+- Do not paste the entire persisted brief into later turns unless the user asks.
+`
+};
+//#endregion
+//#region src/lib/injected-skills/implement-skill.ts
+const IMPLEMENT_SKILL = {
+	name: "gh-implement",
+	md: `---
+name: gh-implement
+description: Parallel implementation of an approved plan using bounded Luna workers with isolated worktrees: each worker implements its task, self-tests, self-reviews, and returns a patch; the lead aggregates into a unified diff, runs staged review, and returns the final diff with a report. Use when a user-approved plan is ready for execution.
+user-invocable: true
+---
+
+# gh-implement: bounded parallel implementation with staged review
+
+Use this skill only after /gh-plan produced a user-approved plan.md. All
+implementation runs at the 200K default window: the lead and every task worker
+use the Luna model at max effort with bare slugs (no 1M accounting). Review is
+staged: a Luna max pass first, then a Sol medium pass only for major issues.
+
+## Hard bounds
+
+- Maximum concurrent implement workers: 8.
+- Maximum retries per task: 2.
+- Maximum review-fix cycles: 2.
+- Worktrees are auto-removed on success and retained on failure for debugging.
+
+## Procedure
+
+1. Parse the approved plan.
+   - Read plan.md fully.
+   - Group tasks by parallelGroup; order groups by dependency.
+   - For each group, prepare an isolated git worktree per task plus a narrow task brief (task spec, relevant context excerpt, acceptance criteria, verification commands).
+
+2. Dispatch bounded implement workers, one parallel batch per group.
+   - Dispatch ALL tasks in the group in a single turn via the Agent tool (subagent_type worker-implement, with worktree isolation, maxWallClockMs 600000 per task so a hung worker is reaped after 10 minutes instead of blocking its slot).
+   - Each worker runs at the 200K default window and must self-contain its work:
+     a. Implement the change.
+     b. Run the task verification commands (tests, typecheck, lint).
+     c. Self-review against the acceptance criteria.
+     d. Fix any self-found issues (at most 2 internal fix cycles).
+     e. Return the patch plus test results and self-review notes.
+   - Do NOT dispatch the same task twice (no dedup exists); a retry is a new dispatch only after a recorded failure.
+   - For a big artifact, have the worker write it to a file and return the path.
+
+3. Aggregate and validate.
+   - Collect all patches and apply them sequentially to the main worktree (or merge the worktrees).
+   - Run the full relevant validation: test suite, typecheck, and lint.
+   - If any task fails validation, route it back to an implement worker (at most 2 retries per task). If it still fails, checkpoint with the failure as residual risk instead of pretending it is solved.
+
+4. Run staged review.
+   - Pass 1 (always): dispatch the worker-review subagent (via the Agent tool, maxWallClockMs 300000) over the unified diff for correctness against acceptance criteria, code quality and consistency, security and performance regressions, and test coverage. Categorize findings as minor (style, nits) or major (logic, architecture).
+   - If pass 1 finds no major issues, finish here.
+   - Pass 2 (major issues only): dispatch a fix worker (via the Agent tool, maxWallClockMs 300000) at the 200K default window using the Sol model at medium effort with the flagged areas, the failing checks, and the pass-1 findings. It returns fixed patches or an explicit escalate-to-user with reasons.
+
+5. Finalize.
+   - Apply any review fixes and re-run full validation.
+   - Produce the unified diff for the whole plan.
+   - Write .github-router/plans/<slug>/implementation-report.md with task completion status, test results summary, review findings and resolutions, the final diff path, and residual risks.
+
+## Return format
+
+Return:
+
+- Unified diff path.
+- Implementation report path.
+- Task completion status per task id.
+- Test, typecheck, and lint results.
+- Review summary (pass 1 findings; pass 2 findings and fixes if used).
+- Final residual risks and next action.
+
+## Non-goals
+
+- Do not start without a user-approved plan.md.
+- Do not serialize work that has no data dependency; independent tasks in a group run concurrently.
+- Do not nest workflow invocations: workers are internal sessions and must not re-invoke /gh-implement.
+- Do not claim completeness when retries or review cycles are exhausted with open failures.
+`
+};
+//#endregion
 //#region src/lib/injected-skills/orchestrate-skill.ts
 const ORCHESTRATE_SKILL = {
 	name: "gh-orchestrate",
@@ -2020,6 +2377,94 @@ Return:
 `
 };
 //#endregion
+//#region src/lib/injected-skills/plan-skill.ts
+const PLAN_SKILL = {
+	name: "gh-plan",
+	md: `---
+name: gh-plan
+description: Holistic planning from gathered context: ingests the context brief, creates a scoped modular ordered implementation plan with explicit tasks for cheap implementation workers, surfaces open questions for user approval, and persists plan.md. Use when a non-trivial change needs a reviewed plan before implementation.
+user-invocable: true
+---
+
+# gh-plan: holistic planning for cheap implementation
+
+Use this skill after /gh-gather-context (or when equivalent context is already
+available) and before any implementation. The planner runs at the 200K default
+window using the Sol model at medium effort. The plan must be scoped, modular,
+non-overlapping, and ordered, with enough detail for Luna implementation
+workers to execute each task in isolation. User approval is mandatory before
+implementation.
+
+## Prerequisites
+
+- A freshness-stamped context brief from /gh-gather-context, or equivalent context.
+- Read context.compact.md first; read context.md sections on demand (residual unknowns, evidence table).
+
+## Hard bounds
+
+- Maximum tasks: 20.
+- Maximum parallel groups: 5.
+- Keep planner input well under the 200K window (target at most around 150K tokens of context) so there is headroom for reasoning and output. This is self-discipline, not an enforced cap: prefer the compact brief and read full sections only on demand.
+
+## Procedure
+
+1. Ingest context.
+   - Read context.compact.md fully.
+   - Read the evidence table and residual unknowns from context.md.
+   - Identify acceptance criteria, constraints, integration seams, and forbidden changes.
+
+2. Build a blind-spot table before decomposing.
+   - Wrong-spec risk: judgment-only, mitigated only by user-blessed acceptance criteria.
+   - Root-cause risk: executable-checkable if reproduced or covered by a failing test; otherwise advisory.
+   - Integration risk: usually source-verified plus tests where possible.
+   - Regression risk: executable-checkable when tests, typecheck, or lint cover it.
+   - Review risk: advisory cross-lab review reduces correlated blind spots.
+   - Concurrency or merge risk: source-verified and sometimes executable-checkable.
+   - Missing-test risk: executable-checkable only after a test exists and runs.
+   - Tag every blind spot as executable-checkable or judgment-only.
+
+3. Decompose into minimal safe increments.
+   - Each task touches a single file or a tightly coupled file group.
+   - Each task states input artifacts, output artifact, acceptance criteria, verification commands, and rollback concern.
+   - Order tasks by dependency (topological sort); tasks with no data dependency share a parallel group.
+   - Keep each task small enough for one Luna worker at the 200K window (target at most 50K context tokens of relevant files per task).
+   - If the ask needs discovery follow-ups, delegate them to worker-explore background subagents (via the Agent tool, maxWallClockMs 180000) rather than bloating the plan.
+
+4. Surface open questions before finalizing.
+   - Ask about ambiguous acceptance criteria, design decisions with multiple valid approaches, risk tolerance, and test strategy.
+   - Present a short candidate list for confirmation where possible.
+
+5. Persist the plan to .github-router/plans/<slug>/plan.md.
+   - Ask summary and user-blessed acceptance criteria.
+   - Blind-spot table with executable-checkable or judgment-only tags.
+   - Ordered task list with ids, files, dependencies, parallel groups, acceptance criteria, verification commands, rollback concerns, and estimated context tokens.
+   - Open questions and user answers.
+   - Cost estimate: task count, parallel groups, and context tokens.
+   - Residual risks.
+
+6. Checkpoint with the user and wait for explicit approval.
+   - Present the goal, acceptance criteria, task-to-group map, per-task blind spot killed, residual risks, and cost estimate.
+   - If the user rejects scope or cost, downshift to the smallest plan that kills the important blind spots.
+   - Do not proceed to implementation without approval.
+
+## Return format
+
+Return:
+
+- Plan file: path to the durable plan.md.
+- Task count and parallel groups.
+- Open questions and user answers.
+- Cost estimate.
+- Residual risks and next action (implementation only after approval).
+
+## Non-goals
+
+- Do not edit implementation files while planning; in plan mode, produce the plan and acceptance criteria only.
+- Do not present judgment-only conclusions as executable guarantees.
+- Do not hide open unknowns because the plan looks complete.
+`
+};
+//#endregion
 //#region src/lib/injected-skills/research-skill.ts
 const RESEARCH_SKILL = {
 	name: "gh-research",
@@ -2191,6 +2636,88 @@ The dispatcher calls the worker once and relays its result verbatim.
 `
 };
 //#endregion
+//#region src/lib/skill-model-contract.ts
+/**
+* Universal skill model contract for the `/gh-gather-context`, `/gh-plan`,
+* and `/gh-implement` pipeline skills.
+*
+* ALL roles run at the 200K DEFAULT context window (bare slugs, no `[1m]`
+* accounting bracket) on every profile. This module is deliberately
+* dependency-free so profile contracts, launch validation, worker dispatch,
+* and the injected skill bodies can all import the same literals without
+* cycles.
+*
+* Model choices (per pipeline design):
+*   - gatherContext lead + explore agents: Luna, high effort
+*   - plan lead: Sol, medium effort
+*   - implement lead + task agents: Luna, max effort
+*   - review pass 1: Luna, max effort
+*   - review pass 2 (major issues only): Sol, medium effort
+*/
+const SKILL_LUNA_MODEL_ID = "gpt-5.6-luna";
+const SKILL_SOL_MODEL_ID = "gpt-5.6-sol";
+Object.freeze({
+	gatherContext: Object.freeze({
+		lead: SKILL_LUNA_MODEL_ID,
+		exploreAgent: SKILL_LUNA_MODEL_ID,
+		leadEffort: "high",
+		agentEffort: "high"
+	}),
+	plan: Object.freeze({
+		lead: SKILL_SOL_MODEL_ID,
+		leadEffort: "medium"
+	}),
+	implement: Object.freeze({
+		lead: SKILL_LUNA_MODEL_ID,
+		taskAgent: SKILL_LUNA_MODEL_ID,
+		leadEffort: "max",
+		agentEffort: "max"
+	}),
+	review: Object.freeze({
+		pass1: Object.freeze({
+			model: SKILL_LUNA_MODEL_ID,
+			effort: "max"
+		}),
+		pass2: Object.freeze({
+			model: SKILL_SOL_MODEL_ID,
+			effort: "medium"
+		})
+	})
+});
+Object.freeze({
+	gatherContext: Object.freeze({
+		maxRounds: 3,
+		maxExploreAgentsPerRound: 6,
+		maxLexicalSearchesPerRound: 10,
+		maxFollowUpReadsPerRound: 5
+	}),
+	plan: Object.freeze({
+		maxTasks: 20,
+		maxParallelGroups: 5
+	}),
+	implement: Object.freeze({
+		maxConcurrentAgents: 8,
+		maxRetriesPerTask: 2,
+		maxReviewFixCycles: 2
+	})
+});
+/**
+* Profiles that receive the pipeline skills. Every pinned profile gets
+* them; `standard` is intentionally excluded (it keeps the existing
+* research/orchestrate/worker surface).
+*/
+const PIPELINE_SKILL_PROFILES = [
+	"fast",
+	"max",
+	"cheap",
+	"cheap1m",
+	"cheapest",
+	"balanced"
+];
+function isPipelineSkillProfile(profileId) {
+	return PIPELINE_SKILL_PROFILES.includes(profileId);
+}
+//#endregion
 //#region src/lib/injected-skills/artifact-review-skill.ts
 function buildArtifactReviewSkill(peersKey = "peers") {
 	const toolPrefix = `mcp__${peersKey}__artifact_`;
@@ -2329,13 +2856,20 @@ function joinClauses(parts) {
 *  there is no quality-for-cost trade being hidden by leading with the cheap
 *  tier; reserve `reviewer` for the higher-stakes assessment it is there for. */
 function buildNativeReachClauses(opts) {
-	if (opts.profile === "fast" || opts.profile === "cheap" || opts.profile === "cheap1m" || opts.profile === "cheapest") return joinClauses([
-		"`Explore` for broad repository discovery, dependency mapping, and convention tracking",
-		"`Plan` for architectural sequencing, interface contracts, migration risk, and runnable acceptance criteria",
-		"`general-purpose` for mixed, iterative, or multi-step execution tasks",
-		"`implementer` for surgical coding changes matching existing conventions",
-		"`reviewer` for independent adversarial verification, reproduction, and root-causing"
-	]);
+	if (opts.profile === "fast" || opts.profile === "cheap" || opts.profile === "cheap1m" || opts.profile === "cheapest" || opts.profile === "balanced") {
+		if (opts.profile === "cheapest") return joinClauses([
+			"`Explore` for broad repository discovery, dependency mapping, and convention tracking",
+			"`Plan` for architectural sequencing, interface contracts, migration risk, and runnable acceptance criteria",
+			"`General-Purpose` for mixed, iterative, or multi-step execution tasks",
+			"`reviewer` for independent adversarial verification, reproduction, and root-causing"
+		]);
+		return joinClauses([
+			"`Explore` for broad repository discovery, dependency mapping, and convention tracking (launch in parallel)",
+			"`Plan` for architectural sequencing, interface contracts, migration risk, and runnable acceptance criteria (delegates discovery to `Explore`)",
+			"`General-Purpose` for mixed, iterative, or multi-step execution tasks (follows a Plan handoff when one exists)",
+			"`reviewer` for independent adversarial verification, reproduction, and root-causing after non-trivial changes"
+		]);
+	}
 	const clauses = [];
 	const implementerFast = opts.implementerFastAvailable !== false;
 	const reviewerFast = opts.reviewerFastAvailable !== false;
@@ -2367,15 +2901,17 @@ function buildOperatingDefaultsDirective(opts = {}) {
 	if (opts.profile === "max") {
 		const peersKey = opts.peersKey ?? opts.groupKeys?.peers ?? "peers";
 		const artifactClause = opts.artifactAvailable ? ` Live human review is available in the artifact panel via \`mcp__${peersKey}__artifact_*\`.` : "";
-		return "## Operating defaults (apply when the user has not specified otherwise; the user's explicit direction and the domain's own standards always override)\n\nMax launch profile. The lead owns the outcome. Start with direct repository or runtime evidence. Handle narrow, obvious, surgical, and single-command work directly; delegate a bounded workstream when it is broad, slow, context-heavy, or benefits from a genuinely independent perspective. " + MAX_PARALLELISM_RULE + " Brief each role with the desired outcome, relevant context, constraints, expected evidence, and verification. Use the roster as complementary capabilities, never as a required Explore → Plan → implement → review sequence. Avoid overlapping assignments and do not ask several models the same generic question. Synthesize results against the repository and executable checks: model agreement is not verification. Use one fresh-context peer only when a consequential judgment remains after direct checks; use the coordinator only when several distinct lenses could change the decision. Advisor is optional, non-binding counsel for one focused consequential uncertainty that evidence and the appropriate roles cannot settle; it has no approval or workflow authority, and a further consultation requires materially new or conflicting evidence." + artifactClause;
+		return "## Operating defaults (these layer with the user's explicit direction and the domain's own standards as addons, not replacements: follow all three together; on a direct conflict the user's direction wins, then the domain standard, then the default below)\n\nMax launch profile. The lead owns the outcome. Start with direct repository or runtime evidence. Handle narrow, obvious, surgical, and single-command work directly; delegate a bounded workstream when it is broad, slow, context-heavy, or benefits from a genuinely independent perspective. " + MAX_PARALLELISM_RULE + " Brief each role with the desired outcome, relevant context, constraints, expected evidence, and verification. Use the roster as complementary capabilities, never as a required Explore → Plan → implement → review sequence. Avoid overlapping assignments and do not ask several models the same generic question. Synthesize results against the repository and executable checks: model agreement is not verification. Use one fresh-context peer only when a consequential judgment remains after direct checks; use the coordinator only when several distinct lenses could change the decision. Advisor is optional, non-binding counsel for one focused consequential uncertainty that evidence and the appropriate roles cannot settle; it has no approval or workflow authority, and a further consultation requires materially new or conflicting evidence." + artifactClause + "\n\nPipeline skills (all 200K default context). For non-trivial changes, run in order: (1) `/gh-gather-context` BEFORE planning when grounded context is needed: it decomposes the ask, runs lexical search, fans out to bounded Luna-high explore workers, and writes context.md plus context.compact.md; (2) `/gh-plan` AFTER context and BEFORE implementation: it ingests the context brief with Sol-medium, produces a scoped modular ordered plan.md with explicit tasks for Luna workers, surfaces open questions, and waits for user approval; (3) `/gh-implement` AFTER plan approval: it runs bounded parallel Luna-max task workers in isolated worktrees (each self-tests and self-reviews), aggregates a unified diff, and runs staged review (Luna max, then Sol medium for major issues only). Skip the pipeline for trivial surgical work. Never implement without an approved plan.";
 	}
-	if (opts.profile === "fast" || opts.profile === "cheap" || opts.profile === "cheap1m" || opts.profile === "cheapest") {
+	if (opts.profile === "fast" || opts.profile === "cheap" || opts.profile === "cheap1m" || opts.profile === "cheapest" || opts.profile === "balanced") {
 		const isCheap = opts.profile === "cheap" || opts.profile === "cheap1m";
 		const isCheapest = opts.profile === "cheapest";
-		const profileLabel = isCheapest ? "Cheapest" : isCheap ? "Cheap" : "Fast";
-		const oracleDescriptor = isCheapest ? "GPT-5.6 Sol (200K/high)" : isCheap ? "Grok 4.6 (200K/medium)" : "exact Opus 5 (1M/high)";
+		const isBalanced = opts.profile === "balanced";
+		const profileLabel = isCheapest ? "Cheapest" : isCheap ? "Cheap" : isBalanced ? "Balanced" : "Fast";
+		const oracleDescriptor = isCheapest ? "GPT-5.6 Sol (200K/high)" : isCheap || isBalanced ? "Grok 4.6 (200K/medium)" : "exact Opus 5 (1M/high)";
 		const astraDescriptor = isCheap && !isCheapest ? "200K/medium" : "200K/high";
-		if (opts.fastRuntimeAvailable === false) return `## Operating defaults (apply when the user has not specified otherwise; the user's explicit direction and the domain's own standards always override)
+		const searchGuidance = opts.semanticSearchAvailable === true ? "Search strategy (cheapest first): (1) LEXICAL `code` search (mode:\"lexical\"/\"exact\", plus Grep/Glob) for symbols, filenames, errors, routes, flags, and config keys — zero model cost; (2) SEMANTIC `code` search for intent/concept questions where literal keywords may not appear; (3) `Explore` subagents read the narrowed files and return file:line conclusions — expensive models (Plan, reviewer, Oracle) see only the synthesized subset, never raw search output. " : "Search strategy (cheapest first): LEXICAL `code` search (mode:\"lexical\"/\"exact\", plus Grep/Glob) for symbols, filenames, errors, routes, flags, and config keys — zero model cost. `Explore` subagents read the narrowed files and return file:line conclusions — expensive models (Plan, reviewer, Oracle) see only the synthesized subset, never raw search output. ";
+		if (opts.fastRuntimeAvailable === false) return `## Operating defaults (these layer with the user's explicit direction and the domain's own standards as addons, not replacements: follow all three together; on a direct conflict the user's direction wins, then the domain standard, then the default below)
 
 ${profileLabel} profile runtime wiring is unavailable. Work directly, use only tools actually listed in this session, verify with the repository's relevant build/tests before declaring done, report uncertainty, and do not invent unavailable capabilities.`;
 		const peersKey = opts.peersKey ?? opts.groupKeys?.peers ?? "peers";
@@ -2386,32 +2922,29 @@ ${profileLabel} profile runtime wiring is unavailable. Work directly, use only t
 		const workerBrowseClause = opts.browseAvailable ? ` \`worker-browse\` runs delegated autonomous browsing tasks through \`mcp__${workersKey}__browse\`.` : "";
 		const artifactClause = opts.artifactAvailable ? ` \`mcp__${peersKey}__artifact_*\` provides human review in the artifact panel with auto-open on plan completion.` : "";
 		const astraClause = opts.astraAvailable && (opts.profile === "fast" || opts.profile === "cheap1m") ? ` \`mcp__${peersKey}__astra\` (GPT-6 Astra ${astraDescriptor}) is the terminal escalation consultant for the lead only, reserved strictly for the hardest dead ends when direct evidence, Advisor, and Oracle have all failed to produce a defensible path (consulted at most 1-2 times per decision with concise context and specific questions).` : "";
-		return `## Operating defaults (apply when the user has not specified otherwise; the user's explicit direction and the domain's own standards always override)
-
-${profileLabel} launch profile. The lead coordinates execution across specialized native roles: ` + buildNativeReachClauses(opts) + `. In plan mode or when designing changes with complex sequencing, interface contracts, or acceptance criteria, delegate architectural planning to \`Plan\` (in plan mode, produce the plan and acceptance criteria; do not edit files). Discovery rule: delegate to \`Explore\` instead of exploring yourself. For any question spanning more than a couple of files, launch one or more \`Explore\` subagents in parallel with scoped evidence questions and let them return file:line citations; read directly only the small subset you must touch to decide or edit. \`Plan\` follows the same rule when it needs repository facts. Implementation rule: delegate bounded implementation to \`implementer\` whenever a fresh context helps or lead-context pressure matters; brief with outcome, constraints, files in scope, and verification. Review rule: after behavior-changing, cross-boundary, or risk-sensitive implementation, and always after \`implementer\` completes, run relevant build/tests then invoke \`reviewer\` before declaring done. Handle trivial, surgical, single-file, or single-command tasks directly; you do not need to justify skipping delegation. \`Explore\` is cheap and may be launched in parallel across independent discovery questions. Send independent subagent calls in parallel within a single turn. Delegation graph: the lead may invoke all five; \`Plan\` may invoke \`Explore\` and \`reviewer\`; \`implementer\` and \`general-purpose\` may invoke \`reviewer\`; \`Explore\`, \`reviewer\`, and \`worker-browse\` cannot invoke native subagents.
+		return "## Operating defaults (these layer with the user's explicit direction and the domain's own standards as addons, not replacements: follow all three together; on a direct conflict the user's direction wins, then the domain standard, then the default below)\n\n" + (isCheapest ? `${profileLabel} launch profile. The lead owns the outcome and handles straightforward work directly. ` + buildNativeReachClauses(opts) + ". Handle trivial, surgical, single-file, or single-command tasks directly; you do not need to justify skipping delegation. `Explore` may be used for discovery spanning more than a couple of files; `Plan` for sequencing with complex interfaces or acceptance criteria; `General-Purpose` for mixed multi-step execution; `reviewer` for behavior-changing or risk-sensitive changes. Delegation graph: the lead may invoke all four; `Plan` may invoke `Explore` and `reviewer`; `General-Purpose` may invoke `reviewer`; `Explore`, `reviewer`, and `worker-browse` cannot invoke native subagents.\n\n" : `${profileLabel} launch profile. The lead coordinates execution across specialized native roles: ` + buildNativeReachClauses(opts) + ". In plan mode or when designing changes with complex sequencing, interface contracts, or acceptance criteria, delegate architectural planning to `Plan` (in plan mode, produce the plan and acceptance criteria; do not edit files). Phase pipeline (budget gather, expensive plan, budget execution, expensive verification). GATHER: delegate to `Explore` instead of exploring yourself. For any question spanning more than a couple of files, launch one or more `Explore` subagents in parallel with scoped evidence questions and let them return file:line citations; read directly only the small subset you must touch to decide or edit. `Plan` follows the same rule when it needs repository facts. PLAN: `Plan` produces handoff-ready steps (ordered, file:line, done conditions, acceptance criteria) for a `General-Purpose` executor that cannot see its reasoning; `Plan` may consult Oracle on unresolved trade-offs and reports any remaining gap to the lead. EXECUTE: delegate mixed multi-step work and Plan handoffs to `General-Purpose` in a fresh context to preserve lead context; brief with outcome, constraints, files in scope, and verification. VERIFY: after behavior-changing, cross-boundary, or risk-sensitive implementation, run relevant build/tests then invoke `reviewer` before declaring done. Handle trivial, surgical, single-file, or single-command tasks directly; you do not need to justify skipping delegation. `Explore` is cheap and may be launched in parallel across independent discovery questions. Send independent subagent calls in parallel within a single turn. Delegation graph: the lead may invoke all four; `Plan` may invoke `Explore` and `reviewer`; `General-Purpose` may invoke `reviewer`; `Explore`, `reviewer`, and `worker-browse` cannot invoke native subagents.\n\n") + `Consultation guidance: Follow an evidence-first escalation ladder. Direct empirical evidence (search, code, tests, builds) settles factual questions first. Advisor is an optional, non-binding, lead-only transcript-aware sounding board for trajectory guidance or framing checks (direction, not dictation), and never use it for routine progress, waiting, directly verifiable facts, or completion ritual. \`mcp__${peersKey}__oracle\` is ${oracleDescriptor}, an expert consultant available to the lead and \`Plan\`, preferred over advisor for difficult conceptual, algorithmic, spec/protocol, or architectural tradeoffs evaluated in a self-contained brief; \`reviewer\` and other subagents cannot call Oracle. \`Plan\` may consult Oracle on unresolved trade-offs, and reports any remaining tie-breaking gap to the lead.${astraClause} ` + searchGuidance + `\`mcp__${searchKey}__web\` provides citable sources.${browserClause}${workerBrowseClause}${artifactClause}\n\nPipeline skills (all 200K default context). For non-trivial changes, run in order: (1) \`/gh-gather-context\` BEFORE planning when grounded context is needed: it decomposes the ask, runs lexical search, fans out to bounded Luna-high explore workers, and writes context.md plus context.compact.md; (2) \`/gh-plan\` AFTER context and BEFORE implementation: it ingests the context brief with Sol-medium, produces a scoped modular ordered plan.md with explicit tasks for Luna workers, surfaces open questions, and waits for user approval; (3) \`/gh-implement\` AFTER plan approval: it runs bounded parallel Luna-max task workers in isolated worktrees (each self-tests and self-reviews), aggregates a unified diff, and runs staged review (Luna max, then Sol medium for major issues only). Skip the pipeline for trivial surgical work. Never implement without an approved plan.
 
-Consultation guidance: Follow an evidence-first escalation ladder. Direct empirical evidence (search, code, tests, builds) settles factual questions first. Advisor is an optional, non-binding, lead-only transcript-aware sounding board for trajectory guidance or framing checks (direction, not dictation), and never use it for routine progress, waiting, directly verifiable facts, or completion ritual. \`mcp__${peersKey}__oracle\` is ${oracleDescriptor}, an expert consultant available to the lead and \`Plan\`, preferred over advisor for difficult conceptual, algorithmic, spec/protocol, or architectural tradeoffs evaluated in a self-contained brief; \`reviewer\` and other subagents cannot call Oracle. \`Plan\` may consult Oracle on unresolved trade-offs, and reports any remaining tie-breaking gap to the lead.${astraClause} \`mcp__${searchKey}__code\` provides semantic-first code search and \`mcp__${searchKey}__web\` provides citable sources.${browserClause}${workerBrowseClause}${artifactClause}\n\nVerify claims with concrete repository evidence and tests before declaring work done. User instructions outrank delegation triggers. Stop named teammates when finished.`;
+Verify claims with concrete repository evidence and tests before declaring work done. User instructions outrank delegation triggers. Stop named teammates when finished.`;
 	}
-	return "## Operating defaults (apply when the user has not specified otherwise; the user's explicit direction and the domain's own standards always override)\n\nOrchestrate. Delegate research, implementation, review, and large reads to the right subagent, worker, or model. Reach for " + buildNativeReachClauses(opts) + "; worker-* agents for background non-blocking runs; Task subagents for parallel work; peer critics for review. That keeps your own context free to reason and collaborate with the user. Launch independent agents concurrently in a single message rather than serially. Delegation pays when the work is WIDE (many files or sources to sweep) or SLOW, and you need only the conclusion: the main thread is where you think with and respond to the user, and its context window is a finite shared resource. It does NOT pay merely because a sub-question is separable. A narrow, deep question whose whole value is file:line fidelity loses exactly that through a summarization layer, and a sub-question you could answer in one command is cheaper done directly than paying a subagent's startup. Do trivial, surgical, and last-mile work yourself. A named teammate persists after it reports so you can send it follow-ups, and nothing reaps it for you: its idle notice means available, not finished. Stop it once you are done with it.\n\nAdversarial review. The peer critics (`codex_critic` and `codex_reviewer`, `gemini_critic` and `gemini_reviewer`, `opus_critic`, and the `peer-review-coordinator` that fans out to several of them) are fresh-context models, so what they add is a blind spot that whoever produced the work cannot reach by thinking harder about it; prefer a critic from a different lab than the producer, since blind spots correlate within a lab. The `advisor` is a complement and not a substitute: it sees your transcript, so it catches your own drift and momentum, but it inherits your framing, which is exactly what a fresh-context critic does not. They earn their keep on consequential design choices, recommendations, and hard-to-reverse decisions: the cases where plausible alternatives remain and the conclusion rests on judgment rather than on something you can verify directly. That is where confabulation hides, so budget the wait even under delivery pressure. Always consult one when the change touches auth, user input, database queries, crypto, or serialization. They do NOT pay for read-only tracing, ordinary repository lookup, or a conclusion that a focused test, a direct reproduction, or unambiguous code evidence already settles. Asking a critic to re-derive a proven fact returns a confident answer either way, which is ritual skepticism rather than review, and skipping them there is the right call and not a shortcut. Match the lens to the artifact: a strategic critic for plans and trade-offs, a code reviewer for a concrete diff, the coordinator only when the risk warrants several independent lenses. Give whichever you pick the artifact and the constraints and not your rationale, since justification anchors the review and dulls it.\n\nAim high. Default to radical simplicity and a relentless focus on the user's real experience: design for the person and the job to be done, not the demo. Reason about the whole system from first principles, anticipating scale and the long arc rather than patching the surface. Work backwards from the outcome the user actually needs. Question every assumption and prefer what you can derive, reproduce, or test.\n\nEngineering excellence. When making technical decisions, give little weight to development cost; prefer quality, simplicity, robustness, scalability, and long-term maintainability. Fix a bug by first reproducing it end to end, as close to how a real user hits it as you can, so you solve the real problem and not a symptom. When testing a product end to end, be picky about the UI and obsessed with pixel perfection: if something clearly looks off, even when it is unrelated to your task, get it fixed along the way. Hold that same bar for the codebase itself: a lint error, a failing test, or a flaky test is worth fixing the moment you see it, whoever introduced it. Fold it into your current work rather than letting it derail the task the user actually asked for.";
+	return "## Operating defaults (these layer with the user's explicit direction and the domain's own standards as addons, not replacements: follow all three together; on a direct conflict the user's direction wins, then the domain standard, then the default below)\n\nOrchestrate. Delegate research, implementation, review, and large reads to the right subagent, worker, or model. Reach for " + buildNativeReachClauses(opts) + "; worker-* agents for background non-blocking runs; Task subagents for parallel work; peer critics for review. That keeps your own context free to reason and collaborate with the user. Launch independent agents concurrently in a single message rather than serially. Delegation pays when the work is WIDE (many files or sources to sweep) or SLOW, and you need only the conclusion: the main thread is where you think with and respond to the user, and its context window is a finite shared resource. It does NOT pay merely because a sub-question is separable. A narrow, deep question whose whole value is file:line fidelity loses exactly that through a summarization layer, and a sub-question you could answer in one command is cheaper done directly than paying a subagent's startup. Do trivial, surgical, and last-mile work yourself. A named teammate persists after it reports so you can send it follow-ups, and nothing reaps it for you: its idle notice means available, not finished. Stop it once you are done with it.\n\nAdversarial review. The peer critics (`codex_critic` and `codex_reviewer`, `gemini_critic` and `gemini_reviewer`, `opus_critic`, and the `peer-review-coordinator` that fans out to several of them) are fresh-context models, so what they add is a blind spot that whoever produced the work cannot reach by thinking harder about it; prefer a critic from a different lab than the producer, since blind spots correlate within a lab. The `advisor` is a complement and not a substitute: it sees your transcript, so it catches your own drift and momentum, but it inherits your framing, which is exactly what a fresh-context critic does not. They earn their keep on consequential design choices, recommendations, and hard-to-reverse decisions: the cases where plausible alternatives remain and the conclusion rests on judgment rather than on something you can verify directly. That is where confabulation hides, so budget the wait even under delivery pressure. Always consult one when the change touches auth, user input, database queries, crypto, or serialization. They do NOT pay for read-only tracing, ordinary repository lookup, or a conclusion that a focused test, a direct reproduction, or unambiguous code evidence already settles. Asking a critic to re-derive a proven fact returns a confident answer either way, which is ritual skepticism rather than review, and skipping them there is the right call and not a shortcut. Match the lens to the artifact: a strategic critic for plans and trade-offs, a code reviewer for a concrete diff, the coordinator only when the risk warrants several independent lenses. Give whichever you pick the artifact and the constraints and not your rationale, since justification anchors the review and dulls it.\n\nAim high. Default to radical simplicity and a relentless focus on the user's real experience: design for the person and the job to be done, not the demo. Reason about the whole system from first principles, anticipating scale and the long arc rather than patching the surface. Work backwards from the outcome the user actually needs. Question every assumption and prefer what you can derive, reproduce, or test.\n\nEngineering excellence. When making technical decisions, give little weight to development cost; prefer quality, simplicity, robustness, scalability, and long-term maintainability. Fix a bug by first reproducing it end to end, as close to how a real user hits it as you can, so you solve the real problem and not a symptom. When testing a product end to end, be picky about the UI and obsessed with pixel perfection: if something clearly looks off, even when it is unrelated to your task, get it fixed along the way. Hold that same bar for the codebase itself: a lint error, a failing test, or a flaky test is worth fixing the moment you see it, whoever introduced it. Fold it into your current work rather than letting it derail the task the user actually asked for.";
 }
 /** The all-available form of the directive. Prefer
 *  `buildOperatingDefaultsDirective` on any path that knows which natives
 *  resolved; this const is the default for callers and tests that do not model
 *  a thin catalog. */
 const OPERATING_DEFAULTS_DIRECTIVE = buildOperatingDefaultsDirective();
-const STANDARD_OPERATING_DEFAULTS_DIGEST = "## Operating defaults (the user's explicit direction and the domain's standards always override)\n\nDelegate when the work is WIDE (many files or sources to sweep) or SLOW and you need only the conclusion, to protect the main thread's finite context and keep it free for reasoning and interacting with the user; prefer parallel delegation for independent work. Do NOT delegate merely because a sub-question is separable: a narrow, deep question whose value is file:line fidelity loses exactly that through a summarization layer, and one answerable in a single command is cheaper done directly. Do trivial, surgical, and last-mile work yourself. Stop a named teammate once you are done with it: it persists for follow-ups, its idle notice means available rather than finished, and nothing reaps it for you.\n\nVerify, do not assert. Run the code, read the file, check the exit code. A claim in prose is worth nothing against state you did not check, and a check that cannot fail proves nothing. Reproduce a bug end to end, the way a real user hits it, before fixing it. Fix a lint error, failing test, or flake the moment you see it, whoever introduced it, without letting it derail the task at hand. Prefer quality and long-term maintainability over development cost.\n\nVerification has a blind spot: a consequential recommendation, a design or trade-off call, or a hard-to-reverse decision that still turns on judgment among plausible alternatives once the direct evidence is in. That is where confabulation hides, so put it past a peer critic before you ship it and budget the wait even under delivery pressure. When a test, a run, a reproduction, or a search would settle the claim, settle it that way instead; a critic asked to re-derive what you can already prove is ritual, not review.\n\nThe agent roster, the tool surface, and the reasoning behind these defaults are in your CLAUDE.md project instructions. Read them when choosing HOW to work; the rules above apply without a lookup.";
+const STANDARD_OPERATING_DEFAULTS_DIGEST = "## Operating defaults (these layer with the user's direction and the domain's standards as addons: follow all three; on a direct conflict the user's direction wins, then the domain standard, then the default below)\n\nDelegate when the work is WIDE (many files or sources to sweep) or SLOW and you need only the conclusion, to protect the main thread's finite context and keep it free for reasoning and interacting with the user; prefer parallel delegation for independent work. Do NOT delegate merely because a sub-question is separable: a narrow, deep question whose value is file:line fidelity loses exactly that through a summarization layer, and one answerable in a single command is cheaper done directly. Do trivial, surgical, and last-mile work yourself. Stop a named teammate once you are done with it: it persists for follow-ups, its idle notice means available rather than finished, and nothing reaps it for you.\n\nVerify, do not assert. Run the code, read the file, check the exit code. A claim in prose is worth nothing against state you did not check, and a check that cannot fail proves nothing. Reproduce a bug end to end, the way a real user hits it, before fixing it. Fix a lint error, failing test, or flake the moment you see it, whoever introduced it, without letting it derail the task at hand. Prefer quality and long-term maintainability over development cost.\n\nVerification has a blind spot: a consequential recommendation, a design or trade-off call, or a hard-to-reverse decision that still turns on judgment among plausible alternatives once the direct evidence is in. That is where confabulation hides, so put it past a peer critic before you ship it and budget the wait even under delivery pressure. When a test, a run, a reproduction, or a search would settle the claim, settle it that way instead; a critic asked to re-derive what you can already prove is ritual, not review.\n\nThe agent roster, the tool surface, and the reasoning behind these defaults are in your CLAUDE.md project instructions. Read them when choosing HOW to work; the rules above apply without a lookup.";
 function buildOperatingDefaultsDigest(opts = {}) {
-	if (opts.profile === "max") return "## Operating defaults (the user's explicit direction and the domain's standards always override)\n\nMax launch profile. The lead owns the outcome. Start with direct repository or runtime evidence. Do narrow, obvious, surgical, and single-command work directly; delegate bounded work that is broad, slow, context-heavy, or independently valuable. " + MAX_PARALLELISM_RULE + " Give delegated workstreams non-overlapping scopes and state the outcome, constraints, evidence, and verification expected.\n\nSynthesize and verify: run the code, inspect outputs, and check tests. Agent count and agreement are not evidence. Use a fresh-context peer only for consequential judgment that remains after direct checks, and use the coordinator only when several distinct lenses could change the decision. Advisor is optional, non-binding, primary-lead-only counsel for one focused consequential uncertainty; it is not an approval or completion gate.";
-	if (opts.profile === "fast" || opts.profile === "cheap" || opts.profile === "cheap1m" || opts.profile === "cheapest") {
+	if (opts.profile === "max") return "## Operating defaults (these layer with the user's direction and the domain's standards as addons: follow all three; on a direct conflict the user's direction wins, then the domain standard, then the default below)\n\nMax launch profile. The lead owns the outcome. Start with direct repository or runtime evidence. Do narrow, obvious, surgical, and single-command work directly; delegate bounded work that is broad, slow, context-heavy, or independently valuable. " + MAX_PARALLELISM_RULE + " Give delegated workstreams non-overlapping scopes and state the outcome, constraints, evidence, and verification expected.\n\nPipeline skills (all 200K default): `/gh-gather-context` before planning when context is needed, `/gh-plan` before implementation (waits for user approval), `/gh-implement` after approval with bounded parallel workers and staged review. Skip for trivial work.\n\nSynthesize and verify: run the code, inspect outputs, and check tests. Agent count and agreement are not evidence. Use a fresh-context peer only for consequential judgment that remains after direct checks, and use the coordinator only when several distinct lenses could change the decision. Advisor is optional, non-binding, primary-lead-only counsel for one focused consequential uncertainty; it is not an approval or completion gate.";
+	if (opts.profile === "fast" || opts.profile === "cheap" || opts.profile === "cheap1m" || opts.profile === "cheapest" || opts.profile === "balanced") {
 		const isCheap = opts.profile === "cheap" || opts.profile === "cheap1m";
 		const isCheapest = opts.profile === "cheapest";
-		const profileLabel = isCheapest ? "Cheapest" : isCheap ? "Cheap" : "Fast";
-		const oracleDescriptor = isCheapest ? "(GPT-5.6 Sol 200K/high, lead and Plan)" : isCheap ? "(Grok 4.6 200K/medium, lead and Plan)" : "(Opus 5 1M/high, lead and Plan)";
+		const isBalanced = opts.profile === "balanced";
+		const profileLabel = isCheapest ? "Cheapest" : isCheap ? "Cheap" : isBalanced ? "Balanced" : "Fast";
+		const oracleDescriptor = isCheapest ? "(GPT-5.6 Sol 200K/high, lead and Plan)" : isCheap || isBalanced ? "(Grok 4.6 200K/medium, lead and Plan)" : "(Opus 5 1M/high, lead and Plan)";
 		const advisorDescriptor = isCheapest ? "(Gemini/high, lead-only)" : "(Sol/high, lead-only)";
 		const astraStep = opts.astraAvailable && (opts.profile === "fast" || opts.profile === "cheap1m") ? `; (4) \`astra\` (GPT-6 Astra 200K/${isCheap ? "medium" : "high"}, lead-only) only as a last resort when direct evidence, Advisor, and Oracle cannot produce a defensible path (at most 1-2 calls per decision).` : ".";
-		return `## Operating defaults (the user's explicit direction and the domain's standards always override)
-
-${profileLabel} launch profile. The lead coordinates execution across specialized roles: delegate broad discovery to \`Explore\` in parallel and do not sweep the repo yourself (read directly only files you will act on); delegate to \`Plan\` in plan mode or when structuring complex multi-step sequencing (\`Plan\` is an advisory planning capability, not an approval gate); delegate bounded implementation to \`implementer\` in a fresh context to preserve lead context (\`general-purpose\` for mixed multi-step execution); delegate to \`reviewer\` after behavior-changing or risk-sensitive implementation, and always after \`implementer\` completes, to verify correctness before declaring done; handle trivial and surgical edits directly. Send independent subagent calls in parallel within a single turn. Stop named teammates when finished.\n\nVerify claims against real evidence: run relevant commands and tests. Follow a disciplined consultation ladder for unresolved decisions: (1) direct code inspection, search, builds, and tests settle factual questions; (2) \`advisor\` ` + advisorDescriptor + " for transcript-aware framing checks or trajectory guidance; (3) `oracle` " + oracleDescriptor + " for self-contained technical/architectural trade-offs" + astraStep;
+		return "## Operating defaults (these layer with the user's direction and the domain's standards as addons: follow all three; on a direct conflict the user's direction wins, then the domain standard, then the default below)\n\n" + (isCheapest ? `${profileLabel} launch profile. The lead owns the outcome and handles straightforward work directly: use \`Explore\` for discovery spanning more than a couple of files, \`Plan\` in plan mode or for complex sequencing, \`General-Purpose\` for mixed multi-step execution, and \`reviewer\` for behavior-changing or risk-sensitive changes. Handle trivial and surgical edits directly. Stop named teammates when finished.\n\n` : `${profileLabel} launch profile. The lead coordinates execution across specialized roles: delegate broad discovery to \`Explore\` in parallel and do not sweep the repo yourself (read directly only files you will act on); delegate to \`Plan\` in plan mode or when structuring complex multi-step sequencing (\`Plan\` is an advisory planning capability, not an approval gate, and writes handoff-ready steps for \`General-Purpose\`); delegate mixed multi-step execution and Plan handoffs to \`General-Purpose\` in a fresh context; delegate to \`reviewer\` after behavior-changing or risk-sensitive implementation to verify correctness before declaring done; handle trivial and surgical edits directly. Send independent subagent calls in parallel within a single turn. Stop named teammates when finished.\n\n`) + "Pipeline skills (all 200K default): `/gh-gather-context` before planning when context is needed, `/gh-plan` before implementation (waits for user approval), `/gh-implement` after approval with bounded parallel workers and staged review. Skip for trivial work.\n\nVerify claims against real evidence: run relevant commands and tests. Follow a disciplined consultation ladder for unresolved decisions: (1) direct code inspection, search, builds, and tests settle factual questions; (2) `advisor` " + advisorDescriptor + " for transcript-aware framing checks or trajectory guidance; (3) `oracle` " + oracleDescriptor + " for self-contained technical/architectural trade-offs" + astraStep;
 	}
 	return STANDARD_OPERATING_DEFAULTS_DIGEST;
 }
@@ -2880,9 +3413,18 @@ async function writeInjectedSkill(name, md) {
 * `/gh-orchestrate`, `/gh-floor-keeper`, `/gh-first-mate`). See
 * `docs/floor-raising-agent-surface.md`.
 */
+/** Pipeline skills for pinned profiles (all 200K default context). */
+const PIPELINE_SKILLS = [
+	GATHER_CONTEXT_SKILL,
+	PLAN_SKILL,
+	IMPLEMENT_SKILL
+];
 /** All injected skills, in dependency order (research underpins the others). */
 const INJECTED_SKILLS = [
 	RESEARCH_SKILL,
+	GATHER_CONTEXT_SKILL,
+	PLAN_SKILL,
+	IMPLEMENT_SKILL,
 	ORCHESTRATE_SKILL,
 	FLOOR_KEEPER_SKILL,
 	WORKER_SKILL,
@@ -2892,8 +3434,14 @@ const INJECTED_SKILLS = [
 	FIRST_MATE_CONDUCT_SKILL
 ];
 function injectedSkillsForLaunch(selection) {
-	if (selection.profileId === "fast" || selection.profileId === "cheap" || selection.profileId === "cheap1m" || selection.profileId === "cheapest") return [];
-	if (selection.profileId === "max") return selection.firstMateEnabled ? INJECTED_SKILLS.filter((skill) => skill.name.startsWith("gh-first-mate")) : [];
+	if (isPipelineSkillProfile(selection.profileId)) {
+		if (selection.profileId === "max") {
+			const pipeline = PIPELINE_SKILLS.slice();
+			if (selection.firstMateEnabled) return [...pipeline, ...INJECTED_SKILLS.filter((skill) => skill.name.startsWith("gh-first-mate"))];
+			return pipeline;
+		}
+		return PIPELINE_SKILLS.slice();
+	}
 	if (!selection.workerSkillsActive) return [];
 	return INJECTED_SKILLS.filter((skill) => selection.firstMateEnabled || !skill.name.startsWith("gh-first-mate"));
 }
@@ -2964,4 +3512,4 @@ async function injectAttributionSuppressionIntoSettingsFile(settingsPath) {
 //#endregion
 export { writePeerMcpRuntimeFiles as C, workersKeyOf as S, sanitizeServeSettingsEnv as _, appendPeerAwarenessToMirroredClaudeMd as a, resolveCodexCliBackend as b, buildOperatingDefaultsDirective as c, prependStyleDirectiveToMirroredClaudeMd as d, buildArtifactReviewSkill as f, planModeAllowRules as g, injectAllowRules as h, writeInjectedSkill as i, prependArtifactPanelDirectiveToMirroredClaudeMd as l, configureServeDefaultPermissionMode as m, INJECTED_SKILLS as n, appendToolbeltAwarenessToMirroredClaudeMd as o, SEAMLESS_BUILTIN_TOOLS as p, injectedSkillsForLaunch as r, buildOperatingDefaultsDigest as s, injectAttributionSuppressionIntoSettingsFile as t, prependOperatingDefaultsToMirroredClaudeMd as u, BUILTIN_SUBAGENT_DEFINITIONS as v, resolveGroupKeysFromMirror as x, injectPeerMcpIntoMirror as y };
 
-//# sourceMappingURL=attribution-settings-z-U2L7ab.js.map
+//# sourceMappingURL=attribution-settings-sTUXqFzx.js.map