@massa-ai/cursor-plugin 1.25.0 → 1.27.0

package/skills/massa-ai/references/repo-rules-discovery.md

@@ -1,7 +1,7 @@
 # Repo Rules Discovery
 
-Use this reference from `workflows/spec-driven.md` before the first repository
-mutation. It defines how to discover, load, and enforce the target repository's
+Use from `workflows/spec-driven.md` before the first repository
+mutation. Defines how to discover, load, and enforce the target repository's
 own AI-harness rules and implementation conventions, so spec-driven
 implementation conforms to the repo it runs in rather than only to the
 skill's defaults.
@@ -12,8 +12,8 @@ the target repo**: it loads what is present and never invents what is absent.
 ## Principle
 
 A repository's rules live in its own harness files and conventions. spec-driven
-must read them before implementing and enforce conformance, because a change
-that follows the skill's defaults but violates the repo's module layout, test
+must read them before implementing and enforce conformance — a change that
+follows the skill's defaults but violates the repo's module layout, test
 placement, or lint rules is not deliverable. Silence here reads as "the repo
 has no rules", which is almost never true — it means they were not looked up.
 

package/skills/massa-ai/references/rfc/discovery-and-sizing.md

@@ -1,6 +1,6 @@
 # RFC Discovery And Classification
 
-Load this reference before source investigation, RFC classification, impact selection, or clarification questions.
+Load before source investigation, RFC classification, impact selection, or clarification questions.
 
 ## Workflow Fit
 

package/skills/massa-ai/references/rfc/document-contract.md

@@ -1,6 +1,6 @@
 # RFC Document Contract
 
-Load this reference when drafting or revising an RFC. Preserve the full decision structure while tailoring detail to the RFC type and impact.
+Load when drafting or revising an RFC. Preserve the full decision structure while tailoring detail to the RFC type and impact.
 
 ## Section Contract
 

package/skills/massa-ai/references/rfc/quality-and-lifecycle.md

@@ -1,6 +1,6 @@
 # RFC Quality And Lifecycle
 
-Load this reference before challenging, finalizing, saving, updating, or closing an RFC.
+Load before challenging, finalizing, saving, updating, or closing an RFC.
 
 ## Quality Gate
 

package/skills/massa-ai/references/root-cause-scripts.md

@@ -1,6 +1,6 @@
 # Root-Cause Proof Scripts
 
-Use this reference the moment an implementation or fix stops converging. It is a
+Use the moment an implementation or fix stops converging. It is a
 circuit breaker, not a diagnosis method: it fires mid-implementation in any
 workflow — `feature`, `debug`, `refactor`, `spec-driven`, any `*-fix` — including
 the ones that never opened a reproduction loop.
@@ -11,7 +11,7 @@ This file is where any implementation *stops guessing*.
 ## Principle
 
 An agent that has failed twice on the same symptom does not have a code-reading
-problem. It has a data problem. Reading the same source a third time produces a
+problem — it has a data problem. Reading the same source a third time produces a
 third theory with the same evidence base as the first two. The only way out is
 to make the program tell you what it is actually doing.
 

package/skills/massa-ai/references/sonarqube-mcp.md

