@massa-ai/cursor-plugin 1.6.0

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

@@ -0,0 +1,114 @@
+### Tests Audit
+
+Use this workflow for findings-only audit of test coverage, regression protection, assertion quality, fixture reliability, and missing deterministic sensors in a concrete target: modified files, explicit files/globs, commit ranges, branch comparisons, modules/packages, symbols/classes/functions, feature/runtime flows, explicitly requested whole-repo scope, or an implementation scope packet supplied by `workflows/implementation/implementation-audit.md`.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Do not use this workflow to write, run, or fix test findings as the main task; route that to `workflows/tests/tests-fix.md`. Do not use it for generic correctness, security, architecture, code quality, or requirements findings; route those to the dedicated workflows.
+
+This workflow is findings-only. Do not edit code unless the user separately asks for fixes.
+
+1. Resolve/reuse `workflowSessionId`: `test-audit-[entity]`
+2. Load shared references:
+   - `references/codebase-investigation.md`
+   - `references/audit-scope.md`
+   - `references/audit-report-io.md` before writing the final direct audit report
+   - `references/mobile-context.md` when the scope touches KMP, iOS, Android, native bridges, mobile lifecycle, offline sync, permissions, local persistence, UI snapshots/screenshots, or backend-mobile contracts
+   - `references/context-firewall.md` before inspecting large diffs, logs, snapshots, generated reports, 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, PR subagent invocation, or independent verification of high-impact findings
+3. `recall` -> load testing conventions, mock boundaries, prior flaky tests, known regressions, project constraints, reusable verification recipes, and accepted test exceptions for the target area.
+   - Apply the Memory Freshness Gate from `references/audit-scope.md`; recalled exceptions are leads, not proof.
+4. Establish the investigation scope before proceeding:
+   - Modified files scope: use when the user says modified files, changed files, current changes, uncommitted changes, staged changes, or unstaged changes.
+   - Explicit files/globs scope: use when the user names files, directories, or globs.
+   - Commit range scope: use when the user provides commits/ranges or asks for commits made by me, my branch commits, or test gaps introduced by branch commits.
+   - Branch comparison scope: use when the user names base/head branches, refs, or a branch diff.
+   - Codebase area scope: use when the user names a path, module, package, feature area, test suite, or glob.
+   - Symbol/class/function scope: use when the user names public classes, functions, APIs, handlers, or exported surfaces.
+   - Feature/flow scope: use when the user names a runtime flow, user journey, or feature area.
+   - Whole-repo scope: use only when the user explicitly asks for a whole-repo tests audit.
+   - Implementation parent scope: use only when `workflows/implementation/implementation-audit.md` invokes this workflow with a concrete implementation scope packet.
+   - If the target focus is missing, vague, or too broad, ask for a concrete target from the supported scope types in `references/audit-scope.md`.
+   - Build the shared scope packet from `references/audit-scope.md` and carry it into the report.
+5. For modified files scope:
+   - Include staged and unstaged tracked files from the working tree.
+   - Include untracked non-generated source, test, fixture, schema, config, and docs files only when they can affect runtime, validation, or test behavior.
+   - Exclude deleted files unless their deletion can break test coverage, imports, exports, routing, migrations, config, tests, or packaging.
+   - Exclude generated, dependency, build, log, cache, temporary, and secret paths per repo rules.
+   - Inspect diffs first, then tests and surrounding code needed to understand regression risk.
+6. For commit range scope:
+   - If the user supplied explicit commits or a revision range, use that exact range.
+   - If the user asked for commits made by me, resolve author identity from `git config user.email`; if empty, use `git config user.name`.
+   - For branch-relative commit scopes, resolve the branch base from the upstream merge-base first, then fall back in order to `origin/main`, `origin/master`, `main`, and `master`.
+   - If the user asked for commits made by me, review branch-unique commits authored by the resolved identity.
+   - If no explicit range, required author identity, or branch base can be resolved, ask the user for the missing value before proceeding.
+   - Inspect changed files and diffs from those commits, then tests, fixtures, config, schemas, and prior bug patterns only as needed.
+7. For codebase area scope:
+   - Require a concrete path, module, package, feature area, or glob.
+   - If the target area is missing, ask for it before proceeding.
+   - Follow the shared retrieval order from `references/codebase-investigation.md` to find production entry points, tests, fixtures, mocks, test commands, and coverage-sensitive config.
+8. For explicit files/globs, branch comparison, symbol/class/function, feature/flow, or explicitly requested whole-repo scope:
+   - Resolve the target with `references/audit-scope.md` and record the resolution method, base/head when relevant, resolved files, exclusions, and freshness timestamp.
+   - For symbol/class/function targets, inspect definitions, call paths, behavior contracts, tests, fixtures, mocks, and test commands only as needed.
+   - For feature/flow targets, map changed or targeted behavior to existing tests and deterministic harnesses.
+   - If whole-repo scope is requested, map major test surfaces first and report skipped depth checks rather than implying exhaustive coverage.
+9. For implementation parent scope:
+   - Accept the exact scope packet from `implementation-audit`; do not broaden beyond resolved files, nearby tests, fixtures, config, and callers needed to verify regression protection.
+   - Return compact findings to the parent implementation audit; do not write broad project memories unless explicitly assigned.
+10. Investigation pass. Dispatch `audit-specialist` 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`
+> - trigger: large scope, explicit parallel/subagent request, PR subagent invocation, or independent verification of high-impact finding
+> - scope: the tests audit target — test files, fixtures, harnesses, coverage
+> - permissions: read-only
+> - inputs: shared scope packet; `lens: performance` (test coverage is under the performance lens); recalled testing conventions, flaky tests, known regressions
+> - sensors: map behavior to tests; check missing tests for new branches, error paths, async logic, migrations; fixture health, assertion quality, flakiness root-cause
+> - output: findings with missing/weak coverage type, location, evidence, regression risk, severity, simplest test direction, deterministic sensor, verification suggestion
+> - firewall: raw diffs/logs/search output summarized, not returned raw
+> - memory: suggest-only; main agent persists reusable testing patterns
+
+    - Map changed or targeted behavior to existing tests, fixtures, mocks, and deterministic harnesses.
+   - Check missing tests for new branches, error paths, auth/validation/persistence changes, async or race-prone logic, migrations, public contracts, and recalled bug patterns.
+   - For mobile scopes, check KMP shared and platform-specific `actual` tests, Android/iOS harnesses, native bridge payload coverage, permissions, lifecycle, offline sync, deep links, push/background flows, UI snapshots/screenshots, device-matrix assumptions, and platform parity claims from `references/mobile-context.md`.
+   - Check weak assertions, tests that only assert implementation details, fixture drift, nondeterminism, hidden network/time/filesystem dependencies, skipped tests, and weakened snapshots.
+   - For each candidate finding, record the concrete claim, source evidence, impacted behavior, likely regression path, provisional severity, and what would disprove it.
+11. False-positive pass:
+   - Try to disprove every candidate before reporting it.
+   - Check existing unit, integration, e2e, contract, snapshot, fixture, and harness coverage; also check framework-generated coverage and accepted exceptions.
+   - If a deterministic test command is cheap and in scope, run it as a sensor; if not, report the skipped command and reason.
+   - Drop candidates disproven by evidence, downgrade candidates with partial mitigation, and mark low-confidence findings explicitly.
+12. Severity rules (apply the countable threshold first, then the qualitative clause):
+   - `critical`: missing or broken tests around data loss, auth/privacy, migration, deployment-blocking, irreversible corruption risk, OR >10 affected files; otherwise use the qualitative clause below.
+   - `high`: missing or weak tests around a core flow, public contract, persistence behavior, validation, security boundary, or severe regression risk.
+   - `medium`: missing edge-flow coverage, flaky or nondeterministic test risk, fixture drift, weak assertions, or missing regression coverage around changed logic (<=10 affected files).
+   - `low`: minor coverage gap, low-impact assertion hardening, incomplete evidence, or weakly supported concern.
+13. Final report:
+   - Findings first, ordered by severity: `critical`, `high`, `medium`, `low`.
+   - Each finding must use `TST-<N>` and include the canonical fields from `references/audit-report-io.md`: severity, confidence, file/line, evidence, impacted behavior, regression risk, simplest test direction, deterministic sensor, and verification suggestion.
+   - If no test audit findings are found, say that clearly and list scope checked plus skipped checks.
+   - Include ruled-out candidates when they were plausible enough to matter.
+   - Include scope checked, deterministic evidence or skipped-check notes, memory outcome, and residual risk.
+   - Include the Verification/Test Fidelity Checklist from `references/audit-report-io.md`; tie every `TST-*` finding or no-finding claim to deterministic sensors, commands/artifacts, results, validation assets, or skipped-check reasons. Model judgment alone cannot satisfy verification/testing all-clear.
+   - For direct top-level invocation, use the Plan Mode save rule and canonical report contract from `references/audit-report-io.md` for `audits/tests/<YYYY-MM-DD tests-audit>.md`.
+   - For implementation audit child invocation, return compact findings to the parent unless the parent explicitly requests saved audit artifacts.
+14. Persist only durable knowledge:
+   - Do not persist one-off findings.
+   - Persist repeated test gap patterns, project-specific testing conventions, accepted exceptions, flaky-test patterns, or reusable verification recipes after scoring with the Importance Calibration System.
+   - Use required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:tests-audit`, `entity:<entity>`, and one `memory:<tier>` tag.
+15. Complete the Evidence Gate from `references/evidence-gate.md`.
+
+## Examples
+
+User asks: "Find test gaps in modified files."
+
+1. Use `workflowSessionId=test-audit-modified-files`.
+2. Scope to staged, unstaged, and relevant untracked files; inspect changed behavior before tests.
+3. Map changed behavior to existing tests and deterministic harnesses.
+4. Report findings by severity with simplest test direction.
+
+User asks: "Audit src/payments test coverage."
+
+1. Use `workflowSessionId=test-audit-payments`.
+2. Scope to `src/payments`, its tests, fixtures, mocks, config, and public contracts.
+3. Report missing regression coverage, weak assertions, flaky risks, and skipped checks.

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

