@zhixuan92/multi-model-agent 4.3.1 → 4.4.0

package/dist/skills/mma-audit/SKILL.md

@@ -1,58 +1,45 @@
 ---
 name: mma-audit
 description: >-
-  Use when the user asks to audit a spec / plan / design doc / recommendation
-  doc / config. Four `auditType` modes pick the lens. `default`
-  (prose-coherence) is right for specs and requirements. `plan` (NEW 4.2.3+)
-  verifies a code-execution plan against the actual codebase — use this before
-  any `mma-execute-plan` dispatch. `security` / `performance` are narrow lenses
-  for threat models / scaling specs.
+  Use when the user asks to audit a spec / plan / design doc / skill file. The
+  `subtype` field picks the criteria set. `default` (prose-coherence) is the
+  general doc auditor. `plan` verifies a code-execution plan against the actual
+  codebase — run this before any `mma-execute-plan` dispatch. `spec` audits
+  requirement prose for testability and decision-trace. `skill` audits a
+  SKILL.md against reader-effectiveness criteria.
 when_to_use: >-
-  User asks for a doc/spec/plan/config audit OR a methodology skill
+  User asks for a doc / spec / plan / skill audit OR a methodology skill
   (superpowers:dispatching-parallel-agents, /security-review) points at one AND
   mmagent is running. Audit on PROSE/SPEC docs — use mma-review for source code.
-  Audit a CODE-EXECUTION PLAN against the codebase — use auditType=plan.
-version: 4.3.1
+  Audit a CODE-EXECUTION PLAN against the codebase — use subtype=plan.
+version: 4.4.0
 ---
 
 # mma-audit
 
 ## Overview
 
-`mma-audit` sends a prose artifact to workers for structured auditing — and (4.2.3+) can also audit a code-execution plan against a real codebase via `auditType: 'plan'`.
+`mma-audit` sends a prose artifact to workers for structured auditing. The `subtype` field picks WHICH criteria set the workers apply — every subtype runs through the same sequential-criteria read-only lifecycle, but each one carries its own criteria list, semantics, and prompt scaffolding.
 
-**Two distinct uses, picked by `auditType`:**
+**Four subtypes — picked by the kind of artifact, not by the lens you want:**
 
 | You're auditing… | Use… | What it checks |
 |---|---|---|
-| A spec, design doc, recommendation doc, post-mortem, or any **requirements / "what we want" prose** | `auditType: 'default'` | Prose-internal coherence — would a literal-following worker produce the right outcome from this prose alone? Catches ambiguity, contradictions, missing branches, drift, scope-creep. **Does NOT verify against any codebase.** |
-| A **code-execution PLAN** (`docs/superpowers/plans/*.md` or similar) before running it via `mma-execute-plan` | `auditType: 'plan'` (4.2.3+) | Plan-vs-codebase coherence — for every method / type / file path / signature / import / verify command the plan names, the codebase actually contains it as described. 8 verification perspectives running in parallel. Catches the bug class the prose-coherence audit cannot see (e.g. plan says `registerBlock` but actual interface is `register`). |
-| A threat model / auth spec | `auditType: 'security'` | Narrow security lens — only emits security findings. |
-| A scaling design / latency-sensitive spec | `auditType: 'performance'` | Narrow performance lens — only emits perf findings. |
+| A general prose artifact (design doc, recommendation, post-mortem, README) | `subtype: 'default'` | Comprehensive prose-coherence — would a literal-following worker produce the right outcome from this prose alone? Catches ambiguity, contradictions, missing branches, drift, scope-creep. **Does NOT verify against any codebase.** |
+| A **code-execution PLAN** (`docs/superpowers/plans/*.md` or similar) before running it via `mma-execute-plan` | `subtype: 'plan'` | Plan-vs-codebase coherence — for every method / type / file path / signature / import / verify command the plan names, the codebase actually contains it as described. Catches the bug class the prose-coherence audit cannot see (e.g. plan says `registerBlock` but actual interface is `register`). |
+| A **requirement spec** (what we want, why; success criteria) | `subtype: 'spec'` | Requirement-prose executability — every requirement testable, scope explicit, acceptance criteria covered, non-functional requirements captured, decision-trace exposed, conflicts surfaced. |
+| A **SKILL.md** for an `mma-*` skill or comparable agent-facing playbook | `subtype: 'skill'` | Skill-file reader-effectiveness — when-to-use specificity, endpoint contract integrity, example correctness, anti-pattern coverage, link integrity. |
 
