@massa-ai/cursor-plugin 1.61.0 → 1.62.0

package/skills/{to-prd → create-prd}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-description: "Turn the current conversation into a PRD. Use when the user asks to create, synthesize, or convert existing discussion and codebase context into a Product Requirements Document without another interview. Do NOT use for implementation plans, architecture design docs, RFCs, TDDs, or discovery interviews that require new product questioning. — explicit massa-ai 'to-prd' workflow"
+description: "Turn the current conversation into a PRD. Use when the user asks to create, synthesize, or convert existing discussion and codebase context into a Product Requirements Document without another interview. Do NOT use for implementation plans, architecture design docs, RFCs, TDDs, or discovery interviews that require new product questioning. — explicit massa-ai 'create-prd' workflow"
 argument-hint: "[task description]"
 ---
 <!-- massa-ai:generated workflow-command -->
 
-Explicit massa-ai workflow invocation: `to-prd`.
+Explicit massa-ai workflow invocation: `create-prd`.
 
 Load the massa-ai router skill if not already loaded (dedupe guard), then
-route to workflow `to-prd` under routing precedence 1 (explicit route) —
+route to workflow `create-prd` under routing precedence 1 (explicit route) —
 do not reclassify. Pass the following as the task description; if empty,
 the workflow's own intake gathers it.
 

package/skills/{rfc → create-rfc}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-description: "Use this workflow when a significant technical, process, product, vendor, tool, or policy decision is still open and stakeholders need a structured proposal before committing. — explicit massa-ai 'rfc' workflow"
+description: "Use this workflow when a significant technical, process, product, vendor, tool, or policy decision is still open and stakeholders need a structured proposal before committing. — explicit massa-ai 'create-rfc' workflow"
 argument-hint: "[task description]"
 ---
 <!-- massa-ai:generated workflow-command -->
 
-Explicit massa-ai workflow invocation: `rfc`.
+Explicit massa-ai workflow invocation: `create-rfc`.
 
 Load the massa-ai router skill if not already loaded (dedupe guard), then
-route to workflow `rfc` under routing precedence 1 (explicit route) —
+route to workflow `create-rfc` under routing precedence 1 (explicit route) —
 do not reclassify. Pass the following as the task description; if empty,
 the workflow's own intake gathers it.
 

package/skills/{tdd → create-tdd}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-description: "Use this workflow to write a Technical Design Document once one product direction is selected and no unresolved API, data, security, or rollout decision blocks implementation. — explicit massa-ai 'tdd' workflow"
+description: "Use this workflow to write a Technical Design Document once one product direction is selected and no unresolved API, data, security, or rollout decision blocks implementation. — explicit massa-ai 'create-tdd' workflow"
 argument-hint: "[task description]"
 ---
 <!-- massa-ai:generated workflow-command -->
 
-Explicit massa-ai workflow invocation: `tdd`.
+Explicit massa-ai workflow invocation: `create-tdd`.
 
 Load the massa-ai router skill if not already loaded (dedupe guard), then
-route to workflow `tdd` under routing precedence 1 (explicit route) —
+route to workflow `create-tdd` under routing precedence 1 (explicit route) —
 do not reclassify. Pass the following as the task description; if empty,
 the workflow's own intake gathers it.
 

package/skills/{ticket → create-ticket}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-description: "Use this workflow to draft, review, create, or resume creation of Jira Epics, issues, or sub-tasks through Atlassian MCP, the only tracker and mutation path. — explicit massa-ai 'ticket' workflow"
+description: "Use this workflow to draft, review, create, or resume creation of Jira Epics, issues, or sub-tasks through Atlassian MCP, the only tracker and mutation path. — explicit massa-ai 'create-ticket' workflow"
 argument-hint: "[task description]"
 ---
 <!-- massa-ai:generated workflow-command -->
 
-Explicit massa-ai workflow invocation: `ticket`.
+Explicit massa-ai workflow invocation: `create-ticket`.
 
 Load the massa-ai router skill if not already loaded (dedupe guard), then
-route to workflow `ticket` under routing precedence 1 (explicit route) —
+route to workflow `create-ticket` under routing precedence 1 (explicit route) —
 do not reclassify. Pass the following as the task description; if empty,
 the workflow's own intake gathers it.
 

package/skills/massa-ai/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: massa-ai
-description: Default memory-backed workflow router for every coding, planning-before-coding, debugging, code review, refactoring, or implementation conversation. Always load it once per new coding session, select specialized workflows first, and use the general fallback otherwise. Handles massa-ai recall/search, durable memory, context compaction, handoff, audits, specs, ADR/RFC/TDD, and evidence gates. Do NOT use for generic non-coding chat or bulk-loading every workflow/reference.
+description: Default memory-backed workflow router for every coding, planning-before-coding, debugging, code review, refactoring, or implementation conversation. Always load it once per new coding session, select specialized workflows first, and work under the Core Contract without a workflow file otherwise. Handles massa-ai recall/search, durable memory, context compaction, handoff, audits, specs, ADR/RFC/TDD, and evidence gates. Do NOT use for generic non-coding chat or bulk-loading every workflow/reference.
 license: MIT
 metadata:
   author: Luiz Massa
