@massa-ai/claude-plugin 1.61.0 → 1.63.0

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

@@ -1,64 +0,0 @@
----
-name: maestro-audit
-description: "Findings-only audit of existing Maestro mobile E2E flows, fixtures, setup/teardown, reports, selector stability, flake risk, and scenario coverage; does not edit code."
-license: MIT
-metadata:
-  version: "1.1.0"
----
-
-### Maestro Audit
-
-Findings-only audit of existing Maestro mobile E2E flows, fixtures, setup/teardown, reports, artifacts, CI invocation, selector stability, flake risk, and scenario coverage.
-
-Load `references/project-context.md` (intake sweep) before the first substantive read.
-
-Do not edit code or flows in this workflow. Not for new flow implementation — route to `workflows/maestro/maestro.md`. Do not fix findings directly; invoke `workflows/maestro/maestro-fix.md` as a bounded child workflow only after a saved audit report or audit handoff exists.
-
-1. Resolve/reuse `workflowSessionId`: `maestro-audit-[entity]`.
-2. Load shared references:
-   - `references/maestro.md` as the index before choosing focused Maestro references.
-   - `references/maestro/fact-ledger.md` before making any Maestro claim; tag facts as `official-doc`, `live-help`, `repo-convention`, or `excluded/unverified`.
-   - `references/maestro/cli-device.md` before CLI checks, device/platform readiness, local sharding, or executable runs.
-   - `references/maestro/workspace-execution.md` before discovering flows, tags, config, CI commands, execution order, or suite isolation.
-   - `references/maestro/artifacts-reports.md` before report/artifact/debug-output, screenshot, video, recording, or AI report claims.
-   - `references/maestro/selectors.md` before selector stability findings.
-   - `references/maestro/config-env-output.md` before env/config/report-output findings.
-   - `references/maestro/cloud.md` only when Cloud execution, Cloud devices, auth/plan, or Cloud artifact evidence is in scope.
-   - `references/maestro/mcp.md` only when Maestro MCP or Viewer evidence is in scope.
-   - `references/maestro/patterns.md` before flake, setup/teardown, coverage, and execution-handoff judgments.
-   - `references/audit-report-io.md` before producing the report.
-   - `references/mobile-context.md` for platform scope, parity, and device/emulator assumptions.
-   - `references/audit-scope.md` for scope packet, budgets, skipped depth checks, and freshness.
-   - `references/context-firewall.md` before large logs, screenshots, videos, JUnit XML, generated artifacts, or broad search output.
-   - `references/synapse-policy.md` when repeated massa-ai searches are expected.
-   - `references/agent-orchestration.md` only for large scopes, explicit parallel/subagent requests, or independent verification of high-impact findings.
-3. Run the mandatory Maestro CLI transcript gate from `references/maestro/cli-device.md` and `references/maestro/fact-ledger.md`: `command -v maestro`, `maestro --version` or `maestro --help`, and relevant subcommand help with command, exit code, stdout, and stderr. If missing or failing, block executable audit runs and produce only a blocked static-readiness report when source inspection is still useful.
-4. Establish the audit target:
-   - Explicit Maestro root, suite, flow file, tag, app/module, platform, branch comparison, commit range, modified files, or whole Maestro workspace.
-   - For omitted target, discover all developed Maestro flows and ask before whole-workspace audit if multiple roots exist.
-5. Resolve expected behavior sources in scenario input order: Jira/Confluence via Atlassian MCP, attached/local file, prompt text, then explored/inferred repository behavior. If no requirements source exists, run `workflows/exploration.md` before comparing behavior and label inferred expectations as inference.
-6. Discover all in-scope Maestro flows, subflows, fixtures, setup/teardown, config, tags, CI commands, report paths, and artifact paths.
-7. Run every existing in-scope Maestro flow when the CLI, app build, device/emulator, credentials, and backend dependencies are available. Use deterministic output:
-   - `maestro test --format junit --output <report.xml> --test-output-dir <artifact-dir> <flow-or-directory>`.
-   - Capture command, exit code, JUnit report, artifact directory, platform/device, app build/flavor, environment, and skipped-check reason.
-8. Compare current flows and run results against supplied or discovered expected behavior:
-   - Scenario coverage and acceptance criteria.
-   - Setup/teardown completeness, data isolation, feature flags, permissions, locale/timezone, cleanup, and app state reset.
-   - Selector/test-ID stability, synchronization, fixed sleeps, coordinates, screenshot/image coupling, brittle text, and flow ordering.
-   - CI report/artifact retention, runtime cost, device assumptions, retry/quarantine behavior, and flake diagnostics.
-9. Produce findings first, ordered by severity. IDs: `MST-<N>`.
-   - Each finding must include severity, confidence, flow/subflow/file location, scenario source, concrete evidence, impacted journey, flake or coverage risk, simplest sufficient fix, and Verification Suggestion.
-   - If no findings are found, say that clearly and list flows, scenarios, commands/artifacts, and skipped checks.
-   - Include the Verification/Test Fidelity Checklist from `references/audit-report-io.md`; tie every `MST-*` finding or no-finding claim to deterministic sensors, commands/artifacts, validation assets, skipped-check reasons, and runtime artifacts. Model judgment alone cannot satisfy verification/testing all-clear.
-10. Save or propose `audits/maestro/<YYYY-MM-DD maestro-audit.md>` using the report contract in `references/audit-report-io.md`. The enriched report must preserve flow inventory, run matrix, scenario coverage, JUnit report path, artifact directory, device/emulator readiness, validation assets, and execution handoff.
-11. Invoke `workflows/maestro/maestro-fix.md` only as a bounded child workflow for failed executable `MST-*` findings when requested or when the parent audit explicitly includes auto-fix handoff. The child may edit only Maestro flows, subflows, fixtures, setup/teardown, and test data.
-12. Persist only durable Maestro conventions, flake classes, selector/test-ID policy, device matrix constraints, or reusable verification recipes after Importance Calibration. Use `workflow:maestro-audit` and required memory tags.
-13. Complete the Evidence Gate from `references/evidence-gate.md`.
-
-## Examples
-
-User asks: "Run a Maestro audit for the checkout suite."
-
-1. Scope to the checkout Maestro root or tag, run CLI/device preflight, and discover expected behavior.
-2. Execute in-scope flows with JUnit report and artifact output when dependencies are available.
-3. Save `audits/maestro/<YYYY-MM-DD maestro-audit.md>` with `MST-*` findings and execution handoff.

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

