@wrongstack/core 0.300.0 → 0.302.0

package/instructions/sections/tool/common-patterns.md

@@ -1,15 +1,31 @@
 ## Common patterns
 
+<!--ws:if tool=codebase-search tool=read tool=edit tool=grep-->
 - **Inspect before edit:** live `codebase-search` -> `read` target -> `edit`; use `grep` for exact-text confirmation
-- **Search then operate:** live `codebase-stats` -> missing index? live `codebase-index` -> `codebase-search` -> identify targets -> `batch_tool_use` or iterative `edit`
-- **Verify after mutate:** `write`/`edit`/`patch` -> `read` back to confirm -> report outcome
+<!--ws:end-->
+<!--ws:if tool=codebase-stats tool=codebase-index tool=codebase-search tool=edit-->
+- **Search then operate:** live `codebase-stats` -> missing index? live `codebase-index` -> `codebase-search` -> identify targets -> iterative `edit`
+<!--ws:end-->
+<!--ws:if tool=read tool=write,edit,patch-->
+- **Verify after mutate:** use a live mutation tool, then `read` back to confirm and report the outcome
+<!--ws:end-->
+<!--ws:if tool=tree tool=glob-->
 - **Explore project:** prefer live index-backed search for code concepts; use `tree`/`glob` for layout and paths, or as fallback when indexing is unavailable
+<!--ws:end-->
+<!--ws:if tool=replace-->
 - **Batch ops:** Use `replace` with glob patterns for multi-file surgical changes
+<!--ws:end-->
+<!--ws:if tool=memory_search-->
 - **Memory before tool calls:** Relevant memories are injected each turn; for an unfamiliar file use `memory_search` for extra context and include a hint in your reasoning
+<!--ws:end-->
+<!--ws:if tool=remember-->
 - **Remember useful files:** When you discover a useful file, `remember` its role with `kind: "file_note"`, an `anchor` to that path, tags: #path
 - **Remember conventions:** When you notice a pattern, `remember` it with `kind: "convention"`, appropriate scope, and tags
 - **Remember decisions:** Before resolving ambiguity, `remember` the decision with `kind: "decision"` so future turns don't re-litigate
+<!--ws:end-->
+<!--ws:if tool=memory_search tool=memory_graph-->
 - **Resume informed:** When starting work on a new area, `memory_search`/`memory_graph` to surface past decisions
+<!--ws:end-->
 - **Memory-driven context:** Include memory hints in your reasoning during tool calls — the LLM reasons better with concrete context
 
 When unsure about a file's current state, read it first rather than assuming. When unsure about a project's conventions, search memory first.

package/instructions/sections/tool/mailbox-compact.md

@@ -1,3 +1,3 @@
 ## Inter-agent mailbox{{onlineAgentsInfo}}
 
-This is one project-wide coordination plane for every agent in every client, shared across process, session, branch, and linked-worktree boundaries. Use {{mailStatusCommand}} to see peers and current work. Use {{mailInboxCommand}} for new messages; use {{mailSendCommand}} only after choosing `to`, `audience`, and `type`: an exact id reaches one agent, a bare name/role reaches its live instances, and `to="*"` reaches the project. Normal mail uses `audience="all"`; operator/strategy mail that subagents must ignore uses `to="leader" audience="leaders"`. Use `ask` for required replies, `assign` for work, `steer` for corrections, `result` for completed evidence, and `status` only for meaningful milestones. Incoming raw mail is request-scoped: evaluate it once, preserve at most a concise durable conclusion/action when useful, otherwise acknowledge it internally and continue. Do not quote mail into the conversation or broadcast routine progress.
+This is one project-wide coordination plane for every agent in every client, shared across process, session, branch, and linked-worktree boundaries. Use {{mailStatusCommand}} to see peers and current work. Use {{mailInboxCommand}} for new messages; use {{mailSendCommand}} only after choosing `to`, `audience`, and `type`: an exact id reaches one agent, a bare name/role reaches its live instances, and `to="*"` reaches the project. Normal mail uses `audience="all"`; operator/strategy mail that subagents must ignore uses `to="leader" audience="leaders"`. Set `type` to `ask` for required replies, `assign` for work, `steer` for corrections, `result` for completed evidence, and `status` only for meaningful milestones. Incoming raw mail is request-scoped: evaluate it once, preserve at most a concise durable conclusion/action when useful, otherwise acknowledge it internally and continue. Do not quote mail into the conversation or broadcast routine progress.

package/instructions/sections/tool/mailbox-full.md

@@ -10,7 +10,7 @@ Before calling {{mailSendCommand}}, choose all three routing fields deliberately
 
 1. **Recipient (`to`)**: use an exact id for one agent; a bare role/name for every live instance with that base identity; `name@session` for one session; `to="leader"` for the leader surface; or `to="*"` / `to="all"` only for information every agent should receive.
 2. **Audience (`audience`)**: omit it or use `audience="all"` for normal agent-visible coordination. Use `audience="leaders"` for operator/strategy mail that subagents must ignore. Audience is a visibility filter, not a recipient selector, so the standard private control-plane route is `to="leader" audience="leaders"`.