@@ -35,6 +35,9 @@ Before reading any massa-ai file:
 
 - Every coding/planning task uses one stable `projectId` and
   `workflowSessionId`.
+- Sub-agents are dispatched by bare charter name (`builder`, `code-reviewer`, ...).
+  On the Claude plugin route, dispatch the plugin-namespaced `massa-ai:<name>`
+  so a same-named user or project agent cannot intercept the dispatch.
 - Start with `recall` for relevant prior decisions/patterns.
 - Default startup/context recall is budgeted: use `limit <= 3`,
   `minImportance >= 0.7`, and `types=["critical","decision","pattern"]`
@@ -113,7 +116,7 @@ Examples:
 - `feature-user-onboarding`
 - `refactor-auth-module`
 - `spec-billing-workflow`
-- `adr-postgres-migration`
+- `create-adr-postgres-migration`
 
 Resolve `projectId`:
 
@@ -143,9 +146,6 @@ current context already contains it.
 | `security-fix` | fix security audit report findings | `workflows/security/security-fix.md` |
 | `requirements-audit` | requirements/spec/acceptance/scope alignment findings | `workflows/requirements/requirements-audit.md` |
 | `requirements-fix` | fix requirements audit report findings | `workflows/requirements/requirements-fix.md` |
-| `maestro` | implement new Maestro mobile E2E flows | `workflows/maestro/maestro.md` |
-| `maestro-audit` | run and audit existing Maestro mobile E2E flows | `workflows/maestro/maestro-audit.md` |
-| `maestro-fix` | child-only fix for saved Maestro audit findings | `workflows/maestro/maestro-fix.md` |
 | `tests-audit` | test coverage/regression/assertion/flakiness findings | `workflows/tests/tests-audit.md` |
 | `tests-fix` | fix tests audit report findings | `workflows/tests/tests-fix.md` |
 | `bugs-audit` | findings-only bug discovery | `workflows/bugs/bugs-audit.md` |
@@ -159,34 +159,33 @@ current context already contains it.
 | `mobile-figma-audit` | compare an Android, iOS, or KMP UI implementation with a Figma design | `workflows/mobile-figma/mobile-figma-audit.md` |
 | `mobile-figma-fix` | fix saved mobile Figma findings | `workflows/mobile-figma/mobile-figma-fix.md` |
 | `refactor` | behavior-preserving structural cleanup | `workflows/refactor.md` |
-| `adr` | record a finalized decision | `workflows/adr.md` |
-| `rfc` | propose a significant change | `workflows/rfc.md` |
-| `tdd` | technical design / implementation plan | `workflows/tdd.md` |
-| `ticket` | draft and create Jira Epics, issues, and sub-tasks through Atlassian MCP | `workflows/ticket.md` |
+| `create-adr` | record a finalized decision | `workflows/create-adr.md` |
+| `create-rfc` | propose a significant change | `workflows/create-rfc.md` |
+| `create-tdd` | technical design / implementation plan | `workflows/create-tdd.md` |
+| `create-ticket` | draft and create Jira Epics, issues, and sub-tasks through Atlassian MCP | `workflows/create-ticket.md` |
 | `commit` | draft or create safe Conventional Commits with Jira branch prefixes and audit report exclusions | `workflows/commit.md` |
 | `the-fool` | direct challenge, red-team, pre-mortem, evidence audit | `workflows/the-fool.md` |
 | `judge-with-debate` | standalone multi-judge debate evaluation of user-supplied artifacts | `workflows/judge-with-debate.md` |
 | `pr-review` | review a hosted GitHub PR / GitLab MR and post findings via `gh`/`glab` | `workflows/pr-review.md` |
-| `discovery` | product brainstorming / problem-space thinking partner | `workflows/discovery.md` |
-| `to-prd` | turn the current conversation into a PRD without a new interview | `workflows/to-prd.md` |
+| `product-discovery` | product brainstorming / problem-space thinking partner | `workflows/product-discovery.md` |
+| `create-prd` | turn the current conversation into a PRD without a new interview | `workflows/create-prd.md` |
 | `skill-architect` | design and build a new skill through structured conversation | `workflows/skill-architect.md` |
 | `furps-refinement` | FURPS+ refinement of a PRD and/or ADR before implementation, with The Fool pre-validation and DoR coverage | `workflows/refinement/furps-refinement.md` |
