@massa-ai/codex-plugin 1.60.1 → 1.62.0

package/skills/massa-ai/workflows/{discovery.md → product-discovery.md}

@@ -1,6 +1,6 @@
 ---
-name: discovery
-description: "Product discovery and brainstorming workflow — act as a sharp product thinking partner to explore problem spaces, generate and stress-test ideas, and spar on strategy before anything is spec-ready, ending with a mandatory offer to synthesize the conversation into a PRD via the to-prd workflow. Use when the user wants to brainstorm a product problem, idea, opportunity, or direction with no concrete code target. Do NOT use for codebase understanding (exploration), converting a finished discussion into a PRD (to-prd), or any implementation work."
+name: product-discovery
+description: "Product discovery and brainstorming workflow — act as a sharp product thinking partner to explore problem spaces, generate and stress-test ideas, and spar on strategy before anything is spec-ready, ending with a mandatory offer to synthesize the conversation into a PRD via the create-prd workflow. Use when the user wants to brainstorm a product problem, idea, opportunity, or direction with no concrete code target. Do NOT use for codebase understanding (exploration), converting a finished discussion into a PRD (create-prd), or any implementation work."
 license: Apache-2.0
 metadata:
   version: "1.0.0"
@@ -10,7 +10,7 @@ metadata:
 
 Attribution: adapted from the `product-brainstorming` skill in
 `anthropics/knowledge-work-plugins` (Apache-2.0). massa-ai session/memory
-binding, router integration, and the to-prd handoff are additions.
+binding, router integration, and the create-prd handoff are additions.
 
 Act as a sharp product thinking partner — the experienced PM (Product
 Manager) or design lead who challenges assumptions, asks hard questions, and
@@ -22,7 +22,7 @@ have reached alone.
 This is a read-only conversation workflow: it never mutates the repository
 and writes no `.specs/` artifacts. Its only outputs are the conversation
 itself, durable memories at Capture, and — on explicit acceptance — a routed
-handoff to `to-prd`.
+handoff to `create-prd`.
 
 Load `references/project-context.md` (intake sweep) before the first
 substantive read when the conversation touches an existing product or
@@ -30,7 +30,7 @@ codebase; product context grounds the brainstorm in what exists today.
 
 ## Session And Memory
 
-- `workflowSessionId`: `discovery-<entity>` (e.g., `discovery-onboarding-dropoff`),
+- `workflowSessionId`: `product-discovery-<entity>` (e.g., `product-discovery-onboarding-dropoff`),
   stable for the whole conversation.
 - Start with a budgeted `recall` (limit ≤ 3, minImportance ≥ 0.7, types
   `critical`/`decision`/`pattern`): prior product decisions, rejected
@@ -121,25 +121,25 @@ name the stage transition when it helps the user follow.
 At Capture, persist the durable subset via `remember`: chosen directions
 with their why and rejected directions with reasons as `decision`, reusable
 framings or cross-session insights as `pattern` — tagged
-`project:<projectId>`, `session:discovery-<entity>`, `workflow:discovery`,
+`project:<projectId>`, `session:product-discovery-<entity>`, `workflow:product-discovery`,
 `entity:<name>`, and a memory-tier tag. Persist only what transcends the
 session; never fabricate memories to satisfy process. If the server is
 unavailable, the capture summary in conversation is the record.
 
-## PRD Handoff (to-prd)
+## PRD Handoff (create-prd)
 
 End every Capture with an explicit offer — this step is mandatory, the PRD
 is not:
 
 > "Want me to turn this into a PRD (Product Requirements Document)? I'd
-> synthesize this conversation through the `to-prd` workflow — no new
+> synthesize this conversation through the `create-prd` workflow — no new
 > interview."
 
-- **Accepted** → route to `workflows/to-prd.md`. The user's acceptance is
-  the explicit request `to-prd`'s routing requires. Carry the current
+- **Accepted** → route to `workflows/create-prd.md`. The user's acceptance is
+  the explicit request `create-prd`'s routing requires. Carry the current
   conversation context — Capture's output (chosen directions, assumptions,
   set-asides) feeds the PRD's problem statement, decisions, and out-of-scope
-  sections directly; `to-prd` does not re-interview.
+  sections directly; `create-prd` does not re-interview.
 - **Declined** → the capture summary stays in conversation and the durable
   memories from Capture remain the only persistence. Offer nothing else.
 
@@ -200,5 +200,5 @@ Discovery completes at Capture plus the PRD offer. Before claiming the
 session complete, apply `references/evidence-gate.md`: the evidence here is
 the capture summary (ideas, assumptions, next steps, set-asides), the memory
 outcome (what was persisted or why persistence was skipped), and the
