@massa-ai/cursor-plugin 1.6.0

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

@@ -0,0 +1,130 @@
+# Atlassian Ticket Execution
+
+Use this reference before any Atlassian tool call that reads creation metadata or mutates Jira.
+
+## Capability Discovery
+
+Inspect currently callable tools and dynamically identify Atlassian MCP operations by capability and schema, not by one provider-specific function name. Locate operations for:
+
+- Accessible Atlassian sites or cloud resources.
+- Jira project lookup.
+- Issue-type, field, option, and hierarchy metadata.
+- Jira issue search and issue retrieval.
+- Jira issue creation.
+
+Atlassian MCP is required. Do not use Jira CLI, REST calls assembled outside the MCP, browser automation, GitHub Issues, Linear, Trello, Asana, Shortcut, or local repository files as creation fallbacks.
+
+If multiple accessible sites contain the same project key, ask the user to choose the site before drafting final fields.
+
+## Preflight
+
+Complete preflight before requesting creation approval:
+
+1. Resolve the exact site or cloud resource and exact Jira project key.
+2. Fetch supported Epic, standard, and sub-task issue types needed by the selected hierarchy.
+3. Fetch required create fields and allowed values for each requested issue type, including parent-field behavior.
+4. Confirm the create operation is callable with the required fields.
+5. Validate every proposed parent relationship against Jira metadata.
+6. Search the selected project for potential duplicates using the exact summary plus the top 3 domain terms from the acceptance criteria, component/surface, and primary user-visible outcome. If fewer than 3 domain terms exist, use all available non-prefix terms and record the reduced query.
+7. Build the exact top-down creation order.
+
+Never promise that a generic `Story`, `Task`, `Bug`, `Spike`, `Epic`, or `Sub-task` name exists. Use the project's returned issue-type IDs and names. When Jira lacks the requested semantic type, show supported choices and require user selection instead of silently mapping it.
+
+## External Review Artifact
+
+Resolve the temporary plans directory in this order:
+
+- Codex: `$CODEX_HOME/plans/`; if `CODEX_HOME` is unset, use `~/.codex/plans/` only when that is the detected Codex home.
+- Claude Code: `~/.claude/plans/`.
+- Cursor: `~/.cursor/plans/`.
+- OpenCode: `~/.config/opencode/plans/`.
+- Other agents: the runtime-provided agent home plus `/plans/`.
+- If no agent home is known or the directory cannot be written, ask for an external writable directory.
+
+The path must resolve outside the active repository. Reject symlinks or relative paths that resolve inside it. Create one file named `ticket-<lowercase-project>-<kebab-slug>-<YYYYMMDDTHHMMSSZ>.md`.
+
+Minimum artifact metadata:
+
+```markdown
+# Jira Ticket Draft
+
+**Project:** EXAMPLE
+**Hierarchy:** epic-tickets | epic-tickets-subtasks | tickets-subtasks
+**Draft Revision:** 1
+**Approval Status:** NOT APPROVED
+**Approved Revision:** none
+**Created:** 2026-06-15T12:00:00Z
+```
+
+For each stable draft ID, include issue type ID and name, summary, parent draft ID or Jira key, dependency draft IDs or Jira keys, required fields, complete description, duplicate candidates and disposition, creation status, Jira key, and Jira URL. Include source pointers, open questions, and the ordered creation list once for the batch.
+
+Any revision to a summary, description, field, relationship, dependency, duplicate disposition, or creation order must increment `Draft Revision`, set `Approval Status: NOT APPROVED`, and clear `Approved Revision`.
+
+## Approval Gate
+
+After final metadata, quality, and duplicate checks, present the current artifact and ask for explicit approval to create the listed Jira issues for the named project and current revision.
+
+Valid approval must clearly authorize Jira creation for that revision. Approval does not carry across revisions. Do not treat prior approval, silence, "looks close", or a request to keep editing as authorization.
+
+Immediately before the first mutation, verify:
+
+- Artifact revision still equals approved revision.
+- Approval status is `APPROVED`.
+- Project, site, issue metadata, and duplicate dispositions have not changed since approval.
+- No unresolved blocking field or open question remains.
+
+If any check changes the draft, invalidate approval and return to review.
+
+## Creation Order And Checkpointing
+
+Create strictly top-down:
+
+1. New Epic, when selected. Capture its key and URL.
+2. Standard issues in dependency-safe order. Set the Epic or parent relationship only through the current Jira-supported field shape.
+3. Sub-tasks after each parent standard issue has a confirmed Jira key.
+
+After each successful create call:
+
+1. Verify the response contains a Jira key or stable identifier.
+2. Fetch or construct the canonical URL only from returned site and issue data.
+3. Update that draft ID in the external artifact to `CREATED` with key and URL before the next mutation.
+4. If artifact update fails, stop before creating another issue and report the confirmed Jira result.
+
+Do not add comments, transition statuses, assign owners, set optional fields, or link issues unless they are explicitly present in the approved draft.
+
+## Ambiguous Results And Partial Failure
+
+For timeout, connection loss, malformed response, or unknown create result:
+
+1. Stop the batch.
+2. Search the selected project using the approved summary plus the top 3 domain terms before retrying.
+3. If one matching issue is confirmed, record it as created and require resume approval for remaining items.
+4. If zero or multiple plausible matches remain, mark the draft ID `UNKNOWN`, report the ambiguity, and do not retry automatically.
+
+For any partial failure:
+
+- Retain the external artifact.
+- Report created, unknown, failed, and pending draft IDs with known Jira links.
+- Never auto-delete created issues.
+- Never auto-transition, comment on, or mark a parent blocked as compensation.
+- Never continue with dependent children after a parent failure.
+
+## Resume
+
+Resume only after explicit user approval of the retained artifact's current revision.
+
+Before resuming:
+
+1. Re-fetch every recorded Jira issue and parent relationship.
+2. Re-run duplicate searches for `UNKNOWN`, `FAILED`, and `PENDING` items.
+3. Re-fetch relevant issue metadata and required fields.
+4. Recompute remaining creation order.
+5. Update any changed facts in the artifact, increment revision, and invalidate old approval.
+
+Create only items confirmed missing. Jira is authoritative for already-created issues; the artifact is the review and checkpoint record.
+
+## Completion And Cleanup
+
+Complete only when every approved draft ID is mapped to a confirmed Jira issue and parent relationships match the approved hierarchy.
+
+Report all keys and URLs first. Then delete the temporary artifact. If deletion fails, report the path and error without changing the successful Jira outcome. Retain the artifact on cancellation, partial failure, or unresolved ambiguity.

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