-| `general` | coding work with no more specific workflow | `workflows/general.md` |
 
 Explicitly requested workflows win. Otherwise choose the most specific matching
 workflow. Use `exploration` only for explicitly read-only understanding or flow
-mapping; route to `general` when no route's precedence key above matches. Ask
+mapping; when no route's precedence key above matches, load no workflow file. Ask
 the user only when two or more routes match the same precedence tier; a single
 match or no match is resolved deterministically without asking.
 
 Deterministic routing precedence, first match wins:
 
 1. **Explicit route:** user names a massa-ai workflow, report family, saved finding type, or asks for a direct challenge.
-2. **Requested artifact:** ADR, RFC, TDD, Jira ticket, commit, session guide, audit report, implementation audit report, mobile Figma report, FURPS refinement report, PRD synthesized from the current conversation -> `to-prd` (explicit request only; refining an existing PRD stays `furps-refinement`), or new SKILL.md / skill design -> `skill-architect`.
-3. **Target type:** broken behavior/error -> `debug`; hosted PR/MR reference (number or URL) to review with posted findings -> `pr-review` (local working diff stays with audit routes); saved audit finding -> matching `*-fix`; implementation scope review -> `implementation-audit`; Maestro E2E/device automation target -> `maestro`, `maestro-audit`, or child-only `maestro-fix` before generic tests workflows; security/privacy/auth finding -> security workflow; tests/flakes/coverage finding -> tests workflow; supplied Figma/screenshot mobile UI design -> `design`; mobile Figma compare/audit -> `mobile-figma-audit`; saved `MFM-*` findings -> `mobile-figma-fix`.
-4. **Primary verb:** create/add/implement -> `feature` unless the concrete target is new Maestro flow work, which routes to `maestro`; restructure without behavior change -> `refactor`; inspect/understand only -> `exploration`; brainstorm/explore a product problem, idea, or direction with no concrete code target -> `discovery`; record selected decision -> `adr`; compare open options -> `rfc`; design settled implementation -> `tdd`; refine/quality-check an existing PRD or ADR document (not implementation auditing) -> `furps-refinement`.
+2. **Requested artifact:** ADR, RFC, TDD, Jira ticket, commit, session guide, audit report, implementation audit report, mobile Figma report, FURPS refinement report, PRD synthesized from the current conversation -> `create-prd` (explicit request only; refining an existing PRD stays `furps-refinement`), or new SKILL.md / skill design -> `skill-architect`.
+3. **Target type:** broken behavior/error -> `debug`; hosted PR/MR reference (number or URL) to review with posted findings -> `pr-review` (local working diff stays with audit routes); saved audit finding -> matching `*-fix`; implementation scope review -> `implementation-audit`; security/privacy/auth finding -> security workflow; tests/flakes/coverage finding -> tests workflow; supplied Figma/screenshot mobile UI design -> `design`; mobile Figma compare/audit -> `mobile-figma-audit`; saved `MFM-*` findings -> `mobile-figma-fix`.
+4. **Primary verb:** create/add/implement -> `feature`; restructure without behavior change -> `refactor`; inspect/understand only -> `exploration`; brainstorm/explore a product problem, idea, or direction with no concrete code target -> `product-discovery`; record selected decision -> `create-adr`; compare open options -> `create-rfc`; design settled implementation -> `create-tdd`; refine/quality-check an existing PRD or ADR document (not implementation auditing) -> `furps-refinement`.
 5. **Risk domain escalation:** migrations, irreversible operations, auth/privacy, cross-service contracts, public compatibility, or work over 10 files routes to `spec-driven` unless the user explicitly requests a narrower workflow and accepts the containment.
-6. **General fallback:** use `general` only after a one-line General fallback preflight names the specialized workflow considered, rejected reason, and why fallback does not change verification or mutation behavior.
+6. **No match:** proceed without loading a workflow file. The main agent works under the Core Contract above (recall, verify, Evidence Gate) and states in one line which specialized workflow it considered and why none applies.
 
 Mobile is a context modifier, not a workflow. Route by primary intent first.
 Load `references/mobile-context.md` for non-debug mobile work, or
@@ -199,8 +198,8 @@ Read and apply the canonical Plan Challenge Policy from the installed
 `AGENTS.md` bootstrap block (single source: `skills/AGENTS.md`). Prompt-level
 user instructions override that policy for the current turn.
 
-For a low-risk plan that receives the lite gate, attempt a read-only
-`massa-ai-plan-critic` subagent with a bounded checklist packet instead of
+For a low-risk plan that receives the lite gate, attempt a
+`judge` subagent in `plan-critique` mode (it writes nothing in that mode) with a bounded checklist packet instead of
 running the checklist in the main agent. The packet includes the proposed plan, scope,
 constraints, compact recalled facts/evidence, known risks, verification recipe,
 parent identifiers, and this output requirement:
