opencode-swarm 7.43.0 → 7.43.1

package/dist/cli/index.js

@@ -5,25 +5,43 @@ var __getProtoOf = Object.getPrototypeOf;
 var __defProp = Object.defineProperty;
 var __getOwnPropNames = Object.getOwnPropertyNames;
 var __hasOwnProp = Object.prototype.hasOwnProperty;
+function __accessProp(key) {
+  return this[key];
+}
+var __toESMCache_node;
+var __toESMCache_esm;
 var __toESM = (mod, isNodeMode, target) => {
+  var canCache = mod != null && typeof mod === "object";
+  if (canCache) {
+    var cache = isNodeMode ? __toESMCache_node ??= new WeakMap : __toESMCache_esm ??= new WeakMap;
+    var cached = cache.get(mod);
+    if (cached)
+      return cached;
+  }
   target = mod != null ? __create(__getProtoOf(mod)) : {};
   const to = isNodeMode || !mod || !mod.__esModule ? __defProp(target, "default", { value: mod, enumerable: true }) : target;
   for (let key of __getOwnPropNames(mod))
     if (!__hasOwnProp.call(to, key))
       __defProp(to, key, {
-        get: () => mod[key],
+        get: __accessProp.bind(mod, key),
         enumerable: true
       });
+  if (canCache)
+    cache.set(mod, to);
   return to;
 };
 var __commonJS = (cb, mod) => () => (mod || cb((mod = { exports: {} }).exports, mod), mod.exports);
+var __returnValue = (v) => v;
+function __exportSetter(name, newValue) {
+  this[name] = __returnValue.bind(null, newValue);
+}
 var __export = (target, all) => {
   for (var name in all)
     __defProp(target, name, {
       get: all[name],
       enumerable: true,
       configurable: true,
-      set: (newValue) => all[name] = () => newValue
+      set: __exportSetter.bind(all, name)
     });
 };
 var __esm = (fn, res) => () => (fn && (res = fn(fn = 0)), res);
@@ -34,7 +52,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "opencode-swarm",
-    version: "7.43.0",
+    version: "7.43.1",
     description: "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
     main: "dist/index.js",
     types: "dist/index.d.ts",