@@ -0,0 +1,96 @@
+### Tests Fix
+
+Use this workflow only to execute fixes from a tests audit markdown report.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Before the first repository mutation, load `references/implementation-delivery.md` for worktree isolation, atomic commits, PR creation, CI watch, and the merge gate, and `references/code-annotation.md` for doc blocks, rationale comments, and test coverage on every created or updated unit. If two consecutive fix attempts fail on the same symptom, stop editing and load `references/root-cause-scripts.md`.
+
+Do not use this workflow for findings-only test coverage, assertion quality, fixture health, flakiness, or regression-risk review; route that to `workflows/tests/tests-audit.md`. Do not use it for generic "write some tests" work without an audit report; route broad test planning through the relevant feature, debug, refactor, or spec-driven workflow.
+
+1. Resolve/reuse `workflowSessionId`: `tests-fix-[entity]`
+2. Load shared references:
+   - `references/audit-report-io.md` before any code or test change
+   - `references/lessons.md` to load confirmed project lessons
+   - `references/codebase-investigation.md` before changing unfamiliar tests or fixtures
+   - `references/mobile-context.md` when the report target touches KMP, iOS, Android, native bridges, mobile lifecycle, offline sync, permissions, local persistence, UI snapshots/screenshots, or backend-mobile contracts
+   - `references/verification-ladder.md` before non-trivial edits
+   - `references/context-firewall.md` before inspecting large logs, snapshots, generated reports, or broad search output
+   - `references/agent-orchestration.md` only for large/high-risk findings, disjoint implementation slices, or independent verification
+3. `recall` -> load testing conventions, mock boundaries, test frameworks, prior flaky tests, known regressions, accepted exceptions, and reusable verification recipes for the report target.
+4. Select the tests audit report with execution focus:
+   - Establish the report selector, target focus, and optional finding selector before selecting a report. Target focus can be a behavior, flow, module, test suite, files/globs, branch comparison, commit range, symbol/class/function, or explicit whole-repo target.
+   - If the user gives a path, read that exact markdown file.
+   - If the user asks for "latest" or gives no path, require a concrete target focus first; do not run the latest tests report against an unspecified target.
+   - Select the latest `audits/tests/<YYYY-MM-DD tests-audit>.md` only after target focus is known, using `references/audit-report-io.md`.
+   - Stop if no report exists; do not infer findings from conversation history.
+   - Validate the report with `references/audit-report-io.md`: workflow, `ProjectId`, `Target`, `Target Focus`, scope, git base/head, required fields, `TST-` IDs, resolved files or material scope evidence, and current file/line evidence. Stop on invalid, stale, target-drifted, or ambiguous reports before editing.
+5. Extract actionable test findings:
+   - Keep findings with concrete `Location`, `Evidence`, impacted behavior, regression risk, `Simplest Test Direction`, `Deterministic Sensor`, and `Verification Suggestion`.
+   - Ignore ruled-out candidates, no-finding sections, and low-confidence hardening ideas unless the user explicitly asks to include them.
+   - If the user supplied finding IDs, extract only those IDs after validating they exist and match the current target focus.
+   - Rank by regression risk, severity, dependency order, and determinism.
+6. Build a coverage execution map before editing:
+   - Finding ID -> behavior under test, missing/weak assertion, fixture/mock boundary, deterministic harness, validation asset, expected failure before fix when possible, and verification command.
+   - Separate missing coverage, weak assertion, fixture drift, flakiness, skipped test, and missing deterministic sensor findings.
+   - For mobile findings, include KMP/shared vs platform-specific boundary, native bridge payload or backend-mobile contract, Android/iOS harness, device matrix or simulator/emulator assumptions, platform parity expectation, and skipped platform checks from `references/mobile-context.md`.
+7. Size each finding with `references/verification-ladder.md`:
+   - Quick: local test addition, assertion strengthening, fixture field correction, or focused skipped-test restoration.
+   - Standard: integration harness change, shared fixture/mocking repair, flake root-cause fix, or production seam needed for deterministic testing; define verification recipe first.
+   - Spec-driven: test strategy redesign, broad harness migration, unclear behavior contract, or production behavior change beyond enabling deterministic tests; pause and route to `workflows/spec-driven.md` or ask for approval.
+8. Apply test fixing methods:
+   - Missing coverage: write the smallest deterministic test that fails on the risky behavior and passes with correct behavior.
+   - Weak assertions: assert externally meaningful behavior, outputs, side effects, persisted state, emitted events, or user-visible contracts rather than implementation details.
+   - Fixture drift: repair fixtures/builders to match current contracts while keeping them minimal and explicit.
+   - Flakiness: prove root cause first; control time, randomness, async scheduling, filesystem, network, and global state with deterministic seams.
+   - Missing sensor: add or document the focused command needed to prove the regression cannot recur.
+   - Mobile coverage: prefer KMP/shared tests before device loops when the behavior is shared; use Android/iOS harnesses, bridge contract tests, screenshot/snapshot checks, lifecycle or permission simulations, and parity validation when the report finding requires them.
+9. Guard validation assets:
+   - Never weaken assertions only to make the suite pass.
+   - Do not delete coverage, snapshots, fixtures, or benchmarks unless the audit report explicitly calls them obsolete and behavior remains protected elsewhere.
+   - Prefer production-code changes only when required to expose a deterministic seam or fix a real bug found while writing the audited test.
+10. Use strict harness sensors:
+   - Never rely on AI subjective evaluation.
+   - If verification found a reusable signal (`ac_gap`, `surviving_mutant`, `spec_precision_gap`, `spec_deviation`, `gate_fail`), record it via `references/lessons.md`:
+     `python3 skills/massa-ai/scripts/lessons.py --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 actual focused test command first, then broader relevant suites when feasible, such as `rtk yarn test`, `rtk npm test`, `rtk pytest`, or `rtk cargo test`.
+   - Continue only when the execution harness returns a clean exit code, or report the exact skipped-check reason.
+   - 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.
+   - Record command/artifact, result, skipped reason or `none`, highest Verification Ladder level reached, validation assets protected, and residual risk.
+11. Use agent orchestration only when it improves signal. Dispatch per `references/agent-orchestration.md`:
+
+> **Dispatch: `massa-ai-builder`** (role: `builder`) — charter `skills/agents/builder/SKILL.md`
+> - trigger: large/high-risk finding, disjoint implementation slice, or explicit subagent request
+> - scope: one isolated test finding with a disjoint write set
+> - permissions: write (disjoint write set)
+> - inputs: the finding ID, missing/weak coverage type, fixture/mock boundary, deterministic harness, and verification command
+> - sensors: focused test command (`bun test`, `pytest`, `cargo test`) with clean exit code; no weakened assertions
+> - output: implementation summary, test counts, commands run, deviations
+> - firewall: raw test output/logs summarized
+> - memory: suggest-only; main agent persists reusable testing patterns
+
+> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
+> - trigger: independent verification of a high-risk test fix
+> - scope: the fixed finding's assertions, fixtures, and report claim closure
+> - permissions: read-only
+> - inputs: the finding, the applied fix, the verification suggestion, and validation assets
+> - sensors: deterministic command (focused test suite, assertion inspection, fixture-not-weakened check) and report claim closure
+> - output: confirmed/disproven closure verdict with evidence
+> - firewall: raw test output/logs summarized
+> - memory: suggest-only; main agent persists reusable verification recipes
+   - Main agent owns report parsing, prioritization, memory writes, final synthesis, and Evidence Gate.
+12. At completion, persist only durable knowledge after scoring with the Importance Calibration System:
+   - Testing conventions, deterministic harness recipes, flaky-test root causes, accepted exceptions, or reusable edge-case coverage patterns.
+   - Use required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:tests-fix`, `entity:<entity>`, and one `memory:<tier>` tag.
+13. Complete the Evidence Gate from `references/evidence-gate.md`; do not mark tests complete without a clean deterministic exit code or explicit skipped-check reason.
+
+## Examples
+
+User asks: "Use tests-fix to fix latest audit findings for report scheduling."
+
+1. Confirm target focus is `report scheduling`, then read the latest matching `audits/tests/* tests-audit.md`.
+2. Validate metadata, target focus, freshness, required fields, and current evidence before editing.
+3. Map each finding to missing coverage, weak assertions, fixture drift, flakiness, or missing sensor work.
+4. Add or repair deterministic tests without weakening validation assets.
+5. Run focused tests and report broader skipped checks when needed.

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

