ma-agents 3.4.9 → 3.5.1

package/.opencode/skills/bmad-review-adversarial-general/SKILL.md

@@ -1,37 +0,0 @@
----
-name: bmad-review-adversarial-general
-description: 'Perform a Cynical Review and produce a findings report. Use when the user requests a critical review of something'
----
-
-# Adversarial Review (General)
-
-**Goal:** Cynically review content and produce findings.
-
-**Your Role:** You are a cynical, jaded reviewer with zero patience for sloppy work. The content was submitted by a clueless weasel and you expect to find problems. Be skeptical of everything. Look for what's missing, not just what's wrong. Use a precise, professional tone — no profanity or personal attacks.
-
-**Inputs:**
-- **content** — Content to review: diff, spec, story, doc, or any artifact
-- **also_consider** (optional) — Areas to keep in mind during review alongside normal adversarial analysis
-
-
-## EXECUTION
-
-### Step 1: Receive Content
-
-- Load the content to review from provided input or context
-- If content to review is empty, ask for clarification and abort
-- Identify content type (diff, branch, uncommitted changes, document, etc.)
-
-### Step 2: Adversarial Analysis
-
-Review with extreme skepticism — assume problems exist. Find at least ten issues to fix or improve in the provided content.
-
-### Step 3: Present Findings
-
-Output findings as a Markdown list (descriptions only).
-
-
-## HALT CONDITIONS
-
-- HALT if zero findings — this is suspicious, re-analyze or ask for guidance
-- HALT if content is empty or unreadable

package/.opencode/skills/bmad-review-edge-case-hunter/SKILL.md

@@ -1,67 +0,0 @@
----
-name: bmad-review-edge-case-hunter
-description: 'Walk every branching path and boundary condition in content, report only unhandled edge cases. Orthogonal to adversarial review - method-driven not attitude-driven. Use when you need exhaustive edge-case analysis of code, specs, or diffs.'
----
-
-# Edge Case Hunter Review
-
-**Goal:** You are a pure path tracer. Never comment on whether code is good or bad; only list missing handling.
-When a diff is provided, scan only the diff hunks and list boundaries that are directly reachable from the changed lines and lack an explicit guard in the diff.
-When no diff is provided (full file or function), treat the entire provided content as the scope.
-Ignore the rest of the codebase unless the provided content explicitly references external functions.
-
-**Inputs:**
-- **content** — Content to review: diff, full file, or function
-- **also_consider** (optional) — Areas to keep in mind during review alongside normal edge-case analysis
-
-**MANDATORY: Execute steps in the Execution section IN EXACT ORDER. DO NOT skip steps or change the sequence. When a halt condition triggers, follow its specific instruction exactly. Each action within a step is a REQUIRED action to complete that step.**
-
-**Your method is exhaustive path enumeration — mechanically walk every branch, not hunt by intuition. Report ONLY paths and conditions that lack handling — discard handled ones silently. Do NOT editorialize or add filler — findings only.**
-
-
-## EXECUTION
-
-### Step 1: Receive Content
-
-- Load the content to review strictly from provided input
-- If content is empty, or cannot be decoded as text, return `[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]` and stop
-- Identify content type (diff, full file, or function) to determine scope rules
-
-### Step 2: Exhaustive Path Analysis
-
-**Walk every branching path and boundary condition within scope — report only unhandled ones.**
-
-- If `also_consider` input was provided, incorporate those areas into the analysis
-- Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
-- For each path: determine whether the content handles it
-- Collect only the unhandled paths as findings — discard handled ones silently
-
-### Step 3: Validate Completeness
-
-- Revisit every edge class from Step 2 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
-- Add any newly found unhandled paths to findings; discard confirmed-handled ones
-
-### Step 4: Present Findings
-
-Output findings as a JSON array following the Output Format specification exactly.
-
-
-## OUTPUT FORMAT
-
-Return ONLY a valid JSON array of objects. Each object must contain exactly these four fields and nothing else:
-
-```json
-[{
-  "location": "file:start-end (or file:line when single line, or file:hunk when exact line unavailable)",
-  "trigger_condition": "one-line description (max 15 words)",
-  "guard_snippet": "minimal code sketch that closes the gap (single-line escaped string, no raw newlines or unescaped quotes)",
-  "potential_consequence": "what could actually go wrong (max 15 words)"
-}]
-```
-
-No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when no unhandled paths are found.
-
-
-## HALT CONDITIONS
-
-- If content is empty or cannot be decoded as text, return `[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]` and stop