@@ -214,19 +213,19 @@ Lite preserves progressive disclosure: do not load The Fool mode references
 unless the lite critique escalates to full.
 
 Low-risk `feature` and `refactor` plans receive the lite gate first. Full The
-Fool stays for `spec-driven`, `design`, `adr`, `rfc`, `tdd`, explicit challenge
+Fool stays for `spec-driven`, `design`, `create-adr`, `create-rfc`, `create-tdd`, explicit challenge
 requests, high-risk domains, or plans touching more than 5 files/classes/modules.
 When the policy selects the full gate, or lite escalates, load
 `workflows/the-fool.md`, select the mode in the main agent, load only the
-selected The Fool references, and attempt a read-only `massa-ai-plan-critic`
-subagent with selected mode context and a bounded critique packet. Subagents inherit
+selected The Fool references, and attempt a `judge` subagent in `plan-critique` mode with the selected mode passed as `fool_mode`
+and a bounded critique packet. Subagents inherit
 `projectId`, parent `workflowSessionId`, workflow name, entity, and compact
 evidence; they do not receive full conversation context.
 
 If the policy file is unavailable, use the conservative fallback: run the full
 gate for high-risk domains, broad multi-module plans, explicit challenge
 requests, and planning workflows that commit to a feature, refactor, ADR, RFC,
-or TDD. If the `massa-ai-plan-critic` agent is unavailable for any reason —
+or TDD. If the `judge` agent is unavailable for any reason —
 spawning forbidden, plugin not installed, unknown `subagent_type` — run a strict
 standalone fresh-eyes local critique against the same output contract and report
 the skipped delegation reason. Do not retry under a different agent name. Reuse
@@ -282,7 +281,7 @@ Load only when a selected workflow asks for them:
 - `references/agent-orchestration.md`
 - `references/subagent-design.md`
 - `references/code-reuse-scan.md`
-- `references/adr-authoring.md`
+- `references/create-adr.md`
 - `references/audit-scope.md`
 - `references/audit-report-io.md`
 - `references/hook-enforcement.md`
@@ -311,12 +310,10 @@ Load only when a selected workflow asks for them:
 - `references/repo-rules-discovery.md`
 - `references/root-cause-scripts.md`
 - `references/conversation-feedback.md`
-- `references/maestro.md`
-- `references/maestro/`
 - `references/synapse-policy.md`
-- `references/tdd/`
-- `references/rfc/`
-- `references/ticket/`
+- `references/create-tdd/`
+- `references/create-rfc/`
+- `references/create-ticket/`
 - `references/spec-driven/`
 - `references/furps/`
 

package/skills/massa-ai/references/agent-orchestration.md

@@ -75,19 +75,19 @@ Keep local when any are true:
 
 ## Plan Challenge Exception
 
-Plan Challenge `plan-critic` is a standing policy exception to the normal dispatch triggers after a concrete plan exists. Always attempt a read-only `massa-ai-plan-critic` for both `depth: lite` and `depth: full` when subagent tooling is available and platform policy permits spawning. Normal base requirements still matter for packet quality: the critique must be bounded, read-only, and concrete, but it does not need to satisfy the ordinary dispatch triggers such as file count, module count, or explicit user delegation.
+The Plan Challenge `judge` dispatch in `plan-critique` mode is a standing policy exception to the normal dispatch triggers after a concrete plan exists. Always attempt it for both `depth: lite` and `depth: full` when subagent tooling is available and platform policy permits spawning. Normal base requirements still matter for packet quality: the critique must be bounded, write nothing, and be concrete, but it does not need to satisfy the ordinary dispatch triggers such as file count, module count, or explicit user delegation.
 
 For all other roles, preserve the normal delegation gates above.
 
 ## Independent Verification Exception (fix workflows + Standard+ light-workflow tiers)
 
-The Independent Verification Mandate in `references/verification-ladder.md` is a second standing policy exception, parallel to the Plan Challenge one: when a `*-fix` workflow closes a finding, or a light workflow (`debug`, `feature`, `general`, `refactor`) completes Standard+ work, always attempt the `massa-ai-verification-agent` dispatch when subagent tooling is available and platform policy permits spawning — it does not need to satisfy the ordinary dispatch triggers (file count, module count, explicit user delegation). Base packet-quality requirements still apply, and the mandate's own tier gates, security-fix unconditional rule, and fresh-eyes fallback live in that ladder section, not here.
+The Independent Verification Mandate in `references/verification-ladder.md` is a second standing policy exception, parallel to the Plan Challenge one: when a `*-fix` workflow closes a finding, or a light workflow (`debug`, `feature`, `refactor`) completes Standard+ work, always attempt the `code-reviewer` dispatch in `verify` mode when subagent tooling is available and platform policy permits spawning — it does not need to satisfy the ordinary dispatch triggers (file count, module count, explicit user delegation). Base packet-quality requirements still apply, and the mandate's own tier gates, security-fix unconditional rule, and fresh-eyes fallback live in that ladder section, not here.
 
 ## Screen Implementation Exception (any workflow that can produce a screen)
 