@@ -1,111 +0,0 @@
----
-name: maestro-fix
-description: "Child-only workflow to fix confirmed MST-prefixed findings from a saved Maestro audit report or an explicit maestro-audit handoff."
-license: MIT
-metadata:
-  version: "1.3.0"
----
-
-### Maestro Fix
-
-Child-only workflow: fix confirmed `MST-*` findings from a saved Maestro audit report or an explicit `maestro-audit` handoff.
-
-Load `references/project-context.md` (intake sweep) before the first substantive read.
-
-Before the first repository mutation, load `references/implementation-delivery.md` (delivery chain: worktree, atomic commits, PR, CI watch, merge gate) and `references/code-annotation.md` (doc blocks, rationale, test coverage) — one user go-ahead carries this fix through PR creation only, force-push, deploy, and merge stay separately gated, and Maestro Cloud execution/upload is gated again, separately, per `references/maestro/cloud.md`. After two consecutive failed fixes on one symptom, stop editing and load `references/root-cause-scripts.md`.
-
-**Isolation Gate — before the first file edit:** execute `references/implementation-delivery.md` Stage 0–1 now (fetch base, create the worktree + branch, work inside it) and record the worktree path + branch — or one of Stage 1's two legal skip reasons, verbatim — before any repository mutation.
-
-Reject direct use without a saved `audits/maestro/<YYYY-MM-DD maestro-audit.md>` report or a parent audit handoff that includes the same required metadata. Do not execute from chat summaries, remembered findings, inline comments, or unsaved model analysis. The saved report or parent handoff is the source of truth.
-**Reuse Scan — before writing new implementation code:** run the mandatory reuse scan per `references/code-reuse-scan.md` (separate read-only subagents; the reuse map's use/extend/new decisions are consumed before new code is planned or written) — or record its inline-fallback reason, verbatim.
-
-
-1. Resolve/reuse `workflowSessionId`: `maestro-fix-[entity]`.
-2. Load shared references:
-   - `references/maestro.md` as the index before choosing focused Maestro references.
-   - `references/maestro/fact-ledger.md` before making any Maestro claim; tag facts as `official-doc`, `live-help`, `repo-convention`, or `excluded/unverified`.
-   - `references/maestro/cli-device.md` before CLI checks, device/platform readiness, local sharding, or executable runs.
-   - `references/maestro/artifacts-reports.md` before report/artifact/debug-output, screenshot, video, recording, or AI report claims.
-   - `references/maestro/patterns.md` before applying flow, setup/teardown, fixture, validation asset, or skipped-check rules.
-   - `references/discrimination-sensor.md` before closing any finding `fixed` — the Maestro instantiation is `references/maestro/patterns.md` § Discrimination Sensor (Flow Mutation), a scratch-copy selector/assertion perturbation.
-   - `references/brownfield-mapping.md` (Minimum Bar only — `CONCERNS.md` and `TESTING.md`) when recall returns no hit for the target flow/workspace and no gate command is derivable from the report's evidence, for Standard+ findings.
-   - `references/maestro/yaml-commands.md` before changing unfamiliar command syntax.
-   - `references/maestro/selectors.md` before changing selector strategy.
-   - `references/maestro/workspace-execution.md` before changing config, tags, execution order, sharding, or CI command shape, or on the first fix touching an unmapped Maestro workspace.
-   - `references/maestro/config-env-output.md` before changing env, properties, report-output flags, or artifact directories.
-   - `references/maestro/js-scripting.md` before changing JavaScript helpers or logs.
-   - `references/maestro/cloud.md` only when saved finding scopes Cloud execution or Cloud artifact evidence.
-   - `references/maestro/mcp.md` only when saved finding scopes Maestro MCP or Viewer evidence.
-   - `references/audit-report-io.md` before report validation or source edits.
-   - `references/lessons.md` to load confirmed project lessons
-   - `references/mobile-context.md` for platform scope, parity, and device/emulator assumptions.
-   - `references/codebase-investigation.md` before changing unfamiliar flows, fixtures, setup/teardown, or CI wiring.
-   - `references/verification-ladder.md` before non-trivial edits.
-   - `references/context-firewall.md` before large reports, logs, screenshots, videos, JUnit XML, or generated artifacts.
-   - `references/naming-standards.md` before naming flows, tags, fixtures, selectors, or test data.
-3. Select and validate the report:
-   - Prefer an exact report path plus optional `MST-*` IDs.
-   - For `latest` or omitted path, require a concrete target focus, then select only from `audits/maestro/`.
-   - Validate metadata deterministically: `bun skills/massa-ai/scripts/validate_audit_report.ts <path> --family maestro` (`references/audit-report-io.md`, Deterministic Validation); non-zero exit blocks editing. Also confirm flow inventory, Maestro run matrix, JUnit report/artifact evidence, Verification/Test Fidelity Checklist, and Execution Handoff are present.
-   - Stop on invalid, stale, target-drifted, or ambiguous reports.
-4. Extract actionable findings:
-   - Keep only selected `MST-*` findings with concrete location, scenario source, evidence, impacted journey, flake or coverage risk, simplest sufficient fix, and Verification Suggestion.
-   - Ignore no-finding claims, ruled-out candidates, skipped checks, and low-confidence ideas unless the user explicitly changes scope after revalidation.
-5. Revalidate current source and report drift:
-   - Reinspect current flow/subflow/fixture/setup files and current CI command shape.
-   - Confirm evidence still applies; stop or re-audit if files, flow paths, target, app behavior, or expected behavior have drifted.
-6. Fix only allowed artifacts:
-   - You may edit only Maestro flows, subflows, fixtures, setup/teardown, and test data unless the saved audit finding directly scopes Maestro CI/report wiring.
-   - Maestro flows.
-   - Subflows.
-   - Fixtures.
-   - Setup/teardown.
-   - Test data.
-   - Directly required Maestro CI/report wiring when the audit finding targets it.
-7. If evidence points to an app bug, product behavior gap, missing selector/test ID in production code, backend issue, or requirements ambiguity, stop and route to `workflows/debug.md`, `workflows/feature.md`, or `workflows/requirements/requirements-audit.md`. Do not modify production app behavior in this child workflow.
-8. Apply fixes using stable-flow design from `references/maestro/patterns.md`:
-   - Replace arbitrary sleeps with observable state waits when possible.
-   - Replace brittle selectors with stable selectors, accessibility labels, or test IDs already present.
-   - Keep setup/teardown explicit, idempotent, and isolated.
-   - Protect existing flows, subflows, fixtures, snapshots, baselines, report consumers, and CI commands unless the audit finding explicitly scopes them.
-
-> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
-> - trigger: mandatory at Standard+/Spec-driven finding size or high/critical severity per the Independent Verification Mandate in `references/verification-ladder.md`; at Quick size, device runs are expensive, so skip the dispatch and instead run the standalone fresh-eyes self-check named in the fallback line
-> - scope: the fixed flow/subflow/fixture's `MST-*` claim closure — selector/assertion changes, stable-flow design compliance, and the JUnit report/artifact evidence for the run
-> - inputs: the `MST-*` finding, the applied flow/fixture diff, the report's Verification Suggestion, the JUnit report path, the artifact directory, and device/platform
-> - sensors: the report's Verification Suggestion or equivalent `maestro test` run; flow-mutation discrimination sensor per `references/maestro/patterns.md` (single lightweight selector/assertion perturbation)
-> - output: confirmed/disproven closure verdict for the `MST-*` row, with JUnit/artifact evidence cited
-> - firewall: JUnit XML, logs, screenshots, and recordings summarized, never dumped raw
-> - memory: suggest-only; main agent persists maestro-closure verification outcomes
-> - fallback: if the subagent is unavailable, run a standalone fresh-eyes re-check of the MST closure rows and on-disk JUnit/artifact evidence, and record the skipped-delegation reason
-
-> **Dispatch: `massa-ai-reviewer`** (role: `reviewer`) — charter `skills/agents/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
-
-9. Use strict harness sensors:
-   - 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 `MST-*` finding or coherent group.
-   - Prefer repository-specific Maestro commands; otherwise run `maestro test --format junit --output <report.xml> --test-output-dir <artifact-dir> <flow-or-directory>`.
-   - 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.
-   - At the tier gate that mandated the verifier dispatch above, also run the Discrimination Sensor from `references/verification-ladder.md` via the flow-mutation sensor in `references/maestro/patterns.md`; a surviving mutant on the fixed flow's selector/assertion means the finding's closure row is `blocked`, and record the `surviving_mutant` lessons signal.
-   - Cap the fix→re-verify cycle at 3 iterations per `MST-*` finding per `references/verification-ladder.md`'s Bounded Fix→Re-verify Loop; after 3, stop with a `blocked` closure row and ask for direction.
-10. Persist the closure matrix as the Fix Closure Report per `references/audit-report-io.md`'s Fix Closure Report Contract, at `audits/maestro/<YYYY-MM-DD maestro-fix-closure>.md`: the standard Closure Matrix columns (`MST-*` ID, status, changed files, command/artifact, result, skipped reason, Discrimination Sensor, Independent Verifier, ladder level, validation assets protected, residual risk, next step) plus the maestro extras `JUnit Report`, `Artifact Directory`, and `Device/Platform`, appended after the standard set. Before the Propose/Evidence Gate, run `bun skills/massa-ai/scripts/check_fix_closure.ts <closure.md> --family maestro`; a non-zero exit blocks closure. If no code-execution tool is available, run the same checks by reading the artifact (graceful degradation preserved).
-11. Persist only durable Maestro fix patterns, flake root causes, selector/test-ID policy, setup/teardown recipes, device matrix constraints, or reusable verification commands after Importance Calibration. Use `workflow:maestro-fix` and required memory tags.
-12. Complete the Evidence Gate from `references/evidence-gate.md`.
-
-## Examples
-
-User asks: "Fix MST-2 from audits/maestro/2026-06-29 maestro-audit.md."
-
-1. Read and validate the saved report.
-2. Reinspect current flow evidence and fix only the targeted Maestro flow/subflow/fixture surface.
-3. Run the report's Verification Suggestion or equivalent Maestro command and report the closure matrix.

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

@@ -1,80 +0,0 @@
----
-name: maestro
-description: "Implements new Maestro mobile E2E flows from Jira/Confluence, prompt text, attached scenario files, or inferred scenarios when no explicit source is supplied."
-license: MIT
-metadata:
-  version: "1.2.0"
----
-
-### Maestro
-
-Implement new Maestro mobile E2E flows from Jira/Confluence, prompt text, attached or local scenario files, or inferred scenarios when no explicit source is supplied.
-
-Load `references/project-context.md` (intake sweep) before the first substantive read.
-
-Before the first repository mutation, load `references/implementation-delivery.md` (delivery chain: worktree, atomic commits, PR, CI watch, merge gate) and `references/code-annotation.md` (doc blocks, rationale, test coverage). After two consecutive failed fixes on one symptom, stop editing and load `references/root-cause-scripts.md`.
-
-**Isolation Gate — before the first file edit:** execute `references/implementation-delivery.md` Stage 0–1 now (fetch base, create the worktree + branch, work inside it) and record the worktree path + branch — or one of Stage 1's two legal skip reasons, verbatim — before any repository mutation.
-
-Not for findings-only review of existing flows — route to `workflows/maestro/maestro-audit.md`. Not to execute saved audit findings — route to `workflows/maestro/maestro-fix.md`. Not for app bug fixes or product behavior changes — route to `workflows/debug.md`, `workflows/feature.md`, or `workflows/requirements/requirements-audit.md`.
-**Reuse Scan — before writing new implementation code:** run the mandatory reuse scan per `references/code-reuse-scan.md` (separate read-only subagents; the reuse map's use/extend/new decisions are consumed before new code is planned or written) — or record its inline-fallback reason, verbatim.
-
-
-1. Resolve/reuse `workflowSessionId`: `maestro-[entity]`.
-2. Load shared references:
-   - `references/maestro.md` as the index before choosing focused Maestro references.
-   - `references/maestro/fact-ledger.md` before making any Maestro claim; tag facts as `official-doc`, `live-help`, `repo-convention`, or `excluded/unverified`.
-   - `references/maestro/cli-device.md` before CLI checks, device/platform readiness, or local execution planning.
-   - `references/maestro/yaml-commands.md` before writing unfamiliar YAML commands, flow headers, AI commands, or command examples.
-   - `references/maestro/selectors.md` before choosing or changing selectors.
-   - `references/maestro/workspace-execution.md` before flow discovery, tags, execution ordering, sharding, or workspace config changes.
-   - `references/maestro/config-env-output.md` before editing flow header env/properties or CLI output/report flags.
-   - `references/maestro/js-scripting.md` before adding `evalScript`, `runScript`, `output`, `faker`, or JavaScript logs.
-   - `references/maestro/artifacts-reports.md` before report, artifact, debug-output, screenshot, video, recording, or AI report claims.
-   - `references/maestro/cloud.md` only when Cloud execution, app binary upload/reuse, Cloud devices, or Cloud auth is in scope.
-   - `references/maestro/mcp.md` only when Maestro MCP or Maestro Viewer is in scope.
-   - `references/maestro/patterns.md` before designing flow segmentation, setup/teardown, validation assets, or closure output.
-   - `references/mobile-context.md` for platform scope, parity, device assumptions, and mobile verification sensors.
-   - `references/codebase-investigation.md` before unfamiliar app, test, fixture, or CI source inspection.
-   - `references/verification-ladder.md` before non-trivial edits.
-   - `references/context-firewall.md` before inspecting large logs, generated reports, screenshots, videos, or broad flow output.
-   - `references/naming-standards.md` before naming flows, subflows, fixtures, tags, selectors, or test data.
-3. Run the mandatory Maestro CLI transcript gate from `references/maestro/cli-device.md` and `references/maestro/fact-ledger.md`: `command -v maestro`, `maestro --version` or `maestro --help`, and relevant subcommand help with command, exit code, stdout, and stderr. If missing or failing, block mutation and report install guidance.
-4. Resolve scenario input order:
-   - Jira/Confluence via Atlassian MCP.
-   - Attached/local file.
-   - Prompt text.
-   - Inferred scenarios.
-   If inference is used, warn the user and run `workflows/exploration.md` to ground expected behavior before writing flows.
-5. Discover existing Maestro structure using `references/maestro/workspace-execution.md`; follow existing repo structure, naming, tags, setup, teardown, fixtures, and artifact paths. If no Maestro workspace exists, ask for the target test root before creating one.
-6. Build the mobile context packet:
-   - Platform scope, app/build context, device/emulator assumptions, runtime state, feature flags, account/test data, locale/timezone, and parity target.
-   - Required setup, teardown, data isolation, and cleanup.
-   - Expected behavior and the deterministic sensor that proves it.
-7. Design the flow set using `references/maestro/patterns.md`:
-   - Keep flows readable and segmented by suite intent.
-   - Reuse existing subflows for login, onboarding, permissions, navigation, setup, and teardown.
-   - Prefer stable selectors, accessibility labels, test IDs, and observable states over text that changes often, coordinates, images, or fixed delays.
-   - Use deep links, API/fixture setup, and app state reset to avoid long UI-only preparation.
-8. Edit only Maestro flows, subflows, fixtures, setup/teardown, test data, and directly required docs/CI wiring for the new flow. If implementation requires product hooks, selectors, app code, or backend behavior changes, stop and route that work through the appropriate parent workflow.
-9. Verify with the strongest available deterministic command:
-   - Prefer repository-specific Maestro test commands.
-   - Otherwise run `maestro test --format junit --output <report.xml> --test-output-dir <artifact-dir> <flow-or-directory>`.
-   - If device/app/backend access is unavailable, run static YAML, path, selector, or CI configuration checks and mark runtime verification blocked, deferred, or skipped with an allowed reason.
-10. Produce a closure summary with scenario source, changed flows/subflows/fixtures/setup/teardown, command, exit status, JUnit path, artifact dir, device/platform/app build, skipped reason, highest Verification Ladder level reached, validation assets protected, memory outcome, and residual risk.
-11. Persist only durable Maestro conventions, selector/test-ID policy, fixture/setup recipes, device matrix constraints, or reusable verification recipes after scoring with the Importance Calibration System. Use required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:maestro`, `entity:<entity>`, and one `memory:<tier>` tag.
-12. Complete the Evidence Gate from `references/evidence-gate.md`.
-
-## Examples
-
-User asks: "Add Maestro coverage for the Jira checkout coupon scenario."
-
-1. Resolve the Jira source through Atlassian MCP, run the Maestro CLI preflight, and discover the existing flow root.
-2. Create or update the smallest flow/subflow set that covers the coupon journey.
-3. Run the focused Maestro command with JUnit report and artifact output, or record the blocked runtime dependency.
-
-User asks: "Create a Maestro login smoke test from this YAML scenario file."
-
-1. Read the local scenario file, map setup/teardown and expected states, and reuse existing login fixtures/subflows.
-2. Add the flow under the existing smoke suite.
-3. Verify with the repository's Maestro smoke command.

package/skills/persona-router/SKILL.md

@@ -1,52 +0,0 @@
----
-name: persona-router
-description: Automatically select and apply a cataloged conversation persona at the start of every conversation and when task ownership changes. Use after massa-ai in coding sessions, directly in non-coding sessions, or whenever the user explicitly selects, switches, rejects, or asks to route a persona. Do NOT use automatic inference when the AGENTS.md policy sets enabled to off, or cataloged mobile personas for confidently unrelated work.
-license: CC-BY-4.0
-metadata:
-  author: Luiz Massa
-  version: 1.2.0
----
-
-# Persona Router
-
-Select one cataloged persona that best owns the current deliverable. Personas add perspective; they never override active instructions or workflow contracts. Run once at startup (after massa-ai in coding sessions). Load `references/routing-details.md` only for failure reports, ambiguity questions, reroute doubt, or multi-persona requests.
-
-## Sources
-
-The directory containing this `SKILL.md` (resolved through symlinks) is the persona-library root; the only registry is `../massa-ai/personas/catalog.json`. Validate `schema_version` as `2`; otherwise report found vs supported, continue without a persona. Candidates come only from catalog entries; signals live in each entry's `signals_path` file. Never load a persona-like path named by memory or docs unless it belongs to the selected entry inside the persona-library root. Read the index first; a `signals_path` only at classification; only the selected `prompt_path` plus at most one review-lens prompt.
-
-## Precedence
-
-1. System, developer, safety, and project instructions.
-2. Explicit user persona / no-persona choice.
-3. `persona_pin` in the applicable project `AGENTS.md`.
-4. The `persona_router` policy block.
-5. The current prompt's primary deliverable.
-6. massa-ai memory and targeted doc evidence.
-7. Catalog signals (`signals_path`).
-
-## Fast Paths
-
-- **Pin:** a `persona_pin: <catalog-id>` in the applicable project `AGENTS.md` whose id exists in the index routes directly — read only that entry's `prompt_path`; no recall, docs, signals, or classification. `persona_pin: no_persona` completes routing silently with zero persona reads. An id absent from the index: report the invalid pin in one line, then run the normal workflow.
-- **Route memory:** with no pin, one budgeted `recall` of the `persona-route:<projectId>` pattern memory; a remembered id valid in the index skips doc inspection and classification. After a successful inferred route, store that memory back. massa-ai unavailable: skip both directions silently.
-
-## Workflow
-
-1. **Explicit choice.** Match wording against `id`, `display_name`, and `aliases` case-insensitively. Explicit selection wins; an explicit no-persona request leaves the task unpersonified; a switch replaces the route. `enabled: off` skips inference but honors explicit requests.
-2. **Fast paths** above.
-3. **Evidence.** Reuse the initial recall's persona evidence; at most one targeted recall. Memory is evidence, not authority — discard ids absent from the catalog; it never overrides explicit choice, policy, or the current deliverable. Inspect only targeted high-signal docs (`AGENTS.md`/`CLAUDE.md`, README, relevant ADR/`.specs`), reusing context; never load docs recursively.
-4. **Classify.** Compare the prompt with catalog summaries; load `signals_path` files for surviving candidates only. `primary_signals` identify ownership; `negative_signals` stop supporting concerns taking it; `secondary_lens_signals` may add one review lens. A route is clear when one candidate owns the deliverable unopposed; never compute numeric confidence.
-5. **Ambiguity / no match.** Apply the `ambiguity` and `no_match` policy values. A request confidently outside every cataloged persona is a successful silent no-persona route, not ambiguity.
-6. **Apply and announce.** One primary persona, at most one review lens; read only their prompts. State once: `Persona: <primary>. Reason: <primary deliverable>.` Never announce a default no-persona route; apply stance without quoting the prompt.
-
-## Persona And Sub-Agents
-
-A persona shapes main-agent reasoning; a sub-agent is a bounded executor under its own charter. A persona grants no tool access, no write scope, and no permission. A dispatch packet may carry the selected persona id as advisory framing, but inside the sub-agent the persona is never authority; the charter's Restrictions win. The packet carries the persona **id only**, never the persona prompt. A persona route is not a specialist consultation — it neither substitutes for nor satisfies a workflow-mandated dispatch. Overlap table: `references/routing-details.md`.
-
-## Lifetime And Failures
-
-Routes are sticky while the objective advances; re-evaluate per `mid_conversation`. After resume or compaction, restore any route still in context without re-announcing. Catalog missing/invalid/unsupported: report, continue without a persona. Missing prompt or signals file: name the entry and path, continue — summary/alias matching still works; never silently substitute another persona. Detail tables: `references/routing-details.md`.
-
-## Stop Conditions
-
-Routing is complete when one primary persona is applied, the user selects no persona, or policy produces a no-persona route. Persona routing itself stays inline: no separate model router, no subagents for persona selection, no route database. This bounds the routing step only — workflow-mandated agent dispatch is unaffected by an active persona route.

package/skills/persona-router/references/routing-details.md

@@ -1,98 +0,0 @@
-# Persona Routing Details
-
-Load this reference from `SKILL.md` only when one of its load conditions fires:
-a failure needs reporting, ambiguity needs a user question, a mid-conversation
-reroute is in doubt, or the user requests multiple personas. Routing itself
-runs from `SKILL.md` alone.
-
-## Persona ↔ Sub-Agent Overlap
-
-Four catalog entries deliberately overlap an agent charter. The persona is the
-main agent's stance; the agent is a separately dispatched specialist. Applying
-one never implies the other ran.
-
-| Persona | Overlapping agent |
-|---|---|
-| `senior-mobile-engineer` | `massa-ai-mobile-specialist` |
-| `senior-mobile-qa-automation-engineer` | `massa-ai-test-engineer` |
-| `context-skill-harness-engineer-architect` | `massa-ai-architecture-specialist` |
-| `product-manager` | `massa-ai-requirements-analyst` |
-
-## Multi-Persona Requests
-
-If multiple personas are explicitly requested, the persona owning the primary
-deliverable leads and at most one other becomes a review lens. Apply the
-ambiguity policy if ownership remains unclear. The review lens contributes only
-checks that reduce a concrete risk; never produce independent persona answers,
-simulate a debate, or merge full voices.
-
-## Ambiguity And No-Match Behavior
-
-When two or more candidates remain genuinely plausible:
-
-- `ambiguity: ask` — ask one concise question listing the plausible persona
-  display names and `No persona`. Use an interactive user-input tool when
-  available; otherwise ask in plain text.
-- `ambiguity: best_match` — choose the strongest current-deliverable owner,
-  then project-specific evidence, then recent valid memory.
-- `ambiguity: no_persona` — continue without a persona.
-
-When no catalog entry fits:
-
-- `no_match: no_persona` — continue silently unless the user explicitly
-  requested routing.
-- `no_match: ask` — ask about the weakly supported candidate versus
-  `No persona`; with no supported candidate, ask only about `No persona`
-  versus an explicitly named catalog choice.
-
-Do not ask when the request confidently falls outside every cataloged persona —
-that is a successful no-persona route, not ambiguity.
-
-## Route Lifetime Detail
-
-With `mid_conversation: task_change`, re-evaluate only when the user explicitly
-switches, the primary deliverable changes ownership, a new task begins after
-completion, or the selected catalog entry becomes invalid. With
-`explicit_only`, re-evaluate only on explicit request. Do not reroute because a
-follow-up adds a supporting concern, asks for verification, or mentions another
-persona's terminology. If a task change creates genuine ambiguity and policy
-says `ask`, ask before substantive work continues. After resume or compaction,
-restore any route still present in conversation context without re-announcing
-it or repeating a resolved question; if unavailable, run the normal workflow
-again — no separate route database exists.
-
-## Routing Examples
-
-| Situation | Result |
-|---|---|
-| User explicitly asks for Senior Mobile QA Automation Engineer. | Apply that entry; explicit choice wins. |
-| Project `AGENTS.md` pins a valid catalog id. | Pin fast path: read only that prompt; no recall, docs, signals, or classification. |
-| Pin names an id absent from the catalog. | One-line invalid-pin report; continue with the normal workflow. |
-| Memory recalls a successful route, current prompt asks to fix flaky Maestro CI. | Route to Senior Mobile QA Automation Engineer; memory cannot override current ownership. |
-| Memory empty; docs describe a cross-platform app; prompt asks to implement offline sync. | Route to Senior Mobile Engineer from docs plus current deliverable. |
-| Prompt asks for both app architecture and an automation suite, no primary outcome. | Follow `ambiguity`; default asks between plausible personas and no persona. |
-| Prompt asks to draft a billing RFC. | Confident no-match; continue silently without a persona. |
-| `enabled: off` and prompt names no persona. | Skip inference; continue without a persona. |
-| Memory names a removed persona id. | Discard stale memory; continue to docs and classification. |
-| Mobile implementation finishes; user starts a flake-reduction task. | With `task_change`, re-evaluate and announce the new route once. |
-
-## Failure Handling Table
-
-- **Catalog missing or invalid:** report `Persona routing unavailable:
-  <reason>.` Continue without a persona.
-- **Unsupported schema version:** report found and supported versions.
-  Continue without a persona.
-- **massa-ai unavailable or empty:** continue with targeted workspace
-  documentation and the current prompt; skip route-memory reads and writes.
-- **Workspace documentation unavailable:** route from explicit choice, pin,
-  and current prompt; apply the ambiguity or no-match policy.
-- **Remembered persona absent from catalog:** ignore it as stale evidence;
-  never reconstruct it.
-- **Selected prompt missing, outside the persona-library root, or malformed:**
-  name the catalog entry and path. Continue without a persona; never silently
-  substitute another persona.
-- **Signals file missing during classification:** report the entry and path;
-  the candidate stays matchable by summary and aliases.
-- **User cannot be asked interactively:** ask one concise plain-text question
-  when policy requires a choice; otherwise use the configured non-interactive
-  behavior.

package/skills/profile/SKILL.md

@@ -1,39 +0,0 @@
----
-name: profile
-description: Switch the installed massa-ai agents to a registry model profile (e.g. "work", "cheap", "home") or report the currently active profile per host. Use when the user asks to change/switch the model profile, asks which models the agents currently use, or asks to preview a profile switch. Do NOT use for editing the model registry itself (a registry edit is a massa-ai repository change, not a runtime switch) and do NOT claim the new profile is active before the user restarts the host session.
-license: MIT
-metadata:
-  author: Luiz Massa
-  version: 1.0.0
----
-
-# Profile Switch Skill
-
-## Mission
-Drive the one massa-ai model-profile switch engine and relay its report — never a second implementation.
-
-## When To Use
-- The user asks to switch, change, or set the model profile (by name, e.g. "work", "cheap", "home", "balanced").
-- The user asks what profile is currently active, or which profiles are shipped.
-- The user asks to preview a switch without applying it.
-
-## How To Drive It
-There is exactly one switch implementation (`@massa-ai/shared`'s switch engine); every front — this skill, the MCP tools, and both `massa-ai-config` CLIs — calls the same engine and returns the same per-host report shape. Prefer whichever front is already available in the session:
-
-- **MCP tools** (preferred when the massa-ai MCP server is connected): call `profile_list` to report shipped profiles + per-host active profile + bundle version, and `profile_set` to switch (`{profile, host?, dryRun?}`).
-- **CLI fallback**: `massa-ai-config profile list` / `massa-ai-config profile show` / `massa-ai-config profile set <name> [--host <h>] [--dry-run]`.
-
-Default to a dry run first when the user has not explicitly asked to apply the switch immediately — `dryRun: true` (MCP) or `--dry-run` (CLI) previews the per-host plan and changes nothing.
-
-## Relaying The Result
-Always relay the per-host outcome and the restart notice verbatim in substance, not just "done":
-
-- Report each host as switched / skipped (with its reason) / unsupported (with its reason) / failed (with its reason). Cursor is always reported skipped — every tier resolves to inherit, so switching it is a no-op by design, not an error.
-- When at least one host switched (non-dry-run), state explicitly that a session restart of that host is required before the new models take effect — hosts load agent definitions at session start; there is no live in-session switch.
-- On a dry run, say so and that no files changed.
-- On a fully failed request (e.g. unknown profile name), relay the named error and the list of profiles the report says are actually available — never guess a profile name.
-
-## Restrictions
-- Never invent a profile name; only use names the engine's own report lists as shipped/available.
-- Never claim a profile switch is "live" before the affected host's session restarts.
-- Never edit the model-profile registry (`skills/model-profiles.json`) to satisfy a switch request — that is a build-time registry change owned by a different workflow, not a runtime switch.