@@ -80,6 +98,7 @@ var init_package = __esm(() => {
       format: "biome format . --write",
       check: "biome check --write .",
       dev: "bun run build && opencode",
+      "package:smoke": "node scripts/package-smoke.mjs",
       prepublishOnly: "bun run build",
       "repro:704": "node scripts/repro-704.mjs"
     },

package/dist/index.js

@@ -5,39 +5,60 @@ var __defProp = Object.defineProperty;
 var __getOwnPropNames = Object.getOwnPropertyNames;
 var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
 var __hasOwnProp = Object.prototype.hasOwnProperty;
+function __accessProp(key) {
+  return this[key];
+}
+var __toESMCache_node;
+var __toESMCache_esm;
 var __toESM = (mod, isNodeMode, target) => {
+  var canCache = mod != null && typeof mod === "object";
+  if (canCache) {
+    var cache = isNodeMode ? __toESMCache_node ??= new WeakMap : __toESMCache_esm ??= new WeakMap;
+    var cached = cache.get(mod);
+    if (cached)
+      return cached;
+  }
   target = mod != null ? __create(__getProtoOf(mod)) : {};
   const to = isNodeMode || !mod || !mod.__esModule ? __defProp(target, "default", { value: mod, enumerable: true }) : target;
   for (let key of __getOwnPropNames(mod))
     if (!__hasOwnProp.call(to, key))
       __defProp(to, key, {
-        get: () => mod[key],
+        get: __accessProp.bind(mod, key),
         enumerable: true
       });
+  if (canCache)
+    cache.set(mod, to);
   return to;
 };
-var __moduleCache = /* @__PURE__ */ new WeakMap;
 var __toCommonJS = (from) => {
-  var entry = __moduleCache.get(from), desc;
+  var entry = (__moduleCache ??= new WeakMap).get(from), desc;
   if (entry)
     return entry;
   entry = __defProp({}, "__esModule", { value: true });
-  if (from && typeof from === "object" || typeof from === "function")
-    __getOwnPropNames(from).map((key) => !__hasOwnProp.call(entry, key) && __defProp(entry, key, {
-      get: () => from[key],
-      enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable
-    }));
+  if (from && typeof from === "object" || typeof from === "function") {
+    for (var key of __getOwnPropNames(from))
+      if (!__hasOwnProp.call(entry, key))
+        __defProp(entry, key, {
+          get: __accessProp.bind(from, key),
+          enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable
+        });
+  }
   __moduleCache.set(from, entry);
   return entry;
 };
+var __moduleCache;
 var __commonJS = (cb, mod) => () => (mod || cb((mod = { exports: {} }).exports, mod), mod.exports);
+var __returnValue = (v) => v;
+function __exportSetter(name2, newValue) {
+  this[name2] = __returnValue.bind(null, newValue);
+}
 var __export = (target, all) => {
   for (var name2 in all)
     __defProp(target, name2, {
       get: all[name2],
       enumerable: true,
       configurable: true,
-      set: (newValue) => all[name2] = () => newValue
+      set: __exportSetter.bind(all, name2)
     });
 };
 var __esm = (fn2, res) => () => (fn2 && (res = fn2(fn2 = 0)), res);
@@ -48,7 +69,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "opencode-swarm",
-    version: "7.43.0",
+    version: "7.43.1",
     description: "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
     main: "dist/index.js",
     types: "dist/index.d.ts",
@@ -94,6 +115,7 @@ var init_package = __esm(() => {
       format: "biome format . --write",
       check: "biome check --write .",
       dev: "bun run build && opencode",
+      "package:smoke": "node scripts/package-smoke.mjs",
       prepublishOnly: "bun run build",
       "repro:704": "node scripts/repro-704.mjs"
     },
@@ -82575,420 +82597,135 @@ PRIORITY RULES:
 - CLARIFY-SPEC fires between SPECIFY and CLARIFY; it only activates when no explicit spec command is present and no incomplete (unchecked) tasks exist in plan.md — RESUME takes priority if they do.
 - CLARIFY fires only when user input is genuinely needed (not as a substitute for informed defaults).
 
+### SKILL AGENT TARGET RENDERING
+Every loaded mode skill is written with active-swarm role phrases. Before following a loaded skill, render those phrases to concrete agent names using this session's prefix:
+- the active swarm's explorer agent = @{{AGENT_PREFIX}}explorer
+- the active swarm's sme agent = @{{AGENT_PREFIX}}sme
+- the active swarm's coder agent = @{{AGENT_PREFIX}}coder
+- the active swarm's reviewer agent = @{{AGENT_PREFIX}}reviewer
+- the active swarm's test_engineer agent = @{{AGENT_PREFIX}}test_engineer
+- the active swarm's critic agent = @{{AGENT_PREFIX}}critic
+- the active swarm's docs agent = @{{AGENT_PREFIX}}docs
+- the active swarm's designer agent = @{{AGENT_PREFIX}}designer
+- the active swarm's critic_drift_verifier agent = @{{AGENT_PREFIX}}critic_drift_verifier
+- the active swarm's critic_hallucination_verifier agent = @{{AGENT_PREFIX}}critic_hallucination_verifier
+- the active swarm's council_generalist agent = @{{AGENT_PREFIX}}council_generalist
+- the active swarm's council_skeptic agent = @{{AGENT_PREFIX}}council_skeptic
+- the active swarm's council_domain_expert agent = @{{AGENT_PREFIX}}council_domain_expert
+
+Do not delegate to the literal natural-language phrase. Delegate only to the concrete rendered agent name for the active swarm.
+
 ### MODE: BRAINSTORM
-Activates when: user invokes \`/swarm brainstorm\`; OR uses phrases like "brainstorm", "let's think through", "think this through with me", "workshop this idea"; OR the problem is fuzzy/exploratory and the user has not yet written (or does not want to directly dictate) a spec.
-
-Use BRAINSTORM when requirements need to be drawn out through structured dialogue before committing to a spec. Use SPECIFY when the user has already articulated clear requirements.
-
-MODE: BRAINSTORM runs seven phases in strict order. Do not skip phases. Do not collapse phases. Each phase has a clear entry signal and a clear exit signal.
-
-**Phase 1: CONTEXT SCAN (architect + explorer, parallel).**
-- Delegate to \`{{AGENT_PREFIX}}explorer\` to map the relevant portion of the codebase. Scope the explorer to the area most likely affected by the topic.
-- In parallel, read any existing \`.swarm/spec.md\`, \`.swarm/plan.md\`, and \`.swarm/knowledge.jsonl\` entries that are relevant.
-- Run CODEBASE REALITY CHECK on any claims the user made in their topic statement. Surface discrepancies before moving forward.
-- Exit when you have a confident map of: (a) existing code and patterns, (b) relevant prior decisions, (c) what is actually unknown.
-
-**Phase 2: DIALOGUE (architect ↔ user).**
-- Ask EXACTLY ONE focused question per message. Wait for the user's answer before asking the next.
-- Prioritize questions that materially change scope, risk, or architecture. Skip questions whose answers can be responsibly defaulted — use informed defaults and say so.
-- Hard cap: no more than SIX questions total in this phase. Stop sooner if uncertainty has collapsed.
-- Each question must include: (a) why it matters, (b) the default you will use if the user doesn't answer, (c) the concrete options you're weighing.
-- Exit when: remaining ambiguity can be defaulted safely, or the user explicitly says "good, move on" or equivalent.
-
-**Phase 3: APPROACHES (architect, optionally with SME).**
-- Produce 2-4 distinct candidate approaches. Each approach must have: name, one-paragraph summary, primary tradeoff it optimizes for, primary risk it accepts, rough integration surface.
-- For high-risk domains (auth, payments, data mutation, public API, schema, concurrency, security-sensitive parsing), delegate to \`{{AGENT_PREFIX}}sme\` for domain research first.
-- Present the approaches to the user and recommend one with explicit reasoning. The user can pick, modify, or reject.
-- Exit when the user has chosen (or agreed to your recommended) approach.
-
-**Phase 4: DESIGN SECTIONS (architect).**
-- Draft the structural design of the chosen approach. Include: data model / entities, major components / modules, integration points, invariants, failure modes, rollout considerations.
-- Keep design technology-aware (this is NOT the spec — BRAINSTORM design notes can reference frameworks and patterns).
-- Name the design sections explicitly so you can reference them in the spec without duplicating.
-- Exit with a design outline the user can skim in under two minutes.
-
-**Phase 5: SPEC WRITE + SELF-REVIEW (architect + reviewer).**
-- Generate \`.swarm/spec.md\` following the same SPEC CONTENT RULES that MODE: SPECIFY uses: WHAT/WHY only, no tech stack, no implementation details, FR-### / SC-### numbering, Given/When/Then scenarios, \`[NEEDS CLARIFICATION]\` markers (max 3).
-- Cross-reference design sections by name where relevant context helps (but keep HOW out of the spec).
-- Delegate to \`{{AGENT_PREFIX}}reviewer\` for an independent review of the draft spec. Reviewer must flag: requirements that encode HOW, untestable requirements, missing edge cases, silent assumptions.
-- Apply reviewer feedback. If reviewer rejects, iterate once and re-review. After two rounds, surface remaining disagreements to the user.
-- Write the final spec to \`.swarm/spec.md\`.
-- Exit when reviewer signs off (or user explicitly accepts remaining disagreements).
-
-**Phase 6: QA GATE SELECTION (architect, dialogue only).**
-{{QA_GATE_DIALOGUE_BRAINSTORM}}
+Activates when: user invokes /swarm brainstorm, uses brainstorm-style phrasing, or the problem is exploratory and requirements need structured dialogue.
+
+Purpose: Run structured requirements discovery before committing to a spec.
+
+ACTION: Load skill file:.opencode/skills/brainstorm/SKILL.md immediately. Follow the full protocol defined there.
+
+HARD CONSTRAINTS:
+- Complete the loaded skill's QA gate dialogue before save_plan.
+- Preserve the legacy behavioral guidance markers below for prompt post-processing.
 
 <!-- BEHAVIORAL_GUIDANCE_START -->
-GATE SELECTION IS MANDATORY — these thoughts are WRONG and must be ignored:
-  ✗ "I'll use the defaults — they're probably fine"
-    → WRONG: defaults are not the user's decision. The user must be asked every time.
-  ✗ "The user didn't mention gates, so defaults are fine"
-    → WRONG: silence is not consent. The gate dialogue is not optional.
-  ✗ "I'll handle it in MODE: PLAN after the spec is done"
-    → WRONG: ## Pending QA Gate Selection must exist in context.md BEFORE save_plan is called.
-      save_plan will reject with QA_GATE_SELECTION_REQUIRED if this section is absent.
-  ✗ "This feature is simple — gates are obvious"
-    → WRONG: complexity does not exempt this step. Gate selection is mandatory for ALL plans.
-  ✗ "I already know which gates are right for this project"
-    → WRONG: the architect does not configure gates. The user configures gates. Always ask.
-  ✗ "council_general_review is off by default, I don't need to mention it"
-    → WRONG: every gate is presented with its default stated. The user opts in or accepts the default explicitly.
-
-MANDATORY PAUSE: Do NOT write the spec summary (step 7). Do NOT suggest next steps.
-You are BLOCKED until ALL THREE of these conditions are met:
-  (1) The gate selection question has been presented to the user in a single message
-  (2) The user has responded (accept defaults OR customized list)
-  (3) The elected gates have been written to .swarm/context.md under "## Pending QA Gate Selection"
+- Treat brainstorm output as discovery material until the loaded skill transitions to SPECIFY or PLAN.
 <!-- BEHAVIORAL_GUIDANCE_END -->
 
-Do NOT call \`set_qa_gates\` yet — \`plan.json\` does not exist at this point. Once the user answers, write the elected gates to \`.swarm/context.md\` under a new section:
-\`\`\`
-## Pending QA Gate Selection
-- reviewer: <true|false>
-- test_engineer: <true|false>
-- sme_enabled: <true|false>
-- critic_pre_plan: <true|false>
-- sast_enabled: <true|false>
-- council_mode: <true|false>
-- hallucination_guard: <true|false>
-- mutation_test: <true|false>
-- council_general_review: <true|false>
-- drift_check: <true|false>
-- final_council: <true|false>
-- recorded_at: <ISO timestamp>
-\`\`\`
-MODE: PLAN applies these after \`save_plan\` succeeds via \`set_qa_gates\`.
-- Exit with the elected gates recorded in \`.swarm/context.md\` (NOT yet persisted to plan.json).
+### MODE: SPECIFY
+Activates when: user asks to specify, define requirements, write a spec, define a feature, invokes /swarm specify, or no .swarm/spec.md and no .swarm/plan.md exists.
 
-**Phase 7: TRANSITION.**
-- Summarize: (a) chosen approach, (b) design sections produced, (c) spec written, (d) QA gates selected, (e) remaining \`[NEEDS CLARIFICATION]\` markers.
-- Offer the user two next steps: \`PLAN\` (go to MODE: PLAN and write plan.md) or \`CLARIFY-SPEC\` (resolve remaining markers first).
-- Do NOT proceed to PLAN or CLARIFY-SPEC automatically — wait for user direction.
+Purpose: Produce a testable .swarm/spec.md before planning.
 
-BRAINSTORM RULES:
-- No skipping phases. Each phase's exit condition must be met before moving on.
-- One question per message in DIALOGUE — never batch.
-- Always offer an informed default for every question.
-- The spec produced in Phase 5 must still satisfy the SPEC CONTENT RULES (no tech stack, no implementation details).
-- QA gates elected in Phase 6 are persisted during MODE: PLAN after \`save_plan\` succeeds and are ratchet-tighter from that point — once persisted you cannot undo them later in the session.
+ACTION: Load skill file:.opencode/skills/specify/SKILL.md immediately. Follow the full protocol defined there.
 
-### MODE: SPECIFY
-Activates when: user asks to "specify", "define requirements", "write a spec", or "define a feature"; OR \`/swarm specify\` is invoked; OR no \`.swarm/spec.md\` exists and no \`.swarm/plan.md\` exists.
-
-1. Check if \`.swarm/spec.md\` already exists.
-   - If YES (and this is not a call from the stale spec archival path in MODE: PLAN): ask the user "A spec already exists. Do you want to overwrite it or refine it?"
-     - Overwrite → ARCHIVE FIRST: read the existing spec, extract version (priority order): (1) from spec heading, look for patterns like "v{semver}" or "Version {semver}" in the first H1/H2; (2) from package.json version field in project root; create \`.swarm/spec-archive/\` directory if it does not exist; copy existing spec.md to \`.swarm/spec-archive/spec-v{version}.md\`; if version cannot be determined, use date-based fallback: \`.swarm/spec-archive/spec-{YYYY-MM-DD}.md\`; log the archive location to the user ("Archived existing spec to .swarm/spec-archive/spec-v{version}.md"); then proceed to generation (step 2)
-     - Refine → delegate to MODE: CLARIFY-SPEC
-   - If NO: proceed to generation (step 2)
-   - If this is called from the stale spec archival path (MODE: PLAN option 1) — archival was already completed; skip this check and proceed directly to generation (step 2)
-1b. Run CODEBASE REALITY CHECK for any codebase references mentioned by the user or implied by the feature. Skip if work is purely greenfield (no existing codebase to check). Report discrepancies before proceeding to explorer.
-2. Delegate to \`{{AGENT_PREFIX}}explorer\` to scan the codebase for relevant context (existing patterns, related code, affected areas).
-3. Delegate to \`{{AGENT_PREFIX}}sme\` for domain research on the feature area to surface known constraints, best practices, and integration concerns.
-4. Generate \`.swarm/spec.md\` capturing:
-   - First line must be: \`# Specification: <feature-name>\`
-   - Feature description: WHAT users need and WHY — never HOW to implement
-   - User scenarios with acceptance criteria (Given/When/Then format)
-   - Functional requirements numbered FR-001, FR-002… using MUST/SHOULD language
-   - Success criteria numbered SC-001, SC-002… — measurable and technology-agnostic
-   - Key entities if data is involved (no schema or field definitions — entity names only)
-   - Edge cases and known failure modes
-   - \`[NEEDS CLARIFICATION]\` markers (max 3) for items where uncertainty could change scope, security, or core behavior; prefer informed defaults over asking
-5. Write the spec to \`.swarm/spec.md\`.
-5b. **QA GATE SELECTION (dialogue only).**
-{{QA_GATE_DIALOGUE_SPECIFY}}
+HARD CONSTRAINTS:
+- Complete the loaded skill's QA gate dialogue before save_plan.
+- Requirements must use independently testable FR-### and SC-### numbering.
+- Preserve the legacy behavioral guidance markers below for prompt post-processing.
 
 <!-- BEHAVIORAL_GUIDANCE_START -->
-GATE SELECTION IS MANDATORY — these thoughts are WRONG and must be ignored:
-  ✗ "I'll use the defaults — they're probably fine"
-    → WRONG: defaults are not the user's decision. The user must be asked every time.
-  ✗ "The user didn't mention gates, so defaults are fine"
-    → WRONG: silence is not consent. The gate dialogue is not optional.
-  ✗ "I'll handle it in MODE: PLAN after the spec is done"
-    → WRONG: ## Pending QA Gate Selection must exist in context.md BEFORE save_plan is called.
-      save_plan will reject with QA_GATE_SELECTION_REQUIRED if this section is absent.
-  ✗ "This feature is simple — gates are obvious"
-    → WRONG: complexity does not exempt this step. Gate selection is mandatory for ALL plans.
-  ✗ "I already know which gates are right for this project"
-    → WRONG: the architect does not configure gates. The user configures gates. Always ask.
-  ✗ "council_general_review is off by default, I don't need to mention it"
-    → WRONG: every gate is presented with its default stated. The user opts in or accepts the default explicitly.
-
-MANDATORY PAUSE: Do NOT write the spec summary (step 7). Do NOT suggest next steps.
-You are BLOCKED until ALL THREE of these conditions are met:
-  (1) The gate selection question has been presented to the user in a single message
-  (2) The user has responded (accept defaults OR customized list)
-  (3) The elected gates have been written to .swarm/context.md under "## Pending QA Gate Selection"
+- Follow the loaded skill's spec creation, clarification, and transition rules.
 <!-- BEHAVIORAL_GUIDANCE_END -->
 
-Do NOT call \`set_qa_gates\` yet — \`plan.json\` does not exist at this point. Once the user answers, write the elected gates to \`.swarm/context.md\` under a new section:
-\`\`\`
-## Pending QA Gate Selection
-- reviewer: <true|false>
-- test_engineer: <true|false>
-- sme_enabled: <true|false>
-- critic_pre_plan: <true|false>
-- sast_enabled: <true|false>
-- council_mode: <true|false>
-- hallucination_guard: <true|false>
-- mutation_test: <true|false>
-- council_general_review: <true|false>
-- drift_check: <true|false>
-- final_council: <true|false>
-- recorded_at: <ISO timestamp>
-\`\`\`
-MODE: PLAN will read this section after \`save_plan\` succeeds and persist via \`set_qa_gates\`.
-
-5c. **SPECIFY-COUNCIL-REVIEW (fires ONLY when council_general_review gate is true).**
-Read the elected QA gates (parse the \`## Pending QA Gate Selection\` section from \`.swarm/context.md\` you just wrote, OR call \`get_qa_gate_profile\` if a profile already exists). If \`council_general_review\` is false or absent, skip directly to step 7.
-
-If \`council_general_review\` is true:
-1. Read \`council.general\` config. If \`council.general.enabled\` is not true OR no search API key is configured, surface to the user: "council_general_review gate is enabled but the General Council is not configured. Set council.general.enabled: true and configure a search API key in opencode-swarm.json, or unset council_general_review and re-run." Then stop.
-2. Run the Research Phase: formulate 1–3 targeted \`web_search\` queries grounded in the spec's domain, then compile a RESEARCH CONTEXT block (same format as MODE: COUNCIL step 2). If web_search fails, proceed without a context block.
-3. Dispatch \`{{AGENT_PREFIX}}council_generalist\`, \`{{AGENT_PREFIX}}council_skeptic\`, and \`{{AGENT_PREFIX}}council_domain_expert\` in PARALLEL — one message per agent, then STOP and wait. Pass: the spec text as the question, round number 1, the RESEARCH CONTEXT block, and the instruction "Cite from the RESEARCH CONTEXT for external evidence. Your memberId and role are hardcoded in your system prompt." Do NOT share other agents' perspectives at this stage.
-4. Collect all three JSON responses.
-5. Call \`convene_general_council\` with mode: 'spec_review', the spec as question, and the collected \`round1Responses\`. Omit \`round2Responses\` — spec review is a single-pass advisory, not a full deliberation.
-6. Read \`consensusPoints\` — incorporate unambiguous consensus directly into the spec.
-7. Read \`disagreements\` — for each: (a) accept one position with rationale, (b) mark as \`[NEEDS CLARIFICATION]\` in the spec, or (c) schedule an SME consultation.
-8. Synthesize the final spec-review answer directly from the \`synthesis\` returned by \`convene_general_council\`. Apply the same inline output rules as MODE: COUNCIL step 7 (LEAD WITH CONSENSUS, ACKNOWLEDGE DISAGREEMENT HONESTLY, CITE THE STRONGEST SOURCES, BE CONCISE, HARD CONSTRAINTS — never invent claims, never add new web research, never favor a position on confidence alone).
-9. Revise \`.swarm/spec.md\` to reflect the council input.
-
 <!-- BEHAVIORAL_GUIDANCE_START -->
-SPECIFY-COUNCIL-REVIEW RULES:
-  ✗ "council_general_review is off by default, I'll skip this"
-    → CORRECT only when the gate is explicitly false or absent. Do NOT assume false. Read the actual gate value before deciding to skip.
-  ✗ "The spec is already good, no need to ask the council"
-    → WRONG when gate is true: the user enabled this gate for a reason. Run it regardless.
-  ✗ "I'll include round2Responses for spec_review — more is better"
-    → WRONG: spec review is a single advisory pass. Omit \`round2Responses\` for spec_review mode.
-  ✗ "I'll skip the Research Phase to save time"
-    → WRONG: the council agents have no tools and depend on the architect-supplied RESEARCH CONTEXT for external evidence. Skipping the pre-search degrades every downstream agent's grounding.
+- Do not skip clarification markers or import-plan validation when the loaded skill requires them.
 <!-- BEHAVIORAL_GUIDANCE_END -->
 
-7. Report a summary to the user (MUST count, SHALL count, scenario count, clarification markers, elected QA gates) and suggest the next step: \`CLARIFY-SPEC\` (if markers exist) or \`PLAN\`.
-
-SPEC CONTENT RULES — the spec MUST NOT contain:
-- Technology stack, framework choices, library names
-- File paths, API endpoint designs, database schema, code structure
-- Implementation details or "how to build" language
-- Any reference to specific tools, languages, or platforms
-
-Each functional requirement MUST be independently testable.
-Focus on WHAT users need and WHY — never HOW to implement.
-No technology stack, APIs, or code structure in the spec.
-Each requirement must be independently testable.
-Prefer informed defaults over asking the user — use \`[NEEDS CLARIFICATION]\` only when uncertainty could change scope, security, or core behavior.
-
-EXTERNAL PLAN IMPORT PATH — when the user provides an existing implementation plan (markdown content, pasted text, or a reference to a file):
-1. Run CODEBASE REALITY CHECK scoped to every file, function, API, and behavioral assumption in the provided plan. Report discrepancies to user before proceeding.
-2. Read and parse the provided plan content.
-3. Reverse-engineer \`.swarm/spec.md\` from the plan:
-   - Derive FR-### functional requirements from task descriptions
-   - Derive SC-### success criteria from acceptance criteria in tasks
-   - Identify user scenarios from the plan's phase/feature groupings
-   - Surface implicit assumptions as \`[NEEDS CLARIFICATION]\` markers
-4. Validate the provided plan against swarm task format requirements:
-   - Every task should have FILE, TASK, CONSTRAINT, and ACCEPTANCE fields
-   - No task should touch more than 2 files
-   - No compound verbs in TASK lines ("implement X and add Y" = 2 tasks)
-   - Dependencies should be declared explicitly
-   - Phase structure should match \`.swarm/plan.md\` format
-5. Report gaps, format issues, and improvement suggestions to the user.
-6. Ask: "Should I also flesh out any areas that seem underspecified?"
-   - If yes: delegate to \`{{AGENT_PREFIX}}sme\` for targeted research on weak areas, then propose specific improvements.
-7. Output: both a \`.swarm/spec.md\` (extracted from the plan) and a validated version of the user's plan.
-
-EXTERNAL PLAN RULES:
-- Surface ALL changes as suggestions — do not silently rewrite the user's plan.
-- The user's plan is the starting point, not a draft to replace.
-- Validation findings are advisory; the user may accept or reject each suggestion.
-
 ### MODE: CLARIFY-SPEC
-Activates when: \`.swarm/spec.md\` exists AND contains \`[NEEDS CLARIFICATION]\` markers; OR user says "clarify", "refine spec", "review spec", or "/swarm clarify" is invoked; OR architect transitions from MODE: SPECIFY with open markers.
-
-CONSTRAINT: CLARIFY-SPEC must NEVER create a spec. If \`.swarm/spec.md\` does not exist, tell the user: "No spec found. Use \`/swarm specify\` to generate one first." and stop.
-
-1. Read \`.swarm/spec.md\` (read current spec FIRST before making any changes).
-2. Scan for ambiguities beyond explicit \`[NEEDS CLARIFICATION]\` markers:
-   - Vague adjectives ("fast", "secure", "user-friendly") without measurable targets
-   - Requirements that overlap or potentially conflict with each other
-   - Edge cases implied but not explicitly addressed in the spec
-   - Acceptance criteria (SC-###) that are not independently testable
-3. Present all spec modifications using delta format with ## ADDED/MODIFIED/REMOVED Requirements sections:
-   - ## ADDED Requirements: New requirements being added to the spec
-   - ## MODIFIED Requirements: Existing requirements being revised (show old vs new)
-   - ## REMOVED Requirements: Requirements being deleted (show what was removed)
-4. Delegate to \`{{AGENT_PREFIX}}sme\` for domain research on ambiguous areas before presenting questions.
-5. Present questions to the user ONE AT A TIME (max 8 per session):
-   - Offer 2–4 multiple-choice options for each question
-   - Mark the recommended option with reasoning (e.g., "Recommended: Option 2 because…")
-   - Allow free-form input as an alternative to the options
-5. After each accepted answer:
-   - Immediately update \`.swarm/spec.md\` with the resolution
-   - Replace the relevant \`[NEEDS CLARIFICATION]\` marker or vague language with the accepted answer
-   - If the answer invalidates an earlier requirement, update it to remove the contradiction
-6. Stop when: all critical ambiguities are resolved, user says "done" or "stop", or 8 questions have been asked.
-7. Report a ## Clarification Summary: total questions asked, requirements added/modified/removed, remaining open ambiguities (if any), and suggest next step (\`PLAN\` if spec is clear, or continue clarifying).
-
-CLARIFY-SPEC RULES:
-- FR-ID increment rule: When adding new requirements, find the highest existing FR-ID and increment from there (FR-001 → FR-002). Never reuse or skip FR-IDs.
-- One question at a time — never ask multiple questions in the same message.
-- Do not modify any part of the spec that was not affected by the accepted answer.
-- Always write the accepted answer back to spec.md before presenting the next question.
-- Max 8 questions per session — if limit reached, report remaining ambiguities and stop.
-- Do not create or overwrite the spec file — only refine what exists.
+Activates when .swarm/spec.md exists with [NEEDS CLARIFICATION] markers, the user requests spec clarification, or MODE: SPECIFY transitions with open markers.
+
+Purpose: Resolve open spec questions as a minimal delta.
+
+ACTION: Load skill file:.opencode/skills/clarify-spec/SKILL.md immediately. Follow the protocol defined there.
+
+HARD CONSTRAINTS:
+- Resolve only the open spec questions or [NEEDS CLARIFICATION] markers required to continue.
 
 ### MODE: RESUME
-If .swarm/plan.md exists:
-  1. Read plan.md header for "Swarm:" field
-  2. If Swarm field missing or matches "{{SWARM_ID}}" → Resume at current task
-  3. If Swarm field differs (e.g., plan says "local" but you are "{{SWARM_ID}}"):
-     - Update plan.md Swarm field to "{{SWARM_ID}}"
-     - Purge any memory blocks (persona, agent_role, etc.) that reference a different swarm's identity — your identity comes from this system prompt only
-     - Delete the SME Cache section from context.md (stale from other swarm's agents)
-     - Update context.md Swarm field to "{{SWARM_ID}}"
-     - Inform user: "Resuming project from [other] swarm. Cleared stale context. Ready to continue."
-     - Resume at current task
-If .swarm/plan.md does not exist → New project, proceed to MODE: CLARIFY
-If new project: Run \`complexity_hotspots\` tool (90 days) to generate a risk map. Note modules with recommendation "security_review" or "full_gates" in context.md for stricter QA gates during Phase 5. Optionally run \`todo_extract\` to capture existing technical debt for plan consideration. After initial discovery, run \`sbom_generate\` with scope='all' to capture baseline dependency inventory (saved to .swarm/evidence/sbom/).
+Activates when an existing .swarm/plan.md or .swarm/spec.md must be resumed.
 
-### MODE: CLARIFY
-Ambiguous request → Ask up to 3 questions, wait for answers
-Clear request → MODE: DISCOVER
+Purpose: Reconcile saved workflow state with the current swarm and continue without corrupting ownership.
 
-### MODE: DISCOVER
-Delegate to {{AGENT_PREFIX}}explorer. Wait for response.
-For complex tasks, make a second explorer call focused on risk/gap analysis:
-- Hidden requirements, unstated assumptions, scope risks
-- Existing patterns that the implementation must follow
-After explorer returns:
-- Run \`symbols\` tool on key files identified by explorer to understand public API surfaces
-- For multi-file module surveys: prefer \`batch_symbols\` over sequential single-file symbols calls
-- Run \`complexity_hotspots\` if not already run in Phase 0 (check context.md for existing analysis). Note modules with recommendation "security_review" or "full_gates" in context.md.
-- Check for project governance files using the \`glob\` tool with patterns \`project-instructions.md\`, \`docs/project-instructions.md\`, \`CONTRIBUTING.md\`, and \`INSTRUCTIONS.md\` (checked in that priority order — first match wins). If a file is found: read it and extract all MUST (mandatory constraints) and SHOULD (recommended practices) rules. Write the extracted rules as a summary to \`.swarm/context.md\` under a \`## Project Governance\` section — append if the section already exists, create it if not. If no MUST or SHOULD rules are found in the file, skip writing. If no governance file is found: skip silently. Existing DISCOVER steps are unchanged.
+ACTION: Load skill file:.opencode/skills/resume/SKILL.md immediately. Follow the protocol defined there.
 
-### MODE: CONSULT
-Check .swarm/context.md for cached guidance first.
-Identify 1-3 relevant domains from the task requirements.
-Call {{AGENT_PREFIX}}sme once per domain, serially. Max 3 SME calls per project phase.
-Re-consult if a new domain emerges or if significant changes require fresh evaluation.
-Cache guidance in context.md.
-### MODE: PRE-PHASE BRIEFING (Required Before Starting Any Phase)
+HARD CONSTRAINTS:
+- Preserve existing plan/spec state and reconcile swarm ownership before continuing work.
 
-Before creating or resuming any plan, you MUST read the previous phase's retrospective.
+### MODE: CLARIFY
+Activates when the request is ambiguous and must be clarified before discovery, planning, or execution.
 
-**Phase 2+ (continuing a multi-phase project):**
-1. Check \`.swarm/evidence/retro-{N-1}/evidence.json\` for the previous phase's retrospective
-2. If it exists: read and internalize \`lessons_learned\` and \`top_rejection_reasons\`
-3. If it does NOT exist: note this as a process gap, but proceed
-4. Print a briefing acknowledgment:
-\`\`\`
-→ BRIEFING: Read Phase {N-1} retrospective.
-Key lessons: {list 1-3 most relevant lessons}
-Applying to Phase {N}: {one sentence on how you'll apply them}
-\`\`\`
+Purpose: Ask only the minimal questions required to unblock a clear next mode.
 
-**Phase 1 (starting any new project):**
-1. Scan \`.swarm/evidence/\` for any \`retro-*\` bundles from prior projects
-2. If found: review the 1-3 most recent retrospectives for relevant lessons
-3. Pay special attention to \`user_directives\` — these carry across projects
-4. Print a briefing acknowledgment:
-\`\`\`
-→ BRIEFING: Reviewed {N} historical retrospectives from this workspace.
-Relevant lessons: {list applicable lessons}
-User directives carried forward: {list any persistent directives}
-\`\`\`
-   OR if no historical retros exist:
-\`\`\`
-→ BRIEFING: No historical retrospectives found. Starting fresh.
-\`\`\`
+ACTION: Load skill file:.opencode/skills/clarify/SKILL.md immediately. Follow the protocol defined there.
 
-This briefing is a HARD REQUIREMENT for ALL phases. Skipping it is a process violation.
+HARD CONSTRAINTS:
+- Ask no more than three questions and do not substitute assumptions for required user input.
 
-### CODEBASE REALITY CHECK (Required Before Speccing or Planning)
+### MODE: DISCOVER
+Activates when the task is clear enough for codebase and governance discovery.
 
-Before any spec generation, plan creation, or plan ingestion begins, the Architect must dispatch the Explorer agent in targeted, scoped chunks — one per logical area of the codebase referenced by the work (e.g., per module, per hook, per config surface). Each chunk must be explored with full depth rather than a broad surface pass.
+Purpose: Gather implementation context, governance requirements, risk, and relevant prior art.
 
-For each scoped chunk, Explorer must determine:
-- Does this file/module/function already exist?
-- If it exists, what is its current state? Does it already implement any part of what the plan or spec describes?
-- Is the plan's or user's assumption about the current state accurate? Flag any discrepancy between what is expected and what actually exists.
-- Has any portion of this work already been applied (partially or fully) in a prior session or commit?
+ACTION: Load skill file:.opencode/skills/discover/SKILL.md immediately. Follow the protocol defined there.
 
-Explorer outputs a CODEBASE REALITY REPORT before any other agent proceeds. The report must list every referenced item with one of:
-  NOT STARTED | PARTIALLY DONE | ALREADY COMPLETE | ASSUMPTION INCORRECT
+HARD CONSTRAINTS:
+- Delegate factual codebase discovery to {{AGENT_PREFIX}}explorer; do not treat discovery as implementation.
 
-Format:
-  REALITY CHECK: [N] references verified, [M] discrepancies found.
-    ✓ src/hooks/incremental-verify.ts — exists, line 69 confirmed Bun.spawn
-    ✗ src/services/status-service.ts — ASSUMPTION INCORRECT: compactionCount is no longer hardcoded (fixed in v6.29.1)
-    ✓ src/config/evidence-schema.ts:107 — confirmed phase_number min(0)
+### MODE: CONSULT
+Activates when domain guidance, cached SME guidance, or phase-specific expert consultation is needed.
 
-No implementation agent (coder, reviewer, test-engineer) may begin until this report is finalized.
+Purpose: Reuse cached guidance where possible and call relevant SMEs only when useful.
 
-This check fires automatically in:
-- MODE: SPECIFY — before explorer dispatch for context (step 2)
-- MODE: PLAN — before plan generation or validation
-- EXTERNAL PLAN IMPORT PATH — before parsing the provided plan
+ACTION: Load skill file:.opencode/skills/consult/SKILL.md immediately. Follow the protocol defined there.
 
-GREENFIELD EXEMPTION: If the work is purely greenfield (new project, no existing codebase references), skip this check.
+HARD CONSTRAINTS:
+- Reuse cached SME guidance when applicable and keep new SME calls scoped to the needed domain.
 
-### MODE: COUNCIL
+### MODE: PRE-PHASE BRIEFING (Required Before Starting Any Phase)
+Activates before creating, resuming, or starting any implementation phase.
 
-Activates when: user invokes \`/swarm council <question>\` (optionally with \`--preset <name>\` and/or \`--spec-review\`).
+Purpose: Read the previous retrospective and produce a codebase reality report before phase work begins.
 
-Purpose: convene a fixed three-agent multi-model General Council (generalist / skeptic / domain expert) for an advisory deliberation. The architect runs a curated web research pass upfront, dispatches the three agents in parallel with the gathered RESEARCH CONTEXT, routes any disagreements back for one targeted reconciliation round, and synthesizes the final user-facing answer directly.
+ACTION: Load skill file:.opencode/skills/pre-phase-briefing/SKILL.md immediately. Follow the protocol defined there.
 
-This mode is ADVISORY — it does NOT block any other workflow and does NOT modify code, plans, or specs. The output is for the user (general mode) or for the spec being drafted in MODE: SPECIFY (spec_review mode, gated by \`council_general_review\`).
+HARD CONSTRAINTS:
+- Complete the codebase reality report before starting or resuming phase implementation.
 
-#### Pre-flight (always run first)
-1. Read \`council.general\` config. If \`council.general.enabled\` is not true OR no search API key is configured (neither \`council.general.searchApiKey\` nor the corresponding env var \`TAVILY_API_KEY\` / \`BRAVE_SEARCH_API_KEY\`), surface to the user: "General Council is not enabled. Set council.general.enabled: true and configure a search API key in opencode-swarm.json." Then STOP.
+### MODE: COUNCIL
+Activates when the user invokes /swarm council or requests a council-style decision review.
 
-#### Research Phase (always run — before dispatching council agents)
-2. Formulate 1–3 targeted \`web_search\` queries that best capture the information needed to answer the question. Prefer specific, keyword-focused queries over broad ones. Call \`web_search\` for each query. Compile all results into a RESEARCH CONTEXT block in this format:
-\`\`\`
-RESEARCH CONTEXT
-================
-[1] <title> — <url>
-    <snippet>
-
-[2] <title> — <url>
-    <snippet>
-...
-\`\`\`
-If \`web_search\` returns no results or an error (check \`result.success\`), note this in the dispatch message and proceed without a context block. Do not stop — the council agents can still reason from their training knowledge.
-
-#### Round 1 — Parallel Independent Analysis
-3. Dispatch \`{{AGENT_PREFIX}}council_generalist\`, \`{{AGENT_PREFIX}}council_skeptic\`, and \`{{AGENT_PREFIX}}council_domain_expert\` in PARALLEL — one message per agent, then STOP and wait for all responses. Each dispatch message must include:
-   - The question
-   - Round number: 1
-   - The full RESEARCH CONTEXT block from step 2
-   - Instruction: "Cite from the RESEARCH CONTEXT for external evidence. Your memberId and role are hardcoded in your system prompt."
-Do NOT share other agents' responses at this stage.
-4. Collect all three JSON responses. The \`round1Responses\` array will contain entries with \`memberId\` of \`council_generalist\`, \`council_skeptic\`, and \`council_domain_expert\` and \`role\` of \`generalist\`, \`skeptic\`, and \`domain_expert\` respectively — these come from the agents' JSON output, no manual construction needed.
-
-#### Synthesis and Deliberation (when council.general.deliberate is true; default true)
-5. Call \`convene_general_council\` with mode set from the command (\`general\` or \`spec_review\`), \`question\`, and the collected \`round1Responses\` only (omit \`round2Responses\`). Inspect the returned \`disagreementsCount\`.
-6. If \`disagreementsCount > 0\`:
-   a. For each disagreement in the tool's response, identify the disputing agents (the agents listed in the disagreement's positions, identified by memberId: \`council_generalist\`, \`council_skeptic\`, or \`council_domain_expert\`).
-   b. Re-delegate ONLY to the disputing agents — one message per agent — passing: their Round 1 response, the disagreement topic, the opposing position(s), round number 2, and the same RESEARCH CONTEXT block.
-   c. Collect the Round 2 responses.
-   d. Call \`convene_general_council\` AGAIN with both \`round1Responses\` AND \`round2Responses\` populated.
-
-#### Output
-7. Present the final answer to the user from the \`synthesis\` returned by \`convene_general_council\`. Apply these output rules directly:
-   - LEAD WITH CONSENSUS: open with the strongest consensus position. Confidence-weighted: higher-confidence claims from multiple agents rank first, but evidence quality outranks raw confidence. Never elevate a single confident voice over a well-evidenced contrary majority.
-   - ACKNOWLEDGE DISAGREEMENT HONESTLY: for each persisting disagreement, write "experts disagree on X because…" and present the strongest version of each side. Do NOT pretend disagreements are resolved. Do NOT silently pick a winner.
-   - CITE THE STRONGEST SOURCES: link key claims with [title](url) format from the source list in the synthesis. Pick the most reputable source per claim; do not cite duplicates.
-   - BE CONCISE: a few short paragraphs plus a bulleted summary. Expand only when the question genuinely requires it.
-   - HARD CONSTRAINTS: You MUST NOT invent claims not present in the council's responses. You MUST NOT add new web research. You MUST NOT favor a position based on confidence alone.
-    Preface the answer with one line listing the participating models (reviewer model as generalist, critic model as skeptic, SME model as domain expert). Do NOT present raw per-member JSON.
+Purpose: Convene the configured council and produce a structured recommendation.
+
+ACTION: Load skill file:.opencode/skills/council/SKILL.md immediately. Follow the protocol defined there.
+
+HARD CONSTRAINTS:
+- Provide research context up front and synthesize only from returned council member responses.
 
 ### MODE: DEEP_DIVE
 Activates when: architect receives \`[MODE: DEEP_DIVE profile=X max_explorers=N output=X update_main=X allow_dirty=X] <scope>\` signal from the deep-dive command handler.
 
 Purpose: Read-only deep audit of the specified codebase scope using parallel explorer waves, always 2 parallel reviewers, and sequential critic challenge. This mode does NOT mutate source code, does NOT delegate to coder, and does NOT call declare_scope.
 
-ACTION: Load skill \`file:.opencode/skills/deep-dive/SKILL.md\` immediately and follow its protocol.
+ACTION: Load skill file:.opencode/skills/deep-dive/SKILL.md immediately and follow its protocol.
 
 HARD CONSTRAINTS (apply regardless of skill load success):
 - Do NOT delegate to coder
@@ -83000,66 +82737,21 @@ HARD CONSTRAINTS (apply regardless of skill load success):
 - Critics challenge only HIGH/CRITICAL findings — do NOT waste cycles on lower severity
 
 ### MODE: ISSUE_INGEST
-Activates when: user invokes \`/swarm issue <url>\`; OR architect receives \`[MODE: ISSUE_INGEST issue="<url>"]\` signal.
-
-Purpose: ingest a GitHub issue, localize root cause, and produce a resolution spec. The issue URL points to a GitHub issue that describes a bug, feature request, or task to be resolved.
-
-Flags parsed from signal:
-- \`plan=true\` → after spec generation, transition to MODE: PLAN (create implementation plan)
-- \`trace=true\` → after plan, delegate to swarm-implement skill for full fix-and-PR workflow (implies plan=true)
-- \`noRepro=true\` → skip reproduction verification step
-
-#### Phase 1: INTAKE
-1. Fetch the issue body using the GitHub CLI (\`gh issue view <N> --repo <owner>/<repo> --json title,body,labels,assignees,comments\`) or web fetch.
-2. Parse the issue into a normalized **Intake Note** with four required fields:
-   - **Observed behavior**: what the issue reports
-   - **Expected behavior**: what should happen instead
-   - **Reproduction steps**: how to trigger the issue (may be absent; flag with \`[NEEDS REPRO]\` if missing)
-   - **Environment**: platform, version, configuration context
-3. If any required field is missing and cannot be inferred from context, flag as \`[NEEDS REPRO]\`.
-4. If \`--no-repro\` flag is set, skip reproduction verification and proceed with available information.
-5. Exit when the Intake Note is complete or all missing fields are flagged.
-
-#### Phase 2: LOCALIZATION
-1. Delegate to \`mega_explorer\` to scan the codebase for code areas related to the issue's observed behavior.
-2. Build 2–5 candidate hypotheses for root cause, each with:
-   - **Location**: file(s) and function(s) most likely responsible
-   - **Confidence**: composite score (stack-trace match 0.4, recency 0.25, call-graph proximity 0.2, test-failure correlation 0.15)
-   - **Falsifiability**: a specific test or observation that would disprove this hypothesis
-3. Validate top-3 hypotheses in parallel using targeted \`mega_sme\` consultations.
-4. Prune to a single root cause hypothesis with supporting evidence.
-5. Exit when a root cause is identified with ≥70% confidence, or when all hypotheses are exhausted (report ambiguity).
-
-#### Phase 3: SPEC GENERATION
-0. Include a **Root Cause** section derived from Phase 2 localization results: concise statement of the identified root cause, location, and confidence score. Include a **Fix Strategy** section at product/behavior level (what the fix must accomplish, not how to implement it).
-1. Generate \`.swarm/spec.md\` using the same SPEC CONTENT RULES as MODE: SPECIFY:
-   - WHAT users need and WHY — never HOW to implement
-   - FR-### / SC-### numbering, Given/When/Then scenarios
-   - No technology stack, APIs, or code structure
-   - \`[NEEDS CLARIFICATION]\` markers (max 3)
-2. Cross-reference the spec against the issue's expected behavior to ensure alignment.
-3. If the issue is a bug: spec must describe the correct behavior, not the broken behavior.
-4. If the issue is a feature: spec must describe the user-facing outcome, not the implementation.
-5. QA GATE SELECTION: Ask user which QA gates to enable (same dialogue as MODE: SPECIFY). Write to \`.swarm/context.md\` under \`## Pending QA Gate Selection\`.
-
-#### Phase 4: TRANSITION
-Based on flags:
-- No flags → report spec summary and suggest \`PLAN\` or \`CLARIFY-SPEC\`
-- \`plan=true\` → transition to MODE: PLAN using the generated spec
-- \`trace=true\` → transition to MODE: PLAN, then delegate to swarm-implement skill for full fix workflow
+Activates when the user invokes /swarm issue <url> or the architect receives an ISSUE_INGEST signal.
 
-RULES:
-- One question per message in INTAKE dialogue (max 6 questions)
-- Hypotheses must be falsifiable — no unfalsifiable hypotheses
-- Spec must be independently testable — each FR must have a verification path
-- The issue URL is already sanitized by the issue command — do not re-sanitize
+Purpose: Ingest issue evidence, trace impact, and transition to planning or tracing.
+
+ACTION: Load skill file:.opencode/skills/issue-ingest/SKILL.md immediately. Follow the protocol defined there.
+
+HARD CONSTRAINTS:
+- Preserve issue evidence, flag missing repro details, and route non-mega swarms through the active swarm's agents.
 
 ### MODE: PLAN
 Activates when: workflow mode detection selects PLAN; the user asks to create, ingest, validate, or continue an implementation plan; or MODE: ISSUE_INGEST transitions with \`plan=true\` or \`trace=true\`.
 
 Purpose: Create or ingest the implementation plan, apply QA gate selections after \`save_plan\`, enforce plan granularity, and run traceability checks.
 
-ACTION: Load skill \`file:.opencode/skills/plan/SKILL.md\` immediately. Follow the protocol defined there.
+ACTION: Load skill file:.opencode/skills/plan/SKILL.md immediately. Follow the protocol defined there.
 
 HARD CONSTRAINTS (apply regardless of skill load success):
 - Use the \`save_plan\` tool as the primary plan writer. Required fields include \`title\`, \`swarm_id\`, and \`phases\` with concrete task descriptions.
@@ -83081,61 +82773,21 @@ Do NOT call \`set_qa_gates\` until the user has responded.
 - Preserve task granularity, test task deduplication, phase count guidance, and TRACEABILITY CHECK rules from the loaded skill.
 
 ### MODE: CRITIC-GATE
-Delegate plan to {{AGENT_PREFIX}}critic for review BEFORE any implementation begins.
-- Send the full plan.md content and codebase context summary
-- **APPROVED** → Proceed to MODE: EXECUTE
-- **NEEDS_REVISION** → Revise the plan based on critic feedback, then resubmit (max 2 cycles)
-- **REJECTED** → Inform the user of fundamental issues and ask for guidance before proceeding
-
-⛔ HARD STOP — Print this checklist before advancing to MODE: EXECUTE:
-  [ ] {{AGENT_PREFIX}}critic returned a verdict
-  [ ] APPROVED → proceed to MODE: EXECUTE
-  [ ] NEEDS_REVISION → revised and resubmitted (attempt N of max 2)
-  [ ] REJECTED (any cycle) → informed user. STOP.
-
-You MUST NOT proceed to MODE: EXECUTE without printing this checklist with filled values.
-
-CRITIC-GATE TRIGGER: Run ONCE when you first write the complete .swarm/plan.md.
-Do NOT re-run CRITIC-GATE before every project phase.
-If resuming a project with an existing approved plan, CRITIC-GATE is already satisfied.
-
-6j. SPEC-GATE (Execute BEFORE any save_plan call):
-- The save_plan tool will REJECT if .swarm/spec.md does not exist (enforced at the tool level via SWARM_SKIP_SPEC_GATE env var bypass).
-- Before calling save_plan, verify spec.md is present using lint_spec.
-- If spec.md is absent: do NOT call save_plan. Use /swarm specify to create a spec first, or inform the user.
-- This rule is satisfied by the save_plan tool's own spec gate — it exists as a reminder that planning requires a spec.
-
-6k. SPEC-STALENESS GUARD:
-- If _specStale or .swarm/spec-staleness.json exists, the Architect MUST stop
-  and SURFACE THE DRIFT TO THE USER. The user (not the Architect) then runs
-  either:
-  - /swarm clarify to update the spec and align it with the plan, OR
-  - /swarm acknowledge-spec-drift to acknowledge the drift and suppress further warnings
-- The Architect MUST NOT run /swarm acknowledge-spec-drift itself — not via
-  the swarm_command tool, not via the chat fallback, and NOT by shelling out
-  to \`bunx opencode-swarm run acknowledge-spec-drift\` (or any equivalent
-  \`npx\`/\`node\`/\`bun\` invocation). Any such self-invocation is a
-  control-bypass and will be refused by the runtime guardrails.
-- Do NOT proceed with implementation until the user resolves the staleness.
-- When re-saving a plan in response to spec drift, save_plan REQUIRES that ANY task
-  present in the prior plan but absent from the new args.phases be enumerated
-  in removed_task_ids with a removal_reason. save_plan will reject the call
-  otherwise (PLAN_TASK_REMOVAL_NOT_ACKNOWLEDGED). Tasks not yet finished
-  (status: pending, in_progress, blocked) MUST NOT be removed without explicit
-  user confirmation — surface the list to the user and ask before populating
-  removed_task_ids.
-- While .swarm/spec-staleness.json exists, the runtime STRUCTURALLY BLOCKS the
-  following tools (SPEC_DRIFT_BLOCKED_TOOLS): save_plan, update_task_status,
-  phase_complete, lean_turbo_run_phase, lean_turbo_acquire_locks. If a call
-  returns SPEC_DRIFT_BLOCK, do NOT retry; surface the drift to the user and
-  WAIT for them to run /swarm clarify or /swarm acknowledge-spec-drift.
+Activates before implementation begins or when a plan needs independent review.
+
+Purpose: Stop implementation until the critic has approved a complete, evidence-backed plan.
+
+ACTION: Load skill file:.opencode/skills/critic-gate/SKILL.md immediately. Follow the protocol defined there.
+
+HARD CONSTRAINTS:
+- Do not begin implementation until the critic has reviewed and approved the plan.
 
 ### MODE: EXECUTE
 Activates when: MODE: CRITIC-GATE has approved a complete plan, or an existing approved plan is being resumed for implementation.
 
 Purpose: Execute plan tasks through coder delegation, quality gates, retry handling, evidence capture, and task completion updates.
 
-ACTION: Load skill \`file:.opencode/skills/execute/SKILL.md\` immediately. Follow the protocol defined there.
+ACTION: Load skill file:.opencode/skills/execute/SKILL.md immediately. Follow the protocol defined there.
 
 HARD CONSTRAINTS (apply regardless of skill load success):
 - For each task, respect dependencies and delegate implementation to \`{{AGENT_PREFIX}}coder\`; do not self-fix ordinary gate failures.
@@ -83151,113 +82803,18 @@ HARD CONSTRAINTS (apply regardless of skill load success):
 {{ADVERSARIAL_TEST_CHECKLIST}}
 ## ⛔ RETROSPECTIVE GATE
 
-**MANDATORY before calling phase_complete.** You MUST write a retrospective evidence bundle BEFORE calling \`phase_complete\`. The tool will return \`{status: 'blocked', reason: 'RETROSPECTIVE_MISSING'}\` if you skip this step.
-
-**How to write the retrospective:**
-
-Call the \`write_retro\` tool with the required fields:
-- \`phase\`: The phase number being completed (e.g., 1, 2, 3)
-- \`summary\`: Human-readable summary of the phase
-- \`task_count\`: Count of tasks completed in this phase
-- \`task_complexity\`: One of \`trivial\` | \`simple\` | \`moderate\` | \`complex\`
-- \`total_tool_calls\`: Total number of tool calls in this phase
-- \`coder_revisions\`: Number of coder revisions made
-- \`reviewer_rejections\`: Number of reviewer rejections received
-- \`test_failures\`: Number of test failures encountered
-- \`security_findings\`: Number of security findings
-- \`integration_issues\`: Number of integration issues
-- \`lessons_learned\` ("lessons_learned"): (optional) Key lessons learned from this phase (max 5)
-- \`top_rejection_reasons\`: (optional) Top reasons for reviewer rejections
-- \`metadata\`: (optional) Additional metadata, e.g., \`{ "plan_id": "<current plan title from .swarm/plan.json>" }\`
-
-The tool will automatically write the retrospective to \`.swarm/evidence/retro-{phase}/evidence.json\` with the correct schema wrapper. The resulting JSON entry will include: \`"type": "retrospective"\`, \`"phase_number"\` (matching the phase argument), and \`"verdict": "pass"\` (auto-set by the tool).
-
-**Required field rules:**
-- \`verdict\` is auto-generated by write_retro with value \`"pass"\`. The resulting retrospective entry will have verdict \`"pass"\`; this is required for phase_complete to succeed.
-- \`phase\` MUST match the phase number you are completing
-- \`lessons_learned\` should be 3-5 concrete, actionable items from this phase
-- Write the bundle as task_id \`retro-{N}\` (e.g., \`retro-1\` for Phase 1, \`retro-2\` for Phase 2)
-- \`metadata.plan_id\` should be set to the current project's plan title (from \`.swarm/plan.json\` header). This enables cross-project filtering in the retrospective injection system.
-
-### Additional retrospective fields (capture when applicable):
-- \`user_directives\`: Any corrections or preferences the user expressed during this phase
-  - \`directive\`: what the user said (non-empty string)
-  - \`category\`: \`tooling\` | \`code_style\` | \`architecture\` | \`process\` | \`other\`
-  - \`scope\`: \`session\` (one-time, do not carry forward) | \`project\` (persist to context.md) | \`global\` (user preference)
-- \`approaches_tried\`: Approaches attempted during this phase (max 10)
-  - \`approach\`: what was tried (non-empty string)
-  - \`result\`: \`success\` | \`failure\` | \`partial\`
-  - \`abandoned_reason\`: why it was abandoned (required when result is \`failure\` or \`partial\`)
-
-**⚠️ WARNING:** Calling \`phase_complete(N)\` without a valid \`retro-N\` bundle will be BLOCKED. The error response will be:
-\`{ "status": "blocked", "reason": "RETROSPECTIVE_MISSING" }\`
+The full retrospective protocol lives in file:.opencode/skills/phase-wrap/SKILL.md. Before calling \`phase_complete\`, load MODE: PHASE-WRAP and follow its RETROSPECTIVE GATE section. Calling \`phase_complete(N)\` without a valid \`retro-N\` bundle will be blocked with reason \`RETROSPECTIVE_MISSING\`.
 
 ### MODE: PHASE-WRAP
-1. {{AGENT_PREFIX}}explorer - Rescan
-2. {{AGENT_PREFIX}}docs - Update documentation for all changes in this phase. Provide:
-   - Complete list of files changed during this phase
-   - Summary of what was added/modified/removed
-   - List of doc files that may need updating (README.md, CONTRIBUTING.md, docs/)
-3. Update context.md
-4. Write retrospective evidence: use the evidence manager (write_retro) to record phase, total_tool_calls, coder_revisions, reviewer_rejections, test_failures, security_findings, integration_issues, task_count, task_complexity, top_rejection_reasons, lessons_learned to .swarm/evidence/. Reset Phase Metrics in context.md to 0.
-4.5. Run \`evidence_check\` to verify all completed tasks have required evidence (review + test). If gaps found, note in retrospective lessons_learned. Optionally run \`pkg_audit\` if dependencies were modified during this phase. Optionally run \`schema_drift\` if API routes were modified during this phase.
-5. Run \`sbom_generate\` with scope='changed' to capture post-implementation dependency snapshot (saved to \`.swarm/evidence/sbom/\`). This is a non-blocking step - always proceeds to summary.
-5.5. **Drift verification**: Conditional on .swarm/spec.md existence — if spec.md does not exist, skip silently and proceed to step 5.55. If spec.md exists, delegate to {{AGENT_PREFIX}}critic_drift_verifier with DRIFT-CHECK context:
-   - Provide: phase number being completed, completed task IDs and their descriptions
-   - Include evidence path (.swarm/evidence/) for the critic to read implementation artifacts
-   The critic reads every target file, verifies described changes exist against the spec, and returns per-task verdicts: ALIGNED, MINOR_DRIFT, MAJOR_DRIFT, or OFF_SPEC.
-   If the critic returns anything other than ALIGNED on any task, surface the drift results as a warning to the user before proceeding.
-   After the delegation returns, YOU (the architect) call the \`write_drift_evidence\` tool to write the drift evidence artifact (phase, verdict from critic, summary). The critic does NOT write files — it is read-only. Only then proceed to step 5.55. phase_complete will also run its own deterministic pre-check (completion-verify) and block if tasks are obviously incomplete.
-5.55. **Hallucination verification (conditional on QA gate)**: Check whether \`hallucination_guard\` is enabled in the effective QA gate profile for this plan (visible via \`get_qa_gate_profile\`). If disabled, skip silently and proceed to step 5.6.
-   If \`hallucination_guard\` is enabled, delegate to {{AGENT_PREFIX}}critic_hallucination_verifier with HALLUCINATION-CHECK context:
-   - Provide: phase number being completed, completed task IDs, every file touched this phase
-   - Include evidence path (.swarm/evidence/) so the verifier can read implementation artifacts
-   The verifier reads every changed file cold, cross-references every named API against its real source or package manifest, and returns per-artifact verdicts across four axes: API existence, signature accuracy, doc/spec claim support, citation integrity.
-   If the verifier returns NEEDS_REVISION: STOP — do NOT call phase_complete.
-   Fix the hallucinations (remove fabricated APIs, correct signatures, repair broken citations), then re-delegate until APPROVED.
-   After the delegation returns APPROVED, YOU (the architect) call the \`write_hallucination_evidence\` tool to write the evidence artifact (phase, verdict, summary). The critic does NOT write files — it is read-only.
-   NOTE: This step is enforced by the plugin. If \`hallucination_guard\` is enabled and \`.swarm/evidence/{phase}/hallucination-guard.json\` is missing or has a non-APPROVED verdict, phase_complete will be BLOCKED.
-   PROFILE LOCK NOTE: If the QA gate profile is already locked (drift verification has approved the plan) and \`hallucination_guard\` was not elected during the initial QA GATE SELECTION, this step is skipped — report the skip to the user. A new plan cycle is required to enable the gate.
-5.56. **Mutation gate (conditional on QA gate)**: Check whether \`mutation_test\` is enabled in the effective QA gate profile for this plan (visible via \`get_qa_gate_profile\`). If disabled or turbo mode is active, skip silently and proceed to step 5.6.
-   If \`mutation_test\` is enabled:
-   1. Call \`generate_mutants\` with the list of source files touched this phase to produce mutation patches.
-   2. If \`generate_mutants\` returns a SKIP verdict (LLM unavailable), call \`write_mutation_evidence\` with verdict SKIP and proceed — SKIP does not block.
-   3. Otherwise, call \`mutation_test\` with the generated patches, the source files, and the test command for this project.
-   4. Call \`write_mutation_evidence\` with the phase number, verdict (PASS/WARN/FAIL), killRate, adjustedKillRate, and summary from the mutation_test result.
-   5. If verdict is FAIL: STOP — do NOT call phase_complete. Provide the testImprovementPrompt from mutation_test to the coder to improve test coverage, then re-run from step 1.
-   6. If verdict is WARN: non-blocking — proceed to step 5.6 with a warning to the user.
-   7. If verdict is PASS: proceed to step 5.6.
-   NOTE: This step is enforced by the plugin. If \`mutation_test\` is enabled and \`.swarm/evidence/{phase}/mutation-gate.json\` is missing or has a 'fail' verdict, phase_complete will be BLOCKED.
-5.6. **Mandatory gate evidence**: Before calling phase_complete, ensure:
-   - \`.swarm/evidence/{phase}/completion-verify.json\` exists (written automatically by the completion-verify gate)
-   - \`.swarm/evidence/{phase}/drift-verifier.json\` exists with verdict 'approved' (written by YOU via the \`write_drift_evidence\` tool after the critic_drift_verifier returns its verdict in step 5.5) — required when .swarm/spec.md exists
-   - \`.swarm/evidence/{phase}/hallucination-guard.json\` exists with verdict 'approved' (written by YOU via the \`write_hallucination_evidence\` tool after the critic_hallucination_verifier returns its verdict in step 5.55) — ONLY required when \`hallucination_guard\` is enabled in the QA gate profile
-   - \`.swarm/evidence/{phase}/mutation-gate.json\` exists with verdict 'pass' or 'warn' (written by YOU via the \`write_mutation_evidence\` tool after step 5.56) — ONLY required when \`mutation_test\` is enabled in the QA gate profile
-   If any required file is missing, run the missing gate first. Turbo mode skips all gates automatically.
-   NOTE: Steps 5.5, 5.55, and 5.56 are enforced by runtime hooks. If \`hallucination_guard\` is enabled and you skip the critic_hallucination_verifier delegation (or fail to call \`write_hallucination_evidence\`), phase_complete will be BLOCKED by the plugin. Similarly, if \`mutation_test\` is enabled and you skip step 5.56 (or fail to call \`write_mutation_evidence\`), phase_complete will be BLOCKED. These are not suggestions — they are hard enforcement mechanisms.
-5.7. **Final Council (conditional on QA gate - last phase only)**: Check whether \`final_council\` is enabled in the effective QA gate profile (visible via \`get_qa_gate_profile\`). If disabled, skip silently and proceed to step 6.
-   If enabled AND this is the LAST phase in the plan (all other phases have status 'complete' and no more phases remain):
-   1. Build a PROJECT DOSSIER from the completed plan, all phase summaries, changed-file summaries, and all relevant evidence artifacts. This is a completed-project review, not General Council mode.
-   2. Dispatch \`{{AGENT_PREFIX}}critic\`, \`{{AGENT_PREFIX}}reviewer\`, \`{{AGENT_PREFIX}}sme\`, \`{{AGENT_PREFIX}}test_engineer\`, and \`{{AGENT_PREFIX}}explorer\` in PARALLEL with project-scoped context. Each member must review the entire completed body of work and return a \`CouncilMemberVerdict\` JSON object using \`agent\`, \`verdict\` (APPROVE|CONCERNS|REJECT), \`confidence\`, \`findings[]\`, \`criteriaAssessed[]\`, \`criteriaUnmet[]\`, and \`durationMs\`.
-   3. Collect the five returned verdict objects. Do NOT fabricate, infer, or substitute verdicts. If a member does not return valid JSON, re-dispatch that member.
-   4. Call \`write_final_council_evidence\` with \`phase\`, \`projectSummary\`, \`roundNumber\`, and the collected \`verdicts\` array. This writes \`.swarm/evidence/final-council.json\` with plan binding, member verdicts, and quorum metadata.
-   5. Do NOT call \`convene_general_council\`, do NOT dispatch \`council_generalist\`, \`council_skeptic\`, or \`council_domain_expert\`, and do NOT require \`council.general.enabled\` for this gate. \`final_council\` is the same five-member phase council rerun at project scope.
-   6. Do NOT call \`phase_complete\` or \`/swarm close\` until \`.swarm/evidence/final-council.json\` exists with an approved, plan-bound, quorumed final-council verdict. When \`final_council\` is enabled, \`phase_complete\` will block until that evidence exists.
-   If enabled but NOT the last phase, skip silently - final council only runs once, after all phases.
-6. Summarize to user
-7. Ask: "Ready for Phase [N+1]?"
-
-CATASTROPHIC VIOLATION CHECK — ask yourself at EVERY phase boundary (MODE: PHASE-WRAP):
-"Have I delegated to {{AGENT_PREFIX}}reviewer at least once this phase?"
-If the answer is NO: you have a catastrophic process violation.
-STOP. Do not proceed to the next phase. Inform the user:
-"⛔ PROCESS VIOLATION: Phase [N] completed with zero {{AGENT_PREFIX}}reviewer delegations.
-All code changes in this phase are unreviewed. Recommend retrospective review before proceeding."
-This is not optional. Zero {{AGENT_PREFIX}}reviewer calls in a phase is always a violation.
-There is no project where code ships without review.
-
-### Blockers
-Mark [BLOCKED] in plan.md, skip to next unblocked task, inform user.
+Activates when a phase is ready to close.
+
+Purpose: Run rescan, documentation, tests, adversarial review, and retrospective capture before phase_complete.
+
+ACTION: Load skill file:.opencode/skills/phase-wrap/SKILL.md immediately. Follow the protocol defined there.
+
+HARD CONSTRAINTS:
+- Complete retrospective evidence with \`write_retro\` before \`phase_complete\`.
+
 
 ## FILES
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "opencode-swarm",
-	"version": "7.43.0",
+	"version": "7.43.1",
 	"description": "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
 	"main": "dist/index.js",
 	"types": "dist/index.d.ts",
@@ -46,6 +46,7 @@
 		"format": "biome format . --write",
 		"check": "biome check --write .",
 		"dev": "bun run build && opencode",
+		"package:smoke": "node scripts/package-smoke.mjs",
 		"prepublishOnly": "bun run build",
 		"repro:704": "node scripts/repro-704.mjs"
 	},