@massa-ai/codex-plugin 1.60.1 → 1.62.0

package/skills/massa-ai/references/furps/intake.md

@@ -18,7 +18,7 @@ A run may combine sources (e.g., a Jira PRD epic + a Confluence ADR). Record eve
 
 ## Atlassian MCP (read-only capability discovery)
 
-This workflow only reads from Atlassian; it never creates issues or pages. Reuse the capability-discovery pattern from `references/ticket/atlassian-fix.md`:
+This workflow only reads from Atlassian; it never creates issues or pages. Reuse the capability-discovery pattern from `references/create-ticket/atlassian-fix.md`:
 
 1. Inspect currently callable tools.
 2. Identify Atlassian MCP operations by capability and schema, not by provider-specific function name. Needed capabilities: Jira issue retrieval and Confluence page retrieval.
@@ -68,9 +68,9 @@ The main agent builds one packet reused across sub-agents:
 
 ## Sub-agent packet contracts
 
-### plan-critic (The Fool) — evidence_audit
+### judge `plan-critique` (The Fool) — evidence_audit
 
-- role: `plan-critic`; mode: `evidence_audit`
+- role: `judge`; mode: `plan-critique`; depth: `full`; fool_mode: `evidence_audit`
 - purpose: grade whether the PRD/ADR claims are source-backed, complete, falsifiable
 - scope: the document as the challenged thesis
 - permissions: read-only
@@ -80,9 +80,9 @@ The main agent builds one packet reused across sub-agents:
 - firewall: summarize the document; no raw dumps
 - memory: suggest only
 
-### plan-critic (The Fool) — pre_mortem
+### judge `plan-critique` (The Fool) — pre_mortem
 
-- role: `plan-critic`; mode: `pre_mortem`
+- role: `judge`; mode: `plan-critique`; depth: `full`; fool_mode: `pre_mortem`
 - purpose: anticipate execution-phase failures of the proposed solution
 - inputs: document packet, DoR, recalled facts, AND the evidence_audit summary
 - output: Fool critique contract, focused on failure narratives
@@ -90,9 +90,9 @@ The main agent builds one packet reused across sub-agents:
 
 Dispatch `pre_mortem` after `evidence_audit` returns, so it can build on identified gaps.
 
-### furps-analyst — one per dimension (F, U, R, P, S, X)
+### product-manager `furps` — one per dimension (F, U, R, P, S, X)
 
-- role: `furps-analyst`; dimension: `<letter>`
+- role: `product-manager`; mode: `furps`; dimension: `<letter>`
 - purpose: analyze one FURPS+ dimension against its checklist section
 - scope: the assigned dimension's check items only
 - permissions: read-only

package/skills/massa-ai/references/hook-enforcement.md

@@ -64,7 +64,6 @@ absent, it falls back to the flat evidence matrix (graceful degradation).
 | `bugs-fix` | verification-fix gate |
 | `code-quality-fix` | verification-fix gate |
 | `implementation-fix` | verification-fix gate |
-| `maestro-fix` | verification-fix gate |
 | `mobile-figma-fix` | verification-fix gate |
 | `requirements-fix` | verification-fix gate |
 | `security-fix` | verification-fix gate |
@@ -78,23 +77,20 @@ absent, it falls back to the flat evidence matrix (graceful degradation).
 | `bugs-audit` | flat evidence matrix |
 | `code-quality-audit` | flat evidence matrix |
 | `implementation-audit` | flat evidence matrix |
-| `maestro-audit` | flat evidence matrix |
 | `mobile-figma-audit` | flat evidence matrix |
 | `requirements-audit` | flat evidence matrix |
 | `security-audit` | flat evidence matrix |
 | `tests-audit` | flat evidence matrix |
 | `furps-refinement` | flat evidence matrix (findings-only; report written + DoR coverage gaps listed) |
-| `adr` | flat evidence matrix |
+| `create-adr` | flat evidence matrix |
 | `commit` | flat evidence matrix |
 | `design` | flat evidence matrix |
-| `general` | flat evidence matrix |
 | `long-session` | flat evidence matrix |
-| `maestro` | flat evidence matrix |
 | `onboarding` | flat evidence matrix |
-| `rfc` | flat evidence matrix |
-| `tdd` | flat evidence matrix |
+| `create-rfc` | flat evidence matrix |
+| `create-tdd` | flat evidence matrix |
 | `the-fool` | flat evidence matrix |
-| `ticket` | flat evidence matrix |
+| `create-ticket` | flat evidence matrix |
 
 ## massa-ai Dual-Write / Tag Contract
 

package/skills/massa-ai/references/implementation-delivery.md

@@ -65,14 +65,14 @@ worktree was never provisioned is an environment failure; say so rather than
 reporting it as a code failure.
 
 **Phased work — one branch per Phase/Wave.** When the work is phased (sourced
-from `workflows/ticket.md`, a spec-driven `tasks.md` with Phases/Waves, a TDD
+from `workflows/create-ticket.md`, a spec-driven `tasks.md` with Phases/Waves, a TDD
 PR-group table, or a `references/pr-task-fix.md` PR-group split), create
 **one branch per Phase/Wave**, not one branch per task
 and not one branch for the whole feature. All Phases/PR groups of one feature
 share that feature's single Stage 3 delivery authorization — one go-ahead
 covers every group's commits, pushes, and PR creation. Name the branch with the phase's Jira
 Task key, e.g. `feat/<PHASE-KEY>-<slug>` (so `feat/SA-100-phase-1-search-split`
-for phase SA-100). The phase key comes from `workflows/ticket.md` or the user.
+for phase SA-100). The phase key comes from `workflows/create-ticket.md` or the user.
 Each Task inside the phase is then one atomic commit on that branch, prefixed
 with its own sub-task key — the commit contract is owned by
 `workflows/commit.md`; do not restate it here. Non-phased work keeps the