@@ -0,0 +1,65 @@
+# 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.
+
+## Ordered Intake
+
+Resolve inputs in this order:
+
+1. **Jira project key**: require an explicit key such as `MOBILE`, `SA`, or `EXP`. Use Atlassian MCP to confirm exact accessibility and project identity. Do not infer a project from repository names, Git history, existing branch names, or arbitrary issue references.
+2. **Hierarchy**: require one of these exact modes:
+   - `epic-tickets`: create a new Epic and standard child issues.
+   - `epic-tickets-subtasks`: create a new Epic, standard child issues, and sub-tasks.
+   - `tickets-subtasks`: create standard issues and optional sub-tasks without creating an Epic. Ask for an existing Epic key only when the user wants those standard issues attached and Jira supports that relationship.
+3. **Ticket template source**: ask whether to use a Jira reference issue, an explicitly supplied local file or pasted template, or the built-in templates. A Jira reference may be supplied as a key or URL.
+4. **Definition of Ready and Definition of Done**: ask whether the user wants to provide either source. Accept Jira or Confluence content through Atlassian MCP, explicitly supplied local files, or pasted text. Use built-in checklists when omitted.
+5. **Jira-required choices**: after metadata inspection, ask only for unresolved issue types, priorities, components, labels, ownership, versions, or custom fields that are required by Jira or material to the user's intent.
+
+Group related choices into at most three concise questions at a time. Reuse answers across the draft unless the user scopes a different value to a specific issue.
+
+## Source Roles
+
+Use each source only for its declared role:
+
+- User prompt, supplied requirements, specs, TDDs, and approved project documents provide business and technical facts.
+- Jira or pasted reference tickets provide headings, field conventions, tone, naming style, and expected detail.
+- DoR/DoD sources provide readiness and completion checks.
+- Current Jira metadata provides authoritative project, issue-type, field, option, and hierarchy constraints.
+- Current source code provides verified implementation context when exploration is enabled.
+- massa-ai memory provides leads and prior conventions, not current Jira truth.
+
+Never copy a reference ticket's business context, customer names, issue keys, owners, components, labels, dates, estimates, links, acceptance criteria, or implementation claims unless another valid source confirms they apply.
+
+If a reference and current Jira metadata conflict, current Jira metadata wins for fields and hierarchy. Surface meaningful format conflicts instead of silently blending them.
+
+## Bounded Code Exploration
+
+Run the massa-ai exploration workflow as a read-only child pass when ticket quality depends on current implementation context, reusable utilities, ownership boundaries, or likely affected modules.
+
+Skip exploration when:
+
+- The user explicitly opts out.
+- No codebase is available.
+- Work is process-only and source inspection would not improve scope or verification.
+- Supplied authoritative design material already resolves the relevant implementation boundaries.
+
+Exploration must:
+
+- Start from the closest code entry point to the requested behavior.
+- Return exact current-source paths or symbols plus confirmed patterns and constraints.
+- Separate confirmed facts from inferences.
+- Use one consolidated pass by default.
+- Parallelize only genuinely independent code areas when agent orchestration is available and context packets remain isolated.
+
+Exploration must not:
+
+- Search Git history, branches, commits, pull requests, or repository ticket references for ticket examples or template conventions.
+- Invent file paths or prescribe implementation details unsupported by current source.
+- Turn repository observations into Jira project conventions.
+
+## Missing Sources
+
+- Unreadable Jira reference: ask whether to retry with a valid key or use built-in templates.
+- Unreadable DoR/DoD source: report which source failed and ask whether to retry or use the corresponding default.
+- Ambiguous pasted content: ask whether it is a template, factual requirements, DoR, or DoD before using it.
+- Large source set: apply `references/context-firewall.md` and retain compact facts with source pointers instead of raw copies.

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

