opencode-swarm 7.59.1 → 7.61.0

package/.opencode/skills/brainstorm/SKILL.md

@@ -21,6 +21,17 @@ MODE: BRAINSTORM runs seven phases in strict order. Do not skip phases. Do not c
 - 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 1b: GENERAL COUNCIL ADVISORY (optional, architect).**
+If `council.general.enabled` is true in the resolved opencode-swarm config AND a search API key is configured:
+- Ask the user: "Enable General Council advisory input? The 3-agent council (generalist, skeptic, domain expert) will research the problem domain and provide diverse perspectives to inform the specification and plan. (default: no)"
+- If the user declines or config is not enabled, skip to Phase 2.
+- If the user accepts:
+  1. Run the Research Phase: formulate 1-3 targeted `web_search` queries grounded in the topic.
+  2. Dispatch `the active swarm's council_generalist agent`, `the active swarm's council_skeptic agent`, and `the active swarm's council_domain_expert agent` in PARALLEL with the RESEARCH CONTEXT.
+  3. Collect responses, call `convene_general_council` with mode `general`.
+  4. Carry the council's consensus and disagreements forward as context for subsequent phases.
+- Exit with council input noted (or skipped).
+
 **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.
@@ -48,25 +59,29 @@ MODE: BRAINSTORM runs seven phases in strict order. Do not skip phases. Do not c
 - 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).**
-Now ask the user which QA gates to enable for this plan -- do not select on their behalf.
+**Phase 6: QA GATE SELECTION, PARALLEL CODERS, AND COMMIT FREQUENCY (architect, dialogue only).**
+Now ask the user which QA gates to enable for this plan, how many parallel coders to use, and the commit frequency -- do not select on their behalf. Present all three items together as one unified exchange.
 
-Present the eleven gates with their defaults (DEFAULT_QA_GATES) as a single user-facing question. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
+Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder count, and commit frequency as a single user-facing section. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
 - reviewer (default: ON) -- code review of coder output
 - test_engineer (default: ON) -- test verification of coder output
 - sme_enabled (default: ON) -- SME consultation during planning/clarification
 - critic_pre_plan (default: ON) -- critic review before plan finalization
 - sast_enabled (default: ON) -- static security scanning
-- council_mode (default: OFF) -- multi-member council gate (recommended for high-impact architecture, public APIs, schema/data mutation, security-sensitive code)
+- council_mode (default: OFF) -- replaces per-task Stage B (reviewer + test_engineer) with the full 5-member council (critic, reviewer, sme, test_engineer, explorer). Requires council.enabled: true in config. (recommended for high-impact architecture, public APIs, schema/data mutation, security-sensitive code)
 - hallucination_guard (default: OFF) -- when enabled, mandatory per-phase API/signature/claim/citation verification via critic_hallucination_verifier at PHASE-WRAP; phase_complete will REJECT phase completion unless .swarm/evidence/{phase}/hallucination-guard.json exists with an APPROVED verdict (recommended for claim-heavy or research-heavy work)
 - mutation_test (default: OFF) -- when enabled, runs mutation testing on source files touched this phase via generate_mutants + mutation_test + write_mutation_evidence at PHASE-WRAP; FAIL verdict blocks phase_complete; WARN is non-blocking (recommended for projects with coverage gaps or safety-critical code)
-- council_general_review (default: OFF) -- when enabled, MODE: SPECIFY runs convene_general_council on the draft spec before the critic-gate; the architect runs a curated web_search pass, dispatches council_generalist / council_skeptic / council_domain_expert in parallel with a shared RESEARCH CONTEXT block, deliberates on disagreements, and synthesizes the result directly into the spec (recommended for novel architecture, unclear best practices, or high-risk design decisions). Requires council.general.enabled: true and a configured search API key in the resolved config: global ~/.config/opencode/opencode-swarm.json, then project .opencode/opencode-swarm.json overrides.
+- phase_council (default: OFF) -- full 5-member council reviews all work in a phase holistically at phase_complete time. Requires council.enabled: true in config. (recommended for multi-task phases with cross-cutting concerns or high-risk integration)
 - drift_check (default: ON) -- when enabled, mandatory per-phase drift verification via critic_drift_verifier at PHASE-WRAP; compares implemented changes against spec.md intent; hard-blocks phase_complete when spec.md exists and drift evidence is missing or REJECTED; advisory-only when no spec.md exists (recommended for all projects with a specification)
