severally-mcp 2.0.0 → 2.3.1

package/plugins/severally/skills/_template/SKILL.md.tmpl

@@ -5,9 +5,9 @@ description: Use when a decision deserves a second, independent mind - an archit
 
 # Consulting a peer agent
 
-You have three peers, each reached through the `severally` MCP server as a fresh child session. They can
-search and browse the web. They cannot edit files, reach the network outside search/browse, load MCP tools,
-see your session, or consult anyone else. In practice they know only what you put in the brief and the files you expose to them.{{EXECUTION_CAVEAT}}
+You have three peers, each reached through the `severally` MCP server as a fresh child session that can read files
+and search the web, but not edit them, load MCP tools, see your session or consult anyone else. Each knows only
+what you put in the brief and the files you expose to it.{{EXECUTION_CAVEAT}}
 
 ## A normal consultation is three calls
 
@@ -22,13 +22,14 @@ see your session, or consult anyone else. In practice they know only what you pu
    }})
    ```
 
-2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits up to 45 seconds for
-   the answer by itself; call it again while `status` is `running`, and work on something independent in between.
+2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits for the answer by itself,
+   up to a limit the server sets (45 seconds, or ten minutes where the client allows it); call it again while
+   `status` is `running`. To work on something independent meanwhile, ask for a shorter wait (`reference.md`).
 3. **Check one point, report, and record it once** (see **Before you hand the decision back**).
 
-That is the whole routine. The rest of the record — more verdicts, a prediction and reflection, follow-ups,
-the export into the repository, the details of reading a fan-out — is in `reference.md`, in the same
-directory as this file. Read it only for a decision you will have to justify later, or when you follow up.
+That is the whole routine. The rest — follow-ups, a prediction and reflection, the export, reading a fan-out
+in detail — is in `reference.md`, in the same directory as this file. Read it for a decision you will have to
+justify later, or when you follow up.
 
 ## Pick the consultant
 
@@ -42,12 +43,10 @@ costs one consultation's quota per consultant. Narrow to `target` (singular) onl
 specific peer, or when the decision clearly does not warrant that much. This is the one rule for how many to
 ask.
 
-A consultant is one CLI running one model, and the operator decides which ones exist. `consult_start`'s
-description lists the ones this machine can actually reach as `name: CLI, model`. When the user names one,
-pass **the word the user used** as `target` — a name, a CLI (`codex`, `agy`), a vendor or a model
-(「Claude Opusと相談して」 is `target: "claude opus"`) — and let the server resolve it. A word that fits several
-comes back as `target_ambiguous` with the candidates: ask the user which one they meant. One that is not
-installed comes back as `target_unavailable` with the available list: take that as final and tell the user.
+The operator decides which consultants exist; `consult_start`'s description lists the ones this machine can
+actually reach. When the user names one, pass **the word the user used** as `target`
+(「Claude Opusと相談して」 is `target: "claude opus"`). `target_ambiguous`: ask the user which one they meant.
+`target_unavailable`: take the available list as final and tell the user.
 
 **Do not pick a model yourself.** When the user named no one, ask everyone; overriding the operator's
 consultants on your own judgement — including after a `usage_limit` failure — substitutes a different mind
@@ -61,9 +60,8 @@ answer can say which model answered.
 
 ## When this is worth it
 
-When a wrong answer is expensive or hard to undo: an architectural or interface decision, a data migration, a
-security or concurrency design; two options that still look close; an investigation that has stalled after two
-failed attempts; or the user asked. Not for routine edits, a rename, a test that just needs writing, or
+When a wrong answer is expensive or hard to undo (an interface, a migration, a security or concurrency design),
+two options still look close, an investigation has stalled after two attempts, or the user asked. Not for
 anything you would be comfortable defending on your own.
 
 **Before you ask the user to approve a change that is hard to reverse** and nobody else has reviewed it,
@@ -80,15 +78,13 @@ Pass `initiator: "user"` when the user asked for the consultation; leave it out
 - **Ask one decidable question.** What runs out the clock is scope, not brief length: when the budget runs out
   the session is killed and you get nothing. Split "research everything about X" or three questions at once,
   and ask the one whose answer changes what you do next.
-- **Hand over the code.** The consultant starts in an empty working directory and is not told where your
-  repository is. Name the files by absolute path in `context.expose_paths` in this first call (at most 20
-  entries, 500 files, 5 MB; never your home directory or one holding keys), or pass
+- **Hand over the code.** The consultant is not told where your repository is. Name the files by absolute path
+  in `context.expose_paths` (a repository root works; never your home directory or one holding keys), or pass
   `context.expose_diff: { repo: "<absolute path>" }` for a change you are making. When `consult_start` answers
   `files_exposed: 0` and the question is about code, `consult_cancel` and start again with `expose_paths`.
 - **Put the load-bearing facts in `context.facts`**, and test output or a log in `context.artifacts`.
-- **The mode follows from the context.** Leave `mode` out: no proposal is `explore`, a proposal is `review`, a
-  proposal with `counterpoints` (the other side's claims) is `debate`. To gather opinions without showing your
-  own, leave `context.proposal` empty; a reviewed plan is answered around the plan.
+- **Leave `mode` out**; it follows from the context. To gather opinions without showing your own, leave
+  `context.proposal` empty: a reviewed plan is answered around the plan.
 - A constraint is read as fixed and will not be challenged; if it is your own call, put it under `facts` with
   its reason. For material that must not leave the machine through a URL, pass `network: "off"`.
 

package/plugins/severally/skills/_template/reference.md.tmpl

@@ -17,9 +17,8 @@ checked as given: the server rejects a first-round `explore` that carries a prop
 anchoring-sensitive — if you want your plan critiqued, that is `review`.
 
 **For a decision heavy enough to be worth two consultations**, ask `explore` first on the facts alone, then
-`review` with the proposal, and read what the first raised that the second never did. Measured on this
-project: repeat runs of the identical brief did not move the bottom line, while withholding the proposal once
-did, and the withheld run was the only one to question what the decision was even about.
+`review` with the proposal, and read what the first raised that the second never did. A consultant that sees
+your proposal tends to answer around it; one that does not is more likely to question the framing itself.
 
 ## A brief for a decision you will live with
 
@@ -70,10 +69,14 @@ names. Your own CLI is a fresh session but not another lineage, and its `quality
 consultants of one vendor.
 
 Send **one** `targets` call: every consultant receives the byte-identical brief, which is what makes the answers