@@ -0,0 +1,82 @@
+### The Fool
+
+Use this workflow for direct requests to challenge ideas, plans, decisions, proposals, architectures, evidence, or assumptions. Also use it as the configured post-plan challenge gate after other massa-ai workflows construct a plan.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+Do not use this workflow to build the initial plan, make the decision, or execute implementation work. It critiques and strengthens existing thinking.
+
+## Configuration
+
+Read the canonical **Plan Challenge Policy** from the installed `AGENTS.md`
+bootstrap block (`<!-- massa-ai:bootstrap -->`), whose single source is
+`skills/AGENTS.md` in the product repo. If that
+file is unavailable, use the deterministic runtime fallback: run the lite gate
+with `pre_mortem` mode (do not judgment-select the gate or mode), and revise
+the parent plan when critical or high findings are valid.
+
+User prompt overrides take precedence for the current turn only, such as "skip the Fool gate", "use red-team mode", or "append critique without revising the plan".
+
+## Workflow
+
+1. Resolve/reuse context:
+   - Direct challenge request: use `workflowSessionId=fool-[entity]`.
+   - Post-plan gate: inherit the parent workflow's exact `projectId`,
+     `workflowSessionId`, workflow name, entity, and memory context.
+2. `recall` -> load prior decisions, rejected approaches, constraints, accepted risks, and relevant evidence for the target entity.
+3. Require a concrete proposed plan before critique. If there is no plan, return to the parent workflow and construct the plan first. After a concrete plan exists, always attempt a read-only `massa-ai-plan-critic` subagent when subagent tooling is available. If that agent is unavailable, follow the no-agent fallback in `references/agent-orchestration.md` (Name Resolution): run the critique locally against the same output contract and report the skipped delegation.
+4. Resolve gate depth:
+   - Post-plan lite gate: keep parent identifiers and dispatch a bounded lite checklist packet without loading The Fool mode references.
+   - Post-plan full gate or direct challenge: continue to mode selection and full critique.
+   - Direct challenge requests use `workflowSessionId=fool-[entity]`; post-plan gates keep the parent identifiers and send only a bounded packet.
+5. Lite `massa-ai-plan-critic` packet:
+   - Inputs: proposed plan, scope, constraints, parent workflow, compact recalled facts/evidence, known risks, verification recipe, context-firewall limits, and lite checklist.
+   - Output must include the strongest low-risk challenges plus `escalate_to_full: true|false` and reason.
+   - If `escalate_to_full: false`, synthesize the lite critique, revise or accept risk according to policy, and complete the gate without loading The Fool mode references.
+   - If `escalate_to_full: true`, the main agent selects full mode, loads the relevant references, and dispatches a full `massa-ai-plan-critic` pass.
+6. Select The Fool mode for full gates:
+   - `mode: auto`: read `references/the-fool/mode-selection-guide.md` and choose the best mode from plan content and domain.
+   - `mode: ask`: ask the user only when interactive input is available; otherwise fall back to `auto` and report the fallback.
+   - Concrete mode values map to The Fool references: `pre_mortem`, `red_team`, `evidence_audit`, `socratic`, or `dialectic`.
+   - Mode reference map:
+     - `pre_mortem` -> `references/the-fool/pre-mortem-analysis.md`
+     - `red_team` -> `references/the-fool/red-team-adversarial.md`
+     - `evidence_audit` -> `references/the-fool/evidence-audit.md`
+     - `socratic` -> `references/the-fool/socratic-questioning.md`
+     - `dialectic` -> `references/the-fool/dialectic-synthesis.md`
+7. Load only the selected The Fool reference plus `references/the-fool/cognitive-bias-inventory.md`.
+8. Dispatch the full critique:
+   - Load `references/agent-orchestration.md`.
+   - Use the `plan-critic` contract and capability-packet shape from `references/agent-orchestration.md`; dispatch under `massa-ai-plan-critic`.
+   - Send only the proposed plan, scope, constraints, parent workflow, recalled facts, verification recipe, known risks, selected mode, context-firewall limits, and output contract.
+   - If subagents are unavailable or platform policy forbids spawning, run a strict standalone fresh-eyes local critique and record the skipped delegation reason.
+   - Normal delegation gates in `references/agent-orchestration.md` still apply to other roles, but Plan Challenge `plan-critic` is a standing policy exception after a concrete plan exists.
+9. Critique output must include:
+   - selected mode
+   - steelmanned thesis
+   - 3-5 strongest challenges
+   - severity: `critical`, `high`, `medium`, or `low`
+   - affected plan section
+   - evidence gap or assumption at risk
+   - required revision or accepted-risk framing
+   - confidence impact
+   - exact next step
+10. Synthesize using `references/decision-engine.md`:
+   - `serious_findings: revise_plan`: revise valid `critical` or `high` findings before presenting the final plan.
+   - `serious_findings: append_critique`: keep the plan and attach the critique for user decision.
+   - `serious_findings: warn_only`: mention serious risks briefly without restructuring the plan.
+11. Persist only durable outcomes after recall and scoring:
+   - accepted architecture constraints, rejected approaches, durable risk decisions, or reusable critique patterns
+   - required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:the-fool` or parent workflow for post-plan gates, `entity:<entity>`, and one `memory:<tier>`
+   - skip one-off critique notes and subagent chatter
+12. Complete the Evidence Gate from `references/evidence-gate.md`.
+
+## Post-Plan Gate Output
+
+When used as a gate, the final user-facing plan should not expose raw subagent chatter. Include only the revised plan and a compact note such as:
+
+```md
+Plan Challenge: ran The Fool in pre-mortem mode; revised verification and rollout risks before finalizing.
+```
+
+If the gate is skipped, state why only when it affects confidence, user expectation, or configured behavior.

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

@@ -0,0 +1,42 @@
+### Ticket
+
+Use this workflow when the user wants to draft, review, create, or resume creation of Jira Epics, standard issues, or sub-tasks. Jira through Atlassian MCP is the only tracker and mutation path. Do not use Jira CLI, browser automation, another tracker, or repository backlog files as fallbacks.
+
+Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+
+## Workflow
+
+1. Resolve or reuse `projectId` and `workflowSessionId=ticket-<entity>`.
+2. Recall durable project conventions, prior Jira constraints, and ticket-writing decisions through `recall`. Treat recalled facts as leads until confirmed by the user or current Jira metadata.
+3. Load the focused contracts:
+   - `references/ticket/intake-and-sources.md` for ordered questions, reference-ticket isolation, DoR/DoD inputs, and bounded code exploration.
+   - `references/ticket/templates-and-quality.md` for title prefixes, built-in templates, decomposition, and draft validation.
+   - `references/ticket/atlassian-fix.md` before tool discovery, preflight, approval, Jira creation, resume, or cleanup.
+   - `references/context-firewall.md` when Jira, Confluence, supplied files, or exploration output could flood context.
+4. Discover Atlassian MCP capabilities dynamically. Require readable Jira project metadata and issue-creation capability before promising creation. If Atlassian MCP is missing or read-only, drafting may continue, but stop before approval-to-create and report the unavailable capability. Never substitute a CLI or tracker.
+5. Run ordered intake from `intake-and-sources.md`. Ask only for information not already supplied or discoverable from Atlassian metadata. Validate the exact project key without silently correcting it.
+6. When code grounding is useful, run a bounded read-only child pass using `workflows/exploration.md`, then return to the ticket session. Never search Git history, branches, commits, or repository ticket references for ticket examples or templates.
+7. Inspect the selected Jira project's issue types, required fields, parent rules, and relevant field options before finalizing the draft. A reference ticket controls format and tone only; it does not authorize copying project facts.
+8. Draft the requested hierarchy using `templates-and-quality.md`. Keep each standard issue independently understandable, use sub-tasks only for atomic work owned by one parent, and make dependencies explicit.
+9. Search the selected Jira project for potential duplicates using the proposed summary and distinctive scope terms. Record candidates in the review artifact; do not silently merge, skip, or close work.
+10. Resolve the agent-native external plans directory and create one temporary review file named `ticket-<project>-<slug>-<YYYYMMDDTHHMMSSZ>.md`. The artifact must be outside the repository and contain stable draft IDs, draft revision, approval status, creation order, Jira fields, full descriptions, duplicate candidates, open questions, and created keys or URLs when present.
+11. Run every deterministic quality gate from `templates-and-quality.md`. Present the current artifact for review. Any content or field revision increments `Draft Revision` and resets `Approval Status` to `NOT APPROVED`.
+12. Require explicit user approval for the current draft revision before any Jira mutation. Approval of an older revision, generic encouragement, or approval given before the final quality and duplicate checks is invalid.
+13. Execute the top-down creation contract from `atlassian-fix.md`: Epic first when requested, then standard issues, then sub-tasks. Persist each successful key and URL into the external review artifact before the next create call.
+14. On partial failure, stop immediately. Retain the artifact, report created and pending draft IDs, and do not delete, transition, comment on, or otherwise compensate Jira issues automatically. Resume only with fresh explicit approval after Jira state and duplicate candidates are re-fetched.
+15. After complete success, report all created keys and URLs, then delete the temporary review artifact. A cleanup failure does not invalidate Jira creation; report the retained path.
+16. Persist only durable conventions or reusable Jira constraints after scoring and deduplication. Do not persist raw ticket bodies, customer data, temporary draft state, or one-run creation results to massa-ai.
+17. Complete `references/evidence-gate.md`, including Atlassian capability used, artifact cleanup result, created issue links, skipped checks, memory outcome, and residual risk.
+
+## Failure Handling
+
+- Invalid or inaccessible project key: stop intake at project validation and ask for a valid key; never guess a nearby project.
+- Missing reference ticket or source document: report the failed source and ask whether to retry or use built-in templates.
+- Unsupported requested issue type or required custom field: show the Jira-supported choices and ask only for the blocking selection or value.
+- Missing external plans path or write permission: ask for an external writable path; never write the draft into the repository.
+- Duplicate candidate: present the candidate and require a create, revise, or cancel decision before approval.
+- Jira create ambiguity or timeout: search Jira before retrying. Treat an unknown result as potentially created until disproved.
+
+## Stop Conditions
+
+Stop when the user leaves a reviewed draft without approval, cancels the run, Atlassian MCP cannot perform the required action, a blocking field remains unresolved, a partial failure needs a resume decision, or all approved issues are created and the temporary artifact cleanup has been attempted.

package/skills/persona-router/SKILL.md

@@ -0,0 +1,158 @@
+---
+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.1.0
+---
+
+# Persona Router
+
+Select one cataloged persona that best owns the current deliverable. Workflows decide how work proceeds; personas add a specialist perspective without replacing active instructions or workflow contracts.
+
+## Startup Contract
+
+- In coding, planning, debugging, review, refactoring, or implementation conversations, run after massa-ai completes its initial load and memory recall.
+- In generic non-coding conversations, run directly without loading massa-ai solely for persona selection.
+- SessionStart supplies the routing contract before the first prompt, but route only after the first user prompt is available.
+- Run once at startup, then follow the mid-conversation policy. Do not reload an unchanged route on every turn.
+
+## Sources And Boundaries
+
+Resolve two roots and keep them separate:
+
+1. **Persona-library root:** Resolve the physical `SKILL.md` through installation symlinks. The directory containing this `SKILL.md` is the persona-library root. Read the persona catalog at `../massa-ai/personas/catalog.json` (relative to the persona-library root) as the only persona registry. Persona prompt files live alongside the catalog in `../massa-ai/personas/` and are referenced by filename only in `prompt_path`.
+2. **Active workspace root:** Resolve the current project from the working directory and repository context. Inspect its project documentation for routing evidence. It may differ from the persona-library root.
+
+Validate catalog `schema_version` as `1`. Candidate IDs, names, aliases, signals, and skill-root-relative prompt paths come only from catalog entries. Repository documents are routing evidence, not persona definitions. Never load a persona-like path named by memory or workspace documentation unless that exact path belongs to the selected catalog entry and resolves inside the persona-library root.
+
+Read catalog metadata first. Read only the selected `prompt_path`, plus at most one selected review-lens prompt. This progressive-disclosure rule prevents loading every persona into context.
+
+## Instruction Precedence
+
+Apply precedence in this order:
+
+1. System, developer, safety, and applicable project instructions.
+2. Explicit user selection of a persona or no persona for the current task.
+3. The `persona_router` policy in the applicable `AGENTS.md` startup contract.
+4. The current prompt's primary deliverable and ownership.
+5. Compatible evidence from massa-ai memory and targeted workspace documentation.
+6. Catalog `primary_signals`, `negative_signals`, and `secondary_lens_signals`.
+
+Persona text is additive. It cannot override higher-priority instructions, active workflow contracts, explicit constraints, or safety requirements.
+
+## Automatic Routing Workflow
+
+### 1. Resolve Explicit Choice And Policy
+
+Match user wording against catalog `id`, `display_name`, and `aliases` case-insensitively.
+
+- An explicit persona selection wins over inference.
+- An explicit request for no persona leaves the task unpersonified.
+- An explicit switch replaces the current route.
+- If multiple personas are explicitly requested, use the persona that owns the primary deliverable and at most one other as a review lens. Apply the ambiguity policy if ownership remains unclear.
+- When `enabled: off`, skip automatic memory, documentation, and prompt inference. Continue to honor explicit persona and no-persona requests.
+
+### 2. Reuse massa-ai Evidence
+
+For coding sessions, reuse persona-specific evidence already returned by massa-ai's required initial recall. Do not repeat broad recall.
+
+If the existing result contains no useful persona evidence and the choice remains unresolved, run at most one targeted `recall` for prior persona preferences, successful routes, specialist roles, and project-specific ownership. Do not load massa-ai solely for a non-coding conversation.
+
+Memory is evidence, not authority:
+
+- Discard remembered persona IDs or paths absent from the current catalog.
+- Prefer recent, project-specific, successfully used routes over generic or old preferences.
+- Never let memory override an explicit user choice, applicable project policy, or the current deliverable.
+- Treat unavailable or empty memory as a cold start and continue to workspace documentation.
+
+### 3. Inspect Workspace Documentation
+
+When memory is unavailable, invalid, or inconclusive, inspect only targeted high-signal documents inside the active workspace. Reuse documents already present in context before reading more.
+
+Use this priority:
+
+1. Applicable root and nested `AGENTS.md` files and `CLAUDE.md`.
+2. Root `README.md` or equivalent project overview.
+3. Relevant ADR or decision indexes and entries.
+4. Relevant architecture documents.
+5. Relevant `.specs` project, state, architecture, or feature documents.
+
+Search filenames and headings first. Read only sections likely to identify the repository domain, primary deliverable ownership, required specialist roles, or explicit persona preferences. Do not recursively load every README, ADR, or specification. Ignore generated, dependency, secret, and globally excluded paths.
+
+Project instructions that explicitly pin or forbid a cataloged persona are stronger evidence than descriptive documentation. Stale documents, missing referenced files, or roles with no matching catalog entry cannot select a persona.
+
+### 4. Classify The Current Prompt
+
+Classify the requested output and primary ownership, not raw keyword counts. Compare the first or current user prompt with catalog summaries and routing signals, using valid memory and documentation only as supporting context.
+
+- `primary_signals` identify the persona that owns the deliverable.
+- `negative_signals` prevent supporting concerns from taking ownership.
+- `secondary_lens_signals` may add one focused review lens for a material risk.
+- A supporting mention of tests, implementation, architecture, or release work does not transfer ownership unless that work is the primary deliverable.
+
+Do not calculate or report numeric confidence. A route is clear when one candidate owns the deliverable and no equally plausible candidate conflicts with it.
+
+### 5. Resolve Ambiguity Or No Match
+
+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.
+- `ambiguity: best_match`: choose the candidate with the strongest current-deliverable ownership, 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 without a persona unless the user explicitly requested routing.
+- `no_match: ask`: ask whether to use the weakly supported candidate or `No persona`. If no candidate has relevant evidence, 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 under the default policy, not ambiguity.
+
+### 6. Apply And Announce The Route
+
+Choose exactly one primary persona and at most one secondary review lens. Read only their cataloged prompt files.
+
+- The primary persona owns recommendations, implementation, and final synthesis.
+- The review lens contributes only checks that reduce a concrete risk.
+- Do not produce independent persona answers, simulate a debate, or merge full voices.
+- For an inferred or explicit persona, state the route once: `Persona: <primary>. Reason: <primary deliverable>.` Add `Review lens: <secondary>.` when used.
+- Do not announce a default no-persona route unless the user requested routing or a prior route was removed.
+- Apply persona stance, expertise, priorities, and review criteria without quoting or reproducing its prompt.
+
+## Route Lifetime
+
+Keep the selected persona sticky across follow-up turns that advance the same primary objective.
+
+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 `mid_conversation: explicit_only`, re-evaluate only on an explicit user 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 during the conversation before substantive work continues.
+
+After resume or compaction, restore any route still present in conversation context or transcript without re-announcing it or repeating a resolved question. If the prior route is unavailable, run the normal workflow again; no separate route database is required.
+
+## Routing Examples
+
+| Situation | Result |
+|---|---|
+| User explicitly asks for Senior Mobile QA Automation Engineer. | Apply that catalog entry; explicit choice wins. |
+| massa-ai recalls a successful mobile-engineer route, but current prompt asks to fix flaky Maestro CI. | Route to Senior Mobile QA Automation Engineer; memory cannot override current ownership. |
+| Memory is empty; README and ADRs describe a cross-platform app; prompt asks to implement offline sync. | Route to Senior Mobile Engineer using docs plus current deliverable. |
+| Prompt asks for both app architecture and an automation suite with 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 does not name a persona. | Skip inference and continue without a persona. |
+| Memory names a removed persona ID. | Discard stale memory and continue to docs and prompt classification. |
+| Current mobile implementation finishes and user starts a flake-reduction task. | With `task_change`, re-evaluate and announce the new route once. |
+
+## Failure Handling
+
+- **Catalog missing or invalid:** Report `Persona routing unavailable: <reason>.` Continue without a persona.
+- **Unsupported schema version:** Report the found and supported versions. Continue without a persona.
+- **massa-ai unavailable or empty:** Continue with targeted workspace documentation and the current prompt.
+- **Workspace documentation unavailable:** Route from explicit choice and current prompt; apply 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; do not silently substitute another persona.
+- **User cannot be asked interactively:** Ask one concise plain-text question when policy requires a choice; otherwise use the configured non-interactive behavior.
+
+## Stop Conditions
+
+Routing is complete when one primary persona is applied, the user selects no persona, or policy intentionally produces a no-persona route. Do not invoke a separate model router, launch subagents, create subprocess orchestration, or persist a route database.

package/skills/status/SKILL.md

@@ -0,0 +1,15 @@
+---
+description: Show massa-ai health and indexed projects status
+allowed-tools: ["mcp__massa-ai__list_projects", "mcp__massa-ai__analytics"]
+---
+
+Show a health snapshot of the massa-ai installation.
+
+1. Call `mcp__massa-ai__list_projects` with `status=all`.
+2. Call `mcp__massa-ai__analytics` with `type=summary`.
+3. Render:
+   - A table of workspaces: projectId | status | filesCount | chunksCount | lastIndexedAt
+   - Totals: searches performed, unique queries, cache hit rate, top queries
+   - Flag anything unusual: a workspace stuck in `indexing`, a workspace in `error`, or cache hit rate below 30%.
+
+Keep it dense — one screen.