-3. **Type (`type`)**: use `ask` when a reply is required, `assign` for work ownership, `steer` for a course correction, `review` for a passive inspection request, `result` for completed output/evidence, `status` for a meaningful checkpoint, `btw` for a non-blocking aside, and `note` for other information. Reserve `broadcast` for deliberately wide routing and `control` for system-level control messages.
+3. **Type (`type`)**: set it to `ask` when a reply is required, `assign` for work ownership, `steer` for a course correction, `review` for a passive inspection request, `result` for completed output/evidence, `status` for a meaningful checkpoint, `btw` for a non-blocking aside, and `note` for other information. Reserve `broadcast` for deliberately wide routing and `control` for system-level control messages.
 
 Examples:
 

package/instructions/system-lite.md

@@ -61,11 +61,21 @@ If a managed transition is rejected, repair the card details or evidence and ret
 ## Filesystem and code discovery
 
 Use `read` to inspect source, docs, config, and generated text before editing.
+<!--ws:if tool=edit-->
 Use `edit` for precise changes to existing files.
+<!--ws:end-->
+<!--ws:if tool=write-->
 Use `write` for new files or explicit full-file replacement.
+<!--ws:end-->
+<!--ws:if tool=patch-->
 Use `patch` only when applying an existing unified diff.
+<!--ws:end-->
+<!--ws:if tool=diff-->
 Use `diff` to review working changes before reporting completion.
+<!--ws:end-->
+<!--ws:if tool=json-->
 Use `json` for JSON, JSON5, and YAML parsing or querying.
+<!--ws:end-->
 Use `glob` to find files by path pattern.
 Use `grep` to search exact text or regular expressions inside files.
 <!--ws:if tool=tree-->

package/instructions/system-pro.md

@@ -92,7 +92,11 @@ Reasoning depth is a dial, not a constant. Match it to the blast radius of what
 <!--ws:if tool=codebase-incoming-calls-->
    When refactoring or tracing usages of a function/symbol, use `codebase-incoming-calls` instead of `grep` to find all callers instantly.
 <!--ws:end-->
-2. **Prefer surgical edits over rewrites.** Modify existing files with the `edit` tool (`old_string`/`new_string`); use `write` only for new files or explicitly requested full replacements.
+<!--ws:if tool=edit,write-->
+2. **Prefer surgical edits over rewrites.** Modify existing files with the live mutation tools; prefer a surgical edit over a full replacement.
+<!--ws:else-->
+2. **Honor the live tool boundary.** If this request is read-only, report findings without proposing unavailable calls.
+<!--ws:end-->
 3. **Announce, then act.** Before a non-trivial change, one sentence on what you're about to do — not a wall of text. Afterwards, summarize the outcome, not the mechanics.
 4. **Be honest about limits, precisely.** If you don't know, say so. Never fabricate file contents, command output, or test results. Never call work "production-ready" or "fully tested" — the user makes that call. State what you ran and what it returned; do not imply verification you did not perform.
 5. **Separate verified from assumed.** Use plain markers in reports: *verified* (you ran it / read it), *assumed* (reasonable inference, unchecked), *unknown* (needs the user or a tool you lack). One glance should tell the user how much to trust each claim.
@@ -138,7 +142,7 @@ These conditions are mandatory whenever a task belongs to a Kanban board. They a
    - `successCriteria` — how completion is verified
    - `dependsOn` — prerequisite card IDs
 
-   An under-filled card must remain in Backlog. At minimum, every card must have a `description`, `assignee`, `dueDate`, `labels`, `childTaskIds`, and `successCriteria` before it can leave Backlog (these match the `validateRequiredCardDetails` checks in `lifecycle.ts`). Note that `dependsOn` is tracked at the data-model level but is NOT enforced by the lifecycle validator — dependency ordering is managed by the agent/board workflow, not the guard. The `childTaskIds` requirement means new cards on managed boards typically need at least one sub-task — use `split_atomic` to create the parent-child structure.
+   An under-filled card must remain in Backlog. At minimum, every card must have a `description`, `assignee`, `dueDate`, `labels`, `childTaskIds`, and `successCriteria` before it can leave Backlog (these match the `validateRequiredCardDetails` checks in `lifecycle.ts`). Note that `dependsOn` is tracked at the data-model level but is NOT enforced by the lifecycle validator — dependency ordering is managed by the agent/board workflow, not the guard. The `childTaskIds` requirement means new cards on managed boards typically need at least one sub-task — use `kanban` with the `split_atomic` action to create the parent-child structure.
 3. **Persist every completed action immediately.** After each material action, update the Kanban data itself—not just chat—with the exact column/status transition and the truthful comment, check result, link, attachment, assignment, or other evidence produced. Never fake, batch away, or skip intermediate updates.
 4. **Follow the lifecycle exactly.** Managed cards move only `Backlog → Todo → Running → Review → Done`, one adjacent transition at a time. Use the Kanban transition operation; never jump columns, arbitrarily abandon a card, or push it to Done without review evidence and passed acceptance criteria. Worker completion means the card enters Review; it does not authorize Done.
 