@@ -0,0 +1,73 @@
+# SonarQube MCP Protocol
+
+Use from `workflows/implementation/implementation-audit.md` and
+`workflows/implementation/implementation-fix.md` when SonarQube MCP tools may
+be available for the current implementation scope.
+
+## Detection And Availability
+
+Check whether SonarQube MCP is available and useful for the implementation
+scope:
+
+- Detect callable SonarQube MCP tools at runtime, such as project discovery,
+  issue search, file/snippet analysis, advanced code analysis, duplicated-file
+  search, component measures, security hotspots, guidelines, or quality gate
+  status.
+- If SonarQube MCP is unavailable, no project key can be resolved, required
+  credentials/configuration are missing, or the target files are outside the
+  configured SonarQube project, record `SonarQube MCP: not evaluated` with the
+  skipped-check reason and continue normal lens synthesis.
+
+## Firewall And Invocation
+
+If available, use `references/context-firewall.md` and pass only the
+immutable implementation scope packet, resolved files, branch/PR identifiers,
+project key, and minimal file contents or paths the selected SonarQube tools
+require.
+
+Wait for SonarQube MCP execution to finish when a tool starts analysis,
+capture quality gate status when available, and summarize raw
+issues/measures/hotspots instead of copying raw tool output into the report.
+
+## Normalization Areas
+
+Normalize actionable SonarQube results into only these implementation audit
+areas: Architecture, Correctness/Bugs, Code Quality, Security, and Tests. Do
+not create a Requirements finding from SonarQube output.
+
+## Preserved Fields
+
+Preserve Sonar issue key, rule key, tool name, severity/impact, file/line,
+quality gate condition, and evidence summary inside the normalized finding.
+
+## ID Mapping
+
+Use normal source-qualified implementation IDs after normalization, such as
+`Architecture/ARCH-1`, `Correctness/BUG-1`, `Code Quality/CQ-1`,
+`Security/SEC-1`, or `Tests/TST-1`; do not invent `SONAR-*` executable finding
+IDs. The canonical area/prefix table and discipline live in
+`references/audit-report-io.md` (Source-Qualified Finding IDs).
+
+## Exclusion Rules
+
+Keep unmapped, duplicate, low-context, or out-of-scope SonarQube results in
+Scope And Evidence or skipped checks, not in Findings or Execution Handoff.
+
+## Reporting Integration
+
+- Include SonarQube MCP as evidence in the coverage matrix or Scope And
+  Evidence, with quality gate status when available.
+- Sonar-derived findings enter the execution handoff only after normalization
+  to one supported source lens ID, with enough evidence for
+  `implementation-fix` to revalidate from the saved markdown report.
+- Do not persist raw SonarQube output; persist only normalized, durable
+  patterns after Importance Calibration.
+
+## Fix-Time Consumption
+
+Treat SonarQube-derived items as actionable only when the saved
+implementation report already normalized them to a supported source-qualified
+ID with source lens, original ID, Sonar issue/rule evidence, location,
+impact, and verification suggestion. Never execute directly from raw
+SonarQube MCP output, quality gate summaries, chat summaries, or remembered
+Sonar findings.

package/skills/massa-ai/references/spec-driven/artifact-store.md

@@ -1,6 +1,6 @@
 # Spec-Driven Artifact Store
 
-Use this reference before any spec-driven workflow reads or writes feature registry, progress, handoff, phase artifacts, validation reports, or lessons. `.specs/` files are the canonical state layer for spec-driven logical artifacts.
+Use before any spec-driven workflow reads or writes feature registry, progress, handoff, phase artifacts, validation reports, or lessons. `.specs/` files are the canonical state layer for spec-driven logical artifacts.
 
 ## Source Of Truth
 

package/skills/massa-ai/references/spec-driven/brownfield-mapping.md

@@ -0,0 +1,16 @@
+# Brownfield Onboarding — 7-Doc Codebase Mapping
+
+Use from `workflows/spec-driven.md` when the target codebase
+has not yet been mapped (brownfield, new repo, or cold project). The map is
+the shared factual ground for requirements, design, and task derivation;
+each doc feeds a downstream phase.
+
+| Doc | Derives | Feeds |
+| --- | --- | --- |
+| `STACK.md` | languages, runtimes, frameworks, key libraries | Design constraints, verification commands |
+| `ARCHITECTURE.md` | layers, modules, boundaries, data flow | Design, risk surface |
+| `CONVENTIONS.md` | naming, file layout, commit/test conventions | Tasks, Execute |
+| `STRUCTURE.md` | directory map, where new code goes | Tasks, file placement |
+| `TESTING.md` | test runner, how to run gates, coverage tooling | Gate Check Commands, verification recipe |
+| `INTEGRATIONS.md` | external services, APIs, contracts, auth | Discuss, risk escalation |
+| `CONCERNS.md` | known risks, tech debt, migration landmines, security/privacy hotspots | Risk-domain escalation, validation focus |

package/skills/massa-ai/references/spec-driven/code-analysis.md