-- final_council (default: OFF) - when enabled, after all phases complete the architect dispatches the same five phase-council members (`critic`, `reviewer`, `sme`, `test_engineer`, `explorer`) at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This is not General Council mode and does not require `council.general.enabled`.
+- final_council (default: OFF) -- when enabled, after all phases complete the architect dispatches the full 5-member council (critic, reviewer, sme, test_engineer, explorer) -- NOT the General Council -- at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This does not require `council.general.enabled`.
+
+Additionally, present these two sub-items as part of the same exchange:
+- Parallel coders (default: 1, range: 1-4) -- how many coders should run in parallel.
+- Commit frequency (default: phase-level only) -- optional per-task checkpoint commit after each task completion.
 
-One question, one message, defaults pre-stated. Wait for the user's answer.
+The user answers all three (gates, parallel coders, commit frequency) in one exchange. Wait for the user's response.
 
-If the user answered the gate question, immediately follow up with ONE more question: "How many coders should run in parallel? (default: 1, range: 1-4)" -- if the user says a number > 1, also write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
+If the user says parallel coders > 1, write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
 ```
 ## Pending Parallelization Config
 - parallelization_enabled: true
@@ -77,8 +92,6 @@ If the user answered the gate question, immediately follow up with ONE more ques
 ```
 If the user accepts the default (1), skip writing this section entirely -- serial execution is the default and needs no config.
 
-After asking the parallelization question (regardless of whether the user chose serial or parallel), immediately follow up with ONE more question: "Commit frequency for completed tasks? (default: phase-level only; optional per-task checkpoint commit after each task completion)".
-
 If the user chooses per-task commits, write this section to `.swarm/context.md`:
 ```
 ## Task Completion Commit Policy
@@ -100,14 +113,12 @@ GATE SELECTION IS MANDATORY — these thoughts are WRONG and must be ignored:
     → 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"
+  (1) The unified gate/coders/commit selection section has been presented to the user in a single message
+  (2) The user has responded (accept defaults OR customized list for all three items)
+  (3) The elected gates, parallel coder config, and commit policy have been written to .swarm/context.md under "## Pending QA Gate Selection" (and related sections as applicable)
 <!-- 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:
@@ -121,7 +132,7 @@ Do NOT call `set_qa_gates` yet — `plan.json` does not exist at this point. Onc
 - council_mode: <true|false>
 - hallucination_guard: <true|false>
 - mutation_test: <true|false>
-- council_general_review: <true|false>
+- phase_council: <true|false>
 - drift_check: <true|false>
 - final_council: <true|false>
 - recorded_at: <ISO timestamp>
@@ -136,7 +147,7 @@ MODE: PLAN applies these after `save_plan` succeeds via `set_qa_gates`.
 
 BRAINSTORM RULES:
 - No skipping phases. Each phase's exit condition must be met before moving on.
-- One question per message in DIALOGUE — never batch.
+- One question per message in DIALOGUE — never batch. Exception: the QA gate selection section (Phase 6) presents gates, parallel coders, and commit frequency together as one unified exchange.
 - 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.

package/.opencode/skills/council/SKILL.md

@@ -25,8 +25,9 @@ answer directly.
 
 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`).
+being drafted (spec_review mode is available via `/swarm council --spec-review`
+for manual spec review). General Council advisory input is offered as an early
+workflow option in MODE: BRAINSTORM (Phase 1b).
 
 #### Pre-flight (always run first)
 

package/.opencode/skills/execute/SKILL.md

@@ -95,6 +95,18 @@ It does NOT mean "code is reviewed." It does NOT mean "code is tested."
 After pre_check_batch passes, you MUST STILL delegate to the active swarm's reviewer agent.
 Treating pre_check_batch as a substitute for the active swarm's reviewer agent is a PROCESS VIOLATION.
 