-A third standing policy exception, parallel to the two above: **when a task creates or modifies a user-facing screen, always attempt the `massa-ai-designer` dispatch** while subagent tooling is available and platform policy permits spawning. Once that condition holds the dispatch is not subject to the ordinary dispatch triggers — not file count, not module count, not explicit user delegation.
+A third standing policy exception, parallel to the two above: **when a task creates or modifies a user-facing screen, always attempt the `designer` dispatch** while subagent tooling is available and platform policy permits spawning. Once that condition holds the dispatch is not subject to the ordinary dispatch triggers — not file count, not module count, not explicit user delegation.
 
-The condition is the whole gate. On a task with no screen surface the dispatch does not fire at all, which is why the seven dispatching workflows can carry it without firing it on every task. "Creates or modifies a user-facing screen" means a change to a screen, view, page, component, layout, style, theme, or design-token file, or any change whose acceptance criteria describe what a user sees.
+The condition is the whole gate. On a task with no screen surface the dispatch does not fire at all, which is why the dispatching workflows can carry it without firing it on every task. The `design`, `mobile-figma-audit`, and `mobile-figma-fix` workflows dispatch it unconditionally, because every task there is screen work. "Creates or modifies a user-facing screen" means a change to a screen, view, page, component, layout, style, theme, or design-token file, or any change whose acceptance criteria describe what a user sees.
 
 Two shape rules follow from the roles involved:
 
@@ -98,16 +98,25 @@ Base packet-quality requirements still apply, and the no-agent fallback below ap
 
 ## Name Resolution
 
-Charters live at `skills/agents/<role>/SKILL.md`. Hosts register every charter
-under the prefixed name `massa-ai-<role>` (Claude, Codex, Cursor, OpenCode all
-use that prefix; `scripts/generate-subagent-artifacts.ts` emits it).
-
-- **Dispatch under the prefixed host name**, never the bare role name. A bare
-  `subagent_type` does not resolve on any supported host.
-- The bare role name is the registry key: use it in memory tags, capability
-  packets, and prose.
-- Every dispatch block in a workflow carries the prefixed name inline so
-  dispatch never depends on this file being loaded.
+Charters live at `skills/agents/<role>/SKILL.md`. Every host registers each
+charter under its bare role name (`scripts/generate-subagent-artifacts.ts` emits
+`<role>.md` / `<role>.toml` with `name: <role>`). Installers tell massa-ai's
+agent files apart from a user's by the `massa-ai-owned` content marker, never
+by name, and never overwrite a same-named agent the user owns.
+
+- **Claude plugin route: dispatch `massa-ai:<role>`.** Plugin agents live in the
+  plugin namespace (the agent list shows them as `massa-ai:<role>`), so the
+  qualified name reaches massa-ai's agent even when the user or the project
+  defines an agent with the same bare name. The always-loaded router states this
+  rule, so dispatch never depends on this file being loaded.
+- **Claude file route, Codex, Cursor, OpenCode: dispatch the bare `<role>`.**
+  These hosts have no agent namespace. Accepted risk: when an installer skipped
+  a same-named agent the user owns (it warns at install time), that user agent
+  receives the dispatch.
+- Dispatch blocks and prose name the bare role; it is also the registry key in
+  memory tags and capability packets.
+- The pre-rename `massa-ai-<role>` names are retired: installers prune them on
+  upgrade, and no workflow dispatches them.
 
 If the named agent is unavailable for any reason — not registered, plugin not
 installed, spawning forbidden by platform policy, or the host returns an unknown
@@ -118,10 +127,10 @@ delegation with its reason in the Evidence Gate.
 ## Model Diversity Fallback
 
 Applies to any charter whose dispatching workflow requests per-invocation model diversity
-at dispatch time (e.g. `judge` — 3 parallel slots; `meta-judge` — one slot).
+at dispatch time (e.g. `judge` in `scorer` mode — 3 parallel slots; `judge` in `spec-author` mode — one slot).
 
-- Read-only agents (judge, meta-judge, audit-specialist, navigator, and others) carry no
-  per-agent model override in the profile and resolve to the profile's per-tool default.
+- Agents without a per-agent model override in the built-in profiles (`code-explorer`,
+  `code-reviewer`, `judge`, `product-manager`) resolve to the profile's per-tool default.
   By convention, the default is the profile's strongest model.
 - The dispatching workflow (e.g. `workflows/judge-with-debate.md`) is the single source
   for the current slot/model assignment, not the charter file.