@@ -1,6 +1,6 @@
 # Spec-Driven Code Analysis
 
-Use this reference when Specify, Design, Tasks, Execute, or Validate needs source inspection or structural code search.
+Use when Specify, Design, Tasks, Execute, or Validate needs source inspection or structural code search.
 
 <!-- validator anchors: current repository source and approved .specs/ artifacts override stale memory -->
 

package/skills/massa-ai/references/spec-driven/coding-principles.md

@@ -1,6 +1,6 @@
 # Spec-Driven Coding Principles
 
-Use this reference before writing or changing implementation, tests, fixtures, validation assets, scripts, or docs during Execute.
+Use before writing or changing implementation, tests, fixtures, validation assets, scripts, or docs during Execute.
 
 Behavioral bias, not checklist. Read before every implementation.
 

package/skills/massa-ai/references/spec-driven/context-limits.md

@@ -1,6 +1,6 @@
 # Spec-Driven Context Limits
 
-Use this reference when planning context loading for a spec-driven feature or when `.specs/features/<slug>/` artifacts grow large enough to reduce implementation quality.
+Use when planning context loading for a spec-driven feature or when `.specs/features/<slug>/` artifacts grow large enough to reduce implementation quality.
 
 ## Targets
 

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

@@ -1,6 +1,6 @@
 # Design
 
-Use this reference when the spec-driven flow includes a Design phase. The output is `.specs/features/<slug>/design.md`. **Goal**: define HOW to build it — architecture, components, what to reuse.
+Use when the spec-driven flow includes a Design phase. The output is `.specs/features/<slug>/design.md`. **Goal**: define HOW to build it — architecture, components, what to reuse.
 
 **Skip this phase when:** The change is straightforward — no architectural decisions, no new patterns, no component interactions to plan. For simple features, design happens inline during Execute.
 
@@ -85,6 +85,22 @@ If the feature involves data, define models before implementation.
 
 ---
 
+## Deterministic Validation
+
+Before presenting `design.md` for confirmation, run:
+
+```bash
+bun skills/massa-ai/scripts/validate_design.ts <path-or-feature-or-root> [--root .]
+```
+
+It checks the three structurally-required sections (`## Design Summary`,
+`## Risks & Concerns`, `## Tech Decisions`, heading-prefix match) and that
+every `Risks & Concerns` table row has a non-empty, non-placeholder
+Mitigation cell — a `> None found` marker with zero rows is a valid empty
+risk register, not an unfilled one. A non-zero exit blocks confirmation. If
+no code-execution tool is available, run the same checks by reading the
+artifact (graceful degradation preserved).
+
 ## Required Sections
 
 `design.md` must include:
@@ -100,6 +116,11 @@ If the feature involves data, define models before implementation.
 - Large/Complex approach tradeoffs: 2-3 viable approaches, same scope, recommendation first, user-confirmed chosen approach.
 - Verification design, including how tests or checks prove each high-risk requirement.
 - Risks, concerns, and mitigations.
+- Tech decisions (non-obvious ones only), with rationale.
+
+`## Design Summary`, `## Risks & Concerns`, and `## Tech Decisions` are the
+three headings the deterministic validator above requires structurally;
+the rest of this list is enforced by review, not by the script.
 
 ## Decision Supersession
 

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

@@ -1,6 +1,6 @@
 # Spec-Driven Discuss Gray Areas
 
-Use this reference inside Specify when gray areas or implicit requirements affect behavior, scope, data, security/privacy, compatibility, or acceptance criteria. It captures HOW the user envisions the feature when the spec has ambiguous areas — it is NOT a separate phase; it triggers within Specify when the agent detects gray areas that need user input.
+Use inside Specify when gray areas or implicit requirements affect behavior, scope, data, security/privacy, compatibility, or acceptance criteria. It captures HOW the user envisions the feature when the spec has ambiguous areas — it is NOT a separate phase; it triggers within Specify when the agent detects gray areas that need user input.
 
 **Goal:** Capture HOW the user envisions the feature when the spec has ambiguous areas. Specifications capture WHAT to build. Design captures the architecture. But neither captures the user's vision for ambiguous areas — layout preferences, interaction patterns, error handling style, content tone. Without this, the agent guesses. With this, the agent builds what the user actually imagined.
 

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