-recorded PRD-offer disposition (accepted → to-prd, declined, or
+recorded PRD-offer disposition (accepted → create-prd, declined, or
 not-PRD-shaped with the named research gap).

package/skills/massa-ai/workflows/refactor.md

@@ -61,23 +61,22 @@ Before the first repository mutation, load `references/implementation-delivery.m
    - Before PR creation, run `bun skills/massa-ai/scripts/check_specs_delivered.ts <slug> --kind refactor` (`--kind quick` for Quick-sized work) — a non-zero exit blocks Propose. If no code-execution tool is available, run the same checks by reading the artifact (graceful degradation preserved).
 10. Include file-integrity checks when tests, specs, benchmarks, fixtures, or snapshots are validation assets. If verification found a reusable signal (`ac_gap`, `surviving_mutant`, `spec_precision_gap`, `spec_deviation`, `gate_fail`), record it via `references/lessons.md`:
      `bun skills/massa-ai/scripts/lessons.ts --root . add --feature "<slug>" --signal "<signal>" --source "<ref>" --text "<one terse lesson>"`
-11. Use `references/agent-orchestration.md` for isolated implementation slices; the verification-agent dispatch below is not discretionary at Standard+ sizing or PR-group execution — that reference's Independent Verification Exception makes it a standing requirement, not a per-task judgment call.
+11. Use `references/agent-orchestration.md` for isolated implementation slices; the `code-reviewer` `verify` dispatch below is not discretionary at Standard+ sizing or PR-group execution — that reference's Independent Verification Exception makes it a standing requirement, not a per-task judgment call.
 12. At completion, persist (run the scoring rubric from `references/decision-engine.md`):
    - Refactored architectural decisions via `remember` as scored `decision` memories
    - Identified and decoupled anti-patterns via `remember` as scored `pattern` memories
 
-> **Dispatch: `massa-ai-reviewer`** (role: `reviewer`) — charter `skills/agents/reviewer/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `review`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: implementation complete, before the verification gate — never optional
 > - scope: the change's diff surface and its task/AC context
-> - permissions: read-only
 > - inputs: diff, acceptance context, recalled code-quality conventions
 > - sensors: bugs, regressions, missing edge cases, smells introduced by the diff
 > - output: ranked findings, blocking vs advisory; blocking findings become fix items before verification runs
 > - firewall: summarized findings only, never raw diff dumps
 > - memory: suggest-only; main agent persists
 
-> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
-> - trigger: Standard+ refactor sizing or any PR-group execution per the Independent Verification Mandate in `references/verification-ladder.md` — mandatory once reviewer fix items are resolved; Quick-sized refactors dispatch only when validation assets were touched, otherwise run the fresh-eyes fallback below and record the skip reason
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `verify`) — charter `skills/agents/code-reviewer/SKILL.md`
+> - trigger: Standard+ refactor sizing or any PR-group execution per the Independent Verification Mandate in `references/verification-ladder.md` — mandatory once `code-reviewer` review fix items are resolved; Quick-sized refactors dispatch only when validation assets were touched, otherwise run the fresh-eyes fallback below and record the skip reason
 > - scope: the moved/transformed code across this refactor's PR groups and the characterization tests that must protect it
 > - inputs: the characterization baseline from step 6 (and step 7 for mobile refactors), the diff of moved code per PR group, and the PR-group map from step 9
 > - sensors: confirm the characterization tests still pass against the moved code's preserved behavior; discrimination sensor per `references/discrimination-sensor.md` (mutate the moved code — never new code — in scratch, one PR group at a time; characterization tests must kill each mutant)

package/skills/massa-ai/workflows/refinement/furps-refinement.md

@@ -12,7 +12,7 @@ Findings-only refinement of a Product Requirements Document (PRD) and/or Archite
 
 Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-Not for authoring a new PRD (use `to-prd` or `spec-driven` Specify), authoring an ADR (use `adr`), proposing change (use `rfc`), auditing implementation against requirements (use `requirements-audit`), or auditing code/security/architecture. It refines the document itself; it does not edit code.
+Not for authoring a new PRD (use `create-prd` or `spec-driven` Specify), authoring an ADR (use `create-adr`), proposing change (use `create-rfc`), auditing implementation against requirements (use `requirements-audit`), or auditing code/security/architecture. It refines the document itself; it does not edit code.
 
 Findings-only: do not edit the PRD/ADR unless the user separately asks.
 
@@ -21,7 +21,7 @@ Findings-only: do not edit the PRD/ADR unless the user separately asks.
    - `references/furps/intake.md` before intake and sub-agent dispatch
    - `references/furps/checklist.md` for the per-dimension check items
    - `references/furps/report-contract.md` before writing the report
-   - `references/furps/analyst-role.md` and `skills/agents/furps-analyst/SKILL.md` before dispatching `massa-ai-furps-analyst`
+   - `references/furps/analyst-role.md` and `skills/agents/product-manager/SKILL.md` before dispatching `product-manager` in `furps` mode
    - `references/agent-orchestration.md` and `references/context-firewall.md` before dispatch
    - `references/audit-report-io.md` before writing the final report
    - `references/synapse-policy.md` when repeated massa-ai searches are expected
@@ -33,17 +33,17 @@ Findings-only: do not edit the PRD/ADR unless the user separately asks.
    - If the source is missing or ambiguous, ask once before proceeding.
 4. The Fool pre-validation (sub-agents, one per mode):
    - Load `workflows/the-fool.md`. Treat the PRD/ADR as the challenged thesis (direct challenge; inherit `projectId`/`workflowSessionId`).
-   - Dispatch a read-only `massa-ai-plan-critic` sub-agent in `evidence_audit` mode with the document packet, DoR, and recalled facts.
-   - Then dispatch a `massa-ai-plan-critic` sub-agent in `pre_mortem` mode, passing the `evidence_audit` summary as input.
+   - Dispatch a `judge` sub-agent in `plan-critique` mode (full depth, `fool_mode: evidence_audit`; it writes nothing) with the document packet, DoR, and recalled facts.
+   - Then dispatch a `judge` sub-agent in `plan-critique` mode (full depth, `fool_mode: pre_mortem`), passing the `evidence_audit` summary as input.
    - Collect the compact validation: source-confidence gaps, unsourceable claims, and execution-phase failure assumptions.
    - Gate: if `evidence_audit` surfaces critical gaps that block meaningful FURPS analysis, ask the user whether to proceed-with-caveats or pause for document completion. Otherwise attach the Fool summary to the FURPS packets.
 5. FURPS+ dimension analysis (sub-agents, one per dimension, parallel):