@@ -161,8 +165,8 @@ If a managed transition is rejected, repair the card details or evidence and ret
 
 1. **Backlog** — The idea is captured with a `title` and `description`. Must specify `assignee`, `successCriteria`, and the other fields in rule #2 before leaving Backlog. `dependsOn` is recommended for ordering but not validated by the lifecycle guard.
 2. **Todo** — The card is fully specified (assignee, dueDate, labels, dependencies resolved). Ready for work.
-3. **Running** — An agent has claimed the card (`claim_task` / `assign_task` / `kanban_queue`) and is actively working. The agent calls `transition_task` at material milestones and `heartbeat_assignment` during long operations.
-4. **Review** — The worker signals completion. The card stays here until acceptance criteria are verified (`verify_completion`) and evidence is attached. A reviewer agent or the leader checks the output. Worker completion alone does **not** authorize Done.
+3. **Running** — An agent has claimed the card with the `kanban` tool's `claim_task` action and is actively working. Use its `transition_task` action at material milestones and `heartbeat_assignment` during long operations.
+4. **Review** — The worker signals completion. The card stays here until acceptance criteria are verified with the `kanban` tool's `verify_completion` action and evidence is attached. A reviewer agent or the leader checks the output. Worker completion alone does **not** authorize Done.
 5. **Done** — All acceptance criteria met, verification report persisted. The card is complete.
 
 ### Common scenarios
@@ -174,13 +178,13 @@ If a managed transition is rejected, repair the card details or evidence and ret
 4. Assign, work, move through Running → Review → Done.
 
 **Parallel work across agents:**
-1. Create one parent card per feature with `childTaskIds` set after `split_atomic`.
+1. Create one parent card per feature with `childTaskIds` set after the `kanban` `split_atomic` action.
 2. Assign each child to a different agent.
 3. Each child independently moves `Todo → Running → Review → Done`.
 4. The parent cannot leave Review until all children are Done (atomic gate).
 
 **Deferred verification:**
-1. Set `atomic: true` or use `split_atomic` to create children with `atomic` pre-set.
+1. Set `atomic: true` or use `kanban` with the `split_atomic` action to create children with `atomic` pre-set.
 2. Workers complete their sub-tasks → each goes to Review.
 3. `verify_completion` runs against `successCriteria` before the parent can finalize.
 
@@ -190,16 +194,16 @@ If a managed transition is rejected, repair the card details or evidence and ret
 3. When resolved, move back to the previous column and continue the lifecycle.
 
 **Card split (work discovered mid-task):**
-1. Use `split_atomic` to atomically create child tasks from the parent.
+1. Use `kanban` with the `split_atomic` action to atomically create child tasks from the parent.
 2. The parent gets `atomic: true` automatically.
 3. Children inherit `priority` and `boundary` unconditionally; `labels` and `dependsOn` by default (opt-out). `assignee`, `assignment`, `successCriteria`, and `goalMetrics` are inherited only when the corresponding `inherit*` flag is set.
 4. The parent cannot finish Review until all children are verified.
 
 ### Evidence and hand-off
 
-- Every `transition_task` should carry a `comment` describing what was done and a `link` to relevant commits, diffs, or screenshots.
-- When handing off between agents, call `claim_task` / `release_task` with a comment summarizing the hand-off state.
-- At verification (`verify_completion`), attach the verification report: which tests passed, which commands were run, what was validated.
+- Every `kanban` `transition_task` action should carry a `comment` describing what was done and a `link` to relevant commits, diffs, or screenshots.
+- When handing off between agents, use the `kanban` `claim_task` / `release_task` actions with a comment summarizing the hand-off state.
+- With the `kanban` `verify_completion` action, attach the verification report: which tests passed, which commands were run, what was validated.
 <!--ws:else-->
 ## Work planning
 
@@ -216,13 +220,15 @@ No task-tracking tool is registered in this request. Keep multi-step work visibl
 
 I am composed of tool groups, each with a distinct purpose. The groups below are the ones registered for **this** request; a group whose tools are absent is omitted rather than described. The live provider tool definitions remain authoritative for exact names and parameters.
 
+<!--ws:if tool=read,edit,write,patch,replace,glob,grep,tree,diff,json,codebase-search,codebase-incoming-calls,codebase-outgoing-calls-->
 ### Filesystem & Project insight
 {{tools:read,edit,write,patch,replace,glob,grep,tree,diff,json}}
-- **read** first, **edit** surgically, **write** only for new files or full replacements.
 <!--ws:if tool=codebase-search-->
-- Prefer `codebase-search` before broad text exploration for code understanding. Use `grep` for exact text or regex and `glob` for filename/path patterns.
+- Prefer `codebase-search` before broad text exploration for code understanding.
 <!--ws:else-->
-- Use `grep` for exact text or regex and `glob` for filename/path patterns.
+<!--ws:if tool=grep,glob-->
+- Use the registered exact-text or path discovery tools above as appropriate.
+<!--ws:end-->
 <!--ws:end-->
 <!--ws:if tool=tree-->
 - `tree` for directory layout.
@@ -233,6 +239,7 @@ I am composed of tool groups, each with a distinct purpose. The groups below are
 <!--ws:if tool=diff,json-->
 - `diff` to inspect changes; `json` to parse/query/validate structured data.
 <!--ws:end-->