-comparable. Poll the single group with `consult_get({ group_id })` and stop it with
-`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap (nine by default, shared by
-every severally session on this machine) and one consultation's quota per consultant, and `targets` is refused
-on a follow-up.
+comparable (on a follow-up to the group, the same new question, with each one's own earlier rounds). Poll the single group with `consult_get({ group_id })` and stop it with
+`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap per consultant (nine by default,
+shared by every severally session on this machine; the group starts only if every member gets one) and one
+consultation's quota per consultant. To ask every member again, follow up the group: `followup_to: "<group_id>"`
+with no `target` or `targets` (see Follow-ups).
+
+While you wait, `consult_get` blocks for up to its limit (ten minutes where the client allows it). To work on
+something independent in between, pass a shorter `wait_ms` and come back.
 
 `comparison.by_target` holds, per consultant: stance, summary, confidence, evidence basis, finding points (each
 with its `id` and severity), `severity_counts`, `decision_changers`, alternatives, unknowns (`u1` …),
@@ -93,7 +96,7 @@ Reading them against each other:
 4. **Read `decision_changers` before spending a follow-up**: a consultant that named the condition under which
    it would change its mind has told you what evidence to go get.
 5. **Spend a follow-up only on a divergence that would change your decision**, sent only to the consultant
-   whose reading it belongs to.
+   whose reading it belongs to, or to the whole group (`followup_to: "<group_id>"`) when it concerns all of them.
 6. **A stance every consultant shares is not evidence that the plan was checked.** Look for a premise they all
    rely on and none could verify; name it only if you can actually identify one.
 
@@ -123,14 +126,23 @@ in `failure.detail`, which tells you whether to retry with a longer budget or a
 
 By default a chain has five rounds: one initial round plus up to four follow-ups
 (`followup_to: "<previous job_id>"`); the operator can configure 1–20 (`server.max_rounds`), and