package/skills/massa-ai/references/knowledge-verification-chain.md

@@ -22,4 +22,3 @@ Step 2 reads whatever project documentation the target repository actually has;
 ## Family Instantiations
 
 - **Requirements family:** the audit report's cited Requirement Source may be treated as Step 0 — the authoritative anchor the rest of the chain verifies implementation facts against. Step 0 answers *what was required*; Steps 1-5 still govern *how the code behaves*.
-- **Maestro:** `references/maestro/fact-ledger.md`'s Authority Order is the Maestro instantiation of this chain (official-doc → live-help → repo-convention → excluded/unverified). Do not layer the generic chain on top of it.

package/skills/massa-ai/references/mobile-context.md

@@ -7,9 +7,6 @@ Mobile is a context modifier, not a primary workflow. Keep the selected workflow
 - New capability -> `workflows/feature.md`
 - Behavior-preserving structure change -> `workflows/refactor.md`
 - Broken behavior, crashes, regressions, or device-specific failures -> `workflows/debug.md` plus `references/mobile-diagnosis.md`
-- New Maestro mobile E2E flow implementation -> `workflows/maestro/maestro.md`
-- Findings-only Maestro mobile E2E audit -> `workflows/maestro/maestro-audit.md`
-- Child-only fix for saved Maestro audit findings -> `workflows/maestro/maestro-fix.md`
 - Findings-only test coverage review -> `workflows/tests/tests-audit.md`
 - Fix findings from a tests audit report -> `workflows/tests/tests-fix.md`
 - Direct Android Views/Compose, UIKit/SwiftUI, or KMP Compose Multiplatform implementation from Figma or screenshot context -> `workflows/design.md`
@@ -19,11 +16,11 @@ Mobile is a context modifier, not a primary workflow. Keep the selected workflow
 - Fix findings from a security audit report -> `workflows/security/security-fix.md`
 - Broad, cross-boundary, unclear, or multi-platform implementation -> `workflows/spec-driven.md`
 
-Maestro is a first-class mobile E2E workflow family when the primary target is flow implementation, existing-flow audit, or saved `MST-*` remediation. Generic test coverage, assertion quality, or regression-risk review still belongs to `workflows/tests/tests-audit.md` or `workflows/tests/tests-fix.md` when the target is not Maestro-specific.
+Mobile E2E test coverage, assertion quality, flakiness, or regression-risk review belongs to `workflows/tests/tests-audit.md` or `workflows/tests/tests-fix.md`, whatever the E2E tool.
 
 ## Design-Source Intake Gate
 
-Use this gate for `feature`, `spec-driven`, `rfc`, `adr`, and `tdd` workflows when the target is Android, iOS, KMP Compose Multiplatform UI, or plausibly mobile UI. Clear backend, CLI, docs, infrastructure, or non-UI work skips the gate entirely.
+Use this gate for `feature`, `spec-driven`, `create-rfc`, `create-adr`, and `create-tdd` workflows when the target is Android, iOS, KMP Compose Multiplatform UI, or plausibly mobile UI. Clear backend, CLI, docs, infrastructure, or non-UI work skips the gate entirely.
 
 - Ask once for one or more Figma links, node IDs, a readable desktop selection, supplied screenshots, or explicit `none`. Treat `none` as a first-class answer: record `Figma Source: none by user choice` and do not re-ask unless the mobile UI scope changes.
 - When Figma sources or screenshots are supplied for supported Android, iOS, or KMP Compose Multiplatform UI implementation/update work, keep the parent workflow as the lifecycle owner and invoke `workflows/design.md` only for the affected UI slice or visual feasibility context. Preserve mobile Figma routing by intent: compare/audit wording uses `workflows/mobile-figma/mobile-figma-audit.md`; saved `MFM-*` findings use `workflows/mobile-figma/mobile-figma-fix.md`.

package/skills/massa-ai/references/pr-task-fix.md

@@ -44,7 +44,7 @@ If stacked branching is declined, unavailable, or not applicable, continue seque
 
 ## Jira-Key Stacked Branches
 
-After the PR groups are stable, inspect their Jira keys. Offer stacked branch automation only when every PR group has a confirmed Jira key. Do not create Jira tickets from this reference; ticket creation remains owned by `workflows/ticket.md`.
+After the PR groups are stable, inspect their Jira keys. Offer stacked branch automation only when every PR group has a confirmed Jira key. Do not create Jira tickets from this reference; ticket creation remains owned by `workflows/create-ticket.md`.
 
 If every group has a Jira key, ask whether the user wants to automatically create separate stacked branches for each Jira task. If the user accepts, ask for:
 

package/skills/massa-ai/references/spec-driven/sub-agents.md

@@ -178,7 +178,7 @@ When sub-agents are unavailable (a single agent executing the full feature), use
 
 **Applies only if the harness can assign a model per sub-agent.** If it cannot, ignore this section and run everything on the default model — the workflow is correct either way. The point is to spend high-reasoning capacity where ambiguity and consequence are high, and a faster tier where the work is mechanical, instead of paying top-tier cost uniformly.
 
-massa-ai resolves the actual model per agent through `metadata.model_tier` (`light` / `standard` / `deep`) in each sub-agent's charter (`skills/agents/<name>/SKILL.md`), combined with the host and the active profile in `skills/model-profiles.json` (see `CLAUDE.md` § Agent-harness surface). This section maps role/work characteristics onto that mechanism — it is not a separate free-floating table.
+massa-ai resolves the actual model per agent through the active profile in `skills/model-profiles.json` (see `CLAUDE.md` § Agent-harness surface). Most agents use the profile's per-tool default; some carry per-agent overrides. This section maps role/work characteristics onto that decision framework — it is not a separate free-floating table.
 
 Judge the tier by the work in front of the role, not by the role's title:
 