package/.opencode/skills/bmad-shard-doc/SKILL.md

@@ -1,105 +0,0 @@
----
-name: bmad-shard-doc
-description: 'Splits large markdown documents into smaller, organized files based on level 2 (default) sections. Use if the user says perform shard document'
----
-
-# Shard Document
-
-**Goal:** Split large markdown documents into smaller, organized files based on level 2 sections using `npx @kayvan/markdown-tree-parser`.
-
-## CRITICAL RULES
-
-- MANDATORY: Execute ALL steps in the EXECUTION section IN EXACT ORDER
-- DO NOT skip steps or change the sequence
-- HALT immediately when halt-conditions are met
-- Each action within a step is a REQUIRED action to complete that step
-
-## EXECUTION
-
-### Step 1: Get Source Document
-
-- Ask user for the source document path if not provided already
-- Verify file exists and is accessible
-- Verify file is markdown format (.md extension)
-- If file not found or not markdown: HALT with error message
-
-### Step 2: Get Destination Folder
-
-- Determine default destination: same location as source file, folder named after source file without .md extension
-  - Example: `/path/to/architecture.md` --> `/path/to/architecture/`
-- Ask user for the destination folder path (`[y]` to confirm use of default: `[suggested-path]`, else enter a new path)
-- If user accepts default: use the suggested destination path
-- If user provides custom path: use the custom destination path
-- Verify destination folder exists or can be created
-- Check write permissions for destination
-- If permission denied: HALT with error message
-
-### Step 3: Execute Sharding
-
-- Inform user that sharding is beginning
-- Execute command: `npx @kayvan/markdown-tree-parser explode [source-document] [destination-folder]`
-- Capture command output and any errors
-- If command fails: HALT and display error to user
-
-### Step 4: Verify Output
-
-- Check that destination folder contains sharded files
-- Verify index.md was created in destination folder
-- Count the number of files created
-- If no files created: HALT with error message
-
-### Step 5: Report Completion
-
-- Display completion report to user including:
-  - Source document path and name
-  - Destination folder path
-  - Number of section files created
-  - Confirmation that index.md was created
-  - Any tool output or warnings
-- Inform user that sharding completed successfully
-
-### Step 6: Handle Original Document
-
-> **Critical:** Keeping both the original and sharded versions defeats the purpose of sharding and can cause confusion.
-
-Present user with options for the original document:
-
-> What would you like to do with the original document `[source-document-name]`?
->
-> Options:
-> - `[d]` Delete - Remove the original (recommended - shards can always be recombined)
-> - `[m]` Move to archive - Move original to a backup/archive location
-> - `[k]` Keep - Leave original in place (NOT recommended - defeats sharding purpose)
->
-> Your choice (d/m/k):
-
-#### If user selects `d` (delete)
-
-- Delete the original source document file
-- Confirm deletion to user: "Original document deleted: [source-document-path]"
-- Note: The document can be reconstructed from shards by concatenating all section files in order
-
-#### If user selects `m` (move)
-
-- Determine default archive location: same directory as source, in an `archive` subfolder
-  - Example: `/path/to/architecture.md` --> `/path/to/archive/architecture.md`
-- Ask: Archive location (`[y]` to use default: `[default-archive-path]`, or provide custom path)
-- If user accepts default: use default archive path
-- If user provides custom path: use custom archive path
-- Create archive directory if it does not exist
-- Move original document to archive location
-- Confirm move to user: "Original document moved to: [archive-path]"
-
-#### If user selects `k` (keep)
-
-- Display warning to user:
-  - Keeping both original and sharded versions is NOT recommended
-  - The discover_inputs protocol may load the wrong version
-  - Updates to one will not reflect in the other
-  - Duplicate content taking up space
-  - Consider deleting or archiving the original document
-- Confirm user choice: "Original document kept at: [source-document-path]"
-
-## HALT CONDITIONS
-
-- HALT if npx command fails or produces no output files

package/.opencode/skills/bmad-sprint-planning/SKILL.md

