@massa-ai/codex-plugin 1.26.0 → 1.29.0

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

@@ -1,12 +1,20 @@
+---
+name: tests-fix
+description: "Executes fixes from a saved tests audit report; not for findings-only coverage review or generic test-writing work without an audit report."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### Tests Fix
 
-Use this workflow only to execute fixes from a tests audit markdown report.
+Execute fixes from a tests audit markdown report only.
 
-Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-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`.
+Before the first repository mutation, load `references/implementation-delivery.md` (delivery chain: worktree, atomic commits, PR, CI watch, merge gate) and `references/code-annotation.md` (doc blocks, rationale, test coverage). After two consecutive failed fixes on one symptom, stop editing and load `references/root-cause-scripts.md`.
 
-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.
+Not for findings-only test coverage, assertion quality, fixture health, flakiness, or regression-risk review — route to `workflows/tests/tests-audit.md`. Not 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:
@@ -24,7 +32,7 @@ Do not use this workflow for findings-only test coverage, assertion quality, fix
    - 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.
+   - Validate the report deterministically: `bun skills/massa-ai/scripts/validate_audit_report.ts <path> --family tests` (`references/audit-report-io.md`, Deterministic Validation); non-zero exit blocks editing. Also confirm resolved files or material scope evidence and current file/line evidence; stop on stale, target-drifted, or ambiguous reports.
 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.

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

@@ -1,10 +1,18 @@
+---
+name: the-fool
+description: "Use this workflow for direct requests to challenge ideas, plans, decisions, or evidence, and as the configured post-plan challenge gate after other workflows construct a plan."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### 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.
+Use for direct requests to challenge ideas, plans, decisions, proposals, architectures, evidence, or assumptions. Also use 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.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-Do not use this workflow to build the initial plan, make the decision, or execute implementation work. It critiques and strengthens existing thinking.
+Not to build the initial plan, make the decision, or execute implementation work. It critiques and strengthens existing thinking.
 
 ## Configuration
 

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

@@ -1,8 +1,16 @@
+---
+name: ticket
+description: "Use this workflow to draft, review, create, or resume creation of Jira Epics, issues, or sub-tasks through Atlassian MCP, the only tracker and mutation path."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### 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.
+Use 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.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
 ## Workflow
 

package/skills/massa-ai/workflows/to-prd.md

@@ -0,0 +1,81 @@
+---
+name: to-prd
+description: "Turn the current conversation into a PRD. Use when the user asks to create, synthesize, or convert existing discussion and codebase context into a Product Requirements Document without another interview. Do NOT use for implementation plans, architecture design docs, RFCs, TDDs, or discovery interviews that require new product questioning."
+license: MIT
+metadata:
+  version: "1.0.0"
+---
+
+### To-PRD (Conversation → Product Requirements Document)
+
+This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
+
+Route here only on explicit user request to convert the current conversation into a PRD (Product Requirements Document); refining an existing PRD stays `furps-refinement`.
+
+Load `references/project-context.md` (intake sweep) before the first substantive read.
+
+## Process
+
+1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
+
+2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
+
+Record the seams in the PRD and proceed from the current context unless the user explicitly asks to review them first.
+
+3. Write the PRD using the template below. Apply the `ready-for-agent` triage label - no need for additional triage.
+
+<prd-template>
+
+## Problem Statement
+
+The problem that the user is facing, from the user's perspective.
+
+## Solution
+
+The solution to the problem, from the user's perspective.
+
+## User Stories
+
+A LONG, numbered list of user stories. Each user story should be in the format of:
+
+1. As an <actor>, I want a <feature>, so that <benefit>
+
+<user-story-example>
+1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
+</user-story-example>
+
+This list of user stories should be extremely extensive and cover all aspects of the feature.
+
+## Implementation Decisions
+
+A list of implementation decisions that were made. This can include:
+
+- The modules that will be built/modified
+- The interfaces of those modules that will be modified
+- Technical clarifications from the developer
+- Architectural decisions
+- Schema changes
+- API contracts
+- Specific interactions
+
+Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+
+Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+
+## Testing Decisions
+
+A list of testing decisions that were made. Include:
+
+- A description of what makes a good test (only test external behavior, not implementation details)
+- Which modules will be tested
+- Prior art for the tests (i.e. similar types of tests in the codebase)
+
+## Out of Scope
+
+A description of the things that are out of scope for this PRD.
+
+## Further Notes
+
+Any further notes about the feature.
+
+</prd-template>