@@ -0,0 +1,129 @@
+# Ticket Templates And Quality
+
+Use this reference when decomposing work, selecting prefixes, drafting descriptions, and validating the review artifact.
+
+## Title Prefixes
+
+Every Epic, standard issue, and sub-task summary must start with exactly one allowed prefix:
+
+`[Mobile]`, `[FE]`, `[BE]`, `[Mobile/FE/BE]`, `[Mobile/FE]`, `[Mobile/BE]`, `[FE/BE]`, `[SPIKE]`, `[E2E]`, `[INFRA]`, `[DEVOPS]`
+
+Selection rules:
+
+- Use `[SPIKE]`, `[E2E]`, `[INFRA]`, or `[DEVOPS]` when purpose defines the work.
+- Otherwise select the exact affected application layers.
+- Do not add service names as extra bracketed prefixes.
+- Ask when source evidence supports multiple prefixes and the distinction changes ownership or scope.
+- Keep the remaining summary concise, action-oriented, and specific enough to distinguish duplicate candidates.
+
+## Built-In Definition Of Ready
+
+Use when the user supplies no DoR:
+
+- Outcome and motivation are clear.
+- In-scope and out-of-scope boundaries are explicit.
+- Acceptance or exit criteria are observable and testable.
+- Dependencies, blockers, and parent relationships are identified.
+- Required design, API, UX, data, or operational references are linked when applicable.
+- Important unknowns have an owner or are explicitly excluded from the ticket.
+- Jira-required fields are resolved.
+
+## Built-In Definition Of Done
+
+Use when the user supplies no DoD:
+
+- Acceptance or exit criteria have objective evidence.
+- Relevant automated tests and required manual checks pass.
+- Lint, type, build, and validation commands required by the affected project pass.
+- Security, privacy, accessibility, observability, migration, and rollback work is completed when triggered by scope.
+- Documentation and operational runbooks are updated when behavior or operations changed.
+- No unrelated scope is bundled into completion.
+- Created or changed behavior is traceable to this Jira issue.
+
+Do not add impossible or irrelevant default checks to a ticket. Mark a default item `Not applicable` only with a short reason, or remove it during review.
+
+## Built-In Templates
+
+Follow a user-provided template's compatible structure first. Otherwise use the smallest applicable built-in template.
+
+### Epic
+
+- **Outcome**: user or business result and why it matters.
+- **Context**: source-backed background and constraints.
+- **Scope**: explicit in scope and out of scope.
+- **Success Measures**: observable outcomes without fabricated metrics.
+- **Child Work**: proposed standard issues and dependency order.
+- **Dependencies And Risks**: external teams, systems, decisions, and material risks.
+- **References**: supplied documents and verified links.
+- **Definition Of Ready** and **Definition Of Done**.
+
+### Story Or Task
+
+- **Goal**: delivered outcome and value.
+- **Context**: enough source-backed context for an assignee with no prior conversation.
+- **Scope**: in scope and out of scope.
+- **Implementation Context**: verified files, modules, contracts, or reusable patterns when exploration ran; avoid prescribing incidental syntax.
+- **Acceptance Criteria**: observable behavior, including important failure behavior.
+- **Dependencies** and **References**.
+- **Definition Of Ready** and **Definition Of Done**.
+
+Use Story for user-facing value and Task for engineering or operational work without direct user value, subject to project-supported Jira issue types.
+
+### Bug
+
+- **Problem**: observed incorrect behavior and impact.
+- **Environment**: affected platform, version, environment, or configuration when known.
+- **Steps To Reproduce**: deterministic steps when available.
+- **Expected Behavior** and **Actual Behavior**.
+- **Evidence**: logs, screenshots, links, or verified source pointers.
+- **Suspected Area**: only evidence-backed locations or hypotheses.
+- **Acceptance Criteria**: corrected behavior plus regression coverage.
+- **Dependencies**, **References**, **Definition Of Ready**, and **Definition Of Done**.
+
+Never state a root cause as fact unless verified. Label hypotheses as hypotheses.
+
+### Spike
+
+- **Question**: the decision or uncertainty to resolve.
+- **Context**: why investigation is needed now.
+- **Scope**: approaches, systems, and explicit exclusions.
+- **Required Evidence**: prototypes, measurements, source review, or vendor documentation.
+- **Exit Criteria**: questions answered, options compared, trade-offs documented, and recommendation produced.
+- **Deliverable**: expected artifact or decision record.
+- **Timebox**: include only when user-provided or required by project convention.
+- **Dependencies**, **References**, **Definition Of Ready**, and **Definition Of Done**.
+
+### Sub-Task
+
+- **Parent Outcome**: parent issue key or stable parent draft ID and contribution to it.
+- **Atomic Work**: one bounded implementation or verification action.
+- **Implementation Context**: verified target boundary when known.
+- **Acceptance Criteria**: evidence that this action is complete.
+- **Dependencies**, **References**, **Definition Of Ready**, and **Definition Of Done**.
+
+A sub-task cannot exist without one standard parent issue. Do not use sub-tasks to hide independently deliverable scope.
+
+## Decomposition Rules
+
+- Prefer independently verifiable standard issues over arbitrary layer-by-layer fragments.
+- Use sub-tasks only when work cannot deliver independently outside its parent because it shares the same owner, release path, acceptance outcome, and verification gate.
+- Split work when acceptance criteria can pass independently, owners differ, release paths differ, one issue contains >3 outcomes, one issue contains >8 checklist items, or a draft mixes unrelated user-visible outcomes.
+- Do not enforce fixed day estimates. Size by outcome coherence, dependency boundaries, reviewability, and whether an assignee can complete the work without reopening product decisions.
+- Express dependency edges through stable draft IDs before Jira keys exist. Reject self-dependencies and cycles.
+
+## Deterministic Quality Gate
+
+Before review approval, verify every draft:
+
+1. Project key was validated through Atlassian MCP.
+2. Requested issue type exists and all Jira-required fields have values or explicit user-approved omission where Jira permits it.
+3. Summary starts with exactly one allowed prefix and contains meaningful text after it.
+4. Outcome, scope, and relevant context are present and source-backed.
+5. Story, Task, Bug, and Sub-task drafts contain observable acceptance criteria; Spike drafts contain observable exit criteria; Epics contain success measures and child scope.
+6. Parent relationships follow current Jira metadata and selected hierarchy mode.
+7. Dependency graph is acyclic and references valid draft IDs or verified Jira keys.
+8. No unresolved placeholder such as `TBD`, `TODO`, `[fill in]`, or invented fact blocks creation. Non-blocking unknowns are labeled and excluded from scope.
+9. Duplicate search was run in the selected project and candidates have an explicit create, revise, or cancel disposition.
+10. Draft artifact records source pointers, open questions, creation order, `Draft Revision`, and `Approval Status: NOT APPROVED` before review.
+
+Do not use an LLM-only quality judgment as proof that these gates passed.

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