@@ -1,6 +0,0 @@
----
-name: bmad-sprint-planning
-description: 'Generate sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"'
----
-
-Follow the instructions in ./workflow.md.

package/.opencode/skills/bmad-sprint-planning/checklist.md

@@ -1,33 +0,0 @@
-# Sprint Planning Validation Checklist
-
-## Core Validation
-
-### Complete Coverage Check
-
-- [ ] Every epic found in epic\*.md files appears in sprint-status.yaml
-- [ ] Every story found in epic\*.md files appears in sprint-status.yaml
-- [ ] Every epic has a corresponding retrospective entry
-- [ ] No items in sprint-status.yaml that don't exist in epic files
-
-### Parsing Verification
-
-Compare epic files against generated sprint-status.yaml:
-
-```
-Epic Files Contains:                Sprint Status Contains:
-✓ Epic 1                            ✓ epic-1: [status]
-  ✓ Story 1.1: User Auth              ✓ 1-1-user-auth: [status]
-  ✓ Story 1.2: Account Mgmt           ✓ 1-2-account-mgmt: [status]
-  ✓ Story 1.3: Plant Naming           ✓ 1-3-plant-naming: [status]
-                                      ✓ epic-1-retrospective: [status]
-✓ Epic 2                            ✓ epic-2: [status]
-  ✓ Story 2.1: Personality Model      ✓ 2-1-personality-model: [status]
-  ✓ Story 2.2: Chat Interface         ✓ 2-2-chat-interface: [status]
-                                      ✓ epic-2-retrospective: [status]
-```
-
-### Final Check
-
-- [ ] Total count of epics matches
-- [ ] Total count of stories matches
-- [ ] All items are in the expected order (epic, stories, retrospective)

package/.opencode/skills/bmad-sprint-planning/sprint-status-template.yaml

@@ -1,56 +0,0 @@
-# Sprint Status Template
-# This is an EXAMPLE showing the expected format
-# The actual file will be generated with all epics/stories from your epic files
-
-# generated: {date}
-# project: {project_name}
-# project_key: {project_key}
-# tracking_system: {tracking_system}
-# story_location: {story_location}
-
-# STATUS DEFINITIONS:
-# ==================
-# Epic Status:
-#   - backlog: Epic not yet started
-#   - in-progress: Epic actively being worked on
-#   - done: All stories in epic completed
-#
-# Story Status:
-#   - backlog: Story only exists in epic file
-#   - ready-for-dev: Story file created, ready for development
-#   - in-progress: Developer actively working on implementation
-#   - review: Implementation complete, ready for review
-#   - done: Story completed
-#
-# Retrospective Status:
-#   - optional: Can be completed but not required
-#   - done: Retrospective has been completed
-#
-# WORKFLOW NOTES:
-# ===============
-# - Mark epic as 'in-progress' when starting work on its first story
-# - SM typically creates next story ONLY after previous one is 'done' to incorporate learnings
-# - Dev moves story to 'review', then Dev runs code-review (fresh context, ideally different LLM)
-
-# EXAMPLE STRUCTURE (your actual epics/stories will replace these):
-
-generated: 05-06-2-2025 21:30
-last_updated: 05-06-2-2025 21:30
-project: My Awesome Project
-project_key: NOKEY
-tracking_system: file-system
-story_location: "{story_location}"
-
-development_status:
-  epic-1: backlog
-  1-1-user-authentication: done
-  1-2-account-management: ready-for-dev
-  1-3-plant-data-model: backlog
-  1-4-add-plant-manual: backlog
-  epic-1-retrospective: optional
-
-  epic-2: backlog
-  2-1-personality-system: backlog
-  2-2-chat-interface: backlog
-  2-3-llm-integration: backlog
-  epic-2-retrospective: optional

package/.opencode/skills/bmad-sprint-planning/workflow.md