-**Core principle (default mode):** One worker per file = no cross-file context pollution.
-**Core principle (plan mode):** One worker per verification perspective (8 in parallel) = each dimension grounds independently in the codebase.
+If you want to bias workers toward a narrow lens (security only, performance only, accessibility only), put that in the free-text `background` portion of the prompt — `subtype` is criteria machinery, not a lens selector.
 
 ## When to Use
 
-**Use `auditType: 'default'` when:**
-- A spec / design doc / recommendation doc / post-mortem needs a critical prose read
-- The artifact will subsequently be executed by a worker reading the prose alone
-- You want to know: "Is this prose internally executable?"
+- `subtype: 'default'` — a general prose artifact needs a critical read for internal executability (the artifact will be acted on by a worker reading the prose alone).
+- `subtype: 'plan'` — you have a written code-execution plan on disk and you're about to dispatch tasks from it via `mma-execute-plan`. This is the ONLY subtype that grounds findings against real source files.
+- `subtype: 'spec'` — you have a requirement / brainstorming-output spec and want to verify every requirement is testable, traceable, and unambiguous BEFORE writing the plan. Typical predecessor to `writing-plans`.
+- `subtype: 'skill'` — you're authoring or revising an `mma-*` skill or comparable SKILL.md and want to know whether agents will actually read it the right way.
 
-**Use `auditType: 'plan'` when:**
-- You have a written code-execution plan on disk and you're about to dispatch tasks from it via `mma-execute-plan`
-- You want to know: "Will this plan actually dispatch successfully against the codebase as it exists today?"
-- This is the ONLY audit mode that grounds findings against real source files
-
-**Don't use mma-audit when:**
-- The thing being audited is source code → `mma-review` (knows about types, call sites, test coverage)
-- You want a quick look ("does this look right?") → just `Read` and use your judgment
-- You need to verify a plan dispatches but you haven't written it yet → write the plan first, then run plan-audit on it
-
-## Endpoint
-
-`POST /audit?cwd=<abs-path>`
+**Don't use mma-audit when:** the thing being audited is source code (→ `mma-review`); a 30-second `Read` would answer it; or you want to verify a plan that hasn't been written yet (write the plan first).
 
 ## Endpoint
 