-`rounds_remaining` says what is left. A follow-up starts in a fresh working directory with no files: pass
+`rounds_remaining` says what is left. `followup_to: "<group_id>"`, with no `target` or `targets`, sends the same new
+question to every member of a fan-out, each continuing from its own latest round with its own history; a member
+that is still running, never answered or has used its rounds is listed under `skipped` and not asked.
+
+A follow-up needs only `followup_to` and the new `question`:
+`consult_start({ request: { followup_to: "<job_id>", question: "..." } })`. The consultant, the mode, `network` and what
+the earlier round was given (objective, constraints, success criteria, facts, proposal, counterpoints,
+artifacts) carry over, and the brief restates them; a field you pass replaces the earlier one, an empty list
+included. A follow-up starts in a fresh working directory with no files: pass
 `context.expose_from_parent: true` to copy again, as they are now, the paths the earlier round exposed (a changed
 or vanished entry is marked), and leave it off when the follow-up does not need them.
 
 Spend follow-ups only where you and the consultant actually diverge: quote the specific point, give the evidence
 that answers it, and ask what would change their view. Write your verdicts with `consult_record` first: the
 consultant is shown each earlier point with your verdict, so it answers what your checking found instead of
-restating it. A follow-up works across a server restart.
+restating it. A follow-up works across a server restart; `consult_list` shows an earlier session's
+consultations with their `job_id` and `group_id`.
 
 After each follow-up, state in one sentence the cause you still differ on. If it is the same as last round and
 the round brought no new evidence and no new condition that would change the judgement, stop and hand the user

package/plugins/severally/skills/antigravity/severally/SKILL.md

@@ -5,9 +5,9 @@ description: Use when a decision deserves a second, independent mind - an archit
 
 # Consulting a peer agent
 
-You have three peers, each reached through the `severally` MCP server as a fresh child session. They can
-search and browse the web. They cannot edit files, reach the network outside search/browse, load MCP tools,
-see your session, or consult anyone else. In practice they know only what you put in the brief and the files you expose to them.
+You have three peers, each reached through the `severally` MCP server as a fresh child session that can read files
+and search the web, but not edit them, load MCP tools, see your session or consult anyone else. Each knows only
+what you put in the brief and the files you expose to it.
 
 One caveat on that list: a consultant can read local files. Its writes are blocked,
 its network reaches only web search and browsing (none with `network: "off"`), credential and history