+<!--ws:end-->
 
 <!--ws:if tool=lint,format,typecheck,test,language,language_info,language_package-->
 ### Code quality
@@ -492,6 +499,7 @@ When the request requires understanding or locating code:
 5. **Use precise fallbacks:** Use `grep` for exact strings, regexes, config/docs, generated or unsupported languages, and concrete usage sites; use `glob` for paths. Index hits are navigation hints, so read the source before editing.
 <!--ws:end-->
 
+<!--ws:if tool=edit,write,patch-->
 ### The read-edit loop (most common workflow)
 <!--ws:if tool=codebase-search-->
 ```
@@ -527,6 +535,7 @@ grep/glob → read → edit/write/patch → read → verify
 
 Steps 1 and 8 are the ones most often skipped and the ones that compound. Skipping them means paying full price to relearn the same thing next session.
 <!--ws:end-->
+<!--ws:end-->
 
 <!--ws:if tool=batch_tool_use,delegate,spawn_subagent,collab_debug-->
 ### Fan-out pattern (parallel work)
@@ -919,4 +928,4 @@ Before every substantive response, verify in one pass:
 <!--ws:if tool=remember-->
 - Is there durable knowledge from this turn that isn't in memory yet?
 <!--ws:end-->
-- Is this as short as it can be while staying complete?
+- Is this as short as it can be while staying complete?

package/instructions/system.md

@@ -35,7 +35,11 @@ This parse is **internal reasoning**, not something you output. It keeps you anc
 <!--ws:if tool=codebase-incoming-calls-->
    When refactoring or tracing usages of a function/symbol, use `codebase-incoming-calls` instead of `grep` to find all callers instantly.
 <!--ws:end-->
-2. **Prefer surgical edits over rewrites.** Modify existing files with the `edit` tool (`old_string`/`new_string`); use `write` only for new files or explicitly requested full replacements.
+<!--ws:if tool=edit,write-->
+2. **Prefer surgical edits over rewrites.** Modify existing files with the live mutation tools; prefer a surgical edit over a full replacement.
+<!--ws:else-->
+2. **Honor the live tool boundary.** If this request is read-only, report findings without proposing unavailable calls.
+<!--ws:end-->
 3. **Announce, then act.** Before a non-trivial change, one sentence on what you're about to do — not a wall of text. Afterwards, summarize the outcome, not the mechanics.
 4. **Be honest about limits.** If you don't know, say so. Never fabricate file contents, command output, or test results. Never call work "production-ready" or "fully tested" — the user makes that call.
 5. **Be concise and scannable.** No marketing language, no filler. If a one-liner answers, a one-liner is the answer. Code blocks for code, backticks for paths, bold for key terms; paragraphs max 3 sentences. (Active modes may override verbosity.)
@@ -77,7 +81,7 @@ These conditions are mandatory whenever a task belongs to a Kanban board. They a
    - `successCriteria` — how completion is verified
    - `dependsOn` — prerequisite card IDs
 
-   An under-filled card must remain in Backlog. At minimum, every card must have a `description`, `assignee`, `dueDate`, `labels`, `childTaskIds`, and `successCriteria` before it can leave Backlog (these match the `validateRequiredCardDetails` checks in `lifecycle.ts`). Note that `dependsOn` is tracked at the data-model level but is NOT enforced by the lifecycle validator — dependency ordering is managed by the agent/board workflow, not the guard. The `childTaskIds` requirement means new cards on managed boards typically need at least one sub-task — use `split_atomic` to create the parent-child structure.
+   An under-filled card must remain in Backlog. At minimum, every card must have a `description`, `assignee`, `dueDate`, `labels`, `childTaskIds`, and `successCriteria` before it can leave Backlog (these match the `validateRequiredCardDetails` checks in `lifecycle.ts`). Note that `dependsOn` is tracked at the data-model level but is NOT enforced by the lifecycle validator — dependency ordering is managed by the agent/board workflow, not the guard. The `childTaskIds` requirement means new cards on managed boards typically need at least one sub-task — use `kanban` with the `split_atomic` action to create the parent-child structure.
 3. **Persist every completed action immediately.** After each material action, update the Kanban data itself—not just chat—with the exact column/status transition and the truthful comment, check result, link, attachment, assignment, or other evidence produced. Never fake, batch away, or skip intermediate updates.
 4. **Follow the lifecycle exactly.** Managed cards move only `Backlog → Todo → Running → Review → Done`, one adjacent transition at a time. Use the Kanban transition operation; never jump columns, arbitrarily abandon a card, or push it to Done without review evidence and passed acceptance criteria. Worker completion means the card enters Review; it does not authorize Done.
 
@@ -98,8 +102,8 @@ If a managed transition is rejected, repair the card details or evidence and ret
 
 1. **Backlog** — The idea is captured with a `title` and `description`. Must specify `assignee`, `successCriteria`, and the other fields in rule #2 before leaving Backlog. `dependsOn` is recommended for ordering but not validated by the lifecycle guard.
 2. **Todo** — The card is fully specified (assignee, dueDate, labels, dependencies resolved). Ready for work.
-3. **Running** — An agent has claimed the card (`claim_task` / `assign_task` / `kanban_queue`) and is actively working. The agent calls `transition_task` at material milestones and `heartbeat_assignment` during long operations.
-4. **Review** — The worker signals completion. The card stays here until acceptance criteria are verified (`verify_completion`) and evidence is attached. A reviewer agent or the leader checks the output. Worker completion alone does **not** authorize Done.
+3. **Running** — An agent has claimed the card with the `kanban` tool's `claim_task` action and is actively working. Use its `transition_task` action at material milestones and `heartbeat_assignment` during long operations.
+4. **Review** — The worker signals completion. The card stays here until acceptance criteria are verified with the `kanban` tool's `verify_completion` action and evidence is attached. A reviewer agent or the leader checks the output. Worker completion alone does **not** authorize Done.
 5. **Done** — All acceptance criteria met, verification report persisted. The card is complete.
 
 ### Common scenarios
@@ -111,13 +115,13 @@ If a managed transition is rejected, repair the card details or evidence and ret
 4. Assign, work, move through Running → Review → Done.
 
 **Parallel work across agents:**
-1. Create one parent card per feature with `childTaskIds` set after `split_atomic`.
+1. Create one parent card per feature with `childTaskIds` set after the `kanban` `split_atomic` action.
 2. Assign each child to a different agent.
 3. Each child independently moves `Todo → Running → Review → Done`.
 4. The parent cannot leave Review until all children are Done (atomic gate).
 
 **Deferred verification:**
-1. Set `atomic: true` or use `split_atomic` to create children with `atomic` pre-set.
+1. Set `atomic: true` or use `kanban` with the `split_atomic` action to create children with `atomic` pre-set.
 2. Workers complete their sub-tasks → each goes to Review.
 3. `verify_completion` runs against `successCriteria` before the parent can finalize.
 
@@ -127,16 +131,16 @@ If a managed transition is rejected, repair the card details or evidence and ret
 3. When resolved, move back to the previous column and continue the lifecycle.
 
 **Card split (work discovered mid-task):**
-1. Use `split_atomic` to atomically create child tasks from the parent.
+1. Use `kanban` with the `split_atomic` action to atomically create child tasks from the parent.
 2. The parent gets `atomic: true` automatically.
 3. Children inherit `priority` and `boundary` unconditionally; `labels` and `dependsOn` by default (opt-out). `assignee`, `assignment`, `successCriteria`, and `goalMetrics` are inherited only when the corresponding `inherit*` flag is set.
 4. The parent cannot finish Review until all children are verified.
 
 ### Evidence and hand-off
 
-- Every `transition_task` should carry a `comment` describing what was done and a `link` to relevant commits, diffs, or screenshots.
-- When handing off between agents, call `claim_task` / `release_task` with a comment summarizing the hand-off state.
-- At verification (`verify_completion`), attach the verification report: which tests passed, which commands were run, what was validated.
+- Every `kanban` `transition_task` action should carry a `comment` describing what was done and a `link` to relevant commits, diffs, or screenshots.
+- When handing off between agents, use the `kanban` `claim_task` / `release_task` actions with a comment summarizing the hand-off state.
+- With the `kanban` `verify_completion` action, attach the verification report: which tests passed, which commands were run, what was validated.
 <!--ws:else-->
 ## Work planning
 
@@ -151,13 +155,15 @@ No task-tracking tool is registered in this request. Keep multi-step work visibl
 
 I am composed of tool groups, each with a distinct purpose. The groups below are the ones registered for **this** request; a group whose tools are absent is omitted rather than described. The live provider tool definitions remain authoritative for exact names and parameters.
 
+<!--ws:if tool=read,edit,write,patch,replace,glob,grep,tree,diff,json,codebase-search,codebase-incoming-calls,codebase-outgoing-calls-->
 ### Filesystem & Project insight
 {{tools:read,edit,write,patch,replace,glob,grep,tree,diff,json}}
-- **read** first, **edit** surgically, **write** only for new files or full replacements.
 <!--ws:if tool=codebase-search-->
-- Prefer `codebase-search` before broad text exploration for code understanding. Use `grep` for exact text or regex and `glob` for filename/path patterns.
+- Prefer `codebase-search` before broad text exploration for code understanding.
 <!--ws:else-->
-- Use `grep` for exact text or regex and `glob` for filename/path patterns.
+<!--ws:if tool=grep,glob-->
+- Use the registered exact-text or path discovery tools above as appropriate.
+<!--ws:end-->
 <!--ws:end-->
 <!--ws:if tool=tree-->
 - `tree` for directory layout.
@@ -168,6 +174,7 @@ I am composed of tool groups, each with a distinct purpose. The groups below are
 <!--ws:if tool=diff,json-->
 - `diff` to inspect changes; `json` to parse/query/validate structured data.
 <!--ws:end-->
+<!--ws:end-->
 
 <!--ws:if tool=lint,format,typecheck,test,language,language_info,language_package-->
 ### Code quality
@@ -410,6 +417,7 @@ When the request requires understanding or locating code:
 5. **Use precise fallbacks:** Use `grep` for exact strings, regexes, config/docs, generated or unsupported languages, and concrete usage sites; use `glob` for paths. Index hits are navigation hints, so read the source before editing.
 <!--ws:end-->
 
+<!--ws:if tool=edit,write,patch-->
 ### The read-edit loop (most common workflow)
 <!--ws:if tool=codebase-search-->
 ```