@@ -65,7 +52,7 @@ version: 4.3.1
 ```json
 {
   "document": "inline content to audit (optional if filePaths given)",
-  "auditType": "default",
+  "subtype": "default",
   "filePaths": ["/project/docs/spec.md"],
   "contextBlockIds": []
 }
@@ -74,7 +61,7 @@ version: 4.3.1
 | Field | Type | Required | Notes |
 |---|---|---|---|
 | `document` | string | no | Inline document content |
-| `auditType` | `'default' \| 'security' \| 'performance' \| 'plan'` | no (defaults to `'default'`) | See "Picking auditType" below. `default` for spec / requirement prose. `plan` (4.2.3+) for code-execution plans audited against the codebase. |
+| `subtype` | `'default' \| 'plan' \| 'spec' \| 'skill'` | no (defaults to `'default'`) | See "Picking subtype" below. |
 | `filePaths` | string[] | no | Files to audit (one worker per file, parallel) |
 | `contextBlockIds` | string[] | no | IDs from `mma-context-blocks` |
 
@@ -82,60 +69,78 @@ Either `document` or `filePaths` (or both) must be provided.
 
 > Worker tier for `mma-audit` is hardcoded to `complex` and is not caller-configurable. Sending `agentType` is rejected with HTTP 400.
 
-### Picking auditType
+### Picking subtype
 
 | Value | When to use |
 |---|---|
-| `default` (or omit the field) | **Spec / requirement / "what we want" prose.** Recommended for design docs, recommendation docs, post-mortems, audits, briefs, READMEs — any prose artifact where the question is "is this internally executable by reading the prose alone?". Does NOT verify against any codebase. |
-| `plan` (4.2.3+) | **Code-execution plans being audited against a real codebase.** Single-file input (the plan markdown). Workers grep / read source files under `cwd` to verify every named symbol / path / signature / import / verify command. Per-task verdicts: `EXECUTABLE` / `PARTIAL` / `BLOCKED`. Use this BEFORE every `mma-execute-plan` dispatch — catches the bug class where the plan names a method/file that doesn't actually exist (the prose-coherence audit cannot see this). |
-| `security` | Narrow opt-in. Use ONLY when you specifically want security findings and not general audit findings (e.g., a threat model where stylistic noise is unwanted). |
-| `performance` | Narrow opt-in. Use ONLY when you specifically want performance findings (e.g., a scaling design where you want hot-path / latency / unbounded-loop findings only). |
-
-**Plan vs Default — which to pick:** The artifact's NATURE decides:
-- **Spec / requirements** (what we want, why) → `default`. Reviewing the prose alone is the goal.
-- **Plan** (concrete tasks with code blocks, file paths, methods to call) → `plan`. The plan only matters if the codebase agrees with it.
+| `default` (or omit the field) | **General prose — design doc, recommendation, post-mortem, README, brief.** Comprehensive prose-coherence audit. Does NOT verify against any codebase. |
+| `plan` | **Code-execution plans being audited against a real codebase.** Single-file input (the plan markdown). Workers grep / read source files under `cwd` to verify every named symbol / path / signature / import / verify command. Use this BEFORE every `mma-execute-plan` dispatch. |
+| `spec` | **Requirement spec / brainstorming-output / what-we-want prose.** Criteria target testability, scope explicitness, acceptance-criteria coverage, decision-trace, assumption exposure. |
+| `skill` | **`SKILL.md` or comparable agent-facing playbook.** Criteria target when-to-use specificity, endpoint contract integrity, example correctness, anti-pattern coverage, link integrity. |
 
-You can run BOTH on a plan: first `default` (prose quality of the plan), then `plan` (does the plan match the codebase?). They cover orthogonal failure modes.
+You can run BOTH on a plan: first `spec` or `default` (prose quality), then `plan` (does the plan match the codebase?). They cover orthogonal failure modes.
 
-The legacy values `correctness`, `style`, and `general` no longer exist — they were a false dichotomy. Sending any of them returns `400 invalid_request` with a hint to use `default`.
+The legacy `auditType` field and its `correctness` / `style` / `general` / `security` / `performance` values no longer exist. Sending `auditType` returns `400 invalid_request`. Sending unknown `subtype` values returns `400 invalid_request` with the allowed enum.
 
 ### Plan-audit specifics
 
-When `auditType: 'plan'`:
+When `subtype: 'plan'`:
 
 - `filePaths` MUST contain exactly **one entry** — the plan markdown. Sending zero or 2+ entries → `400 invalid_request` with the message: *"Plan audit takes exactly one filePath (the plan markdown). The worker discovers and verifies source files itself via its tool surface — do not pre-list source files."*
 - `document` (inline content) is not used in plan mode — the plan must be on disk so workers can reference it by `?cwd=`-relative path.
-- 8 sub-workers run in parallel, one per verification perspective: PATH EXISTENCE, SYMBOL EXISTENCE, SIGNATURE MATCH, IMPORT GRAPH, TEST HARNESS AVAILABILITY, STEP SEQUENCE WITHIN TASK, CROSS-TASK DEPENDENCIES, VERIFICATION COMMAND VALIDITY. Each can return zero findings ("this dimension passes") or N findings.
-- The merge annotator computes a per-task verdict (`EXECUTABLE` / `PARTIAL` / `BLOCKED`) and a "Plan-Audit Summary" block at the end of the report.
-- Only DISPATCH tasks that audit as `EXECUTABLE`. Fix the plan and re-audit if any task is `BLOCKED` or `PARTIAL`.
+- The worker runs the sequential-criteria loop with the plan-audit criteria set: PATH EXISTENCE, SYMBOL EXISTENCE, SIGNATURE MATCH, IMPORT GRAPH, TEST HARNESS AVAILABILITY, STEP SEQUENCE WITHIN TASK, CROSS-TASK DEPENDENCIES, VERIFICATION COMMAND VALIDITY.
+- Read the findings list. Fix the plan and re-audit if any `critical` or `high` plan-audit findings remain.
 
 ## Full example
 
-### Default audit (spec / requirements prose)
+### Default audit (general prose)
 
 ```bash
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
-  -d '{"auditType":"default","filePaths":["/project/docs/api-spec.md"]}' \
+  -d '{"subtype":"default","filePaths":["/project/docs/api-spec.md"]}' \
   "http://localhost:$PORT/audit?cwd=/project")
 BATCH_ID=$(echo "$BATCH" | jq -r '.batchId')
 ```
 
-### Plan audit (4.2.3+ — verify a code-execution plan against the codebase)
+### Spec audit (requirement prose)
 
 ```bash
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
-  -d '{"auditType":"plan","filePaths":["/project/docs/superpowers/plans/2026-05-10-feature.md"]}' \
+  -d '{"subtype":"spec","filePaths":["/project/docs/superpowers/specs/2026-05-12-feature-design.md"]}' \
   "http://localhost:$PORT/audit?cwd=/project")