@@ -29,13 +29,14 @@ copied read-only into its working directory. The Codex consultant additionally h
    }})
    ```
 
-2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits up to 45 seconds for
-   the answer by itself; call it again while `status` is `running`, and work on something independent in between.
+2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits for the answer by itself,
+   up to a limit the server sets (45 seconds, or ten minutes where the client allows it); call it again while
+   `status` is `running`. To work on something independent meanwhile, ask for a shorter wait (`reference.md`).
 3. **Check one point, report, and record it once** (see **Before you hand the decision back**).
 
-That is the whole routine. The rest of the record — more verdicts, a prediction and reflection, follow-ups,
-the export into the repository, the details of reading a fan-out — is in `reference.md`, in the same
-directory as this file. Read it only for a decision you will have to justify later, or when you follow up.
+That is the whole routine. The rest — follow-ups, a prediction and reflection, the export, reading a fan-out
+in detail — is in `reference.md`, in the same directory as this file. Read it for a decision you will have to
+justify later, or when you follow up.
 
 ## Pick the consultant
 
@@ -53,12 +54,10 @@ costs one consultation's quota per consultant. Narrow to `target` (singular) onl
 specific peer, or when the decision clearly does not warrant that much. This is the one rule for how many to
 ask.
 
-A consultant is one CLI running one model, and the operator decides which ones exist. `consult_start`'s
-description lists the ones this machine can actually reach as `name: CLI, model`. When the user names one,
-pass **the word the user used** as `target` — a name, a CLI (`codex`, `agy`), a vendor or a model
-(「Claude Opusと相談して」 is `target: "claude opus"`) — and let the server resolve it. A word that fits several
-comes back as `target_ambiguous` with the candidates: ask the user which one they meant. One that is not
-installed comes back as `target_unavailable` with the available list: take that as final and tell the user.
+The operator decides which consultants exist; `consult_start`'s description lists the ones this machine can
+actually reach. When the user names one, pass **the word the user used** as `target`
+(「Claude Opusと相談して」 is `target: "claude opus"`). `target_ambiguous`: ask the user which one they meant.
+`target_unavailable`: take the available list as final and tell the user.
 
 **Do not pick a model yourself.** When the user named no one, ask everyone; overriding the operator's
 consultants on your own judgement — including after a `usage_limit` failure — substitutes a different mind
@@ -72,9 +71,8 @@ answer can say which model answered.
 
 ## When this is worth it
 
-When a wrong answer is expensive or hard to undo: an architectural or interface decision, a data migration, a
-security or concurrency design; two options that still look close; an investigation that has stalled after two
-failed attempts; or the user asked. Not for routine edits, a rename, a test that just needs writing, or
+When a wrong answer is expensive or hard to undo (an interface, a migration, a security or concurrency design),
+two options still look close, an investigation has stalled after two attempts, or the user asked. Not for
 anything you would be comfortable defending on your own.
 
 **Before you ask the user to approve a change that is hard to reverse** and nobody else has reviewed it,
@@ -91,15 +89,13 @@ Pass `initiator: "user"` when the user asked for the consultation; leave it out
 - **Ask one decidable question.** What runs out the clock is scope, not brief length: when the budget runs out
   the session is killed and you get nothing. Split "research everything about X" or three questions at once,
   and ask the one whose answer changes what you do next.
-- **Hand over the code.** The consultant starts in an empty working directory and is not told where your
-  repository is. Name the files by absolute path in `context.expose_paths` in this first call (at most 20
-  entries, 500 files, 5 MB; never your home directory or one holding keys), or pass
+- **Hand over the code.** The consultant is not told where your repository is. Name the files by absolute path
+  in `context.expose_paths` (a repository root works; never your home directory or one holding keys), or pass
   `context.expose_diff: { repo: "<absolute path>" }` for a change you are making. When `consult_start` answers
   `files_exposed: 0` and the question is about code, `consult_cancel` and start again with `expose_paths`.
 - **Put the load-bearing facts in `context.facts`**, and test output or a log in `context.artifacts`.
-- **The mode follows from the context.** Leave `mode` out: no proposal is `explore`, a proposal is `review`, a
-  proposal with `counterpoints` (the other side's claims) is `debate`. To gather opinions without showing your
-  own, leave `context.proposal` empty; a reviewed plan is answered around the plan.
+- **Leave `mode` out**; it follows from the context. To gather opinions without showing your own, leave
+  `context.proposal` empty: a reviewed plan is answered around the plan.
 - A constraint is read as fixed and will not be challenged; if it is your own call, put it under `facts` with
   its reason. For material that must not leave the machine through a URL, pass `network: "off"`.
 

package/plugins/severally/skills/antigravity/severally/reference.md

@@ -17,9 +17,8 @@ checked as given: the server rejects a first-round `explore` that carries a prop
 anchoring-sensitive — if you want your plan critiqued, that is `review`.
 
 **For a decision heavy enough to be worth two consultations**, ask `explore` first on the facts alone, then
-`review` with the proposal, and read what the first raised that the second never did. Measured on this
-project: repeat runs of the identical brief did not move the bottom line, while withholding the proposal once
-did, and the withheld run was the only one to question what the decision was even about.
+`review` with the proposal, and read what the first raised that the second never did. A consultant that sees
+your proposal tends to answer around it; one that does not is more likely to question the framing itself.
 
 ## A brief for a decision you will live with
 
@@ -70,10 +69,14 @@ names. Your own CLI is a fresh session but not another lineage, and its `quality
 consultants of one vendor.
 
 Send **one** `targets` call: every consultant receives the byte-identical brief, which is what makes the answers
-comparable. Poll the single group with `consult_get({ group_id })` and stop it with
-`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap (nine by default, shared by
-every severally session on this machine) and one consultation's quota per consultant, and `targets` is refused
-on a follow-up.
+comparable (on a follow-up to the group, the same new question, with each one's own earlier rounds). Poll the single group with `consult_get({ group_id })` and stop it with
+`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap per consultant (nine by default,
+shared by every severally session on this machine; the group starts only if every member gets one) and one
+consultation's quota per consultant. To ask every member again, follow up the group: `followup_to: "<group_id>"`
+with no `target` or `targets` (see Follow-ups).
+
+While you wait, `consult_get` blocks for up to its limit (ten minutes where the client allows it). To work on
+something independent in between, pass a shorter `wait_ms` and come back.
 
 `comparison.by_target` holds, per consultant: stance, summary, confidence, evidence basis, finding points (each
 with its `id` and severity), `severity_counts`, `decision_changers`, alternatives, unknowns (`u1` …),
@@ -93,7 +96,7 @@ Reading them against each other:
 4. **Read `decision_changers` before spending a follow-up**: a consultant that named the condition under which
    it would change its mind has told you what evidence to go get.
 5. **Spend a follow-up only on a divergence that would change your decision**, sent only to the consultant