@@ -0,0 +1,62 @@
+# Verification Ladder
+
+Use this reference before completing work, and before Quick/Standard/Spec-driven sizing, shared-reference loading, or a verification recipe.
+
+## Task Sizing Gate
+
+Classify implementation size before editing:
+
+- Quick: <=3 files and <=200 changed LOC, clear acceptance criteria, one ownership area, no public contract, no security/privacy, no migration, no irreversible operation, and no cross-service compatibility risk.
+- Standard: <=10 files or <=500 changed LOC within one ownership area, or shared behavior/public API/test impact that still has clear acceptance criteria and no unresolved architecture decision.
+- Spec-driven: >10 files, >500 changed LOC, multiple ownership areas, unclear acceptance criteria, new dependency, migration, irreversible operation, security/privacy/auth, public compatibility, cross-service contract, or any unresolved architecture/product decision.
+
+Quick tasks can proceed inside the active workflow. Standard tasks need an explicit verification recipe before edits. Spec-driven tasks should route to `workflows/spec-driven.md` or be split into atomic tasks.
+
+## Shared Reference Trigger Table
+
+Load these references when the trigger condition is met:
+
+| Reference | Deterministic trigger |
+|---|---|
+| `references/context-firewall.md` | Before raw artifacts >200 lines, >20 KB, >50 search hits, generated reports, logs, screenshots, external research, or broad search output. |
+| `references/pr-task-fix.md` | Standard+ feature/refactor work, any work split into PR groups, or any task with >3 files or >200 LOC. |
+| `references/agent-orchestration.md` | Explicit user delegation request, >=2 independent slices, >10 files, high/critical audit findings, or independent verification. Do not load for overlapping write sets or tasks needing full conversation history. |
+| `references/naming-standards.md` | New, renamed, audited, or preserved implementation-facing identifiers, public contract fields, fixtures, tests, schemas, docs, or examples. |
+| `references/synapse-policy.md` | Planned related `search` calls >=2, parallel delegated retrieval, or Synapse fallback diagnosis. |
+| `references/mobile-context.md` | Non-debug Android, iOS, KMP, native bridge, lifecycle, offline/sync, permissions, push/background, local persistence, or backend-mobile contract work. |
+| `references/mobile-diagnosis.md` | Debug target involves Android, iOS, KMP, devices, simulators/emulators, native bridges, lifecycle, or mobile-only regressions. |
+
+## Verification Recipe
+
+Before Quick work that touches validation assets, and before all Standard or Spec-driven edits, name:
+
+- expected behavior or acceptance criteria
+- commands, tests, builds, linters, or artifact checks to run
+- validation assets that must not be weakened, such as tests, specs, benchmarks, fixtures, and snapshots
+- skipped checks and the reason they cannot run
+
+## Mandatory Verification Fix Gate
+
+Every `*-fix` workflow must execute this gate for each selected finding or coherent finding group before it can claim closure:
+
+- Run the report's Verification Suggestion when available, or run an equivalent deterministic command/artifact check that proves the same behavior.
+- Run target-relevant tests, builds, lint, type checks, static checks, runtime checks, render sensors, or artifact inspections before final closure; model judgment alone cannot satisfy the gate.
+- A finding cannot be marked `fixed` when a target-relevant command or artifact check exists but was not attempted.
+- If verification cannot run, record one concrete skipped-check reason and mark the finding `blocked`, `deferred`, or `skipped`; do not silently complete it.
+- Reinspect validation assets after changes and record that tests, specs, fixtures, snapshots, benchmarks, public contracts, and generated baselines were not weakened unless the user explicitly requested that validation-asset change.
+- Closure evidence must include command/artifact, result, skipped reason or `none`, highest Verification Ladder level reached, validation assets protected, and residual risk.
+
+## Ladder
+
+Use the cheapest sufficient evidence first:
+
+1. Static checks: lint, typecheck, import checks, schema validation, or focused static scans.
+2. File integrity: confirm validation assets were not deleted, weakened, or rewritten unless the user explicitly requested that change.
+3. Behavioral checks: targeted tests, reproduction commands, build outputs, CLI transcripts, UI artifact inspection, or runtime checks.
+4. Higher-order checks: judge, faithfulness, or semantic similarity checks only when a concrete tool or command exists.
+
+Do not use model self-evaluation as completion evidence. If a higher-order check is unavailable, state that it was skipped and rely on deterministic evidence.
+
+## Output
+
+Report the highest ladder level reached, key command or artifact evidence, skipped checks, and residual risk.