-BATCH_ID=$(echo "$BATCH" | jq -r '.batchId')
 ```
 
-The terminal envelope carries per-task findings + a "Plan-Audit Summary" block at the end of `structuredReport` showing how many tasks are `EXECUTABLE` / `PARTIAL` / `BLOCKED` and the lowest-numbered blocker.
+### Skill audit (SKILL.md)
+
+```bash
+BATCH=$(curl -f --show-error -s -X POST \
+  -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"subtype":"skill","filePaths":["/project/packages/server/src/skills/mma-audit/SKILL.md"]}' \
+  "http://localhost:$PORT/audit?cwd=/project")
+```
+
+### Plan audit (verify a code-execution plan against the codebase)
+
+```bash
+BATCH=$(curl -f --show-error -s -X POST \
+  -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"subtype":"plan","filePaths":["/project/docs/superpowers/plans/2026-05-10-feature.md"]}' \
+  "http://localhost:$PORT/audit?cwd=/project")
+```
 
 @include _shared/polling.md
 
@@ -185,7 +190,9 @@ This skill is one step in the larger flow described in `multi-model-agent` → "
 
 - **Recipe A — Audit-iterate-clean.** `mma-audit` → fix → `mma-audit` again. Sequential rounds. Register the doc via `mma-context-blocks` before round 1 and reuse the same ID across all rounds — avoids re-inlining the same content into every audit call.
 
-- **Recipe E — Plan-validate-execute (4.2.3+).** Before any `mma-execute-plan` batch, run `mma-audit` with `auditType: 'plan'` on the plan file. Read the "Plan-Audit Summary" block. If any task is `BLOCKED`, fix the plan; re-audit. Only dispatch tasks that audit as `EXECUTABLE`. Cost: comparable to a single `default` audit; saves the per-dispatch cost of workers re-discovering the same plan-vs-codebase drift. This catches the bug class where the plan's named methods/files don't actually exist in the codebase — symbols a prose-coherence audit cannot see.
+- **Recipe E — Plan-validate-execute.** Before any `mma-execute-plan` batch, run `mma-audit` with `subtype: 'plan'` on the plan file. Read the findings. If any `critical` / `high` finding survives, fix the plan and re-audit. This catches the bug class where the plan's named methods/files don't actually exist in the codebase — symbols a prose-coherence audit cannot see.
+
+- **Recipe F — Spec-then-plan-then-execute.** When working from a brainstorming spec: `mma-audit` (`subtype: 'spec'`) → fix → `writing-plans` → `mma-audit` (`subtype: 'plan'`) → fix → `mma-execute-plan`. Spec and plan audits catch orthogonal problem classes.
 
 Anti-pattern alert: **`parallel-rounds-same-target`** (AP1). Three parallel audits on the same document re-flag the same issues without seeing each other's fixes. Run rounds sequentially with a fix between each.
 
@@ -197,8 +204,8 @@ The auditor lacks codebase context (no type info, no call-site lookup, no test a
 ❌ **Single huge `document` string instead of `filePaths`**
 Inline docs lose the file boundary, so the per-file parallel split degenerates to one worker. **Fix:** save to disk first, pass `filePaths`.
 
-❌ **Sending legacy auditType values (`correctness`, `style`, `general`)**
-These were removed — they were a false dichotomy that biased workers toward stylistic proofreading on prose artifacts. **Fix:** use `default` (or omit the field). Use `security` or `performance` only when you specifically want a narrow lens.
+❌ **Sending the legacy `auditType` field**
+The field was renamed to `subtype` and the value set was narrowed. **Fix:** use `subtype` with one of `default` / `plan` / `spec` / `skill`. For "security only" / "performance only" lenses, put the bias in the free-text prompt — there is no narrow-lens subtype.
 
 ❌ **Re-auditing the same files round after round without delta context**
 Round 2 worker has no idea what round 1 found. **Fix:** register the round 1 findings as a context block (`mma-context-blocks`) and pass `contextBlockIds` to round 2.

package/dist/skills/mma-context-blocks/SKILL.md

@@ -10,9 +10,9 @@ when_to_use: >-
   A document (spec, plan, codebase summary, prior round's findings, error log)
   larger than ~2 KB will be referenced by two or more mma-* calls in a row.
   Register once here, then pass the ID via `contextBlockIds` on mma-delegate /
-  mma-execute-plan / mma-audit / mma-review / mma-verify / mma-debug /
-  mma-investigate. Cheaper and faster than inlining the same content N times.
-version: 4.3.1
+  mma-execute-plan / mma-audit / mma-review / mma-debug / mma-investigate.
+  Cheaper and faster than inlining the same content N times.
+version: 4.4.0
 ---
 
 # mma-context-blocks
@@ -78,6 +78,7 @@ Returns `200 { ok: true }` on success. Returns `409 pinned` if the block is held
 # Register spec document once
 ID=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d "{\"content\":$(jq -Rs . < /project/docs/spec.md)}" \
@@ -86,6 +87,7 @@ ID=$(curl -f --show-error -s -X POST \
 # Reference from N delegate tasks
 curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d "{\"tasks\":[

package/dist/skills/mma-debug/SKILL.md

@@ -10,7 +10,7 @@ when_to_use: >-
   read files, reproduce, trace — OR a methodology skill
   (superpowers:systematic-debugging) points at the investigation step. Delegate
   the read/reproduce/trace; the main agent stays on the hypothesis and the fix.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # mma-debug
@@ -47,6 +47,7 @@ Submit a problem, context, and hypothesis to a worker for focused debugging. Unl
   "problem": "POST /login returns 500 when password contains special characters",
   "context": "Regression introduced in commit abc123; only affects production config",
   "hypothesis": "The bcrypt binding fails on non-ASCII input in the Docker image",
+  "subtype": "default",
   "filePaths": [
     "/project/src/auth/login.ts",
     "/project/src/auth/password.ts"
@@ -60,6 +61,7 @@ Submit a problem, context, and hypothesis to a worker for focused debugging. Unl
 | `problem` | string | yes | What is broken (one sentence; concrete symptom) |
 | `context` | string | no | Background — what changed recently, what works, what doesn't |
 | `hypothesis` | string | no | Your initial theory; worker tests it first, then explores |
+| `subtype` | `'default'` | no (defaults to `'default'`) | Reserved for future criteria sets; only `default` is wired today. |
 | `filePaths` | string[] | no | All files investigated together (cross-file reasoning) |
 | `contextBlockIds` | string[] | no | IDs from `mma-context-blocks` (e.g. error logs, traces) |
 
@@ -70,6 +72,7 @@ Submit a problem, context, and hypothesis to a worker for focused debugging. Unl
 ```bash
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d '{"problem":"Tests fail on CI only","hypothesis":"Missing env var","filePaths":["/project/src/config.ts"]}' \
@@ -123,7 +126,7 @@ Every finding has the same shape:
 
 This skill is one step in the larger flow described in `multi-model-agent` → "Best practices". Recipes that involve `mma-debug`:
 