-   whose reading it belongs to.
+   whose reading it belongs to, or to the whole group (`followup_to: "<group_id>"`) when it concerns all of them.
 6. **A stance every consultant shares is not evidence that the plan was checked.** Look for a premise they all
    rely on and none could verify; name it only if you can actually identify one.
 
@@ -123,14 +126,23 @@ in `failure.detail`, which tells you whether to retry with a longer budget or a
 
 By default a chain has five rounds: one initial round plus up to four follow-ups
 (`followup_to: "<previous job_id>"`); the operator can configure 1–20 (`server.max_rounds`), and
-`rounds_remaining` says what is left. A follow-up starts in a fresh working directory with no files: pass
+`rounds_remaining` says what is left. `followup_to: "<group_id>"`, with no `target` or `targets`, sends the same new
+question to every member of a fan-out, each continuing from its own latest round with its own history; a member
+that is still running, never answered or has used its rounds is listed under `skipped` and not asked.
+
+A follow-up needs only `followup_to` and the new `question`:
+`consult_start({ request: { followup_to: "<job_id>", question: "..." } })`. The consultant, the mode, `network` and what
+the earlier round was given (objective, constraints, success criteria, facts, proposal, counterpoints,
+artifacts) carry over, and the brief restates them; a field you pass replaces the earlier one, an empty list
+included. A follow-up starts in a fresh working directory with no files: pass
 `context.expose_from_parent: true` to copy again, as they are now, the paths the earlier round exposed (a changed
 or vanished entry is marked), and leave it off when the follow-up does not need them.
 
 Spend follow-ups only where you and the consultant actually diverge: quote the specific point, give the evidence
 that answers it, and ask what would change their view. Write your verdicts with `consult_record` first: the
 consultant is shown each earlier point with your verdict, so it answers what your checking found instead of
-restating it. A follow-up works across a server restart.
+restating it. A follow-up works across a server restart; `consult_list` shows an earlier session's
+consultations with their `job_id` and `group_id`.
 
 After each follow-up, state in one sentence the cause you still differ on. If it is the same as last round and
 the round brought no new evidence and no new condition that would change the judgement, stop and hand the user

package/plugins/severally/skills/claude/severally/SKILL.md

@@ -6,9 +6,9 @@ allowed-tools: mcp__plugin_severally_severally__consult_get mcp__severally__cons
 
 # Consulting a peer agent
 
-You have three peers, each reached through the `severally` MCP server as a fresh child session. They can
-search and browse the web. They cannot edit files, reach the network outside search/browse, load MCP tools,
-see your session, or consult anyone else. In practice they know only what you put in the brief and the files you expose to them.
+You have three peers, each reached through the `severally` MCP server as a fresh child session that can read files
+and search the web, but not edit them, load MCP tools, see your session or consult anyone else. Each knows only
+what you put in the brief and the files you expose to it.
 
 One caveat on that list: a consultant can read local files. Its writes are blocked,
 its network reaches only web search and browsing (none with `network: "off"`), credential and history