@@ -189,13 +189,13 @@ Judge the tier by the work in front of the role, not by the role's title:
 | Batch worker — mechanical phase | Entities, DTOs, config, wiring, straightforward CRUD against a settled pattern | `light` / `standard` |
 | Verifier | Adversarial reasoning: designs mutations, re-derives coverage, judges outcome precision | `deep` (always — per the Rules of thumb below) |
 | Specify / Tasks authoring | Structured but judgment-heavy | `standard` / `deep` |
-| Read-only specialist (audit-specialist, context-curator, furps-analyst, investigator, mobile-specialist, navigator, requirements-analyst, reviewer) | No write access — findings, investigation, or review quality is the entire deliverable, with no implementation pass downstream to catch a missed nuance | `deep` (always — per the Rules of thumb below) |
-| Scoped writer (designer, documentation-agent, judge, test-engineer) | `permission: write`, narrowed by the charter's own Restrictions to one file class — UI-layer / doc / the agent's own report / test files — each with a disjoint write set. Not read-only, so the deep-tier rule below does **not** reach them | per the work, not per the permission |
+| Read-only specialist (code-explorer, code-reviewer, product-manager) | No write access — findings, investigation, or review quality is the entire deliverable, with no implementation pass downstream to catch a missed nuance | `deep` (always — per the Rules of thumb below) |
+| Scoped writer (designer, judge, test-engineer) | `permission: write`, narrowed by the charter's own Restrictions to one file class — UI-layer / the agent's own report / test files — each with a disjoint write set. Not read-only, so the deep-tier rule below does **not** reach them | per the work, not per the permission |
 
 **Rules of thumb:**
 
 - When unsure, size up, not down. An under-powered worker on ambiguous logic produces gaps the Verifier then has to catch — more expensive than paying for reasoning once.
-- **The Verifier always runs on the deepest tier** — per project rule, `skills/agents/verification-agent/SKILL.md` pins `metadata.model_tier: deep`, structurally, not just as advisory guidance here. A weak Verifier defeats the author ≠ verifier gate.
-- **Read-only specialists always run on the deepest tier** — this generalizes the Verifier rule: every findings-only or investigation-only charter (`permission: read-only`) pins `metadata.model_tier: deep` structurally, because there is no later implementation pass to catch what a weaker read-only pass missed.
+- **The Verifier always runs on the deepest tier** — in built-in profiles, `code-reviewer` (whose `verify` mode is the Verifier) carries no per-agent override and resolves to the profile's strongest model. A weak Verifier defeats the author ≠ verifier gate.
+- **Read-only specialists always run on the deepest tier** — this generalizes the Verifier rule: in built-in profiles, every findings-only or investigation-only charter (`permission: read-only`) carries no per-agent override and resolves to the profile's strongest model, because there is no later implementation pass to catch what a weaker read-only pass missed. **Accepted risk:** user overlays via the Web UI Model Catalog can choose a weaker default; the UI help text documents this convention.
 - Set the tier per batch, from that batch's phases. A feature can mix tiers across batches.
 - Outside the Verifier's and read-only specialists' structural pins, this table is advisory metadata only — no gate, commit, or verification step depends on it.

package/skills/massa-ai/references/spec-driven/validate.md

@@ -180,7 +180,7 @@ Fix tasks follow the same format as regular tasks and can be executed with the i
 
 After all checks complete, the Verifier MUST:
 
-1. **Write the persisted report** to `.specs/features/<slug>/validation.md` (see template below). This file is the evidence artifact — it survives the session and can be referenced by CI, reviewers, or future agents. Record in `.specs/project/STATE.md` (Decisions) that validation evidence is available at that path.
+1. **Write the persisted report** to `.specs/features/<slug>/validation.md` (see template below). This file is the evidence artifact — it survives the session and can be referenced by CI, reviewers, or future agents. It is the only file the Verifier writes (the `code-reviewer` `verify` carve-out); the orchestrator records in `.specs/project/STATE.md` (Decisions) that validation evidence is available at that path.
 2. **Return a compact summary in chat** to the orchestrator (see Compact Chat Summary section below). The orchestrator surfaces it to the user and routes any ranked gaps to fix tasks.
 
 **Deterministic backing (run it, do not eyeball it):** after writing the report, run `bun skills/massa-ai/scripts/validate_state.ts <feature> [--root .]`. It confirms the report is real — present, verdict filled to PASS, and backed by at least one `file:line` evidence citation — so a missing, hollow, placeholder, or FAIL report cannot slip through as done. A non-zero exit means the feature is NOT done: repair the report or route the FAIL gaps to fix tasks, then re-run. This is the closing gate of Execute and runs automatically, the same way the lessons layer runs at distillation — never a manual step. If no code-execution tool is available, run the same checks by reading the artifact (graceful degradation preserved).

package/skills/massa-ai/references/subagent-design.md

@@ -81,6 +81,9 @@ Output contract:
 - Risks and skipped checks
 - Exact next step
 
+Modes (only when the role owns more than one output contract):
+- One `### Mode: <name>` section per contract (the name in backticks), holding that mode's own output; the packet `mode` field selects it.
+
 Validation sensors:
 - [tests, build, typecheck, lint, static search, artifact inspection, or source-location proof]
 
@@ -97,24 +100,18 @@ sets drift into three diverging shapes before the canonical section existed. Whe
 workflow dispatches a reusable role, send that canonical packet, not a loose
 instruction.
 