+    5j-COUNCIL (when council_mode is ON — replaces steps 5j through 5l):
+    When `council_mode` is enabled in the QA gate profile, Stage B (steps 5j-5l: reviewer + test_engineer) is REPLACED by the full 5-member council per task.
+
+    After Stage A (pre_check_batch) passes:
+    1. Ensure `declare_council_criteria` was called for this task (prerequisite).
+    2. Dispatch all 5 council members (critic, reviewer, sme, test_engineer, explorer) in PARALLEL with task-scoped context.
+    3. Collect all 5 verdict objects. Do NOT fabricate or substitute verdicts.
+    4. Call `submit_council_verdicts` with the collected verdicts.
+    5. Act on the verdict: APPROVE → task passes. CONCERNS with `success: false` + `reason: 'blocking_concerns_unresolved'` → HIGH/CRITICAL findings are blocking, no evidence written, return to coder with requiredFixes and re-council after fixes. CONCERNS with `success: true` → only MEDIUM/LOW advisory findings, task passes. REJECT → return to coder with requiredFixes.
+
+    When `council_mode` is OFF, the standard Stage B flow (steps 5j-5l: reviewer + test_engineer) runs as normal.
+
     5j. the active swarm's reviewer agent - General review. REJECTED before the configured QA retry limit → coder retry. REJECTED at the configured QA retry limit → escalate.
     → REQUIRED: Print "reviewer: [APPROVED | REJECTED — reason]"
     5k. Security gate: if change matches TIER 3 criteria OR content contains SECURITY_KEYWORDS OR secretscan has ANY findings OR sast_scan has ANY findings at or above threshold → MUST delegate the active swarm's reviewer agent security-only review. REJECTED before the configured QA retry limit → coder retry. REJECTED at the configured QA retry limit → escalate to user.

package/.opencode/skills/phase-wrap/SKILL.md

@@ -97,14 +97,23 @@ The tool will automatically write the retrospective to \`.swarm/evidence/retro-{
    - `.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.65. **Phase Council (conditional on QA gate — `phase_council`)**: Check whether `phase_council` is enabled in the effective QA gate profile (visible via `get_qa_gate_profile`). If disabled, skip silently and proceed to step 5.7.
+   This gate is triggered by the `phase_council` QA gate, NOT by `council_mode`. (`council_mode` controls per-task Stage B replacement in MODE: EXECUTE; `phase_council` controls holistic phase-level review here in MODE: PHASE-WRAP.)
+   If `phase_council` is enabled:
+   1. Build a PHASE DOSSIER from all completed tasks in this phase, their evidence artifacts, changed-file summaries, and any drift/hallucination/mutation evidence.
+   2. Dispatch the full 5-member council (`the active swarm's critic agent`, `the active swarm's reviewer agent`, `the active swarm's sme agent`, `the active swarm's test_engineer agent`, and `the active swarm's explorer agent`) in PARALLEL with phase-scoped context. Each member reviews the entire phase's work holistically and returns a `CouncilMemberVerdict` JSON object.
+   3. Collect all 5 verdict objects. Do NOT fabricate or substitute verdicts.
+   4. Act on the verdict: APPROVE → proceed. CONCERNS with `success: false` + `reason: 'blocking_concerns_unresolved'` → HIGH/CRITICAL findings are blocking, no evidence written, must resolve requiredFixes and re-council. CONCERNS with `success: true` → only MEDIUM/LOW advisory findings, phase may proceed per `phaseConcernsAllowComplete` flag. REJECT → surface required fixes to the user before proceeding.
+   Requires council.enabled: true in config.
+
 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 `the active swarm's critic agent`, `the active swarm's reviewer agent`, `the active swarm's sme agent`, `the active swarm's test_engineer agent`, and `the active swarm's explorer agent` 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`.
+   1. Build a PROJECT DOSSIER from the completed plan, all phase summaries, changed-file summaries, and all relevant evidence artifacts. This is the full 5-member council (NOT the General Council) running a completed-project review.
+   2. Dispatch the full 5-member council (`the active swarm's critic agent`, `the active swarm's reviewer agent`, `the active swarm's sme agent`, `the active swarm's test_engineer agent`, and `the active swarm's explorer agent`) 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.
    ⚠️ **GOTCHA**: `write_final_council_evidence` normalizes CONCERNS verdicts to "rejected" internally. A CONCERNS verdict in the **final council** still blocks `phase_complete` even with zero required fixes. You MUST either address the concerns and get APPROVE on a second council round, or surface the non-blocking advisory to the user before proceeding. (Note: the **phase-level** council has a `phaseConcernsAllowComplete` flag that makes CONCERNS advisory; the final council does not.)