@@ -30,13 +30,14 @@ copied read-only into its working directory. The Codex consultant additionally h
    }})
    ```
 
-2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits up to 45 seconds for
-   the answer by itself; call it again while `status` is `running`, and work on something independent in between.
+2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits for the answer by itself,
+   up to a limit the server sets (45 seconds, or ten minutes where the client allows it); call it again while
+   `status` is `running`. To work on something independent meanwhile, ask for a shorter wait (`reference.md`).
 3. **Check one point, report, and record it once** (see **Before you hand the decision back**).
 
-That is the whole routine. The rest of the record — more verdicts, a prediction and reflection, follow-ups,
-the export into the repository, the details of reading a fan-out — is in `reference.md`, in the same
-directory as this file. Read it only for a decision you will have to justify later, or when you follow up.
+That is the whole routine. The rest — follow-ups, a prediction and reflection, the export, reading a fan-out
+in detail — is in `reference.md`, in the same directory as this file. Read it for a decision you will have to
+justify later, or when you follow up.
 
 ## Pick the consultant
 
@@ -54,12 +55,10 @@ costs one consultation's quota per consultant. Narrow to `target` (singular) onl
 specific peer, or when the decision clearly does not warrant that much. This is the one rule for how many to
 ask.
 
-A consultant is one CLI running one model, and the operator decides which ones exist. `consult_start`'s
-description lists the ones this machine can actually reach as `name: CLI, model`. When the user names one,
-pass **the word the user used** as `target` — a name, a CLI (`codex`, `agy`), a vendor or a model
-(「Claude Opusと相談して」 is `target: "claude opus"`) — and let the server resolve it. A word that fits several
-comes back as `target_ambiguous` with the candidates: ask the user which one they meant. One that is not
-installed comes back as `target_unavailable` with the available list: take that as final and tell the user.
+The operator decides which consultants exist; `consult_start`'s description lists the ones this machine can
+actually reach. When the user names one, pass **the word the user used** as `target`
+(「Claude Opusと相談して」 is `target: "claude opus"`). `target_ambiguous`: ask the user which one they meant.
+`target_unavailable`: take the available list as final and tell the user.
 
 **Do not pick a model yourself.** When the user named no one, ask everyone; overriding the operator's
 consultants on your own judgement — including after a `usage_limit` failure — substitutes a different mind
@@ -73,9 +72,8 @@ answer can say which model answered.
 
 ## When this is worth it
 
-When a wrong answer is expensive or hard to undo: an architectural or interface decision, a data migration, a
-security or concurrency design; two options that still look close; an investigation that has stalled after two
-failed attempts; or the user asked. Not for routine edits, a rename, a test that just needs writing, or
+When a wrong answer is expensive or hard to undo (an interface, a migration, a security or concurrency design),
+two options still look close, an investigation has stalled after two attempts, or the user asked. Not for
 anything you would be comfortable defending on your own.
 
 **Before you ask the user to approve a change that is hard to reverse** and nobody else has reviewed it,
@@ -92,15 +90,13 @@ Pass `initiator: "user"` when the user asked for the consultation; leave it out
 - **Ask one decidable question.** What runs out the clock is scope, not brief length: when the budget runs out
   the session is killed and you get nothing. Split "research everything about X" or three questions at once,
   and ask the one whose answer changes what you do next.
-- **Hand over the code.** The consultant starts in an empty working directory and is not told where your
-  repository is. Name the files by absolute path in `context.expose_paths` in this first call (at most 20
-  entries, 500 files, 5 MB; never your home directory or one holding keys), or pass
+- **Hand over the code.** The consultant is not told where your repository is. Name the files by absolute path
+  in `context.expose_paths` (a repository root works; never your home directory or one holding keys), or pass
   `context.expose_diff: { repo: "<absolute path>" }` for a change you are making. When `consult_start` answers
   `files_exposed: 0` and the question is about code, `consult_cancel` and start again with `expose_paths`.
 - **Put the load-bearing facts in `context.facts`**, and test output or a log in `context.artifacts`.
-- **The mode follows from the context.** Leave `mode` out: no proposal is `explore`, a proposal is `review`, a
-  proposal with `counterpoints` (the other side's claims) is `debate`. To gather opinions without showing your
-  own, leave `context.proposal` empty; a reviewed plan is answered around the plan.
+- **Leave `mode` out**; it follows from the context. To gather opinions without showing your own, leave
+  `context.proposal` empty: a reviewed plan is answered around the plan.
 - A constraint is read as fixed and will not be challenged; if it is your own call, put it under `facts` with
   its reason. For material that must not leave the machine through a URL, pass `network: "off"`.
 

package/plugins/severally/skills/claude/severally/reference.md

@@ -17,9 +17,8 @@ checked as given: the server rejects a first-round `explore` that carries a prop
 anchoring-sensitive — if you want your plan critiqued, that is `review`.
 
 **For a decision heavy enough to be worth two consultations**, ask `explore` first on the facts alone, then
-`review` with the proposal, and read what the first raised that the second never did. Measured on this
-project: repeat runs of the identical brief did not move the bottom line, while withholding the proposal once
-did, and the withheld run was the only one to question what the decision was even about.
+`review` with the proposal, and read what the first raised that the second never did. A consultant that sees
+your proposal tends to answer around it; one that does not is more likely to question the framing itself.
 
 ## A brief for a decision you will live with
 
@@ -70,10 +69,14 @@ names. Your own CLI is a fresh session but not another lineage, and its `quality
 consultants of one vendor.
 
 Send **one** `targets` call: every consultant receives the byte-identical brief, which is what makes the answers