@@ -1,6 +1,6 @@
 # Spec-Driven Execute
 
-Use this reference for the required Execute phase. Implement ONE task at a time: surgical changes, verify, commit, repeat. Validation is the mandatory final Execute gate, not a separate phase.
+Use for the required Execute phase. Implement ONE task at a time: surgical changes, verify, commit, repeat. Validation is the mandatory final Execute gate, not a separate phase.
 
 <!-- validator anchors: evidence-or-zero mapping -->
 
@@ -474,6 +474,8 @@ Then run `references/spec-driven/validate.md` as the final Execute gate. The ver
 
 ## Pause / End of Session
 
+**Checkpoints (long-running task sequences):** create a checkpoint via `create_checkpoint` at task boundaries with `taskId`, `description`, `progressPercent`, `currentStep`, `nextAction`, `fileChanges`, and `checkpointType: "manual"` so progress is resumable after interruption. If resuming after interruption, call `list_checkpoints` with the `taskId` and `restore_checkpoint` to recover task state before continuing. If `create_checkpoint` is unavailable (e.g. `task_checkpoints` table missing), continue with `.specs/` artifact state as the fallback.
+
 When work is interrupted, paused, or a session ends before the feature is complete:
 
 1. Update `.specs/project/STATE.md` — append any new decisions to the `## Decisions` section (append-only; decisions are normally written during Design, but runtime decisions discovered during Execute may be appended).

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

@@ -1,6 +1,6 @@
 # Spec-Driven Memory And State
 
-Use this reference when recording decisions, progress, blockers, handoff, or completion evidence for a spec-driven feature.
+Use when recording decisions, progress, blockers, handoff, or completion evidence for a spec-driven feature.
 
 This memory layer is split across two artifacts with distinct lifecycles. Each has its own write triggers; writes are always section-scoped — never whole-file overwrites.
 

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

@@ -1,8 +1,8 @@
 # Spec-Driven Specify
 
-Use this reference for the required Specify phase. **Goal**: Capture WHAT to build with testable, traceable requirements. The output is `.specs/features/<slug>/spec.md`.
+Use for the required Specify phase. **Goal**: Capture WHAT to build with testable, traceable requirements. The output is `.specs/features/<slug>/spec.md`.
 
-If the feature has ambiguous gray areas (multiple valid approaches for user-facing behavior), the agent will automatically trigger the [discuss gray areas](discuss.md) process within this phase. For clear, well-defined features, it goes straight to the next phase.
+If the feature has ambiguous gray areas (multiple valid approaches for user-facing behavior), the agent automatically triggers the [discuss gray areas](discuss.md) process within this phase. Clear, well-defined features go straight to the next phase.
 
 ## Inputs
 
@@ -67,7 +67,7 @@ The table is canonical; the prose is the applied sweep. **Large/Complex** work m
 
 **Load confirmed lessons first:** Before clarifying, load the project's confirmed lessons so past verification failures shape this spec instead of repeating. Run `bun skills/massa-ai/scripts/lessons.ts --root . list --status confirmed` (optionally `--scope [area]` or `--query [term]` for the area this feature touches) and apply what comes back as guidance. Load only `confirmed` — never `candidate` or `quarantined`. If no store exists yet or no code tool is available, skip silently. See [lessons.md](../lessons.md).
 
-**Lightweight context scan first (Knowledge Verification Chain Step 1):** Before asking questions, briefly scan existing code, patterns, and neighboring features relevant to this feature. Prefer massa-ai tooling first (`list_projects`, `search`, `project_map`, `optimized_context`) before `ast-grep`/`rg`/`grep`, honoring freshness and source-precedence (current source overrides stale index/memory). Use what you find to ground your clarifying questions in reality — not to constrain the spec to current implementation. Keep it lightweight (stay within the <40k token budget; reuse the chain, no new machinery). The spec captures WHAT is needed, not only what exists.
+**Lightweight context scan first (Knowledge Verification Chain Step 1):** Before asking questions, briefly scan existing code, patterns, and neighboring features relevant to this feature. Prefer massa-ai tooling first (`list_projects`, `search`, `project_map`, `optimized_context`) before `ast-grep`/`rg`/`grep`, honoring freshness and source-precedence (current source overrides stale index/memory). Use what you find to ground clarifying questions in reality — not to constrain the spec to current implementation. Keep it lightweight (stay within the <40k token budget; reuse the chain, no new machinery). The spec captures WHAT is needed, not only what exists.
 
 You are a thinking partner, not an interviewer. Start open — let the user dump their mental model. Follow the energy: whatever they emphasize, dig into that.
 

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