@@ -1,263 +0,0 @@
-# Sprint Planning Workflow
-
-**Goal:** Generate sprint status tracking from epics, detecting current story statuses and building a complete sprint-status.yaml file.
-
-**Your Role:** You are a Scrum Master generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml.
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `implementation_artifacts`
-- `planning_artifacts`
-- `date` as system-generated current datetime
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
-### Paths
-
-- `tracking_system` = `file-system`
-- `project_key` = `NOKEY`
-- `story_location` = `{implementation_artifacts}`
-- `story_location_absolute` = `{implementation_artifacts}`
-- `epics_location` = `{planning_artifacts}`
-- `epics_pattern` = `*epic*.md`
-- `status_file` = `{implementation_artifacts}/sprint-status.yaml`
-
-### Input Files
-
-| Input | Path | Load Strategy |
-|-------|------|---------------|
-| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
-
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
-
-### Document Discovery - Full Epic Loading
-
-**Strategy**: Sprint planning needs ALL epics and stories to build complete status tracking.
-
-**Epic Discovery Process:**
-
-1. **Search for whole document first** - Look for `epics.md`, `bmm-epics.md`, or any `*epic*.md` file
-2. **Check for sharded version** - If whole document not found, look for `epics/index.md`
-3. **If sharded version found**:
-   - Read `index.md` to understand the document structure
-   - Read ALL epic section files listed in the index (e.g., `epic-1.md`, `epic-2.md`, etc.)
-   - Process all epics and their stories from the combined content
-   - This ensures complete sprint status coverage
-4. **Priority**: If both whole and sharded versions exist, use the whole document
-
-**Fuzzy matching**: Be flexible with document names - users may use variations like `epics.md`, `bmm-epics.md`, `user-stories.md`, etc.
-
-<workflow>
-
-<step n="1" goal="Parse epic files and extract all work items">
-<action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
-<action>Communicate in {communication_language} with {user_name}</action>
-<action>Look for all files matching `{epics_pattern}` in {epics_location}</action>
-<action>Could be a single `epics.md` file or multiple `epic-1.md`, `epic-2.md` files</action>
-
-<action>For each epic file found, extract:</action>
-
-- Epic numbers from headers like `## Epic 1:` or `## Epic 2:`
-- Story IDs and titles from patterns like `### Story 1.1: User Authentication`
-- Convert story format from `Epic.Story: Title` to kebab-case key: `epic-story-title`
-
-**Story ID Conversion Rules:**
-
-- Original: `### Story 1.1: User Authentication`
-- Replace period with dash: `1-1`
-- Convert title to kebab-case: `user-authentication`
-- Final key: `1-1-user-authentication`
-
-<action>Build complete inventory of all epics and stories from all epic files</action>
-</step>
-
-<step n="2" goal="Build sprint status structure">
-<action>For each epic found, create entries in this order:</action>
-
-1. **Epic entry** - Key: `epic-{num}`, Default status: `backlog`
-2. **Story entries** - Key: `{epic}-{story}-{title}`, Default status: `backlog`
-3. **Retrospective entry** - Key: `epic-{num}-retrospective`, Default status: `optional`
-
-**Example structure:**
-
-```yaml
-development_status:
-  epic-1: backlog
-  1-1-user-authentication: backlog
-  1-2-account-management: backlog
-  epic-1-retrospective: optional
-```
-
-</step>
-
-<step n="3" goal="Apply intelligent status detection">
-<action>For each story, detect current status by checking files:</action>
-
-**Story file detection:**
-
-- Check: `{story_location_absolute}/{story-key}.md` (e.g., `stories/1-1-user-authentication.md`)
-- If exists → upgrade status to at least `ready-for-dev`
-
-**Preservation rule:**
-
-- If existing `{status_file}` exists and has more advanced status, preserve it
-- Never downgrade status (e.g., don't change `done` to `ready-for-dev`)
-
-**Status Flow Reference:**
-
-- Epic: `backlog` → `in-progress` → `done`
-- Story: `backlog` → `ready-for-dev` → `in-progress` → `review` → `done`
-- Retrospective: `optional` ↔ `done`
-  </step>
-
-<step n="4" goal="Generate sprint status file">
-<action>Create or update {status_file} with:</action>
-
-**File Structure:**
-
-```yaml
-# generated: {date}
-# last_updated: {date}
-# project: {project_name}
-# project_key: {project_key}
-# tracking_system: {tracking_system}
-# story_location: {story_location}
-
-# STATUS DEFINITIONS:
-# ==================
-# Epic Status:
-#   - backlog: Epic not yet started
-#   - in-progress: Epic actively being worked on
-#   - done: All stories in epic completed
-#
-# Epic Status Transitions:
-#   - backlog → in-progress: Automatically when first story is created (via create-story)
-#   - in-progress → done: Manually when all stories reach 'done' status
-#
-# Story Status:
-#   - backlog: Story only exists in epic file
-#   - ready-for-dev: Story file created in stories folder
-#   - in-progress: Developer actively working on implementation
-#   - review: Ready for code review (via Dev's code-review workflow)
-#   - done: Story completed
-#
-# Retrospective Status:
-#   - optional: Can be completed but not required
-#   - done: Retrospective has been completed
-#
-# WORKFLOW NOTES:
-# ===============
-# - Epic transitions to 'in-progress' automatically when first story is created
-# - Stories can be worked in parallel if team capacity allows
-# - SM typically creates next story after previous one is 'done' to incorporate learnings
-# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
-
-generated: { date }
-last_updated: { date }
-project: { project_name }
-project_key: { project_key }
-tracking_system: { tracking_system }
-story_location: { story_location }
-
-development_status:
-  # All epics, stories, and retrospectives in order
-```
-
-<action>Write the complete sprint status YAML to {status_file}</action>
-<action>CRITICAL: Metadata appears TWICE - once as comments (#) for documentation, once as YAML key:value fields for parsing</action>
-<action>Ensure all items are ordered: epic, its stories, its retrospective, next epic...</action>
-</step>
-
-<step n="5" goal="Validate and report">
-<action>Perform validation checks:</action>
-
-- [ ] Every epic in epic files appears in {status_file}
-- [ ] Every story in epic files appears in {status_file}
-- [ ] Every epic has a corresponding retrospective entry
-- [ ] No items in {status_file} that don't exist in epic files
-- [ ] All status values are legal (match state machine definitions)
-- [ ] File is valid YAML syntax
-
-<action>Count totals:</action>
-
-- Total epics: {{epic_count}}
-- Total stories: {{story_count}}
-- Epics in-progress: {{in_progress_count}}
-- Stories done: {{done_count}}
-
-<action>Display completion summary to {user_name} in {communication_language}:</action>
-
-**Sprint Status Generated Successfully**
-
-- **File Location:** {status_file}
-- **Total Epics:** {{epic_count}}
-- **Total Stories:** {{story_count}}
-- **Epics In Progress:** {{in_progress_count}}
-- **Stories Completed:** {{done_count}}
-
-**Next Steps:**
-
-1. Review the generated {status_file}
-2. Use this file to track development progress
-3. Agents will update statuses as they work
-4. Re-run this workflow to refresh auto-detected statuses
-
-</step>
-
-</workflow>
-
-## Additional Documentation
-
-### Status State Machine
-
-**Epic Status Flow:**
-
-```
-backlog → in-progress → done
-```
-
-- **backlog**: Epic not yet started
-- **in-progress**: Epic actively being worked on (stories being created/implemented)
-- **done**: All stories in epic completed
-
-**Story Status Flow:**
-
-```
-backlog → ready-for-dev → in-progress → review → done
-```
-
-- **backlog**: Story only exists in epic file
-- **ready-for-dev**: Story file created (e.g., `stories/1-3-plant-naming.md`)
-- **in-progress**: Developer actively working
-- **review**: Ready for code review (via Dev's code-review workflow)
-- **done**: Completed
-
-**Retrospective Status:**
-
-```
-optional ↔ done
-```
-
-- **optional**: Ready to be conducted but not required
-- **done**: Finished
-
-### Guidelines
-
-1. **Epic Activation**: Mark epic as `in-progress` when starting work on its first story
-2. **Sequential Default**: Stories are typically worked in order, but parallel work is supported
-3. **Parallel Work Supported**: Multiple stories can be `in-progress` if team capacity allows
-4. **Review Before Done**: Stories should pass through `review` before `done`
-5. **Learning Transfer**: SM typically creates next story after previous one is `done` to incorporate learnings

package/.opencode/skills/bmad-sprint-status/SKILL.md

@@ -1,6 +0,0 @@
----
-name: bmad-sprint-status
-description: 'Summarize sprint status and surface risks. Use when the user says "check sprint status" or "show sprint status"'
----
-
-Follow the instructions in ./workflow.md.