-comparable. Poll the single group with `consult_get({ group_id })` and stop it with
-`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap (nine by default, shared by
-every severally session on this machine) and one consultation's quota per consultant, and `targets` is refused
-on a follow-up.
+comparable (on a follow-up to the group, the same new question, with each one's own earlier rounds). Poll the single group with `consult_get({ group_id })` and stop it with
+`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap per consultant (nine by default,
+shared by every severally session on this machine; the group starts only if every member gets one) and one
+consultation's quota per consultant. To ask every member again, follow up the group: `followup_to: "<group_id>"`
+with no `target` or `targets` (see Follow-ups).
+
+While you wait, `consult_get` blocks for up to its limit (ten minutes where the client allows it). To work on
+something independent in between, pass a shorter `wait_ms` and come back.
 
 `comparison.by_target` holds, per consultant: stance, summary, confidence, evidence basis, finding points (each
 with its `id` and severity), `severity_counts`, `decision_changers`, alternatives, unknowns (`u1` …),
@@ -93,7 +96,7 @@ Reading them against each other:
 4. **Read `decision_changers` before spending a follow-up**: a consultant that named the condition under which
    it would change its mind has told you what evidence to go get.
 5. **Spend a follow-up only on a divergence that would change your decision**, sent only to the consultant
-   whose reading it belongs to.
+   whose reading it belongs to, or to the whole group (`followup_to: "<group_id>"`) when it concerns all of them.
 6. **A stance every consultant shares is not evidence that the plan was checked.** Look for a premise they all
    rely on and none could verify; name it only if you can actually identify one.
 
@@ -123,14 +126,23 @@ in `failure.detail`, which tells you whether to retry with a longer budget or a
 
 By default a chain has five rounds: one initial round plus up to four follow-ups
 (`followup_to: "<previous job_id>"`); the operator can configure 1–20 (`server.max_rounds`), and
-`rounds_remaining` says what is left. A follow-up starts in a fresh working directory with no files: pass
+`rounds_remaining` says what is left. `followup_to: "<group_id>"`, with no `target` or `targets`, sends the same new
+question to every member of a fan-out, each continuing from its own latest round with its own history; a member
+that is still running, never answered or has used its rounds is listed under `skipped` and not asked.
+
+A follow-up needs only `followup_to` and the new `question`:
+`consult_start({ request: { followup_to: "<job_id>", question: "..." } })`. The consultant, the mode, `network` and what
+the earlier round was given (objective, constraints, success criteria, facts, proposal, counterpoints,
+artifacts) carry over, and the brief restates them; a field you pass replaces the earlier one, an empty list
+included. A follow-up starts in a fresh working directory with no files: pass
 `context.expose_from_parent: true` to copy again, as they are now, the paths the earlier round exposed (a changed
 or vanished entry is marked), and leave it off when the follow-up does not need them.
 
 Spend follow-ups only where you and the consultant actually diverge: quote the specific point, give the evidence
 that answers it, and ask what would change their view. Write your verdicts with `consult_record` first: the
 consultant is shown each earlier point with your verdict, so it answers what your checking found instead of
-restating it. A follow-up works across a server restart.
+restating it. A follow-up works across a server restart; `consult_list` shows an earlier session's
+consultations with their `job_id` and `group_id`.
 
 After each follow-up, state in one sentence the cause you still differ on. If it is the same as last round and
 the round brought no new evidence and no new condition that would change the judgement, stop and hand the user

package/plugins/severally/skills/codex/severally/SKILL.md

@@ -5,9 +5,9 @@ description: Use when a decision deserves a second, independent mind - an archit
 
 # Consulting a peer agent
 
-You have three peers, each reached through the `severally` MCP server as a fresh child session. They can
-search and browse the web. They cannot edit files, reach the network outside search/browse, load MCP tools,
-see your session, or consult anyone else. In practice they know only what you put in the brief and the files you expose to them.
+You have three peers, each reached through the `severally` MCP server as a fresh child session that can read files
+and search the web, but not edit them, load MCP tools, see your session or consult anyone else. Each knows only
+what you put in the brief and the files you expose to it.
 
 One caveat on that list: a consultant can read local files. Its writes are blocked,
 its network reaches only web search and browsing (none with `network: "off"`), credential and history