-   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.
+   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 full 5-member council (NOT the General 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

package/.opencode/skills/plan/SKILL.md

@@ -185,20 +185,23 @@ After `save_plan` succeeds, read `.swarm/context.md`:
 - If a `## Pending QA Gate Selection` section exists: parse the gate values, call `set_qa_gates` with those flags, confirm with the user ("QA gates applied: <list>"), then remove the section from context.md.
 - If a `## Pending Parallelization Config` section also exists: parse the values and call `save_plan` again with `execution_profile` set to `{ parallelization_enabled: <parsed>, max_concurrent_tasks: <parsed>, council_parallel: false, locked: true }`. Then remove the section from context.md. If the plan already had `execution_profile.locked: true`, skip this step — the profile is already locked and immutable.
 - If a `## Task Completion Commit Policy` section exists: preserve it in `.swarm/context.md` (do NOT remove). This section is execution-time guidance for optional per-task checkpoint commits after `update_task_status(status="completed")`.
-- If no pending section exists, ask the user inline now. Present the eleven gates with their defaults (DEFAULT_QA_GATES) as a single user-facing question. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
+- If no pending section exists, ask the user inline now. Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder count, and commit frequency as a single user-facing section. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
   - reviewer (default: ON) - code review of coder output
   - test_engineer (default: ON) - test verification of coder output
   - sme_enabled (default: ON) - SME consultation during planning/clarification
   - critic_pre_plan (default: ON) - critic review before plan finalization
   - sast_enabled (default: ON) - static security scanning
-  - council_mode (default: OFF) - multi-member council gate
+  - council_mode (default: OFF) - replaces per-task Stage B (reviewer + test_engineer) with the full 5-member council (critic, reviewer, sme, test_engineer, explorer). Requires council.enabled: true in config.
   - hallucination_guard (default: OFF) - mandatory per-phase API/signature/claim/citation verification at PHASE-WRAP
   - mutation_test (default: OFF) - mutation testing on source files touched this phase at PHASE-WRAP
-  - council_general_review (default: OFF) - General Council review during MODE: SPECIFY when council.general.enabled is true
+  - phase_council (default: OFF) - full 5-member council reviews all work in a phase holistically at phase_complete time. Requires council.enabled: true in config.
   - drift_check (default: ON) - mandatory per-phase drift verification at PHASE-WRAP
-  - final_council (default: OFF) - final project-scope council after all phases complete
-  One question, one message, defaults pre-stated. Wait for the user's answer.
-  If the user answered the gate question, immediately follow up with one more question: "How many coders should run in parallel? (default: 1, range: 1-4)" If the user says a number greater than 1, also write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
+  - final_council (default: OFF) - when enabled, after all phases complete the architect dispatches the full 5-member council (critic, reviewer, sme, test_engineer, explorer) -- NOT the General Council -- at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This does not require `council.general.enabled`.
+  Additionally, present these two sub-items as part of the same exchange:
+  - Parallel coders (default: 1, range: 1-4) - how many coders should run in parallel.
+  - Commit frequency (default: phase-level only) - optional per-task checkpoint commit after each task completion.
+  The user answers all three (gates, parallel coders, commit frequency) in one exchange. Wait for the user's response.
+  If the user says parallel coders > 1, write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
   ```
   ## Pending Parallelization Config
   - parallelization_enabled: true
@@ -208,7 +211,6 @@ After `save_plan` succeeds, read `.swarm/context.md`:
   - recorded_at: <ISO timestamp>
   ```
   If the user accepts the default (1), skip writing this section entirely; serial execution is the default and needs no config.
-  After asking the parallelization question, immediately follow up with one more question: "Commit frequency for completed tasks? (default: phase-level only; optional per-task checkpoint commit after each task completion)".
   If the user chooses per-task commits, write this section to `.swarm/context.md`:
   ```
   ## Task Completion Commit Policy

package/.opencode/skills/specify/SKILL.md

@@ -30,25 +30,29 @@ Activates when: user asks to "specify", "define requirements", "write a spec", o
    - Edge cases and known failure modes
     - `[NEEDS CLARIFICATION]` markers for items where uncertainty could change scope, security, or core behavior, BUT ONLY after running the clarification funnel: (1) inventory all material uncertainties without numeric cap, (2) classify each as self_resolved/critic_resolved/research_needed/user_decision/deferred_nonblocking — **overconfidence guard:** if the default is not directly supported by user request, spec, or recorded context, classify as `user_decision` rather than `self_resolved`, (3) consult critic_sounding_board with candidate items — critic responds per SoundingBoardVerdict: UNNECESSARY→DROP, RESOLVE→RESOLVE, REPHRASE→REPHRASE, APPROVED→ASK_USER — **always-surface protection:** always-surface categories must not receive UNNECESSARY/DROP; override to APPROVED/ASK_USER, (4) record all resolved items as explicit assumptions in the spec, (5) use markers only for items that survive the funnel (ASK_USER or unresolved after critic consultation). Decision packet format: grouped by category, recommended defaults, blocking vs optional markers, impact of accepting default. Prefer informed defaults over asking
 5. Write the spec to `.swarm/spec.md`.
-5b. **QA GATE SELECTION (dialogue only).**
-Ask the user which QA gates to enable for this plan before suggesting the next step.
+5b. **QA GATE SELECTION, PARALLEL CODERS, AND COMMIT FREQUENCY (dialogue only).**
+Ask the user which QA gates to enable for this plan, how many parallel coders to use, and the commit frequency -- do not select on their behalf. Present all three items together as one unified exchange.
 
-Present the eleven gates with their defaults (DEFAULT_QA_GATES) as a single user-facing question. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
+Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder count, and commit frequency as a single user-facing section. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
 - reviewer (default: ON) -- code review of coder output
 - test_engineer (default: ON) -- test verification of coder output
 - sme_enabled (default: ON) -- SME consultation during planning/clarification
 - critic_pre_plan (default: ON) -- critic review before plan finalization
 - sast_enabled (default: ON) -- static security scanning
-- council_mode (default: OFF) -- multi-member council gate (recommended for high-impact architecture, public APIs, schema/data mutation, security-sensitive code)
+- council_mode (default: OFF) -- replaces per-task Stage B (reviewer + test_engineer) with the full 5-member council (critic, reviewer, sme, test_engineer, explorer). Requires council.enabled: true in config. (recommended for high-impact architecture, public APIs, schema/data mutation, security-sensitive code)
 - hallucination_guard (default: OFF) -- when enabled, mandatory per-phase API/signature/claim/citation verification via critic_hallucination_verifier at PHASE-WRAP; phase_complete will REJECT phase completion unless .swarm/evidence/{phase}/hallucination-guard.json exists with an APPROVED verdict (recommended for claim-heavy or research-heavy work)
 - mutation_test (default: OFF) -- when enabled, runs mutation testing on source files touched this phase via generate_mutants + mutation_test + write_mutation_evidence at PHASE-WRAP; FAIL verdict blocks phase_complete; WARN is non-blocking (recommended for projects with coverage gaps or safety-critical code)
-- council_general_review (default: OFF) -- when enabled, MODE: SPECIFY runs convene_general_council on the draft spec before the critic-gate; the architect runs a curated web_search pass, dispatches council_generalist / council_skeptic / council_domain_expert in parallel with a shared RESEARCH CONTEXT block, deliberates on disagreements, and synthesizes the result directly into the spec (recommended for novel architecture, unclear best practices, or high-risk design decisions). Requires council.general.enabled: true and a configured search API key in the resolved config: global ~/.config/opencode/opencode-swarm.json, then project .opencode/opencode-swarm.json overrides.
+- phase_council (default: OFF) -- full 5-member council reviews all work in a phase holistically at phase_complete time. Requires council.enabled: true in config. (recommended for multi-task phases with cross-cutting concerns or high-risk integration)
 - drift_check (default: ON) -- when enabled, mandatory per-phase drift verification via critic_drift_verifier at PHASE-WRAP; compares implemented changes against spec.md intent; hard-blocks phase_complete when spec.md exists and drift evidence is missing or REJECTED; advisory-only when no spec.md exists (recommended for all projects with a specification)
-- final_council (default: OFF) - when enabled, after all phases complete the architect dispatches the same five phase-council members (`critic`, `reviewer`, `sme`, `test_engineer`, `explorer`) at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This is not General Council mode and does not require `council.general.enabled`.
+- final_council (default: OFF) -- when enabled, after all phases complete the architect dispatches the full 5-member council (critic, reviewer, sme, test_engineer, explorer) -- NOT the General Council -- at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This does not require `council.general.enabled`.
 
-One question, one message, defaults pre-stated. Wait for the user's answer.
+Additionally, present these two sub-items as part of the same exchange:
+- Parallel coders (default: 1, range: 1-4) -- how many coders should run in parallel.
+- Commit frequency (default: phase-level only) -- optional per-task checkpoint commit after each task completion.
 
-If the user answered the gate question, immediately follow up with ONE more question: "How many coders should run in parallel? (default: 1, range: 1-4)" -- if the user says a number > 1, also write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
+The user answers all three (gates, parallel coders, commit frequency) in one exchange. Wait for the user's response.
+
+If the user says parallel coders > 1, write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
 ```
 ## Pending Parallelization Config
 - parallelization_enabled: true
@@ -59,8 +63,6 @@ If the user answered the gate question, immediately follow up with ONE more ques
 ```
 If the user accepts the default (1), skip writing this section entirely -- serial execution is the default and needs no config.
 
-After asking the parallelization question (regardless of whether the user chose serial or parallel), immediately follow up with ONE more question: "Commit frequency for completed tasks? (default: phase-level only; optional per-task checkpoint commit after each task completion)".
-
 If the user chooses per-task commits, write this section to `.swarm/context.md`:
 ```
 ## Task Completion Commit Policy
@@ -82,14 +84,12 @@ GATE SELECTION IS MANDATORY — these thoughts are WRONG and must be ignored:
     → 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"
+  (1) The unified gate/coders/commit selection section has been presented to the user in a single message
+  (2) The user has responded (accept defaults OR customized list for all three items)
+  (3) The elected gates, parallel coder config, and commit policy have been written to .swarm/context.md under "## Pending QA Gate Selection" (and related sections as applicable)
 <!-- 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:
@@ -103,38 +103,14 @@ Do NOT call `set_qa_gates` yet — `plan.json` does not exist at this point. Onc
 - council_mode: <true|false>
 - hallucination_guard: <true|false>
 - mutation_test: <true|false>
-- council_general_review: <true|false>
+- phase_council: <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` from the resolved opencode-swarm config: global ~/.config/opencode/opencode-swarm.json first, then project .opencode/opencode-swarm.json overrides. A global config is valid and must be used when no project override is present; do not fail after checking only the project file. 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 global ~/.config/opencode/opencode-swarm.json or project .opencode/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 or returns no usable current sources for a time-sensitive spec question, stop and report the failed grounding instead of dispatching council members. For stable, non-current spec questions only, note the failed search in the dispatch message and proceed with stable background knowledge.
-3. Dispatch `the active swarm's council_generalist agent`, `the active swarm's council_skeptic agent`, and `the active swarm's council_domain_expert agent` 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.
-<!-- BEHAVIORAL_GUIDANCE_END -->
+General Council advisory input is offered as an early workflow option in MODE: BRAINSTORM (Phase 1b), not as a SPECIFY step. If the user wants council input during SPECIFY, they can use `/swarm council <question>` manually.
 
 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`.