-The one field this reference still names on its own is `persona`, because a
-persona-agent-boundary guard (`.specs/features/persona-agent-boundary/spec.md`)
-checks its clause byte-for-byte in every packet-defining file, this one included:
-
-`persona`: optional. The 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.
-
 Design-time additions this reference owns: a new role's charter must be expressible
 as that packet (if a role needs fields the canonical list cannot carry, the role is
 mis-scoped — split it or fix the charter, do not grow a bespoke packet silently), and
-any deliberate bespoke specialization (judge panel, FURPS analyst, phase-batch
-worker) must declare itself a specialization in its own workflow file and map its
+any deliberate bespoke specialization (judge panel, FURPS `product-manager` fan-out,
+phase-batch worker) must declare itself a specialization in its own workflow file and map its
 fields onto the canonical ones from `agent-orchestration.md`.
 
 ## Quality Checklist
 
 Before adding or revising a reusable role:
 
-- One responsibility; no generic "helper" roles.
+- One responsibility; no generic "helper" roles. A role that absorbs another keeps every former output contract behind its own `Mode:` section rather than dropping one.
 - Trigger description names when to use it and when not to use it.
 - Scope can be represented as a bounded capability packet.
 - Read-only by default; write permissions require disjoint ownership and verification.

package/skills/massa-ai/references/synapse-policy.md

@@ -44,7 +44,7 @@ Config knobs (env, read by the server, not by the agent):
 |---|---|---|
 | `SYNAPSE_ENABLED` | `true` | Master kill switch; `false` bypasses the whole pipeline, and `search` behaves statelessly even when a `sessionId` is passed. |
 | `SYNAPSE_ATTENTION_ENABLED` | `false` | Multi-signal attention re-ranker. **Off by default** — do not attribute re-ranking to Synapse unless it is on. |
-| `LOG_LEVEL` | `info` | `debug` emits one pipeline log line per query (see Reading Pipeline Output). |
+| `MASSA_AI_LOG_LEVEL` | `info` | `debug` emits one pipeline log line per query (see Reading Pipeline Output). |
 
 ## MCP-First Lifecycle
 
@@ -103,7 +103,7 @@ optional. REST prefetch requires `filePath` and may include `symbols`, `chains`,
 
 ## Reading Pipeline Output
 
-With `LOG_LEVEL=debug`, the server emits one structured line per Synapse-scoped
+With `MASSA_AI_LOG_LEVEL=debug`, the server emits one structured line per Synapse-scoped
 query. Use it to decide whether Synapse is helping or whether the query needs
 refining — not as evidence about the codebase.
 

package/skills/massa-ai/references/verification-ladder.md

@@ -50,10 +50,10 @@ Every `*-fix` workflow must execute this gate for each selected finding or coher
 
 ### Independent Verification Mandate (author ≠ verifier)
 
-- At **Standard+ or Spec-driven size, or for any high/critical-severity finding**, dispatching `massa-ai-verification-agent` is **mandatory** before closure — the author must not be the sole verifier of their own work. At Quick size, the subagent hop may be skipped, but the check itself is never skipped: run a standalone fresh-eyes re-check (re-read the finding/ACs, changed files, tests, and diff from scratch) against the same output contract.
+- At **Standard+ or Spec-driven size, or for any high/critical-severity finding**, dispatching `code-reviewer` in `verify` mode is **mandatory** before closure — the author must not be the sole verifier of their own work. At Quick size, the subagent hop may be skipped, but the check itself is never skipped: run a standalone fresh-eyes re-check (re-read the finding/ACs, changed files, tests, and diff from scratch) against the same output contract.
 - **Exception — `security-fix` dispatches the verifier unconditionally** for every finding closed `fixed`, at every tier.
 - Fallback discipline: when the subagent is unavailable (not registered, spawning forbidden), run the standalone fresh-eyes re-check from scratch and record the skipped-delegation reason in closure evidence.
-- Reviewer + verifier both dispatching at Standard+ is intentional cost, mirroring spec-driven's always-on pair — not accidental duplication.
+- `code-reviewer` in `review` and in `verify` mode both dispatching at Standard+ is intentional cost, mirroring spec-driven's always-on pair — not accidental duplication.
 
 ### Discrimination Sensor
 

package/skills/massa-ai/scripts/validate_audit_report.ts

@@ -27,7 +27,7 @@
  *
  *   report.md   Path to a saved audit report markdown file.
  *   --family    One of: architecture | bugs | code-quality | security |
- *               requirements | tests | maestro | mobile-figma | implementation
+ *               requirements | tests | mobile-figma | implementation
  *               Auto-detected from the report's `Workflow:` metadata line
  *               when omitted.
  *   --strict    Treat warnings as errors.
@@ -39,7 +39,7 @@ import { existsSync, readFileSync } from "node:fs";
 
 interface FamilyConfig {
   workflow: string;
-  /** Single-lens/MFM/MST prefix, or null for the implementation composite family. */
+  /** Single-lens/MFM prefix, or null for the implementation composite family. */
   prefix: string | null;
   extraMetadata: string[];
 }