@@ -29,13 +29,14 @@ copied read-only into its working directory.
    }})
    ```
 
-2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits up to 45 seconds for
-   the answer by itself; call it again while `status` is `running`, and work on something independent in between.
+2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits for the answer by itself,
+   up to a limit the server sets (45 seconds, or ten minutes where the client allows it); call it again while
+   `status` is `running`. To work on something independent meanwhile, ask for a shorter wait (`reference.md`).
 3. **Check one point, report, and record it once** (see **Before you hand the decision back**).
 
-That is the whole routine. The rest of the record — more verdicts, a prediction and reflection, follow-ups,
-the export into the repository, the details of reading a fan-out — is in `reference.md`, in the same
-directory as this file. Read it only for a decision you will have to justify later, or when you follow up.
+That is the whole routine. The rest — follow-ups, a prediction and reflection, the export, reading a fan-out
+in detail — is in `reference.md`, in the same directory as this file. Read it for a decision you will have to
+justify later, or when you follow up.
 
 ## Pick the consultant
 
@@ -53,12 +54,10 @@ costs one consultation's quota per consultant. Narrow to `target` (singular) onl
 specific peer, or when the decision clearly does not warrant that much. This is the one rule for how many to
 ask.
 
-A consultant is one CLI running one model, and the operator decides which ones exist. `consult_start`'s
-description lists the ones this machine can actually reach as `name: CLI, model`. When the user names one,
-pass **the word the user used** as `target` — a name, a CLI (`codex`, `agy`), a vendor or a model
-(「Claude Opusと相談して」 is `target: "claude opus"`) — and let the server resolve it. A word that fits several
-comes back as `target_ambiguous` with the candidates: ask the user which one they meant. One that is not
-installed comes back as `target_unavailable` with the available list: take that as final and tell the user.
+The operator decides which consultants exist; `consult_start`'s description lists the ones this machine can
+actually reach. When the user names one, pass **the word the user used** as `target`
+(「Claude Opusと相談して」 is `target: "claude opus"`). `target_ambiguous`: ask the user which one they meant.
+`target_unavailable`: take the available list as final and tell the user.
 
 **Do not pick a model yourself.** When the user named no one, ask everyone; overriding the operator's
 consultants on your own judgement — including after a `usage_limit` failure — substitutes a different mind
@@ -72,9 +71,8 @@ answer can say which model answered.
 
 ## When this is worth it
 
-When a wrong answer is expensive or hard to undo: an architectural or interface decision, a data migration, a
-security or concurrency design; two options that still look close; an investigation that has stalled after two
-failed attempts; or the user asked. Not for routine edits, a rename, a test that just needs writing, or
+When a wrong answer is expensive or hard to undo (an interface, a migration, a security or concurrency design),
+two options still look close, an investigation has stalled after two attempts, or the user asked. Not for
 anything you would be comfortable defending on your own.
 
 **Before you ask the user to approve a change that is hard to reverse** and nobody else has reviewed it,
@@ -91,15 +89,13 @@ Pass `initiator: "user"` when the user asked for the consultation; leave it out
 - **Ask one decidable question.** What runs out the clock is scope, not brief length: when the budget runs out
   the session is killed and you get nothing. Split "research everything about X" or three questions at once,
   and ask the one whose answer changes what you do next.
-- **Hand over the code.** The consultant starts in an empty working directory and is not told where your
-  repository is. Name the files by absolute path in `context.expose_paths` in this first call (at most 20
-  entries, 500 files, 5 MB; never your home directory or one holding keys), or pass
+- **Hand over the code.** The consultant is not told where your repository is. Name the files by absolute path
+  in `context.expose_paths` (a repository root works; never your home directory or one holding keys), or pass
   `context.expose_diff: { repo: "<absolute path>" }` for a change you are making. When `consult_start` answers
   `files_exposed: 0` and the question is about code, `consult_cancel` and start again with `expose_paths`.
 - **Put the load-bearing facts in `context.facts`**, and test output or a log in `context.artifacts`.
-- **The mode follows from the context.** Leave `mode` out: no proposal is `explore`, a proposal is `review`, a
-  proposal with `counterpoints` (the other side's claims) is `debate`. To gather opinions without showing your
-  own, leave `context.proposal` empty; a reviewed plan is answered around the plan.
+- **Leave `mode` out**; it follows from the context. To gather opinions without showing your own, leave
+  `context.proposal` empty: a reviewed plan is answered around the plan.
 - A constraint is read as fixed and will not be challenged; if it is your own call, put it under `facts` with
   its reason. For material that must not leave the machine through a URL, pass `network: "off"`.