-   - Dispatch six `massa-ai-furps-analyst` sub-agents: F, U, R, P, S, X (X = FURPS+ Extensions).
+   - Dispatch six `product-manager` sub-agents in `furps` mode: F, U, R, P, S, X (X = FURPS+ Extensions).
    - Each receives its `checklist.md` section, the bounded document packet, the DoR, and the Fool summary.
    - Each returns per check-item status (`covered|partial|missing|unclear`), `FR-<letter>-<N>` findings, and contributions to Open Questions / Suggestions / Insights / Risks / DoR-gaps.
    - Dispatch the six dimensions in waves of at most 4 concurrent analysts (e.g. 4 then 2), per the wave cap in `references/agent-orchestration.md` (Orchestrator Working Memory). Dimension analyses are order-independent, so wave order does not matter. Each gets its own ephemeral Synapse session only if it performs >=2 searches.
 
-> **Dispatch: `massa-ai-furps-analyst`** (role: `furps-analyst`) — charter `skills/agents/furps-analyst/SKILL.md` — 6 dispatches, one per dimension, waves of ≤4
+> **Dispatch: `product-manager`** (role: `product-manager`, mode: `furps`) — charter `skills/agents/product-manager/SKILL.md` — 6 dispatches, one per dimension, waves of ≤4
 > - trigger: furps-refinement step 5; one analyst per FURPS+ dimension (F, U, R, P, S, X)
 > - scope: exactly one dimension's `checklist.md` section against the bounded document packet
 > - permissions: read-only
@@ -84,7 +84,7 @@ User asks: "Refine this PRD against FURPS before we start building."
 1. `workflowSessionId=furps-refinement-<entity>`.
 2. Ingest the PRD file; resolve DoR from a linked Confluence page via Atlassian MCP.
 3. Run The Fool (`evidence_audit` then `pre_mortem`); proceed (no critical blocker).
-4. Fan out six `massa-ai-furps-analyst` sub-agents (F, U, R, P, S, X) in parallel.
+4. Fan out six `product-manager` sub-agents in `furps` mode (F, U, R, P, S, X) in parallel.
 5. Synthesize; write `audits/refinement/<date> furps-refinement.md`; summarize in chat.
 
 User asks: "Run a FURPS+ analysis on ADR-007."

package/skills/massa-ai/workflows/requirements/requirements-audit.md

@@ -30,9 +30,9 @@ Findings-only: do not edit code unless the user separately asks for fixes.
    - Requirements source scope: use provided prompt text, PR description, issue text, task file, spec, RFC, ADR, acceptance criteria, or README section as the expected behavior source.
    - If requirements source is missing after checking the prompt, PR description, task file, spec, issue text, and repo docs, ask for the requirements source before proceeding.
 5. Resolve the selected branch's mechanics (modified files, commit range, codebase area, explicit-files/branch/symbol/feature/whole-repo, or implementation parent scope) per `references/audit-scope.md` (Lens Audit Scope Resolution Procedure, Requirements row of Per-Lens Scope Deltas). Implementation parent scope additionally carries the requirement source from `implementation-audit`.
-6. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
+6. Investigation pass. Dispatch `product-manager` (`audit` mode) per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
 
-> **Dispatch: `massa-ai-audit-specialist`** (role: `audit-specialist`) — charter `skills/agents/audit-specialist/SKILL.md`
+> **Dispatch: `product-manager`** (role: `product-manager`, mode: `audit`) — charter `skills/agents/product-manager/SKILL.md`
 > - trigger: large scope, explicit parallel/subagent request, PR subagent invocation, or independent verification of high-impact finding
 > - scope: the requirements audit target — files, contracts, specs, acceptance criteria
 > - permissions: read-only

package/skills/massa-ai/workflows/requirements/requirements-fix.md

@@ -64,9 +64,9 @@ Not for findings-only requirements review — route to `workflows/requirements/r
    - Preserve non-goals and explicit constraints.
    - `references/knowledge-verification-chain.md`'s Step 5 settles technical facts only (library/API behavior), never product intent; a product decision gap still stops here regardless of how the chain resolved.
    - If a finding exposes a product decision gap, stop and ask rather than inventing policy.
-10. Use agent orchestration only when it improves signal, with one carve-out: the verification-agent dispatch below is mandatory at its tier gate rather than discretionary, per `references/agent-orchestration.md`'s Independent Verification Exception. Dispatch per `references/agent-orchestration.md`:
+10. Use agent orchestration only when it improves signal, with one carve-out: the `code-reviewer` `verify` dispatch below is mandatory at its tier gate rather than discretionary, per `references/agent-orchestration.md`'s Independent Verification Exception. Dispatch per `references/agent-orchestration.md`:
 
-> **Dispatch: `massa-ai-builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
+> **Dispatch: `builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
 > - trigger: large/high-risk finding, disjoint implementation slice, or explicit subagent request
 > - scope: one isolated requirements finding with a disjoint write set
 > - permissions: write (disjoint write set)
@@ -76,17 +76,16 @@ Not for findings-only requirements review — route to `workflows/requirements/r
 > - firewall: raw diffs/logs summarized
 > - memory: suggest-only; main agent persists reusable requirements patterns
 