-- **Recipe B — Debug-fix-verify.** `mma-debug` → `mma-delegate` (apply fix) → `mma-verify`. Strict order. Register the failing test output / reproduction log as a context block before the debug call; reuse on verify.
+- **Recipe B — Debug-fix-review.** `mma-debug` → `mma-delegate` (apply fix) → `mma-review` with the acceptance criteria in the brief. Strict order. Register the failing test output / reproduction log as a context block before the debug call; reuse it on the review call.
 
 Anti-pattern alert: **`inline-labor-leakage`** (AP2). If you're about to read 3+ files in main context to "understand the bug," that's the labor we delegate — call `mma-debug` with the hypothesis instead.
 
@@ -152,8 +155,8 @@ Every completed task automatically registers a terminal markdown context block c
 
 **Use cases:**
 - Pass debug findings to a downstream `mma-delegate` fix step
-- Feed the root-cause analysis into `mma-verify` for acceptance checking
-- Carry debug context forward through the debug → fix → verify chain
+- Feed the root-cause analysis into a follow-up `mma-review` with acceptance criteria in the brief
+- Carry debug context forward through the debug → fix → review chain
 
 The block is registered server-side at task completion; no caller action is needed to create it. Delete it explicitly via `DELETE /context-blocks/:id` when no longer needed, or let it expire on session teardown.
 

package/dist/skills/mma-delegate/SKILL.md

@@ -11,7 +11,7 @@ when_to_use: >-
   and keep main context free. If a plan file exists → use mma-execute-plan. If
   the task is audit / review / verify / debug / investigate → use the matching
   specialized skill.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # mma-delegate
@@ -76,6 +76,7 @@ Dispatch one or more ad-hoc tasks to workers concurrently. Each task is an indep
 ```bash
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d '{"tasks":[{"prompt":"Refactor utils.ts to remove dead code","filePaths":["/project/src/utils.ts"]}]}' \
@@ -94,7 +95,7 @@ BATCH_ID=$(echo "$BATCH" | jq -r '.batchId')
 This skill is one step in the larger flow described in `multi-model-agent` → "Best practices". Recipes that involve `mma-delegate`:
 
 - **Recipe A (the fix step).** Between audit rounds, `mma-delegate` applies the fix when the change is more than 1-2 lines. Register the spec/audit findings as a context block; pass via `contextBlockIds`.
-- **Recipe B (the apply-fix step).** After `mma-debug` returns a hypothesis, `mma-delegate` applies the fix. Same context block carries forward to `mma-verify`.
+- **Recipe B (the apply-fix step).** After `mma-debug` returns a hypothesis, `mma-delegate` applies the fix. Same context block carries forward to a follow-up `mma-review` if you want acceptance-criteria checking.
 
 Anti-pattern alert: **`inline-labor-leakage`** (AP2). If you're reading 3+ files or grepping in main context before dispatching, you're paying flagship-model tokens for labor. Pass the file paths to `mma-delegate` and let the worker read.
 

package/dist/skills/mma-execute-plan/SKILL.md

@@ -10,7 +10,7 @@ when_to_use: >-
   superpowers:subagent-driven-development / superpowers:executing-plans —
   workers are cheaper and don't pollute main context. Task descriptors must
   match plan headings verbatim.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # mma-execute-plan
@@ -73,6 +73,7 @@ Dispatch named tasks from a plan file to workers. Each `taskDescriptors` string
 ```bash
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d '{"taskDescriptors":["3. Migrate database schema"],"filePaths":["/project/docs/plan.md"]}' \