@@ -138,7 +147,7 @@ Before adding a new reusable role, load `references/subagent-design.md` and writ
 
 **The roster lives in one place: the Agent Table of `skills/AGENTS.md`**, which names
 every shipped specialist with its purpose, trigger, permission, and charter path. Do not
-restate it here. A second roster in this file is what let `judge` and `meta-judge` go
+restate it here. A second roster in this file is what once let the two debate-panel charters go
 undocumented for a whole release with every gate green — the guard checked that the
 charter paths *mentioned* here resolve, which a charter that is never mentioned cannot
 fail.
@@ -149,22 +158,22 @@ resolves to a current agent.
 
 | Legacy role | Current agent | Note |
 |---|---|---|
-| `implementer` | `massa-ai-builder` | renamed |
-| `verifier` | `massa-ai-verification-agent` | renamed; also centralizes the Verification Ladder |
-| `domain-mapper` | `massa-ai-architecture-specialist` | folded in; `lens: domain` |
-| `coupling-auditor` | `massa-ai-architecture-specialist` | folded in; `lens: coupling` |
-| `deepening-architect` | `massa-ai-architecture-specialist` | folded in; `lens: deepening` |
+| `implementer` | `builder` | renamed |
+| `verifier` | `code-reviewer` | folded in; `mode: verify`, which centralizes the Verification Ladder |
+| `domain-mapper` | `code-reviewer` | folded in; `mode: audit`, `lens: architecture`, `sub-mode: domain` (packet field defined in the `code-reviewer` charter Inputs) |
+| `coupling-auditor` | `code-reviewer` | folded in; `mode: audit`, `lens: architecture`, `sub-mode: coupling` |
+| `deepening-architect` | `code-reviewer` | folded in; `mode: audit`, `lens: architecture`, `sub-mode: deepening` |
 
-`investigator`, `plan-critic` and `furps-analyst` kept their own names; every other
-specialist is new and never had a legacy one. Workflows dispatch the current
-`massa-ai-<role>` name through a named dispatch block — the legacy column is traceability
-only, never a dispatch target.
+The charter names retired by the roster consolidation map to current agents in the
+single old→new table of `skills/AGENTS.md`; this file does not repeat it. Workflows
+dispatch the current `<role>` name through a named dispatch block — the legacy column
+is traceability only, never a dispatch target.
 
 ## Capability Packet
 
-**This section is the sole canonical Capability Packet definition.** `references/subagent-design.md` mirrors this list and the root `skills/AGENTS.md` registry points here without restating it. Bespoke packets (judge panel, FURPS analyst, phase-batch worker) are declared specializations that map onto these fields in their own workflow files.
+**This section is the sole canonical Capability Packet definition.** `references/subagent-design.md` mirrors this list and the root `skills/AGENTS.md` registry points here without restating it. Bespoke packets (judge panel, `product-manager` FURPS dispatch, phase-batch worker) are declared specializations that map onto these fields in their own workflow files.
 
-**A subagent inherits nothing from the parent session** — no skills, no personas, no loaded references, no conversation history. Everything the subagent needs is named explicitly in the packet, including the exact reference file paths it must read itself.
+**A subagent inherits nothing from the parent session** — no skills, no loaded references, no conversation history. Everything the subagent needs is named explicitly in the packet, including the exact reference file paths it must read itself.
 
 When dispatching a subagent, send a compact capability packet rather than a loose instruction. Include:
 
@@ -178,11 +187,11 @@ When dispatching a subagent, send a compact capability packet rather than a loos
 - `output`: the exact output contract
 - `firewall`: raw logs, diffs, snapshots, reports, or research that must be summarized
 - `memory`: whether the subagent may suggest memories and who persists them
-- `persona`: optional. The active route's cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt. Omit the field when no persona is routed.
 - `next_use`: what the main agent will do with the result
-- `lens`: conditional — `audit-specialist` dispatches only. One of `bugs | architecture | security | requirements | code-quality | performance`.
+- `mode`: conditional — for a charter that declares modes (`code-explorer`, `code-reviewer`, `designer`, `judge`, `product-manager`, `test-engineer`), the `Mode:` section of the charter this dispatch runs.
+- `lens`: conditional — `code-reviewer` `audit` dispatches only. One of `bugs | architecture | security | code-quality | performance`; the requirements lens is `product-manager` `audit` mode and the tests lens is `test-engineer` `audit` mode.
 