@@ -1,6 +1,6 @@
 # Sub-Agent Delegation
 
-Use this reference during Execute when formal task planning has more than 3 tasks, when the user explicitly asks for delegation, or when final validation needs an independent verifier. Full mechanics for phase-batch workers and the Verifier sub-agent used during Execute.
+Use during Execute when formal task planning has more than 3 tasks, when the user explicitly asks for delegation, or when final validation needs an independent verifier. Full mechanics for phase-batch workers and the Verifier sub-agent used during Execute.
 
 ## Phase-Batch Workers
 

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

@@ -1,6 +1,6 @@
 # Tasks
 
-Use this reference only when the TLC v3 flow includes Tasks. The output is the `.specs/features/<slug>/tasks.md`.
+Use only when the TLC v3 flow includes Tasks. The output is the `.specs/features/<slug>/tasks.md`.
 
 **Goal**: Break into GRANULAR, ATOMIC tasks. Clear dependencies. Right tools. Sequential phase execution plan.
 

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

@@ -1,6 +1,6 @@
 # Spec-Driven Validate
 
-Use this reference for the mandatory final Execute validation gate. This is not a separate phase — verification is part of every task's completion within Execute and runs automatically after the final task or inline step is complete.
+Use for the mandatory final Execute validation gate. This is not a separate phase — verification is part of every task's completion within Execute and runs automatically after the final task or inline step is complete.
 
 <!-- validator anchors: reject shallow assertions | payload/conjunction rule | per-task test adequacy review summary | fix-loop iteration count | 3 verification iterations -->
 

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

@@ -1,8 +1,8 @@
 # Subagent Design
 
-Use this reference only when designing or revising a reusable subagent role, adding a new role to `references/agent-orchestration.md`, or turning repeated delegated work into a stable role charter.
+Use only when designing or revising a reusable subagent role, adding a new role to `references/agent-orchestration.md`, or turning repeated delegated work into a stable role charter.
 
-Do not load this reference for ordinary one-off delegation. For runtime delegation, use `references/agent-orchestration.md`.
+Do not load for ordinary one-off delegation. For runtime delegation, use `references/agent-orchestration.md`.
 
 ## Principle
 