-> **Dispatch: `massa-ai-reviewer`** (role: `reviewer`) — charter `skills/agents/reviewer/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `review`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: implementation complete, before the verification gate — never optional
 > - scope: the fix's diff surface and its task/AC context
-> - permissions: read-only
 > - inputs: diff, acceptance context, recalled code-quality conventions
 > - sensors: bugs, regressions, missing edge cases, smells introduced by the diff
 > - output: ranked findings, blocking vs advisory; blocking findings become fix items before verification runs
 > - firewall: summarized findings only, never raw diff dumps
 > - memory: suggest-only; main agent persists
 
-> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `verify`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: mandatory at Standard+/Spec-driven REQ-fix size or high/critical requirement severity, per the Independent Verification Mandate tier gate in `references/verification-ladder.md`'s Mandatory Verification Fix Gate; a Quick-tier REQ finding takes the fallback below instead
 > - scope: the closed REQ row's Requirement Source alignment, acceptance evidence, and report claim closure
 > - inputs: the finding, its Requirement Source and Requirement ID or Quote, the applied fix, the verification suggestion, and validation assets
@@ -101,7 +100,7 @@ Not for findings-only requirements review — route to `workflows/requirements/r
    - If verification found a reusable signal (`ac_gap`, `surviving_mutant`, `spec_precision_gap`, `spec_deviation`, `gate_fail`), record it via `references/lessons.md`:
      `bun skills/massa-ai/scripts/lessons.ts --root . add --feature "<slug>" --signal "<signal>" --source "<ref>" --text "<one terse lesson>"`
    - Apply the Mandatory Verification Fix Gate from `references/verification-ladder.md`: run the report's Verification Suggestion or an equivalent deterministic command/artifact check for each selected finding or coherent group.
-   - Dispatch the verification-agent block above once a REQ finding reaches Standard+/Spec-driven size or high/critical severity; a Quick-tier finding instead runs the listed fallback self-check — the tier gate decides the hop, never the check itself.
+   - Dispatch the `code-reviewer` `verify` block above once a REQ finding reaches Standard+/Spec-driven size or high/critical severity; a Quick-tier finding instead runs the listed fallback self-check — the tier gate decides the hop, never the check itself.
    - A surviving mutant on the discrimination sensor blocks the row: mark the finding's Closure Matrix status `blocked` and log a `surviving_mutant` signal through `references/lessons.md`.
    - `references/verification-ladder.md`'s Bounded Fix→Re-verify Loop caps re-verify cycles per REQ finding at 3; exhausting it also lands `blocked`.
    - A finding cannot be marked `fixed` when a target-relevant command or artifact check exists but was not attempted; if verification cannot run, mark it `blocked`, `deferred`, or `skipped` with an allowed skipped-check reason.

package/skills/massa-ai/workflows/security/security-audit.md

@@ -29,12 +29,11 @@ Findings-only: do not edit code unless the user separately asks for fixes.
    - Apply the Memory Freshness Gate from `references/audit-scope.md`; recalled exceptions are leads, not proof.
 4. Establish the investigation scope: select the scope type and build the shared scope packet per `references/audit-scope.md`, which owns the supported scope types, the ask-when-vague rule, and the packet fields. Carry the packet into the report.
 5. Resolve the selected branch's mechanics (modified files, commit range, codebase area, explicit-files/branch/symbol/feature/whole-repo, or implementation parent scope) per `references/audit-scope.md` (Lens Audit Scope Resolution Procedure, Security row of Per-Lens Scope Deltas).
-6. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
+6. Investigation pass. Dispatch `code-reviewer` (`audit` mode) per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
 
-> **Dispatch: `massa-ai-audit-specialist`** (role: `audit-specialist`) — charter `skills/agents/audit-specialist/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `audit`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: large scope, explicit parallel/subagent request, PR subagent invocation, or independent verification of high-impact finding
 > - scope: the security audit target — files, trust boundaries, auth paths, validators
-> - permissions: read-only
 > - inputs: shared scope packet; `lens: security`; recalled security decisions, auth boundaries, validation rules, accepted exceptions
 > - sensors: trace untrusted input -> validation -> authorization -> transformation -> persistence; authn/authz, object ownership, tenant isolation, input validation, secret handling, injection risks
 > - output: findings with security boundary, asset, trigger/exploit path, severity, confidence, evidence, simplest fix direction, verification suggestion

package/skills/massa-ai/workflows/security/security-fix.md

@@ -68,7 +68,7 @@ Not for findings-only security review — route to `workflows/security/security-
    - Do not weaken existing security assertions to make tests pass.
 10. Use agent orchestration only when it improves signal — except the verifier dispatch below, which is unconditional for every SEC finding closed `fixed`, carved out under `references/agent-orchestration.md`'s Independent Verification Exception as the security-fix unconditional case (other fix families use the tier-gated one). Dispatch per `references/agent-orchestration.md`:
 
-> **Dispatch: `massa-ai-builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
+> **Dispatch: `builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
 > - trigger: large/high-risk finding, disjoint implementation slice, or explicit subagent request
 > - scope: one isolated security finding with a disjoint write set
 > - permissions: write (disjoint write set)
@@ -78,17 +78,16 @@ Not for findings-only security review — route to `workflows/security/security-
 > - firewall: raw diffs/logs summarized
 > - memory: suggest-only; main agent persists reusable security patterns
 
-> **Dispatch: `massa-ai-reviewer`** (role: `reviewer`) — charter `skills/agents/reviewer/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `review`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: implementation complete, before the verification gate — never optional
 > - scope: the fix's diff surface and its task/AC context
-> - permissions: read-only
 > - inputs: diff, acceptance context, recalled code-quality conventions
 > - sensors: bugs, regressions, missing edge cases, smells introduced by the diff
 > - output: ranked findings, blocking vs advisory; blocking findings become fix items before verification runs
 > - firewall: summarized findings only, never raw diff dumps
 > - memory: suggest-only; main agent persists
 
-> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `verify`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: every SEC finding closed `fixed` — never optional, at every tier (verification-ladder Independent Verification Mandate, security-fix exception)
 > - scope: the fixed SEC finding's guard, exploit path, negative test, and report claim closure
 > - inputs: the SEC finding, the applied guard, the verification suggestion, the exploit path, and validation assets

package/skills/massa-ai/workflows/spec-driven.md

@@ -8,7 +8,7 @@ metadata:
 
 ### Spec-Driven
 