-The named dispatch block that workflows embed (the quoted block whose header carries the prefixed agent name and role) is the block projection of this packet: `role` and `purpose` live in the block's header line, and `next_use` defaults to "the main agent synthesizes and continues the workflow" when absent. The remaining eight fields — `trigger, scope, permissions, inputs, sensors, output, firewall, memory` — appear as the block's body lines, except where Role Defaults below already fix a field's value.
+The named dispatch block that workflows embed (the quoted block whose header carries the agent name, role, and mode) is the block projection of this packet: `role`, `mode`, and `purpose` live in the block's header line, and `next_use` defaults to "the main agent synthesizes and continues the workflow" when absent. The remaining eight fields — `trigger, scope, permissions, inputs, sensors, output, firewall, memory` — appear as the block's body lines, except where Role Defaults below already fix a field's value.
 
 ### Role Defaults
 
@@ -196,24 +205,19 @@ Reading a workflow's dispatch block therefore means reading this section beside
 it. That is the trade: the block stops being self-contained in exchange for
 having exactly one place a shared value can be wrong.
 
-**Every role, every dispatch**
+**`code-reviewer`** (every mode)
 
-- `persona` — as defined in the Capability Packet list above. It is never written
-  in a dispatch block; it applies to all of them.
+- `permissions`: read-only
 
-**`massa-ai-reviewer`**
+**`code-reviewer`, `mode: review`**
 
 - `fallback`: if the subagent is unavailable, run a standalone fresh-eyes review against this output contract and record the skipped-delegation reason
 
-**`massa-ai-verification-agent`**
-
-- `permissions`: read-only
-
-**`massa-ai-designer`** — its dispatch is mandatory-on-condition, so its trigger is
+**`designer`** — its dispatch is mandatory-on-condition, so its trigger is
 fixed here rather than per workflow; a block that reworded it would silently make
 the dispatch advisory in that one file.
 
-- `trigger`: the task creates or modifies a user-facing screen — mandatory once that condition holds, per the Screen Implementation Exception in `references/agent-orchestration.md`; it does not fire when no screen surface is touched
+- `trigger`: the task creates or modifies a user-facing screen — mandatory once that condition holds, per the Screen Implementation Exception in `references/agent-orchestration.md`; it does not fire when no screen surface is touched, and the `design`, `mobile-figma-audit`, and `mobile-figma-fix` workflows dispatch it unconditionally
 - `sensors`: Figma MCP read when a design source exists; per-element expected-vs-actual comparison; the UI module's own build/lint; the states a design under-specifies — empty, loading, error, long text, small and large sizes
 - `inputs`: exact `projectId`, parent `workflowSessionId`, Figma links/node ids or screenshots when supplied, acceptance criteria, the repository's existing UI conventions and design tokens, recalled screen patterns
 - `firewall`: summarized design-source evidence and `path:line` pointers only, never raw Figma node dumps or full file bodies
@@ -283,16 +287,16 @@ Example:
 
 ### Model/Effort Announcement
 
-Every dispatch of any of the 18 massa-ai roster specialists names the agent, its model,
+Every dispatch of any of the 7 massa-ai roster specialists names the agent, its model,
 and its effort in the `Agent Started` line above, inside that line's existing 1-2 line
 budget. No exemption: this covers the three standing dispatch exceptions
-(`plan-critic`, `verification-agent`, `designer`) and spec-driven batch workers exactly
+(`judge` in `plan-critique` mode, `code-reviewer` in `verify` mode, `designer`) and spec-driven batch workers exactly
 like every other dispatch.
 
 - **Source**: the *installed* agent file for the active host — never
   `skills/model-profiles.json`. The installed file reports what the host will actually
   load, including any local profile-switch overlay the registry cannot see.
-- **Read once per session**, for all 18 agents, and cache the result — not once per
+- **Read once per session**, for all 7 agents, and cache the result — not once per
   dispatch.
 - Absent `effort` in the installed file announces `effort: inherit`. Absent `model`, or
   `model: inherit`, announces `model: inherit`.
@@ -300,33 +304,33 @@ like every other dispatch.
   exact attempted path, and the dispatch proceeds — the read never blocks a dispatch.
 
 ```md
-🤖 [Agent Started] Investigator — model opus, effort high. Scope: the four emitters.
+🤖 [Agent Started] Code-explorer — model opus, effort high. Scope: the four emitters.
 🤖 [Agent Started] Designer — model/effort unknown (no installed agent file at
-   <liveRoot>/agents/massa-ai-designer.md). Dispatching anyway.
+   <liveRoot>/agents/designer.md). Dispatching anyway.
 ```
 
 That second line is a measured case, not a hypothetical: on a machine with plugin
-bundle `1.48.0` installed, `massa-ai-designer.md` is absent because `designer` shipped
+bundle `1.48.0` installed, `designer.md` is absent because `designer` shipped
 in `1.50.0` — a live instance of the degraded path above.
 
 Per-host installed-agent path, matching `resolveHostLayout` in
 `packages/shared/src/profile-switch/hosts.ts` — a sensor executes that resolver against
 this table so the two cannot drift silently:
 