package/dist/skills/mma-explore/SKILL.md

@@ -12,7 +12,7 @@ when_to_use: >-
   out mma-investigate (internal) + mma-research (external) in parallel and
   synthesise the results yourself. DO NOT use for convergent single-answer
   questions — those are mma-investigate.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # mma-explore

package/dist/skills/mma-investigate/SKILL.md

@@ -12,7 +12,7 @@ when_to_use: >-
   git-history queries. OR you are about to read 3+ files / run any grep in main
   context — that's the inline-labor-leakage anti-pattern (AP2); delegate to this
   skill instead.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # mma-investigate
@@ -67,6 +67,7 @@ digraph when_to_use {
 ```json
 {
   "question": "How does the auth middleware handle token refresh?",
+  "subtype": "default",
   "filePaths": ["/project/src/auth/"],
   "contextBlockIds": []
 }
@@ -75,6 +76,7 @@ digraph when_to_use {
 | Field | Type | Required | Notes |
 |---|---|---|---|
 | `question` | string | yes | Natural-language investigation question |
+| `subtype` | `'default'` | no (defaults to `'default'`) | Reserved for future criteria sets; only `default` is wired today. |
 | `filePaths` | string[] | no | Anchor paths the worker starts from. Worker may grep beyond. |
 | `contextBlockIds` | string[] | no | IDs from `mma-context-blocks` — enables follow-up / delta investigation |
 | `tools` | `'none' \| 'readonly'` | no | Default `'readonly'`. `'no-shell'` and `'full'` are rejected — investigation is read-only |
@@ -93,6 +95,7 @@ digraph when_to_use {
 ```bash
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d '{"question":"How does the auth middleware handle token refresh?"}' \

package/dist/skills/mma-research/SKILL.md

@@ -10,7 +10,7 @@ when_to_use: >-
   others do, what published methods exist) AND mmagent is running. Delegate the
   multi-source web/adapter research to a worker so the main context stays on
   judgment. NOT for codebase questions — those are mma-investigate.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # mma-research