@@ -74,11 +74,6 @@ const FAMILIES: Record<string, FamilyConfig> = {
   security: { workflow: "security-audit", prefix: "SEC", extraMetadata: ["Requirements Source"] },
   requirements: { workflow: "requirements-audit", prefix: "REQ", extraMetadata: ["Requirements Source"] },
   tests: { workflow: "tests-audit", prefix: "TST", extraMetadata: ["Requirements Source"] },
-  maestro: {
-    workflow: "maestro-audit",
-    prefix: "MST",
-    extraMetadata: ["Scenario Source", "Maestro CLI", "Device/Emulator Readiness"],
-  },
   "mobile-figma": {
     workflow: "mobile-figma-audit",
     prefix: "MFM",
@@ -158,7 +153,7 @@ interface RawFinding {
 }
 
 const FINDING_HEADER_RE = /^###\s+([^:]+):/;
-/** `<PREFIX>-<N>` (single-lens/MFM/MST) or `<Area>/<PREFIX>-<N>` (implementation composite). */
+/** `<PREFIX>-<N>` (single-lens/MFM) or `<Area>/<PREFIX>-<N>` (implementation composite). */
 const SIMPLE_ID_RE = /^([A-Z][A-Z]*)-(\d+)$/;
 const COMPOSITE_ID_RE = /^([A-Za-z][A-Za-z ]*?)\/([A-Z][A-Z]*)-(\d+)$/;
 

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

@@ -50,20 +50,19 @@ Findings-only: do not edit code unless the user separately asks for fixes.
    - Do not report strong coupling as a defect when strength is local, stable, or cohesive and no change friction is shown.
    - Do not recommend ports/adapters, service extraction, VSA migration, or new seams unless evidence shows real variation, volatility, external dependency pressure, or boundary friction.
    - Drop candidates disproven by evidence, downgrade candidates with partial mitigation, and mark judgment-heavy conclusions as `suspect`.
-   - When you reject a refactor candidate, record its load-bearing reason in ruled-out candidates; if likely to be re-proposed, offer an ADR via `workflows/adr.md` so the rejection is not re-litigated next audit.
+   - When you reject a refactor candidate, record its load-bearing reason in ruled-out candidates; if likely to be re-proposed, offer an ADR via `workflows/create-adr.md` so the rejection is not re-litigated next audit.
 8. Use agent orchestration only when it improves signal. Dispatch per `references/agent-orchestration.md`:
 
-> **Dispatch: `massa-ai-architecture-specialist`** (role: `architecture-specialist`) — charter `skills/agents/architecture-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, isolated audit slice, or independent verification of high-impact finding
 > - scope: exact files/modules/boundaries in the audit target
-> - permissions: read-only
-> - inputs: shared scope packet; lens sub-mode (`domain` for bounded-context mapping, `coupling` for dependency-graph/strength/distance/volatility, `deepening` for module-depth opportunities); recalled ADRs and rejected refactors
+> - inputs: shared scope packet; `lens: architecture` with optional `sub-mode` (`domain` for bounded-context mapping, `coupling` for dependency-graph/strength/distance/volatility, `deepening` for module-depth opportunities); recalled ADRs and rejected refactors
 > - sensors: `search_definitions` / `get_references` for exported surfaces and dependency direction; source inspection against current files
 > - output: findings with lens-specific evidence, provisional severity, tradeoff, and what would disprove it
 > - firewall: raw dependency graphs, generated reports, and broad search output summarized, not returned raw
 > - memory: suggest-only; main agent persists accepted constraints/rejected refactors
 
-> **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: independent verification of a high-impact architecture finding
 > - scope: the specific finding's claimed evidence and affected boundary/module
 > - inputs: the candidate finding, its source evidence, ADRs, accepted exceptions, and the verification suggestion

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

@@ -63,7 +63,7 @@ Not for findings-only architecture review — route to `workflows/architecture/a
    - Coupling: reduce strength before distance; replace internal model sharing with explicit contracts, remove cross-boundary knowledge of internals, invert dependencies at stable seams, keep cohesive local coupling close, and avoid cycles.
    - Deepening: delete shallow pass-through modules, merge split concepts when locality improves, deepen useful interfaces by hiding invariants and ordering, test through the interface, and clarify seams only where variation, dependency direction, external I/O, or test substitution justifies it.
    - When a deepening candidate has two or more viable interface shapes, load the Interface Design Method from `references/architecture-deepening-lens.md` (Design It Twice) and pick by leverage and locality before editing.
-   - When you decide not to apply a reported refactor, record the load-bearing reason; if likely to recur, offer an ADR via `workflows/adr.md` so the rejection is not re-litigated.
+   - When you decide not to apply a reported refactor, record the load-bearing reason; if likely to recur, offer an ADR via `workflows/create-adr.md` so the rejection is not re-litigated.
    - Prefer move, merge, inline, or clarify existing seams before adding new abstractions.
    - Use ports/adapters or anti-corruption layers only when the report evidence shows real volatility, boundary pressure, external dependency pressure, model leakage, or at least two real adapters such as production plus test.
    - Do not turn a local code-quality concern into an architecture migration; route broad new design, VSA migration, new service boundaries, or unclear ownership to `workflows/spec-driven.md`.
@@ -73,7 +73,7 @@ Not for findings-only architecture review — route to `workflows/architecture/a
    - Update tests, docs, and imports only where required by the architecture fix.
 10. Use agent orchestration only when it improves signal — except the verifier dispatch below, which is tier-gated mandatory rather than discretionary, carved out under `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 architecture finding with a disjoint write set
 > - permissions: write (disjoint write set)
@@ -83,17 +83,16 @@ Not for findings-only architecture review — route to `workflows/architecture/a
 > - firewall: raw diffs/logs summarized
 > - memory: suggest-only; main agent persists reusable architecture 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 of the architecture finding complete, before the verification gate — never optional
 > - scope: the fix's diff surface and its task/AC context
-> - permissions: read-only
 > - inputs: diff, ARCH 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 architecture fix items before verification runs
 > - firewall: summarized findings only, never raw diff dumps
 > - memory: suggest-only; main agent persists review outcomes for the architecture fix
 
-> **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-sized findings or high/critical severity, per the Independent Verification Mandate in `references/verification-ladder.md`'s Mandatory Verification Fix Gate; Quick-tier findings take the fallback below instead
 > - scope: the fixed finding's dependency direction, seam/adapter shape, tests, imports, and report claim closure
 > - inputs: the finding, the applied fix, the verification suggestion, dependency-direction/import-cycle evidence, and validation assets
@@ -107,7 +106,7 @@ Not for findings-only architecture review — route to `workflows/architecture/a
    - 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.
-   - Run the sensors at the mandate's own tier gate: dispatch the verification-agent block above at Standard+/Spec-driven size or high/critical severity; a Quick-tier finding runs its fallback fresh-eyes self-check instead — the hop is skippable, the check never is.
+   - Run the sensors at the mandate's own tier gate: dispatch the `code-reviewer` `verify` block above at Standard+/Spec-driven size or high/critical severity; a Quick-tier finding runs its fallback fresh-eyes self-check instead — the hop is skippable, the check never is.
    - A surviving mutant on the discrimination sensor marks the finding's Closure Matrix row `blocked` and records a `surviving_mutant` signal via `references/lessons.md`.
    - The fix→re-verify loop is capped per `references/verification-ladder.md`'s Bounded Fix→Re-verify Loop; exhausting it also marks the row `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/bugs/bugs-audit.md

@@ -28,12 +28,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 or accept 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, Bugs 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 bugs audit target — files, diffs, suspicious paths
-> - permissions: read-only
 > - inputs: shared scope packet; `lens: bugs`; recalled regressions, known bug patterns, accepted exceptions
 > - sensors: trace input -> transformation -> output; check diffs, callers/callees, tests, config, migrations; prioritize correctness bugs, crashes, data loss, security regressions, broken contracts, async/race issues
 > - output: findings with bug category, location, evidence, trigger, severity, confidence, simplest fix direction, verification suggestion

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

@@ -62,7 +62,7 @@ Not for findings-only bug discovery — route to `workflows/bugs/bugs-audit.md`.
    - Do not weaken tests, fixtures, snapshots, types, or public contracts to make the fix pass.
 9. Use agent orchestration only when it improves signal, except independent verification of the bug fix, which is mandated at the tiers named in `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 bug finding with a disjoint write set
 > - permissions: write (disjoint write set)
@@ -72,17 +72,16 @@ Not for findings-only bug discovery — route to `workflows/bugs/bugs-audit.md`.
 > - firewall: raw diffs/logs summarized
 > - memory: suggest-only; main agent persists reusable bug 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 bug-fix size or high/critical bug severity, per the Independent Verification Mandate tier gate in `references/verification-ladder.md`
 > - scope: the fixed bug finding's repro path, regression tests, and report claim closure
 > - inputs: the bug finding, the applied root-cause fix, the verification suggestion, and validation assets
@@ -100,7 +99,7 @@ Not for findings-only bug discovery — route to `workflows/bugs/bugs-audit.md`.
    - 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.
    - Run the report's verification suggestion when available.
    - The red→green reproduction proves the regression test catches this bug; the discrimination sensor proves that same assertion would also discriminate against a future wrong implementation — complementary, and both required at Standard+.
-   - At the tiers named in the verification-agent dispatch's trigger above, run the discrimination sensor per `references/discrimination-sensor.md` against the divergence-point fix; a surviving mutant marks the finding's closure row `blocked` and records the `surviving_mutant` lessons signal even when the reproduction test is green.
+   - At the tiers named in the `code-reviewer` `verify` dispatch's trigger above, run the discrimination sensor per `references/discrimination-sensor.md` against the divergence-point fix; a surviving mutant marks the finding's closure row `blocked` and records the `surviving_mutant` lessons signal even when the reproduction test is green.
    - The fix→re-verify cycle is capped per `references/verification-ladder.md`'s Bounded Fix→Re-verify Loop.
    - Run focused regression tests first, then relevant lint/type/build/test commands when feasible.
    - Confirm validation assets were not weakened.

package/skills/massa-ai/workflows/code-quality/code-quality-audit.md

@@ -42,12 +42,11 @@ Findings-only: do not edit code unless the user separately asks for fixes.
    - Load it only for large PRs, codebase-wide audits, explicit parallel/subagent requests, or independent verification of judgment-heavy findings.
    - Keep the audit local for small scopes, unresolved user intent, tightly coupled code without clear owners, or platforms that do not permit subagents.
    - The main agent still owns scope, memory recall, static leads, synthesis, final report, persistence, and Evidence Gate.
-    - If delegating, dispatch `audit-specialist` with `lens: code-quality` per `references/agent-orchestration.md`:
+    - If delegating, dispatch `code-reviewer` in `audit` mode with `lens: code-quality` per `references/agent-orchestration.md`:
 
-> **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 PR, codebase-wide audit, explicit parallel/subagent request, or independent verification of judgment-heavy finding
 > - scope: bounded read-only slice of the audit target
-> - permissions: read-only
 > - inputs: shared scope packet; `lens: code-quality`; quality dimensions (SOLID, Clean Code, KISS/YAGNI, DRY, maintainability)
 > - sensors: static scans for type-tag branches, concrete construction, half-finished surfaces; source inspection
 > - output: findings with smell category, location, evidence, severity, confidence, and simplest fix direction

package/skills/massa-ai/workflows/code-quality/code-quality-fix.md

@@ -60,9 +60,9 @@ Not for findings-only SOLID, Clean Code, KISS, YAGNI, DRY, maintainability, or o
    - Run or identify characterization tests before changing behavior-adjacent code.
    - Do not weaken tests, fixtures, snapshots, types, or public contracts to make cleanup pass.
    - Prefer small reversible edits; verify after each finding or coherent group.
-10. Use agent orchestration only when it improves signal — except the verification-agent dispatch below, which `references/agent-orchestration.md`'s Independent Verification Exception mandates at the tiers named in its trigger regardless of signal improvement. Dispatch per `references/agent-orchestration.md`:
+10. Use agent orchestration only when it improves signal — except the `code-reviewer` `verify` dispatch below, which `references/agent-orchestration.md`'s Independent Verification Exception mandates at the tiers named in its trigger regardless of signal improvement. 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 code-quality finding or disjoint file group
 > - permissions: write (disjoint write set)
@@ -72,17 +72,16 @@ Not for findings-only SOLID, Clean Code, KISS, YAGNI, DRY, maintainability, or o
 > - firewall: raw diffs/logs summarized
 > - memory: suggest-only; main agent persists reusable code-quality 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 of the CQ finding complete, before the verification gate — never optional
 > - scope: the fix's diff surface and its task/AC context
-> - permissions: read-only
 > - inputs: diff, CQ 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 CQ fix items before verification runs
 > - firewall: summarized findings only, never raw diff dumps
 > - memory: suggest-only; main agent persists review outcomes for the code-quality fix
 
-> **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 at Standard+/Spec-driven finding size or high/critical severity; at Quick size the subagent hop is skipped and the standalone fresh-eyes check below runs instead
 > - scope: the fixed finding's behavior-preservation claim over the moved/transformed code, its call sites/imports, and report claim closure
 > - inputs: the finding, the applied fix, the verification suggestion, and validation assets

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

@@ -12,7 +12,7 @@ Use when the user wants to draft a commit message, prepare a commit, or commit c
 
 Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-Not for Jira ticket creation, release notes, changelogs, PR descriptions, or history rewriting. Route Jira issue work to `workflows/ticket.md`. Route broad release documentation to the relevant feature, RFC, or general workflow.
+Not for Jira ticket creation, release notes, changelogs, PR descriptions, or history rewriting. Route Jira issue work to `workflows/create-ticket.md`. Route broad release documentation to the relevant feature or RFC workflow.
 
 ## Workflow
 
@@ -24,8 +24,8 @@ Not for Jira ticket creation, release notes, changelogs, PR descriptions, or his
    - unstaged changed paths from `git diff --name-only`
    - status summary from `git status --short`
    - staged diff when anything is staged; otherwise the unstaged diff for allowed paths
-4. Extract the first Jira key from the branch with case-insensitive regex `(?<![A-Z0-9])([A-Z][A-Z0-9]{1,9}-[0-9]+)(?![A-Z0-9])`. Normalize to uppercase. If no key is found, proceed without a prefix and do not ask. An explicit task key (from `workflows/ticket.md` for phased work, or from the user) takes precedence over the branch-derived key.
-   - **Phased work — one commit per task, prefixed with the task's sub-task key.** When committing phased work sourced from `workflows/ticket.md`, each Task inside a Phase/Wave is exactly **one atomic commit** (never batched; the one-commit-per-task cadence is owned by the Implementation Delivery Protocol, Stage 2). Prefix that commit's subject with the Task's Jira **sub-task** key as `[XXX-YYYY]`, e.g. `[SA-142] feat(auth): reject expired tokens` — same `[<KEY>] ` rule below, sub-task key replacing the generic branch key.
+4. Extract the first Jira key from the branch with case-insensitive regex `(?<![A-Z0-9])([A-Z][A-Z0-9]{1,9}-[0-9]+)(?![A-Z0-9])`. Normalize to uppercase. If no key is found, proceed without a prefix and do not ask. An explicit task key (from `workflows/create-ticket.md` for phased work, or from the user) takes precedence over the branch-derived key.
+   - **Phased work — one commit per task, prefixed with the task's sub-task key.** When committing phased work sourced from `workflows/create-ticket.md`, each Task inside a Phase/Wave is exactly **one atomic commit** (never batched; the one-commit-per-task cadence is owned by the Implementation Delivery Protocol, Stage 2). Prefix that commit's subject with the Task's Jira **sub-task** key as `[XXX-YYYY]`, e.g. `[SA-142] feat(auth): reject expired tokens` — same `[<KEY>] ` rule below, sub-task key replacing the generic branch key.
 5. Resolve commit scope:
    - If files are already staged, treat staged files as the user-selected commit scope and do not stage additional files.
    - If nothing is staged and the user explicitly asked to commit, stage only allowed changed files one path at a time with pathspec-safe commands.

package/skills/massa-ai/workflows/{adr.md → create-adr.md}

@@ -1,6 +1,6 @@
 ---
-name: adr
-description: "Use this workflow to record a finalized or being-finalized architecture decision; route open options to rfc and implementation planning to tdd."
+name: create-adr
+description: "Use this workflow to record a finalized or being-finalized architecture decision; route open options to create-rfc and implementation planning to create-tdd."
 license: MIT
 metadata:
   version: "1.1.0"
@@ -8,17 +8,17 @@ metadata:
 
 ### 📜 ADR (Architecture Decision Record)
 
-Record a finalized or being-finalized architecture decision. Not for deciding among open options — route undecided proposals to `workflows/rfc.md`. Not for implementation planning — route that to `workflows/tdd.md`.
+Record a finalized or being-finalized architecture decision. Not for deciding among open options — route undecided proposals to `workflows/create-rfc.md`. Not for implementation planning — route that to `workflows/create-tdd.md`.
 
 Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-1. Resolve/reuse `projectId` and `workflowSessionId`: `adr-[entity]`.
+1. Resolve/reuse `projectId` and `workflowSessionId`: `create-adr-[entity]`.
 2. Load shared references:
-   - `references/adr-authoring.md` always.
+   - `references/create-adr.md` always.
    - `references/context-firewall.md` before reading large Markdown files, Atlassian pages, NotebookLM outputs, Figma exports, broad research, or verbose source output.
    - `references/mobile-context.md` only when ADR context touches KMP, iOS, Android, native bridges, mobile lifecycle, offline sync, permissions, push/background behavior, local persistence, or backend-mobile contracts.
 3. `recall` -> load previous decisions, related RFCs, PRDs, discussions, superseded ADRs, accepted constraints, rejected options, and project-specific ADR conventions for the entity.
-4. Gather source context using `references/adr-authoring.md`:
+4. Gather source context using `references/create-adr.md`:
    - Use explicitly provided Markdown files and prompt context first.
    - Use ADR templates, PRDs, and RFCs from Markdown or Atlassian MCP when provided.
    - Use optional complementary-stack ADRs (Markdown or Atlassian MCP) as cross-stack context only when they affect contracts, constraints, dependencies, risks, or links.
@@ -27,12 +27,12 @@ Load `references/project-context.md` (intake sweep) before the first substantive
    - When Figma links, nodes, desktop selections, or screenshots materially affect the decision, use `workflows/design.md` as optional child context for mobile UI implications only; the ADR still owns the decision record. Screenshots are context-only unless paired with structured Figma evidence.
    - Use NotebookLM only when the user provides one or more notebook IDs; query each relevant notebook separately, preserve attribution, and do not assume a default notebook.
    - Corroborate with massa-ai search, current repo docs, existing ADRs, and code when the decision depends on current project reality.
-5. Run the ADR readiness gate from `references/adr-authoring.md`:
+5. Run the ADR readiness gate from `references/create-adr.md`:
    - If a needed PRD, RFC, template, decision detail, or source fact is absent, ask for the missing context instead of inventing it.
-   - If an RFC is needed but absent and the user does not know the missing context, assume the decision is not made and route to `workflows/rfc.md`.
+   - If an RFC is needed but absent and the user does not know the missing context, assume the decision is not made and route to `workflows/create-rfc.md`.
    - Require a source-backed or user-confirmed title, date, status, context, decision, consequences, links, and supersession status before drafting.
-6. Draft the ADR using the project's template when available; otherwise use the format selected via `references/adr-authoring.md`'s fallback questions. Tie claims to source confidence: confirmed, user-provided, recalled, inferred, or unresolved.
-7. Run the configured Plan Challenge Gate before saving. ADR decisions require the full gate under the default policy (`adr` is named in the full-gate set of the canonical Plan Challenge Policy); revise valid critical or high findings before the record is written, especially a decision presented without its rejected alternatives, consequences stated only as benefits, an unstated assumption the decision depends on, and status quo or sunk-cost bias in the framing. A challenge that invalidates the decision means the decision is not final — route to `workflows/rfc.md` rather than recording it.
+6. Draft the ADR using the project's template when available; otherwise use the format selected via `references/create-adr.md`'s fallback questions. Tie claims to source confidence: confirmed, user-provided, recalled, inferred, or unresolved.
+7. Run the configured Plan Challenge Gate before saving. ADR decisions require the full gate under the default policy (`create-adr` is named in the full-gate set of the canonical Plan Challenge Policy); revise valid critical or high findings before the record is written, especially a decision presented without its rejected alternatives, consequences stated only as benefits, an unstated assumption the decision depends on, and status quo or sunk-cost bias in the framing. A challenge that invalidates the decision means the decision is not final — route to `workflows/create-rfc.md` rather than recording it.
 8. Save the generated ADR using the selected output target:
    - Default: write to the project's standard ADR directory in Default mode. In Plan Mode, propose the path and content without writing.
    - Confluence: when requested and a parent page link is provided, write a child page through Atlassian MCP and report the resulting page link.

package/skills/massa-ai/workflows/{to-prd.md → create-prd.md}

@@ -1,12 +1,12 @@
 ---
-name: to-prd
+name: create-prd
 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."
 license: MIT
 metadata:
   version: "1.2.0"
 ---
 
-### To-PRD (Conversation → Product Requirements Document)
+### Create-PRD (Conversation → Product Requirements Document)
 
 This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know. The PRD follows the same pattern as `references/spec-driven/specify.md`: definitions, required sections, and directions are shared so a PRD produced here is structurally consistent with a feature spec produced by spec-driven Specify.
 
@@ -180,10 +180,10 @@ Apply the `ready-for-agent` triage label — no need for additional triage.
 
 ## Done
 
-To-PRD is done when every requirement has an ID, acceptance criteria are testable EARS statements, edge cases are named, out-of-scope boundaries are explicit, implicit-requirement dimensions are resolved or marked `N/A because <reason>`, the Requirement Closure Gate is satisfied, and `validate_spec.ts` exits clean (or the no-code-execution-tool fallback was applied).
+Create-PRD is done when every requirement has an ID, acceptance criteria are testable EARS statements, edge cases are named, out-of-scope boundaries are explicit, implicit-requirement dimensions are resolved or marked `N/A because <reason>`, the Requirement Closure Gate is satisfied, and `validate_spec.ts` exits clean (or the no-code-execution-tool fallback was applied).
 
 ## Massa-ai Integration
 
 - **Code analysis:** Use massa-ai tools first (`list_projects`, `search`, `project_map`, `optimized_context`) before `ast-grep`/`rg`/`grep` for the explore step. Current source overrides a stale index or memory (source-precedence rule).
-- **Memory:** Persist verified outcomes worth reusing with `remember`, tagging `project:<id>`, `session:<id>`, `workflow:to-prd`, `entity:<slug>`, `memory:working|episodic|semantic|procedural`.
+- **Memory:** Persist verified outcomes worth reusing with `remember`, tagging `project:<id>`, `session:<id>`, `workflow:create-prd`, `entity:<slug>`, `memory:working|episodic|semantic|procedural`.
 - **Validation:** Evidence-or-zero. Every requirement resolved and assumption logged is checked against current source.