@@ -30,7 +30,7 @@ Is the work recurring, specialized, context-heavy, independently verifiable, and
   -> Design a reusable subagent role with this reference.
 ```
 
-Prefer a skill/reference when the value is procedure or domain knowledge. Prefer a subagent when the value is isolated context, parallel work, or independent verification.
+Prefer a skill/reference for procedure or domain knowledge. Prefer a subagent for isolated context, parallel work, or independent verification.
 
 Reusable role threshold:
 
@@ -94,7 +94,7 @@ Memory boundary:
 **The packet field list lives in one place: `references/agent-orchestration.md`,
 §Capability Packet.** Do not restate it here — a second copy is what let the field
 sets drift into three diverging shapes before the canonical section existed. When a
-workflow dispatches a reusable role, send that canonical packet rather than a loose
+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

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

@@ -1,6 +1,6 @@
 # Synapse Policy
 
-Load this reference when a task is expected to issue more than one
+Load when a task is expected to issue more than one
 `search`, when parallel agents need isolated retrieval context, or when
 Synapse compatibility/fallback behavior matters.
 

package/skills/massa-ai/references/tdd/calibrated-examples.md

@@ -2,7 +2,7 @@
 
 The values below are starting reference values, not requirements. They are calibration anchors, not mandates. Treat every number as a starting-point reference to be confirmed against the project's own SLOs, load profile, and regulatory scope; override per project and record the override in the TDD. None of these tables restore a prescriptive count schema or a fixed section-count mandate.
 
-Load this reference only when the TDD's conditional concerns (rollback, rollout, latency, compliance) apply and the team needs a concrete starting point. It complements `references/tdd/document-contract.md` (which owns the Conditional Concerns trigger table) by giving example budgets; it does not replace project-verified SLOs or legal obligations.
+Load only when the TDD's conditional concerns (rollback, rollout, latency, compliance) apply and the team needs a concrete starting point. It complements `references/tdd/document-contract.md` (which owns the Conditional Concerns trigger table) by giving example budgets; it does not replace project-verified SLOs or legal obligations.
 
 ## Rollback-Trigger Table
 

package/skills/massa-ai/references/tdd/discovery-and-sizing.md

@@ -1,6 +1,6 @@
 # TDD Discovery And Sizing
 
-Load this reference before source investigation, document sizing, or clarification questions for the TDD workflow.
+Load before source investigation, document sizing, or clarification questions for the TDD workflow.
 
 ## Evidence Order
 

package/skills/massa-ai/references/tdd/document-contract.md

@@ -1,6 +1,6 @@
 # TDD Document Contract
 
-Load this reference when drafting or revising a TDD. Use the smallest set of sections that makes the design decision-complete; headings may be renamed to match the user's language and project conventions.
+Load when drafting or revising a TDD. Use the smallest set of sections that makes the design decision-complete; headings may be renamed to match the user's language and project conventions.
 
 ## Core Sections
 

package/skills/massa-ai/references/tdd/quality-and-lifecycle.md

@@ -1,6 +1,6 @@
 # TDD Quality And Lifecycle
 
-Load this reference before challenging, finalizing, saving, or updating a TDD.
+Load before challenging, finalizing, saving, or updating a TDD.
 
 ## Quality Gate
 

package/skills/massa-ai/references/the-fool/cognitive-bias-inventory.md

@@ -4,7 +4,7 @@ Structured bias detection for use during every challenge pass. Integrates findin
 
 ## Core Principle
 
-Cognitive biases are not accusations — they are patterns in human reasoning that systematically distort judgment. The Fool's job is to flag when a bias may be influencing a decision, not to shame the user. Frame bias findings as: "This pattern is common in this type of decision, and here's how it might be affecting your reasoning."
+Cognitive biases are not accusations — they are patterns in human reasoning that systematically distort judgment. The Fool's job is to flag when a bias may be influencing a decision, not to shame the user. Frame bias findings as: "This pattern is common in this type of decision, and here's how it might affect your reasoning."
 
 ## When to Use This File
 

package/skills/massa-ai/references/the-fool/dialectic-synthesis.md

@@ -4,7 +4,7 @@ Hegelian dialectic with steel manning for constructing the strongest possible co
 
 ## Core Principle
 
-The dialectic is not about winning. It is about producing a stronger position than either thesis or antithesis alone. The Fool's job is to argue the other side so well that the user is forced to either refine their position or acknowledge a genuine trade-off.
+The dialectic is not about winning — it is about producing a stronger position than either thesis or antithesis alone. The Fool's job is to argue the other side so well that the user is forced to either refine their position or acknowledge a genuine trade-off.
 
 Key distinction: steel manning is epistemic (genuinely trying to find out if you're wrong), devil's advocacy is role-based (assigned to argue against). Apply both: steel man first, then construct the antithesis.
 

package/skills/massa-ai/references/the-fool/evidence-audit.md

@@ -4,7 +4,7 @@ Falsificationism and evidence quality assessment for auditing whether claims are
 
 ## Core Principle
 
-Karl Popper's key insight: a claim is only meaningful if you can specify what would disprove it. The Evidence Audit mode extracts claims from proposals, designs falsification criteria, assesses evidence quality, identifies cognitive biases, and surfaces competing explanations. The goal is not to disprove — it is to determine whether the evidence actually supports the conclusion.
+Karl Popper's key insight: a claim is only meaningful if you can specify what would disprove it. The Evidence Audit mode extracts claims from proposals, designs falsification criteria, assesses evidence quality, identifies cognitive biases, and surfaces competing explanations. The goal is not to disprove — it is to determine whether the evidence supports the conclusion.
 
 ## Process
 

package/skills/massa-ai/references/the-fool/pre-mortem-analysis.md

@@ -4,7 +4,7 @@ Pre-mortem methodology (Gary Klein) with second-order thinking for identifying h
 
 ## Core Principle
 
-A pre-mortem inverts the question. Instead of "Will this work?" ask: **"It's 6 months from now and this has failed. Why?"** This psychological shift bypasses optimism bias by making failure the starting point, not the thing to be argued against.
+A pre-mortem inverts the question. Instead of "Will this work?" ask: **"It's 6 months from now and this has failed. Why?"** This psychological shift bypasses optimism bias by making failure the starting point, not the thing being argued against.
 
 Research shows prospective hindsight increases correct failure identification by 30% compared to asking "what could go wrong?" directly.
 

package/skills/massa-ai/references/the-fool/red-team-adversarial.md

@@ -4,7 +4,7 @@ Adversarial thinking and red teaming for finding weaknesses before adversaries d
 
 ## Core Principle
 
-Red teaming asks: **"If someone wanted to break, exploit, or game this, how would they do it?"** The Fool adopts the mindset of an adversary — not to cause harm, but to find vulnerabilities before real adversaries do. This applies beyond security: competitors, disgruntled users, perverse incentives, and regulatory challenges are all adversarial forces.
+Red teaming asks: **"If someone wanted to break, exploit, or game this, how would they do it?"** The Fool adopts the mindset of an adversary — not to cause harm, but to find vulnerabilities before real adversaries do. This applies beyond security: competitors, disgruntled users, perverse incentives, and regulatory challenges are all adversarial forces too.
 
 ## The RED Model
 

package/skills/massa-ai/references/the-fool/socratic-questioning.md

@@ -4,7 +4,7 @@ Structured question frameworks for exposing assumptions and deepening understand
 
 ## Core Principle
 
-Socratic questioning does not argue. It asks. The goal is to help the user discover gaps in their own reasoning by surfacing what they have not examined. Every question should create a moment of "I hadn't thought about that."
+Socratic questioning does not argue — it asks. The goal is to help the user discover gaps in their own reasoning by surfacing what they have not examined. Every question should create a moment of "I hadn't thought about that."
 
 The agent must never answer the questions itself. Present them, let the user sit with them.
 

package/skills/massa-ai/references/ticket/atlassian-fix.md

@@ -1,6 +1,6 @@
 # Atlassian Ticket Execution
 
-Use this reference before any Atlassian tool call that reads creation metadata or mutates Jira.
+Use before any Atlassian tool call that reads creation metadata or mutates Jira.
 
 ## Capability Discovery
 

package/skills/massa-ai/references/ticket/intake-and-sources.md

@@ -1,6 +1,6 @@
 # Ticket Intake And Sources
 
-Use this reference from `workflows/ticket.md` before drafting. Gather only missing decisions, keep source roles explicit, and avoid repository-derived ticket conventions.
+Use from `workflows/ticket.md` before drafting. Gather only missing decisions, keep source roles explicit, and avoid repository-derived ticket conventions.
 
 ## Ordered Intake
 

package/skills/massa-ai/references/ticket/templates-and-quality.md

@@ -1,6 +1,6 @@
 # Ticket Templates And Quality
 
-Use this reference when decomposing work, selecting prefixes, drafting descriptions, and validating the review artifact.
+Use when decomposing work, selecting prefixes, drafting descriptions, and validating the review artifact.
 
 ## Title Prefixes
 

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

@@ -1,6 +1,6 @@
 # Verification Ladder
 
-Use this reference before completing work, and before Quick/Standard/Spec-driven sizing, shared-reference loading, or a verification recipe.
+Use before completing work, and before Quick/Standard/Spec-driven sizing, shared-reference loading, or a verification recipe.
 
 ## Task Sizing Gate