@@ -53,6 +53,7 @@ mean and which directions to pursue.
 {
   "researchQuestion": "What approaches exist for streaming JSON parsing under 100KB?",
   "background": "We currently use a single-pass push parser; we want to evaluate alternatives.",
+  "subtype": "default",
   "contextBlockIds": []
 }
 ```
@@ -61,16 +62,20 @@ mean and which directions to pursue.
 |---|---|---|---|
 | `researchQuestion` | string | yes | 20–8000 chars |
 | `background` | string | yes | 20–8000 chars; what you already know / are trying to do |
+| `subtype` | `'default'` | no (defaults to `'default'`) | Reserved for future criteria sets; only `default` is wired today. |
 | `contextBlockIds` | string[] | no | IDs from `mma-context-blocks` |
 
 > Worker tier is hardcoded `complex`. Sending `agentType` or `tools` is rejected with HTTP 400.
 
+The `default` subtype's criteria target primary-source preference, practitioner consensus, recency, counter-perspectives, and cross-domain analogues — the worker is bibliographic, not opinionated.
+
 ## Full example
 
 ```bash
 BATCH=$(curl -f -sS -X POST \
   -H "Authorization: Bearer $TOKEN" \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Content-Type: application/json" \
   -d '{
     "researchQuestion": "State-of-the-art SIMD JSON parsers under 100KB?",

package/dist/skills/mma-retry/SKILL.md

@@ -6,11 +6,11 @@ description: >-
   re-dispatching the whole batch
 when_to_use: >-
   A previous mma-delegate / mma-execute-plan / mma-audit / mma-review /
-  mma-verify / mma-debug / mma-investigate batch returned partial results AND
-  you want to re-try the failed indices only. Prefer this over re-dispatching
-  the whole batch or inline-retrying — it's idempotent and preserves the
-  original batch's diagnostics.
-version: 4.3.1
+  mma-debug / mma-investigate batch returned partial results AND you want to
+  re-try the failed indices only. Prefer this over re-dispatching the whole
+  batch or inline-retrying — it's idempotent and preserves the original batch's
+  diagnostics.
+version: 4.4.0
 ---
 
 # mma-retry
@@ -78,6 +78,7 @@ To re-run all tasks: pass `[0, 1, ..., tasks.length - 1]`. (But consider: if all
 # Original batch had 4 tasks; re-run tasks at index 1 and 3
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d '{"batchId":"550e8400-e29b-41d4-a716-446655440000","taskIndices":[1,3]}' \

package/dist/skills/mma-review/SKILL.md

@@ -10,7 +10,7 @@ when_to_use: >-
   AND mmagent is running. Delegate so each file reviews on its own worker; the
   main agent only decides what to merge. Review on SOURCE CODE — use mma-audit
   for prose specs / configs.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # mma-review
@@ -55,6 +55,7 @@ The cross-file ripple pass (changed-symbol → broken caller) only fires when th
 {
   "code": "inline code snippet (optional if filePaths given)",
   "focus": ["correctness", "security"],
+  "subtype": "default",
   "filePaths": ["/project/src/auth/login.ts"],
   "contextBlockIds": []
 }
@@ -64,6 +65,7 @@ The cross-file ripple pass (changed-symbol → broken caller) only fires when th
 |---|---|---|---|
 | `code` | string | no | Inline code snippet to review |
 | `focus` | string[] | no | Any of `security`, `performance`, `correctness`, `style`. Omit for general review. |
+| `subtype` | `'default'` | no (defaults to `'default'`) | Reserved for future criteria sets; only `default` is wired today. |
 | `filePaths` | string[] | no | Files to review (one worker per file, parallel) |
 | `contextBlockIds` | string[] | no | IDs from `mma-context-blocks` — useful for design docs the reviewer should validate against |
 
@@ -76,6 +78,7 @@ Either `code` or `filePaths` (or both) must be provided.
 ```bash
 BATCH=$(curl -f --show-error -s -X POST \
   -H "X-MMA-Client: $MMA_CLIENT" \
+  -H "X-MMA-Main-Model: $MMA_MAIN_MODEL" \
   -H "Authorization: Bearer $TOKEN" \
   -H "Content-Type: application/json" \
   -d '{"focus":["security","correctness"],"filePaths":["/project/src/auth/login.ts"]}' \

package/dist/skills/multi-model-agent/SKILL.md

@@ -11,7 +11,7 @@ when_to_use: >-
   tasks — AND mmagent is running. Read this once, pick the matching mma-* skill,
   and delegate there. Applies equally whether the user invoked a superpowers
   methodology skill or asked directly.
-version: 4.3.1
+version: 4.4.0
 ---
 
 # multi-model-agent (router)
@@ -36,7 +36,6 @@ digraph picker {
     "mma-execute-plan" [shape=box];
     "mma-audit" [shape=box];
     "mma-review" [shape=box];
-    "mma-verify" [shape=box];
     "mma-debug" [shape=box];
     "mma-investigate" [shape=box];
     "mma-explore" [shape=box];
@@ -47,9 +46,7 @@ digraph picker {
     "Audit a doc?" -> "mma-audit" [label="yes"];
     "Audit a doc?" -> "Review code?" [label="no"];
     "Review code?" -> "mma-review" [label="yes"];
-    "Review code?" -> "Verify a checklist?" [label="no"];
-    "Verify a checklist?" -> "mma-verify" [label="yes"];
-    "Verify a checklist?" -> "Debug a failure?" [label="no"];
+    "Review code?" -> "Debug a failure?" [label="no"];
     "Debug a failure?" -> "mma-debug" [label="yes"];
     "Debug a failure?" -> "Codebase question?" [label="no"];
     "Codebase question?" -> "Convergent or divergent?" [label="yes"];
@@ -63,8 +60,7 @@ digraph picker {
 |---|---|
 | `mma-execute-plan` | Implement tasks from a plan or spec file (descriptors match plan headings) |
 | `mma-audit` | Audit a document/spec/config for security, correctness, style, or performance |
-| `mma-review` | Review code for quality, security, performance, correctness |
-| `mma-verify` | Verify work against a checklist (one item per worker, parallel) |
+| `mma-review` | Review code for quality, security, performance, correctness. Pass acceptance checklists in the brief if you need verification-style checks. |
 | `mma-debug` | Debug a failure with a structured hypothesis |
 | `mma-investigate` | Codebase Q&A — structured answer with `file:line` citations + confidence |
 | `mma-explore` | Divergent ideation from codebase + web research — use before `superpowers:brainstorming` |
@@ -107,9 +103,9 @@ Any artifact (spec, plan, prior-round findings, long error log) that crosses 2+
 
 `mma-audit` → read findings → fix (inline if 1-2 lines, else `mma-delegate`) → `mma-audit` again. Sequential rounds, NOT parallel re-audits. The fix produces new edges; round 2 catches what round 1 couldn't see. Register the doc as a context block before round 1; reuse the same ID across all rounds. The same shape applies to `mma-review` for source code (review → fix → re-review).
 
-### Recipe B — Debug-fix-verify
+### Recipe B — Debug-fix-review
 
-`mma-debug` (read/reproduce/trace) → `mma-delegate` (apply the fix the hypothesis implies) → `mma-verify` (acceptance criteria checked independently). Three skills, strict order. Register the failing test output / reproduction log as a context block before the debug call; reuse it on verify.
+`mma-debug` (read/reproduce/trace) → `mma-delegate` (apply the fix the hypothesis implies) → `mma-review` with the acceptance criteria included in the brief. Three skills, strict order. Register the failing test output / reproduction log as a context block before the debug call; reuse it on the review call so the reviewer can compare against the same evidence.
 
 ### Recipe C — Investigate-plan-execute
 
@@ -121,7 +117,7 @@ When `mma-execute-plan` returns mixed `done` / `done_with_concerns` / `failed`,
 
 ### Anti-patterns
 
-1. **`parallel-rounds-same-target`** — Caller fans out 3 parallel calls of the same skill on the same target — `mma-audit` on one document, `mma-review` on the same source file, or `mma-verify` of the same checklist. The reports overlap heavily; later rounds never see the fix from earlier rounds, so they re-flag the same issues. Corrective: sequential rounds with a fix between each (Recipe A for audit/review; for `mma-verify`, the analog is verify → fix → re-verify, never two verify calls on the unchanged checklist in parallel).
+1. **`parallel-rounds-same-target`** — Caller fans out 3 parallel calls of the same skill on the same target — `mma-audit` on one document, or `mma-review` on the same source file. The reports overlap heavily; later rounds never see the fix from earlier rounds, so they re-flag the same issues. Corrective: sequential rounds with a fix between each (Recipe A).
 
 2. **`inline-labor-leakage`** — Caller does 3+ `Read` calls, or any `grep`, in main context "just to understand the situation." Main tokens get burned on labor; the answer the caller actually needs is one paragraph of synthesis. Corrective: `mma-investigate` for codebase Q&A; if the goal is implementation, jump straight to `mma-delegate` with file paths and let the worker read.
 
@@ -168,7 +164,6 @@ Every other route hardcodes its tier and rejects `agentType` with HTTP 400:
 | `mma-audit` | `complex` |
 | `mma-review` | `complex` |
 | `mma-debug` | `complex` |
-| `mma-verify` | `complex` |
 | `mma-investigate` | `complex` |
 | `mma-explore` | `complex` (all three workers — internal, external, synthesizer) |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zhixuan92/multi-model-agent",
-  "version": "4.3.1",
+  "version": "4.4.0",
   "type": "module",
   "license": "MIT",
   "description": "Standalone HTTP server for multi-model-agent. Routes tool-invocation work to Claude, Codex, or OpenAI-compatible sub-agents with async-polling REST dispatch and installable skills for Claude Code, Gemini CLI, Codex CLI, and Cursor.",
@@ -53,7 +53,7 @@
   },
   "dependencies": {
     "@asteasolutions/zod-to-openapi": "^8.5.0",
-    "@zhixuan92/multi-model-agent-core": "^4.3.1",
+    "@zhixuan92/multi-model-agent-core": "^4.4.0",
     "gray-matter": "^4.0.3",
     "minimist": "^1.2.8",
     "proper-lockfile": "^4.1.2",

package/dist/http/handlers/tools/verify.d.ts

@@ -1,4 +0,0 @@
-import type { HandlerDeps } from '../../handler-deps.js';
-import type { RawHandler } from '../../types.js';
-export declare function buildVerifyHandler(deps: HandlerDeps): RawHandler;
-//# sourceMappingURL=verify.d.ts.map

package/dist/http/handlers/tools/verify.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"verify.d.ts","sourceRoot":"","sources":["../../../../src/http/handlers/tools/verify.ts"],"names":[],"mappings":"AAQA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,uBAAuB,CAAC;AAEzD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,gBAAgB,CAAC;AACjD,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,WAAW,GAAG,UAAU,CAkDhE"}