-| Host | Installed agents directory | Glob | Model / effort keys |
+| Host | Installed agents directory | Owned files | Model / effort keys |
 | --- | --- | --- | --- |
-| Claude — marketplace route | `<marketplaceRoot>/agents`, where `<marketplaceRoot>` is `resolveClaudeMarketplaceInstall`'s live root: for a **directory-source** marketplace the host loads the plugin LIVE from the source bundle — e.g. `<repo>/apps/claude-plugin/agents`; for any other kind it is the *versioned* cache snapshot, e.g. `~/.claude/plugins/cache/massa-ai/massa-ai/1.48.0/agents` (a stale-able snapshot — never hardcode it; read `profile_list`'s `liveRoot`) | `massa-ai-*.md` | `model:` / `effort:` |
-| Claude — file route | `~/.claude/agents` | `massa-ai-*.md` | `model:` / `effort:` |
-| Codex | `~/.codex/agents` | `massa-ai-*.toml` | `model` / `model_reasoning_effort` |
-| OpenCode | `~/.config/opencode/agents` | `massa-ai-*.md` | `model:` / `reasoningEffort:` |
+| Claude — marketplace route | `<marketplaceRoot>/agents`, where `<marketplaceRoot>` is `resolveClaudeMarketplaceInstall`'s live root: for a **directory-source** marketplace the host loads the plugin LIVE from the source bundle — e.g. `<repo>/apps/claude-plugin/agents`; for any other kind it is the *versioned* cache snapshot, e.g. `~/.claude/plugins/cache/massa-ai/massa-ai/1.48.0/agents` (a stale-able snapshot — never hardcode it; read `profile_list`'s `liveRoot`) | `*.md` whose first body line is `<!-- massa-ai-owned: true -->` | `model:` / `effort:` |
+| Claude — file route | `~/.claude/agents` | `*.md` whose first body line is `<!-- massa-ai-owned: true -->` | `model:` / `effort:` |
+| Codex | `~/.codex/agents` | `*.toml` whose first line is `# massa-ai-owned` | `model` / `model_reasoning_effort` |
+| OpenCode | `~/.config/opencode/agents` | `*.md` symlinks into the massa-ai bundle | `model:` / `reasoningEffort:` |
 | Cursor | no lookup — `resolveHostLayout` returns route `skip` | — | announce `model: inherit, effort: inherit` for every agent; Cursor publishes no resolvable model IDs |
 
 Claude's active route (`marketplace` vs `file`) comes from `install-state.json`'s
 per-platform `installRoute` field, never guessed from directory presence.
 
-## Plan-Critic Contract
+## Plan-Critique Contract
 
-Dispatch `massa-ai-plan-critic` only after a concrete plan exists. Dispatch it with the capability packet above and the standard output contract. The subagent receives the plan, scope, constraints, compact recalled facts/evidence, selected depth, selected The Fool mode only for full gates, known risks, verification recipe, parent identifiers, and context-firewall limits. It never receives full conversation context.
+Dispatch `judge` with `mode: plan-critique` only after a concrete plan exists. Dispatch it with the capability packet above and the standard output contract. The subagent receives the plan, scope, constraints, compact recalled facts/evidence, selected depth, `fool_mode` (the selected The Fool mode: `pre_mortem`, `red_team`, `evidence_audit`, `socratic`, or `dialectic`; distinct from the packet `mode`, which stays `plan-critique`) only for full gates, known risks, verification recipe, parent identifiers, and context-firewall limits. It never receives full conversation context.
 
 For `depth: lite`, the packet uses the low-risk checklist and does not include The Fool mode references. It returns:
 
@@ -337,9 +341,9 @@ For `depth: lite`, the packet uses the low-risk checklist and does not include T
 - `escalate_to_full: true|false`
 - escalation reason
 
-For `depth: full`, or after lite escalation, the main agent selects the mode, loads the relevant The Fool references, and dispatches a full packet. It returns:
+For `depth: full`, or after lite escalation, the main agent selects the The Fool mode, loads the relevant The Fool references, and dispatches a full packet carrying it as `fool_mode`. It returns:
 
-- selected mode
+- selected `fool_mode`
 - steelmanned thesis
 - 3-5 strongest challenges
 - severity: `critical`, `high`, `medium`, or `low`
@@ -357,7 +361,7 @@ whose single source is `skills/AGENTS.md` in the product repo.
 
 - Main agent persists durable conclusions after synthesis.
 - Subagents may suggest memory content but should not create broad project memories unless explicitly assigned.
-- Use tags such as `agent:verifier` or `agent:domain-mapper` only when they improve retrieval.
+- Use tags such as `agent:code-reviewer` or `agent:code-explorer` only when they improve retrieval.
 - Do not persist one-off subagent chatter.
 
 ## Synapse Isolation