-Use for explicit spec-driven requests and broad, ambiguous, migration-heavy, cross-boundary, public-contract, or long-running delivery that needs requirements-through-verification control. Ordinary localized fixes and clear small features stay in `debug`, `feature`, `refactor`, or `general` unless the user explicitly requests this workflow.
+Use for explicit spec-driven requests and broad, ambiguous, migration-heavy, cross-boundary, public-contract, or long-running delivery that needs requirements-through-verification control. Ordinary localized fixes and clear small features stay in `debug`, `feature`, or `refactor` unless the user explicitly requests this workflow.
 
 Load `references/project-context.md` (intake sweep) before the first substantive read.
 
@@ -36,7 +36,7 @@ Holds for every task, even if reference files are not opened:
 1. Tests derive from the spec's acceptance criteria and assert spec-defined outcomes — they never mirror the implementation.
 2. The gate must pass (tests pass) before a task is done — the test runner decides, not self-assessment.
 3. One atomic commit per task. Never batch tasks; never weaken, skip, or delete tests to make them pass.
-4. After the last task, a fresh verification-agent always runs automatically (author ≠ verifier) — spec-anchored outcome check plus discrimination sensor. Never optional, never prompted.
+4. After the last task, a fresh `code-reviewer` verifier (`verify` mode) always runs automatically (author ≠ verifier) — spec-anchored outcome check plus discrimination sensor. Never optional, never prompted.
 5. **Blast radius (approval ≠ remote authority):** Approving Execute for this feature authorizes local implementation and local commits, and covers one delivery through PR creation — branch push and `gh pr create` — under one explicit go-ahead given at Execute start. Force-push, deploy, production database changes, merges, and any other remote/externally-visible/destructive operation always require a separate explicit go-ahead, even after that authorization.
 
 ## Auto-Sizing