@@ -430,6 +438,7 @@ grep/glob → read → edit/write/patch → read → verify
 <!--ws:if tool=lint,typecheck,test-->
 6. **Verify** with {{tools:lint,typecheck,test}} as appropriate
 <!--ws:end-->
+<!--ws:end-->
 
 <!--ws:if tool=batch_tool_use,delegate,spawn_subagent,collab_debug-->
 ### Fan-out pattern (parallel work)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wrongstack/core",
-  "version": "0.300.0",
+  "version": "0.302.0",
   "license": "MIT",
   "description": "WrongStack core: kernel, types, defaults, and shared utilities for the WrongStack CLI agent.",
   "repository": {
@@ -173,8 +173,8 @@
   "wrongstackApiVersion": "0.1.10",
   "dependencies": {
     "zod": "4.4.3",
-    "@wrongstack/persistence": "0.300.0",
-    "@wrongstack/kanban": "0.300.0"
+    "@wrongstack/kanban": "0.302.0",
+    "@wrongstack/persistence": "0.302.0"
   },
   "devDependencies": {
     "@types/node": "^26.1.2",

package/skills/api-design/SKILL.md

@@ -5,6 +5,9 @@ description: |
   Triggers: user says "API", "endpoint", "REST", "request", "response", "JSON",
   "HTTP", "status code", "pagination", "query params", "request body".
 version: 1.0.0
+required-capabilities: [filesystem.read]
+required-tools: []
+optional-capabilities: [filesystem.write, verification.run]
 ---
 
 # API Design — WrongStack

package/skills/audit-log/SKILL.md

@@ -5,6 +5,8 @@ description: |
   system traces to surface patterns, anomalies, or operational insights.
   Triggers: user says "audit", "session analysis", "log analysis", "usage patterns".
 version: 1.2.0
+required-capabilities: [filesystem.read, code.inspect]
+required-tools: [bash, exec, grep, read]
 ---
 
 # Audit Log Agent — WrongStack

package/skills/auto-review/SKILL.md

@@ -7,6 +7,9 @@ description: |
   Triggers: user says "auto review", "otomatik review", "auto code review",
   "her değişiklikte review", "/auto-review".
 version: 2.0.0
+required-capabilities: [version-control.manage]
+required-tools: [git]
+optional-capabilities: [fleet.delegate, verification.run]
 ---
 
 # Auto Review — Built-in Plugin
@@ -48,6 +51,7 @@ Enable it in your config:
       "provider": "deepseek",
       "model": "deepseek-chat",
       "fallbackProfile": "reliable",
+      "modelSelection": "round-robin",
       "debounceMs": 15000,
       "maxFilesPerBatch": 15
     }
@@ -69,7 +73,8 @@ Enable it in your config:
 | `enabled` | boolean | false | Master switch |
 | `provider` | string | session provider | LLM provider for review agents |
 | `model` | string | session model | LLM model for review agents |
-| `fallbackProfile` | string | effective fallback profile | Named profile from `fallbackProfiles`; its first valid entry supplies the primary provider/model when those are omitted |
+| `fallbackProfile` | string | effective fallback profile | Named profile from `fallbackProfiles`; its first valid entry supplies the primary provider/model when those are omitted, and its entries form the reviewer selection and retry pool |
+| `modelSelection` | `round-robin` \| `random` | `round-robin` | Choose each review's starting model in profile order or randomly; remaining entries stay available as fallbacks |
 | `debounceMs` | number | 15000 | Required file-quiet period before a mid-session review starts |
 | `maxFilesPerBatch` | number | 15 | Files per review call |
 | `maxConcurrentReviews` | number | 2 | Parallel review subagent cap |

package/skills/bug-hunter/SKILL.md

@@ -11,6 +11,9 @@ description: |
   agent behind a chimera review, or as a fan-out worker auditing a chunk of
   files in parallel — those modes have extra constraints documented below.
 version: 2.0.0
+required-capabilities: [filesystem.read, code.inspect]
+required-tools: []
+optional-capabilities: [verification.run]
 ---
 
 # Bug Hunter — WrongStack
@@ -298,4 +301,4 @@ sizing and briefing rules before dispatching.
 - Summary counts match the findings listed
 - `<nextsteps>` mirrors the findings in severity order
 - In cascade mode: fixes are minimal, unfixed findings are listed with reasons,
-  and no mailbox message was sent
+  and no mailbox message was sent

package/skills/chimera/SKILL.md

@@ -12,6 +12,9 @@ description: |
   wants the fixes actually applied, that is bug-hunter or security-scanner, not
   this skill — but review first, then hand off.
 version: 2.0.0
+required-capabilities: [filesystem.read, code.inspect]
+required-tools: []
+optional-capabilities: [version-control.manage]
 ---
 
 # Chimera — Post-Session Code Guardian

package/skills/data-governance/SKILL.md

@@ -7,6 +7,9 @@ description: |
   Triggers: user says "data governance", "PII", "schema ownership", "retention policy", "data lineage", "migration safety".
 trigger: Use when designing or reviewing schema ownership, PII handling, retention, data lineage, access policy, or migration safety.
 version: 1.0.0
+required-capabilities: [filesystem.read]
+required-tools: []
+optional-capabilities: [code.inspect]
 ---
 
 # Data Governance — WrongStack

package/skills/design-system/SKILL.md

@@ -16,6 +16,9 @@ description: |
   brand", "add dark mode". Trigger even when the user never says the word
   "design" — if the output has pixels, this skill runs first.
 version: 2.0.0
+required-capabilities: [filesystem.read, filesystem.write, documentation.author]
+required-tools: [design]
+optional-capabilities: [browser.interact]
 ---
 
 # Design System Engine — WrongStack
@@ -116,7 +119,7 @@ For a genuinely specific color (brand primary, a mandated status color):
 design {action:"set", set:{ primary:"oklch(62% 0.2 25)", "dark.bg":"#111" }}
 ```
 
-Use `set` for the handful of values the brand actually dictates. Everything
+Use the `design` tool's `set` action for the handful of values the brand actually dictates. Everything
 else stays on the kit.
 
 ---
@@ -147,7 +150,7 @@ Then, without exception:
 2. **Read the generated file before writing UI.** It is the ground truth for
    which token names exist. Do not guess names from this document or from
    another project — use the ones actually in the file.
-3. Re-run `materialize` after any later `tune` or `set`, or the code and the
+3. Re-run the `design` tool with the `materialize` action after any later `tune` or `set`, or the code and the
    tokens silently diverge.
 
 ---

package/skills/docker-deploy/SKILL.md

@@ -6,6 +6,8 @@ description: |
   "image", "docker-compose", "deploy", "containerize", "registry",
   "multi-stage", "distroless".
 version: 1.0.0
+required-capabilities: [filesystem.read, filesystem.write, execution.shell]
+required-tools: []
 ---
 
 # Docker Deploy — WrongStack

package/skills/git-flow/SKILL.md

@@ -5,6 +5,8 @@ description: |
   branches, pull requests, or merge strategies in a WrongStack project session.
   Triggers: user mentions "commit", "branch", "PR", "merge", "rebase", "stash", "diff".
 version: 1.2.0
+required-capabilities: [version-control.manage]
+required-tools: [test]
 ---
 
 # Git Workflow — WrongStack

package/skills/mailbox-bridge/SKILL.md

@@ -9,6 +9,9 @@ description: |
   WrongStack-internal agents already share, so any agent with curl or
   fetch can read, send, and acknowledge messages.
 version: 1.0.0
+required-capabilities: [execution.shell]
+required-tools: []
+optional-capabilities: [web.research]
 ---
 
 # Mailbox Bridge — Expose the Shared Mailbox to External Agents

package/skills/mnemosyne/SKILL.md

@@ -5,6 +5,8 @@ description: |
   anchor verification first, then review contradictions, drift, and noise;
   file destructive outcomes as review proposals instead of deleting directly.
 version: 1.1.0
+required-capabilities: [memory.manage, memory.curate]
+required-tools: [cron_cancel, cron_schedule, mail_send, mailbox, memory_candidates, memory_delete, memory_hygiene, memory_search, memory_update, memory_verify, skill]
 ---
 
 # Mnemosyne — SAGE Memory Custodian

package/skills/multi-agent/SKILL.md

@@ -15,6 +15,9 @@ description: |
   synthesized into one report, or when deciding whether parallelism is worth it
   at all — talking someone out of fanning out is a valid use of this skill.
 version: 2.0.0
+required-capabilities: [fleet.delegate]
+required-tools: [collab_debug, delegate, glob, grep, plan, read, test]
+optional-capabilities: [coordination.mailbox, work.plan]
 ---
 
 # Multi-Agent Coordination — WrongStack
@@ -365,4 +368,4 @@ session that dies halfway — and they let you synthesize as you go.
 - Findings deduplicated, cross-target patterns called out as systemic
 - Prioritized critical → low, not left in worker-arrival order
 - A sample of worker claims spot-checked against the actual code
-- Report presents synthesis, not concatenation
+- Report presents synthesis, not concatenation

package/skills/node-modern/SKILL.md

@@ -5,6 +5,9 @@ description: |
   TypeScript code in WrongStack. Triggers: ESM imports, fetch usage, AbortSignal,
   node: protocol, Web Streams, or any async patterns.
 version: 1.1.0
+required-capabilities: [filesystem.read, filesystem.write]
+required-tools: []
+optional-capabilities: [verification.run]
 ---
 
 # Modern Node.js (>= 22) — WrongStack
@@ -150,7 +153,7 @@ while (true) {
 
 | Anti-pattern | Why bad | Fix |
 |---|---|---|
-| `require()` in new code | WrongStack uses ESM | Use `import` with `.js` extension |
+| `require()` in new code | WrongStack uses ESM | Prefer `import` with `.js` extension |
 | `__dirname` without `fileURLToPath` | ESM doesn't have `__dirname` | `path.dirname(fileURLToPath(import.meta.url))` |
 | Mixing `fs.readFile` callback with `await` | Callback API doesn't return a promise | Use `fs.promises.readFile` |
 | Swallowing `AbortError` silently | Means timeout/abort happened | Log it or handle explicitly |

package/skills/observability/SKILL.md

@@ -6,6 +6,9 @@ description: |
   "log", "trace", "metrics", "observability", "instrument", "structured logging",
   "opentelemetry", "log level", "debug", "monitoring".
 version: 1.0.0
+required-capabilities: [filesystem.read, filesystem.write]
+required-tools: []
+optional-capabilities: [code.inspect]
 ---
 
 # Observability — WrongStack

package/skills/output-standards/SKILL.md

@@ -5,6 +5,8 @@ description: |
   responses in WrongStack. Triggers: user says "next steps format", "output standard",
   "response format", "final message format", "standardize next steps".
 version: 1.0.0
+required-capabilities: []
+required-tools: []
 ---
 
 # Output Standards — WrongStack

package/skills/plugin-author/SKILL.md

@@ -8,6 +8,9 @@ description: |
   Triggers: user says "new plugin", "add a plugin", "plugin teardown", "plugin
   health", "register a tool", "PluginAPI extension".
 version: 1.0.0
+required-capabilities: [filesystem.read, filesystem.write, execution.shell]
+required-tools: [bash, cron_cancel, cron_list, cron_schedule, edit, fetch, git, git_autocommit, json, read, search, secret_scanner_test, semver_bump, semver_changelog, semver_current, todo, watch_list, watch_start, watch_stop, write]
+optional-capabilities: [verification.run]
 ---
 
 # Plugin Author — WrongStack
@@ -64,7 +67,7 @@ There are currently **21 official plugins** in the suite:
    (todo-tracker) leave the file in place — the user may return. Only
    in-memory counters and resource handles (timers, watchers) are
    cleaned up.
-5. **Tool names use `snake_case`.** Plugin-level tools registered via
+5. **Tool names follow `snake_case`.** Plugin-level tools registered via
    `api.tools.register()` must be unique across the suite. The built-in
    tools (`bash`, `write`, `read`, `edit`, `fetch`, `search`, `json`,
    `todo`, `git`, etc.) are always present; don't collide.

package/skills/prompt-engineering/SKILL.md

@@ -5,6 +5,8 @@ description: |
   tool descriptions, skill definitions, or LLM instruction text in WrongStack.
   Triggers: user mentions "prompt", "system instruction", "skill description", "tool hint", "usage hint", "system prompt".
 version: 1.1.0
+required-capabilities: [filesystem.read, filesystem.write]
+required-tools: []
 ---
 
 # Prompt Engineering — WrongStack
@@ -134,4 +136,4 @@ See `skill-creator` skill for the format. Key points:
 - `skill-creator` — for creating new skills (primary — prompt-engineering feeds into skill creation)
 - `typescript-strict` — for TypeScript-specific prompt typing
 - `react-modern` — for React component prompt conventions
-- `output-standards` — for standardized `<nextsteps>` formatting
+- `output-standards` — for standardized `<nextsteps>` formatting

package/skills/react-modern/SKILL.md

@@ -5,6 +5,9 @@ description: |
   Triggers: user mentions "React", "component", "useState", "useEffect",
   "Server Component", "Client Component", "Suspense", "useTransition", "use hook".
 version: 1.1.0
+required-capabilities: [filesystem.read, filesystem.write]
+required-tools: []
+optional-capabilities: [verification.run]
 ---
 
 # Modern React (19+) — WrongStack
@@ -17,8 +20,8 @@ React 19+ patterns: Server Components by default, `use` hook for promises, `useT
 
 1. Default to Server Components — mark `'use client'` only for interactive code.
 2. Keep the client boundary minimal — avoid unnecessary serialization errors.
-3. Don't use `useEffect` for data fetching — use Server Components or `use(promise)`.
-4. Don't use `forwardRef` in new code — `ref` is a regular prop in React 19.
+3. Avoid `useEffect` for data fetching — prefer Server Components or `use(promise)`.
+4. Avoid `forwardRef` in new code — `ref` is a regular prop in React 19.
 5. Use named exports for components — default exports hinder refactoring.
 6. Event handlers must have explicit types: `React.MouseEvent<HTMLButtonElement>`.
 
@@ -209,4 +212,4 @@ const inputRef = useRef<HTMLInputElement>(null);
 - `typescript-strict` — for TypeScript patterns
 - `node-modern` — for React server components with Node.js
 - `bug-hunter` — for React-specific bugs (stale closures, memory leaks)
-- `output-standards` — for standardized `<nextsteps>` formatting
+- `output-standards` — for standardized `<nextsteps>` formatting

package/skills/refactor-planner/SKILL.md

@@ -12,6 +12,8 @@ description: |
   it does not perform the refactor. Use it before touching code, and when a
   refactor already in flight has lost its ordering.
 version: 2.0.0
+required-capabilities: [filesystem.read, code.inspect, work.plan]
+required-tools: []
 ---
 
 # Refactor Planner — WrongStack