@@ -114,26 +114,25 @@ Quick artifacts live under `.specs/quick/NNN-slug/` with a `TASK.md` (one-line i
    - Use per-task commits when the environment and user permissions allow commits; otherwise record the skipped reason.
    - Keep validation assets protected.
    - Update logical feature artifacts in `.specs/features/<slug>/` and `.specs/project/STATE.md` after meaningful progress.
-    - Finish Execute by running `references/spec-driven/validate.md`. Dispatch `verification-agent` (author ≠ verifier) per `references/agent-orchestration.md`; the verification-agent always runs automatically and writes `.specs/features/<slug>/validation.md`. Without subagents, run the standalone fresh-eyes fallback in `validate.md`.
+    - Finish Execute by running `references/spec-driven/validate.md`. Dispatch `code-reviewer` in `verify` mode (author ≠ verifier) per `references/agent-orchestration.md`; the `code-reviewer` verifier always runs automatically and writes `.specs/features/<slug>/validation.md`. Without subagents, run the standalone fresh-eyes fallback in `validate.md`.
 
-**Screen work — before writing or judging any user-facing screen:** when this task creates or modifies a screen, the `massa-ai-designer` dispatch below is mandatory rather than discretionary, carved out of ordinary delegation gating by the Screen Implementation Exception in `references/agent-orchestration.md`. It does not fire when the task touches no screen surface.
+**Screen work — before writing or judging any user-facing screen:** when this task creates or modifies a screen, the `designer` dispatch below is mandatory rather than discretionary, carved out of ordinary delegation gating by the Screen Implementation Exception in `references/agent-orchestration.md`. It does not fire when the task touches no screen surface.
 
-> **Dispatch: `massa-ai-designer`** (role: `designer`) — charter `skills/agents/designer/SKILL.md`
+> **Dispatch: `designer`** (role: `designer`, mode: `implement`) — charter `skills/agents/designer/SKILL.md`
 > - scope: the screens, views, components, layouts, styles, and design tokens in this task's UI surface — never the whole repository
 > - permissions: write, scoped to UI-layer files only with a disjoint write set
 > - output: per-element conformance table (element, expected, actual, verdict, severity) plus the UI files written; a missing or unreachable design source is listed as a skipped sensor, never a silent pass
 
-> **Dispatch: `massa-ai-reviewer`** (role: `reviewer`) — charter `skills/agents/reviewer/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `review`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: implementation complete, before the verification gate — never optional
 > - scope: the task's diff surface and its task/AC context
-> - permissions: read-only
 > - inputs: diff, acceptance context, recalled code-quality conventions
 > - sensors: bugs, regressions, missing edge cases, smells introduced by the diff
 > - output: ranked findings, blocking vs advisory; blocking findings become fix items before verification runs
 > - firewall: summarized findings only, never raw diff dumps
 > - memory: suggest-only; main agent persists
 
-> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `verify`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: spec-driven Execute final gate; author ≠ verifier independence required
 > - scope: the feature's git diff surface, test files, and spec ACs
 > - inputs: `spec.md` (ACs = source of truth), `references/spec-driven/validate.md` as operating checklist, commit range, test files in scope
@@ -142,7 +141,7 @@ Quick artifacts live under `.specs/quick/NNN-slug/` with a `TASK.md` (one-line i
 > - firewall: raw diffs/logs/test output summarized; mutations run in scratch state only
 > - memory: suggest-only; main agent persists validation outcomes
 
-    - The verification-agent re-derives coverage independently using evidence-or-zero and does not inherit the author's mental model.
+    - The `code-reviewer` verifier re-derives coverage independently using evidence-or-zero and does not inherit the author's mental model.
    - The fix → re-verify loop is bounded by the Bounded Fix→Re-verify Loop rule in `references/verification-ladder.md` (cap reached → `Blocked`).
    - Distill lesson signals through `references/lessons.md` when validation produces grounded reusable failures.
 7. Before the delivery chain's Propose stage (PR creation), write and commit `.specs/project/STATE.md`, `.specs/HANDOFF.md`, and `.specs/project/FEATURES.json` on the branch — not merely "after meaningful progress" during Execute, but committed before `gh pr create`. **Deterministic backing (run it, do not eyeball it):** `bun skills/massa-ai/scripts/check_specs_delivered.ts <feature> [--root .]` — a non-zero exit blocks Propose (see `references/implementation-delivery.md` stage 3.5 and GATE-02). If no code-execution tool is available, run the same checks by reading the artifact (graceful degradation preserved). Record decisions, blockers, handoff, and completion evidence per `references/spec-driven/memory.md`'s write triggers.
@@ -169,7 +168,7 @@ Quick artifacts live under `.specs/quick/NNN-slug/` with a `TASK.md` (one-line i
 - Requirement cannot close: keep Specify open and ask the user, or record an explicit accepted assumption before execution.
 - Design or Tasks was skipped incorrectly: stop, create the missing artifact, and resume from the updated contract.
 - Validation command unavailable: record the missing command/tool in `validation.md` and mark `Blocked`.
-- Discrimination sensor cannot be made safely reversible: mark `Blocked` unless the verification-agent can prove equivalent discrimination with an existing deterministic mutation fixture.
+- Discrimination sensor cannot be made safely reversible: mark `Blocked` unless the `code-reviewer` verifier can prove equivalent discrimination with an existing deterministic mutation fixture.
 - Validation conflict: stop for user resolution when a validation asset conflicts with an approved specification.
 - Fix loop reaches the `references/verification-ladder.md` cap: stop with `Blocked`, preserve evidence, and ask for direction.
 

package/skills/massa-ai/workflows/tests/tests-audit.md

@@ -41,9 +41,9 @@ Five gates, five distinct error classes. A green gate elsewhere never substitute
    - Apply the Memory Freshness Gate from `references/audit-scope.md`; recalled exceptions are leads, not proof.
 4. Establish the investigation scope: select the scope type and build the shared scope packet per `references/audit-scope.md`, which owns the supported scope types, the ask-when-vague rule, and the packet fields. Carry the packet into the report.
 5. Resolve the selected branch's mechanics (modified files, commit range, codebase area, explicit-files/branch/symbol/feature/whole-repo, or implementation parent scope) per `references/audit-scope.md` (Lens Audit Scope Resolution Procedure, Tests row of Per-Lens Scope Deltas).
-6. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
+6. Investigation pass. Dispatch `test-engineer` (`audit` mode) per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
 
-> **Dispatch: `massa-ai-audit-specialist`** (role: `audit-specialist`) — charter `skills/agents/audit-specialist/SKILL.md`
+> **Dispatch: `test-engineer`** (role: `test-engineer`, mode: `audit`) — charter `skills/agents/test-engineer/SKILL.md`
 > - trigger: large scope, explicit parallel/subagent request, PR subagent invocation, or independent verification of high-impact finding
 > - scope: the tests audit target — test files, fixtures, harnesses, coverage
 > - permissions: read-only

package/skills/massa-ai/workflows/tests/tests-fix.md

@@ -68,17 +68,16 @@ Not for findings-only test coverage, assertion quality, fixture health, flakines
    - Do not delete coverage, snapshots, fixtures, or benchmarks unless the audit report explicitly calls them obsolete and behavior remains protected elsewhere.
    - Prefer production-code changes only when required to expose a deterministic seam or fix a real bug found while writing the audited test.
 
-> **Dispatch: `massa-ai-reviewer`** (role: `reviewer`) — charter `skills/agents/reviewer/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `review`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: implementation complete, before the verification gate — never optional
 > - scope: the fix's diff surface and its task/AC context
-> - permissions: read-only
 > - inputs: diff, acceptance context, recalled code-quality conventions
 > - sensors: bugs, regressions, missing edge cases, smells introduced by the diff
 > - output: ranked findings, blocking vs advisory; blocking findings become fix items before verification runs
 > - firewall: summarized findings only, never raw diff dumps
 > - memory: suggest-only; main agent persists
 
-> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
+> **Dispatch: `code-reviewer`** (role: `code-reviewer`, mode: `verify`) — charter `skills/agents/code-reviewer/SKILL.md`
 > - trigger: mandatory per the verification-ladder's Independent Verification Mandate for any TST finding closed at Standard+/Spec-driven size or high/critical severity; at Quick size the subagent hop is skipped and the standalone fresh-eyes assertion re-check below runs instead
 > - scope: the fixed TST finding's assertion strength, fixture/mock boundary, coverage-execution-map row, and report claim closure
 > - inputs: the finding, the applied test change, the coverage execution map row, the verification command, and validation assets
@@ -100,17 +99,28 @@ Not for findings-only test coverage, assertion quality, fixture health, flakines
    - Sequence the TST proof in two passes, in order: first reproduce the coverage execution map's `expected failure before fix` row red (the pre-fix run proves the assertion can fail); only then, at Standard+/Spec-driven size or high/critical severity, run the discrimination sensor from `references/discrimination-sensor.md` as the post-fix kill-check against the new/repaired test's subject code — Quick focused-assertion findings are exempt from the sensor pass but never from the pre-fix red check.
    - A surviving mutant means the TST claim is unproven: close that finding's row `blocked` rather than `fixed` and emit the `surviving_mutant` lessons signal via the recording command above.
    - The fix→re-verify cycle is capped per `references/verification-ladder.md`'s Bounded Fix→Re-verify Loop (3 verification iterations, then `Blocked` with evidence preserved).
-11. Use agent orchestration only when it improves signal — except the verification-agent dispatch above, which `references/agent-orchestration.md`'s Independent Verification Exception mandates for TST closures at the sizes/severities its trigger names, regardless of signal improvement. Dispatch per `references/agent-orchestration.md`:
+11. Use agent orchestration only when it improves signal — except the `code-reviewer` `verify` dispatch above, which `references/agent-orchestration.md`'s Independent Verification Exception mandates for TST closures at the sizes/severities its trigger names, regardless of signal improvement. Dispatch per `references/agent-orchestration.md`:
 
-> **Dispatch: `massa-ai-builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
+> **Dispatch: `test-engineer`** (role: `test-engineer`, mode: `fix`) — charter `skills/agents/test-engineer/SKILL.md`
 > - trigger: large/high-risk finding, disjoint implementation slice, or explicit subagent request
 > - scope: one isolated test finding with a disjoint write set
-> - permissions: write (disjoint write set)
+> - permissions: write, test files only (disjoint write set)
 > - inputs: the finding ID, missing/weak coverage type, fixture/mock boundary, deterministic harness, and verification command
 > - sensors: focused test command (`bun test`, `pytest`, `cargo test`) with clean exit code; no weakened assertions
 > - output: implementation summary, test counts, commands run, deviations
 > - firewall: raw test output/logs summarized
 > - memory: suggest-only; main agent persists reusable testing patterns
+
+> **Dispatch: `builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
+> - trigger: a selected TST finding whose fix needs a production seam for deterministic testing (step 7 Standard) — never for a test-file change, which belongs to `test-engineer`, and never for a production behavior change, which routes to `workflows/spec-driven.md`
+> - scope: the seam-only production change for one TST finding, with a write set disjoint from the `test-engineer` test files
+> - permissions: write (disjoint write set, production seam files only; no behavior change)
+> - inputs: the finding ID, the coverage execution map row, the seam required (time, randomness, async scheduling, filesystem, network, or global-state control), and the verification command
+> - sensors: the existing suite stays green with the seam in place, then the focused test command passes against it
+> - output: implementation summary, changed files, commands run, deviations
+> - firewall: raw diffs and test output summarized
+> - memory: suggest-only; main agent persists reusable seam patterns
+
    - Main agent owns report parsing, prioritization, memory writes, final synthesis, and Evidence Gate.
 12. Close out with the Fix Closure Report:
    - The coverage execution map from step 6, now filled in through step 10's discrimination sensor result column, is the pre-edit draft of the Closure Matrix — carry its rows forward rather than re-deriving them.

package/skills/massa-ai/workflows/the-fool.md

@@ -32,16 +32,16 @@ User prompt overrides take precedence for the current turn only, such as "skip t
    - Post-plan gate: inherit the parent workflow's exact `projectId`,
      `workflowSessionId`, workflow name, entity, and memory context.
 2. `recall` -> load prior decisions, rejected approaches, constraints, accepted risks, and relevant evidence for the target entity.
-3. Require a concrete proposed plan before critique. If there is no plan, return to the parent workflow and construct the plan first. After a concrete plan exists, always attempt a read-only `massa-ai-plan-critic` subagent when subagent tooling is available. If that agent is unavailable, follow the no-agent fallback in `references/agent-orchestration.md` (Name Resolution): run the critique locally against the same output contract and report the skipped delegation.
+3. Require a concrete proposed plan before critique. If there is no plan, return to the parent workflow and construct the plan first. After a concrete plan exists, always attempt a `judge` subagent in `plan-critique` mode (it writes nothing in that mode) when subagent tooling is available. If that agent is unavailable, follow the no-agent fallback in `references/agent-orchestration.md` (Name Resolution): run the critique locally against the same output contract and report the skipped delegation.
 4. Resolve gate depth:
    - Post-plan lite gate: keep parent identifiers and dispatch a bounded lite checklist packet without loading The Fool mode references.
    - Post-plan full gate or direct challenge: continue to mode selection and full critique.
    - Direct challenge requests use `workflowSessionId=fool-[entity]`; post-plan gates keep the parent identifiers and send only a bounded packet.
-5. Lite `massa-ai-plan-critic` packet:
+5. Lite `judge` `plan-critique` packet:
    - Inputs: proposed plan, scope, constraints, parent workflow, compact recalled facts/evidence, known risks, verification recipe, context-firewall limits, and lite checklist.
    - Output must include the strongest low-risk challenges plus `escalate_to_full: true|false` and reason.
    - If `escalate_to_full: false`, synthesize the lite critique, revise or accept risk according to policy, and complete the gate without loading The Fool mode references.
-   - If `escalate_to_full: true`, the main agent selects full mode, loads the relevant references, and dispatches a full `massa-ai-plan-critic` pass.
+   - If `escalate_to_full: true`, the main agent selects full mode, loads the relevant references, and dispatches a full `judge` `plan-critique` pass.
 6. Select The Fool mode for full gates:
    - `mode: auto`: read `references/the-fool/mode-selection-guide.md` and choose the best mode from plan content and domain.
    - `mode: ask`: ask the user only when interactive input is available; otherwise fall back to `auto` and report the fallback.
@@ -55,12 +55,12 @@ User prompt overrides take precedence for the current turn only, such as "skip t
 7. Load only the selected The Fool reference plus `references/the-fool/cognitive-bias-inventory.md`.
 8. Dispatch the full critique:
    - Load `references/agent-orchestration.md`.
-   - Use the `plan-critic` contract and capability-packet shape from `references/agent-orchestration.md`; dispatch under `massa-ai-plan-critic`.
-   - Send only the proposed plan, scope, constraints, parent workflow, recalled facts, verification recipe, known risks, selected mode, context-firewall limits, and output contract.
+   - Use the `plan-critique` contract and capability-packet shape from `references/agent-orchestration.md`; dispatch `judge` with `mode: plan-critique`.
+   - Send only the proposed plan, scope, constraints, parent workflow, recalled facts, verification recipe, known risks, the selected The Fool mode as `fool_mode` (the packet `mode` stays `plan-critique`), context-firewall limits, and output contract.
    - If subagents are unavailable or platform policy forbids spawning, run a strict standalone fresh-eyes local critique and record the skipped delegation reason.
-   - Normal delegation gates in `references/agent-orchestration.md` still apply to other roles, but Plan Challenge `plan-critic` is a standing policy exception after a concrete plan exists.
+   - Normal delegation gates in `references/agent-orchestration.md` still apply to other roles, but the Plan Challenge `judge` `plan-critique` dispatch is a standing policy exception after a concrete plan exists.
 9. Critique output must include:
-   - selected mode
+   - selected `fool_mode`
    - steelmanned thesis
    - 3-5 strongest challenges
    - severity: `critical`, `high`, `medium`, or `low`

package/skills/{discovery.md → product-discovery.md}

@@ -1,13 +1,13 @@
 ---
-description: "Product discovery and brainstorming workflow — act as a sharp product thinking partner to explore problem spaces, generate and stress-test ideas, and spar on strategy before anything is spec-ready, ending with a mandatory offer to synthesize the conversation into a PRD via the to-prd workflow. Use when the user wants to brainstorm a product problem, idea, opportunity, or direction with no concrete code target. Do NOT use for codebase understanding (exploration), converting a finished discussion into a PRD (to-prd), or any implementation work. — explicit massa-ai 'discovery' workflow"
+description: "Product discovery and brainstorming workflow — act as a sharp product thinking partner to explore problem spaces, generate and stress-test ideas, and spar on strategy before anything is spec-ready, ending with a mandatory offer to synthesize the conversation into a PRD via the create-prd workflow. Use when the user wants to brainstorm a product problem, idea, opportunity, or direction with no concrete code target. Do NOT use for codebase understanding (exploration), converting a finished discussion into a PRD (create-prd), or any implementation work. — explicit massa-ai 'product-discovery' workflow"
 argument-hint: "[task description]"
 ---
 <!-- massa-ai:generated workflow-command -->
 
-Explicit massa-ai workflow invocation: `discovery`.
+Explicit massa-ai workflow invocation: `product-discovery`.
 
 Load the massa-ai router skill if not already loaded (dedupe guard), then
-route to workflow `discovery` under routing precedence 1 (explicit route) —
+route to workflow `product-discovery` 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/agent-profiles/balanced/massa-ai-architecture-specialist.toml

@@ -1,62 +0,0 @@
-# massa-ai-owned
-name = "massa-ai-architecture-specialist"
-description = "Read-only architecture guidance agent. Evaluate architecture, suggest boundaries, recommend abstractions, evaluate trade-offs, and suggest modularization. Folds the existing domain-mapper, coupling-auditor, and deepening-architect roles into one specialist. Triggers when a workflow needs architectural guidance before or during design. Never implements or rewrites code."
-model = "gpt-5.6-sol"
-model_reasoning_effort = "high"
-sandbox_mode = "read-only"
-developer_instructions = """# Architecture Specialist Agent Skill
-
-## Mission
-Provide architectural guidance by evaluating structure, suggesting boundaries, and weighing trade-offs.
-
-## Responsibilities
-- Evaluate architecture (layering, boundaries, coupling, depth).
-- Suggest module boundaries and seams.
-- Recommend abstractions where duplication or volatility warrants them.
-- Evaluate trade-offs between approaches.
-- Suggest modularization for shallow or over-coupled modules.
-
-## Restrictions
-- Never implement.
-- Never rewrite code.
-- Never load the `massa-ai` or `persona-router` routers, and never open a `personas/` prompt file; the dispatching workflow owns routing and persona selection.
-- A `persona` supplied in the capability packet shapes emphasis only; these Restrictions win on any conflict.
-
-## Inputs
-- `scope`: the module, service, or area under evaluation.
-- `inputs`: recalled facts, source pointers, existing architecture docs.
-- `sensors`: static coupling/depth metrics when available.
-
-## Outputs
-- Status: Complete | Partial | Blocked
-- Scope: modules and boundaries evaluated
-- Evidence: `path:line` pointers, coupling/depth metrics, source locations
-- Findings: boundary suggestions, abstraction recommendations, trade-off analysis, modularization plan
-- Risks and skipped checks
-- Exact next step
-
-## Invocation
-### Use when
-- A workflow needs architectural guidance before or during design.
-- The work crosses module or service boundaries.
-- The user asks for architecture evaluation, coupling analysis, or modularization.
-
-### Do not use when
-- The work is a single-file fix with no architectural surface.
-- The task needs a concrete implementation (route to builder).
-- An audit-specific lens is needed (route to audit-specialist with `lens: architecture`).
-
-## massa-ai Integration
-- Context Firewall: summarize source reads; return findings and metrics, not raw code.
-- Verification Ladder: static (coupling, depth, boundary) checks; no behavioral changes.
-- Massa-ai Memory: suggest durable architecture-decision memories only when a boundary or abstraction is recommended; main agent persists.
-- Synapse: own ephemeral session when evaluation spans multiple modules with repeated searches.
-- References (paths relative to the `massa-ai` skill directory): `references/architecture-lenses.md`, `references/architecture-domain-lens.md`, `references/architecture-coupling-lens.md`, `references/architecture-deepening-lens.md`.
-
-## Validation Sensors
-- Every finding has a `path:line` or metric pointer.
-- Trade-offs name at least two alternatives.
-- Boundary suggestions reference concrete modules.
-
-## Memory Boundary
-Suggest durable memories only when an architectural boundary or abstraction is recommended and accepted. The main agent persists. Do not persist one-off evaluation chatter."""