ma-agents 3.4.9 → 3.5.1

package/.opencode/skills/bmad-create-prd/steps-c/step-12-complete.md

@@ -1,115 +0,0 @@
-# Step 12: Workflow Completion
-
-**Final Step - Complete the PRD**
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ THIS IS A FINAL STEP - Workflow completion required
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
-- 🛑 NO content generation - this is a wrap-up step
-- 📋 FINALIZE document and update workflow status
-- 💬 FOCUS on completion, validation options, and next steps
-- 🎯 UPDATE workflow status files with completion information
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 💾 Update the main workflow status file with completion information (if exists)
-- 📖 Offer validation workflow options to user
-- 🚫 DO NOT load additional steps after this one
-
-## TERMINATION STEP PROTOCOLS:
-
-- This is a FINAL step - workflow completion required
-- Update workflow status file with finalized document
-- Suggest validation and next workflow steps
-- Mark workflow as complete in status tracking
-
-## CONTEXT BOUNDARIES:
-
-- Complete and polished PRD document is available from all previous steps
-- Workflow frontmatter shows all completed steps including polish
-- All collaborative content has been generated, saved, and optimized
-- Focus on completion, validation options, and next steps
-
-## YOUR TASK:
-
-Complete the PRD workflow, update status files, offer validation options, and suggest next steps for the project.
-
-## WORKFLOW COMPLETION SEQUENCE:
-
-### 1. Announce Workflow Completion
-
-Inform user that the PRD is complete and polished:
-- Celebrate successful completion of comprehensive PRD
-- Summarize all sections that were created
-- Highlight that document has been polished for flow and coherence
-- Emphasize document is ready for downstream work
-
-### 2. Workflow Status Update
-
-Update the main workflow status file if there is one:
-
-- Check workflow configuration for a status file (if one exists)
-- Update workflow_status["prd"] = "{outputFile}"
-- Save file, preserving all comments and structure
-- Mark current timestamp as completion time
-
-### 3. Validation Workflow Options
-
-Offer validation workflows to ensure PRD is ready for implementation:
-
-**Available Validation Workflows:**
-
-**Option 1: Check Implementation Readiness** (`skill:bmad-check-implementation-readiness`)
-- Validates PRD has all information needed for development
-- Checks epic coverage completeness
-- Reviews UX alignment with requirements
-- Assesses epic quality and readiness
-- Identifies gaps before architecture/design work begins
-
-**When to use:** Before starting technical architecture or epic breakdown
-
-**Option 2: Skip for Now**
-- Proceed directly to next workflows (architecture, UX, epics)
-- Validation can be done later if needed
-- Some teams prefer to validate during architecture reviews
-
-### 4. Suggest Next Workflows
-
-PRD complete. Invoke the `bmad-help` skill.
-
-### 5. Final Completion Confirmation
-
-- Confirm completion with user and summarize what has been accomplished
-- Document now contains: Executive Summary, Success Criteria, User Journeys, Domain Requirements (if applicable), Innovation Analysis (if applicable), Project-Type Requirements, Functional Requirements (capability contract), Non-Functional Requirements, and has been polished for flow and coherence
-- Ask if they'd like to run validation workflow or proceed to next workflows
-
-## SUCCESS METRICS:
-
-✅ PRD document contains all required sections and has been polished
-✅ All collaborative content properly saved and optimized
-✅ Workflow status file updated with completion information (if exists)
-✅ Validation workflow options clearly presented
-✅ Clear next step guidance provided to user
-✅ Document quality validation completed
-✅ User acknowledges completion and understands next options
-
-## FAILURE MODES:
-
-❌ Not updating workflow status file with completion information (if exists)
-❌ Not offering validation workflow options
-❌ Missing clear next step guidance for user
-❌ Not confirming document completeness with user
-❌ Workflow not properly marked as complete in status tracking (if applicable)
-❌ User unclear about what happens next or what validation options exist
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## FINAL REMINDER to give the user:
-
-The polished PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD - update it also as needed as you continue planning.
-
-**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉

package/.opencode/skills/bmad-create-prd/templates/prd-template.md

@@ -1,10 +0,0 @@
----
-stepsCompleted: []
-inputDocuments: []
-workflowType: 'prd'
----
-
-# Product Requirements Document - {{project_name}}
-
-**Author:** {{user_name}}
-**Date:** {{date}}

package/.opencode/skills/bmad-create-prd/workflow.md

@@ -1,62 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
-outputFile: '{planning_artifacts}/prd.md'
----
-
-# PRD Create Workflow
-
-**Goal:** Create comprehensive PRDs through structured workflow facilitation.
-
-**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
-
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- 🛑 **NEVER** load multiple step files simultaneously
-- 📖 **ALWAYS** read entire step file before execution
-- 🚫 **NEVER** skip steps or optimize the sequence
-- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from {main_config} and resolve:
-
-- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-
-✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
-✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
-
-### 2. Route to Create Workflow
-
-"**Create Mode: Creating a new PRD from scratch.**"
-
-Read fully and follow: `./steps-c/step-01-init.md`

package/.opencode/skills/bmad-create-story/SKILL.md

@@ -1,6 +0,0 @@
----
-name: bmad-create-story
-description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]"'
----
-
-Follow the instructions in ./workflow.md.

package/.opencode/skills/bmad-create-story/checklist.md

@@ -1,357 +0,0 @@
-# 🎯 Story Context Quality Competition Prompt
-
-## **🔥 CRITICAL MISSION: Outperform and Fix the Original Create-Story LLM**
-
-You are an independent quality validator in a **FRESH CONTEXT**. Your mission is to **thoroughly review** a story file that was generated by the create-story workflow and **systematically identify any mistakes, omissions, or disasters** that the original LLM missed.
-
-**Your purpose is NOT just to validate - it's to FIX and PREVENT LLM developer mistakes, omissions, or disasters!**
-
-### **🚨 CRITICAL MISTAKES TO PREVENT:**
-
-- **Reinventing wheels** - Creating duplicate functionality instead of reusing existing
-- **Wrong libraries** - Using incorrect frameworks, versions, or dependencies
-- **Wrong file locations** - Violating project structure and organization
-- **Breaking regressions** - Implementing changes that break existing functionality
-- **Ignoring UX** - Not following user experience design requirements
-- **Vague implementations** - Creating unclear, ambiguous implementations
-- **Lying about completion** - Implementing incorrectly or incompletely
-- **Not learning from past work** - Ignoring previous story learnings and patterns
-
-### **🚨 EXHAUSTIVE ANALYSIS REQUIRED:**
-
-You must thoroughly analyze **ALL artifacts** to extract critical context - do NOT be lazy or skim! This is the most important quality control function in the entire development process!
-
-### **🔬 UTILIZE SUBPROCESSES AND SUBAGENTS:**
-
-Use research subagents, subprocesses, or parallel processing if available to thoroughly analyze different artifacts **simultaneously and thoroughly**. Leave no stone unturned!
-
-### **🎯 COMPETITIVE EXCELLENCE:**
-
-This is a COMPETITION to create the **ULTIMATE story context** that makes LLM developer mistakes **IMPOSSIBLE**!
-
-## **🚀 HOW TO USE THIS CHECKLIST**
-
-### **When Running from Create-Story Workflow:**
-
-- The workflow framework will automatically:
-  - Load this checklist file
-  - Load the newly created story file (`{story_file_path}`)
-  - Load workflow variables from `./workflow.md`
-  - Execute the validation process
-
-### **When Running in Fresh Context:**
-
-- User should provide the story file path being reviewed
-- Load the story file directly
-- Load the corresponding workflow.md for variable context
-- Proceed with systematic analysis
-
-### **Required Inputs:**
-
-- **Story file**: The story file to review and improve
-- **Workflow variables**: From workflow.md (implementation_artifacts, epics_file, etc.)
-- **Source documents**: Epics, architecture, etc. (discovered or provided)
-- **Validation framework**: The workflow's checklist execution system
-
----
-
-## **🔬 SYSTEMATIC RE-ANALYSIS APPROACH**
-
-You will systematically re-do the entire story creation process, but with a critical eye for what the original LLM might have missed:
-
-### **Step 1: Load and Understand the Target**
-
-1. **Load the workflow configuration**: `./workflow.md` for variable inclusion
-2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
-3. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
-4. **Resolve all workflow variables**: implementation_artifacts, epics_file, architecture_file, etc.
-5. **Understand current status**: What story implementation guidance is currently provided?
-
-**Note:** If running in fresh context, user should provide the story file path being reviewed. If running from create-story workflow, the validation framework will automatically discover the checklist and story file.
-
-### **Step 2: Exhaustive Source Document Analysis**
-
-**🔥 CRITICAL: Treat this like YOU are creating the story from scratch to PREVENT DISASTERS!**
-**Discover everything the original LLM missed that could cause developer mistakes, omissions, or disasters!**
-
-#### **2.1 Epics and Stories Analysis**
-
-- Load `{epics_file}` (or sharded equivalents)
-- Extract **COMPLETE Epic {{epic_num}} context**:
-  - Epic objectives and business value
-  - ALL stories in this epic (for cross-story context)
-  - Our specific story's requirements, acceptance criteria
-  - Technical requirements and constraints
-  - Cross-story dependencies and prerequisites
-
-#### **2.2 Architecture Deep-Dive**
-
-- Load `{architecture_file}` (single or sharded)
-- **Systematically scan for ANYTHING relevant to this story:**
-  - Technical stack with versions (languages, frameworks, libraries)
-  - Code structure and organization patterns
-  - API design patterns and contracts
-  - Database schemas and relationships
-  - Security requirements and patterns
-  - Performance requirements and optimization strategies
-  - Testing standards and frameworks
-  - Deployment and environment patterns
-  - Integration patterns and external services
-
-#### **2.3 Previous Story Intelligence (if applicable)**
-
-- If `story_num > 1`, load the previous story file
-- Extract **actionable intelligence**:
-  - Dev notes and learnings
-  - Review feedback and corrections needed
-  - Files created/modified and their patterns
-  - Testing approaches that worked/didn't work
-  - Problems encountered and solutions found
-  - Code patterns and conventions established
-
-#### **2.4 Git History Analysis (if available)**
-
-- Analyze recent commits for patterns:
-  - Files created/modified in previous work
-  - Code patterns and conventions used
-  - Library dependencies added/changed
-  - Architecture decisions implemented
-  - Testing approaches used
-
-#### **2.5 Latest Technical Research**
-
-- Identify any libraries/frameworks mentioned
-- Research latest versions and critical information:
-  - Breaking changes or security updates
-  - Performance improvements or deprecations
-  - Best practices for current versions
-
-### **Step 3: Disaster Prevention Gap Analysis**
-
-**🚨 CRITICAL: Identify every mistake the original LLM missed that could cause DISASTERS!**
-
-#### **3.1 Reinvention Prevention Gaps**
-
-- **Wheel reinvention:** Areas where developer might create duplicate functionality
-- **Code reuse opportunities** not identified that could prevent redundant work
-- **Existing solutions** not mentioned that developer should extend instead of replace
-
-#### **3.2 Technical Specification DISASTERS**
-
-- **Wrong libraries/frameworks:** Missing version requirements that could cause compatibility issues
-- **API contract violations:** Missing endpoint specifications that could break integrations
-- **Database schema conflicts:** Missing requirements that could corrupt data
-- **Security vulnerabilities:** Missing security requirements that could expose the system
-- **Performance disasters:** Missing requirements that could cause system failures
-
-#### **3.3 File Structure DISASTERS**
-
-- **Wrong file locations:** Missing organization requirements that could break build processes
-- **Coding standard violations:** Missing conventions that could create inconsistent codebase
-- **Integration pattern breaks:** Missing data flow requirements that could cause system failures
-- **Deployment failures:** Missing environment requirements that could prevent deployment
-
-#### **3.4 Regression DISASTERS**
-
-- **Breaking changes:** Missing requirements that could break existing functionality
-- **Test failures:** Missing test requirements that could allow bugs to reach production
-- **UX violations:** Missing user experience requirements that could ruin the product
-- **Learning failures:** Missing previous story context that could repeat same mistakes
-
-#### **3.5 Implementation DISASTERS**
-
-- **Vague implementations:** Missing details that could lead to incorrect or incomplete work
-- **Completion lies:** Missing acceptance criteria that could allow fake implementations
-- **Scope creep:** Missing boundaries that could cause unnecessary work
-- **Quality failures:** Missing quality requirements that could deliver broken features
-
-### **Step 4: LLM-Dev-Agent Optimization Analysis**
-
-**CRITICAL STEP: Optimize story context for LLM developer agent consumption**
-
-**Analyze current story for LLM optimization issues:**
-
-- **Verbosity problems:** Excessive detail that wastes tokens without adding value
-- **Ambiguity issues:** Vague instructions that could lead to multiple interpretations
-- **Context overload:** Too much information not directly relevant to implementation
-- **Missing critical signals:** Key requirements buried in verbose text
-- **Poor structure:** Information not organized for efficient LLM processing
-
-**Apply LLM Optimization Principles:**
-
-- **Clarity over verbosity:** Be precise and direct, eliminate fluff
-- **Actionable instructions:** Every sentence should guide implementation
-- **Scannable structure:** Use clear headings, bullet points, and emphasis
-- **Token efficiency:** Pack maximum information into minimum text
-- **Unambiguous language:** Clear requirements with no room for interpretation
-
-### **Step 5: Improvement Recommendations**
-
-**For each gap identified, provide specific, actionable improvements:**
-
-#### **5.1 Critical Misses (Must Fix)**
-
-- Missing essential technical requirements
-- Missing previous story context that could cause errors
-- Missing anti-pattern prevention that could lead to duplicate code
-- Missing security or performance requirements
-
-#### **5.2 Enhancement Opportunities (Should Add)**
-
-- Additional architectural guidance that would help developer
-- More detailed technical specifications
-- Better code reuse opportunities
-- Enhanced testing guidance
-
-#### **5.3 Optimization Suggestions (Nice to Have)**
-
-- Performance optimization hints
-- Additional context for complex scenarios
-- Enhanced debugging or development tips
-
-#### **5.4 LLM Optimization Improvements**
-
-- Token-efficient phrasing of existing content
-- Clearer structure for LLM processing
-- More actionable and direct instructions
-- Reduced verbosity while maintaining completeness
-
----
-
-## **🎯 COMPETITION SUCCESS METRICS**
-
-**You WIN against the original LLM if you identify:**
-
-### **Category 1: Critical Misses (Blockers)**
-
-- Essential technical requirements the developer needs but aren't provided
-- Previous story learnings that would prevent errors if ignored
-- Anti-pattern prevention that would prevent code duplication
-- Security or performance requirements that must be followed
-
-### **Category 2: Enhancement Opportunities**
-
-- Architecture guidance that would significantly help implementation
-- Technical specifications that would prevent wrong approaches
-- Code reuse opportunities the developer should know about
-- Testing guidance that would improve quality
-
-### **Category 3: Optimization Insights**
-
-- Performance or efficiency improvements
-- Development workflow optimizations
-- Additional context for complex scenarios
-
----
-
-## **📋 INTERACTIVE IMPROVEMENT PROCESS**
-
-After completing your systematic analysis, present your findings to the user interactively:
-
-### **Step 5: Present Improvement Suggestions**
-
-```
-🎯 **STORY CONTEXT QUALITY REVIEW COMPLETE**
-
-**Story:** {{story_key}} - {{story_title}}
-
-I found {{critical_count}} critical issues, {{enhancement_count}} enhancements, and {{optimization_count}} optimizations.
-
-## **🚨 CRITICAL ISSUES (Must Fix)**
-
-{{list each critical issue with clear, actionable description}}
-
-## **⚡ ENHANCEMENT OPPORTUNITIES (Should Add)**
-
-{{list each enhancement with clear benefit description}}
-
-## **✨ OPTIMIZATIONS (Nice to Have)**
-
-{{list each optimization with benefit description}}
-
-## **🤖 LLM OPTIMIZATION (Token Efficiency & Clarity)**
-
-{{list each LLM optimization that will improve dev agent performance:
-- Reduce verbosity while maintaining completeness
-- Improve structure for better LLM processing
-- Make instructions more actionable and direct
-- Enhance clarity and reduce ambiguity}}
-```
-
-### **Step 6: Interactive User Selection**
-
-After presenting the suggestions, ask the user:
-
-```
-**IMPROVEMENT OPTIONS:**
-
-Which improvements would you like me to apply to the story?
-
-**Select from the numbered list above, or choose:**
-- **all** - Apply all suggested improvements
-- **critical** - Apply only critical issues
-- **select** - I'll choose specific numbers
-- **none** - Keep story as-is
-- **details** - Show me more details about any suggestion
-
-Your choice:
-```
-
-### **Step 7: Apply Selected Improvements**
-
-When user accepts improvements:
-
-- **Load the story file**
-- **Apply accepted changes** (make them look natural, as if they were always there)
-- **DO NOT reference** the review process, original LLM, or that changes were "added" or "enhanced"
-- **Ensure clean, coherent final story** that reads as if it was created perfectly the first time
-
-### **Step 8: Confirmation**
-
-After applying changes:
-
-```
-✅ **STORY IMPROVEMENTS APPLIED**
-
-Updated {{count}} sections in the story file.
-
-The story now includes comprehensive developer guidance to prevent common implementation issues and ensure flawless execution.
-
-**Next Steps:**
-1. Review the updated story
-2. Run `dev-story` for implementation
-```
-
----
-
-## **💪 COMPETITIVE EXCELLENCE MINDSET**
-
-**Your goal:** Improve the story file with dev agent needed context that makes flawless implementation inevitable while being optimized for LLM developer agent consumption. Remember the dev agent will ONLY have this file to use.
-
-**Success Criteria:** The LLM developer agent that processes your improved story will have:
-
-- ✅ Clear technical requirements they must follow
-- ✅ Previous work context they can build upon
-- ✅ Anti-pattern prevention to avoid common mistakes
-- ✅ Comprehensive guidance for efficient implementation
-- ✅ **Optimized content structure** for maximum clarity and minimum token waste
-- ✅ **Actionable instructions** with no ambiguity or verbosity
-- ✅ **Efficient information density** - maximum guidance in minimum text
-
-**Every improvement should make it IMPOSSIBLE for the developer to:**
-
-- Reinvent existing solutions
-- Use wrong approaches or libraries
-- Create duplicate functionality
-- Miss critical requirements
-- Make implementation errors
-
-**LLM Optimization Should Make it IMPOSSIBLE for the developer agent to:**
-
-- Misinterpret requirements due to ambiguity
-- Waste tokens on verbose, non-actionable content
-- Struggle to find critical information buried in text
-- Get confused by poor structure or organization
-- Miss key implementation signals due to inefficient communication
-
-**Go create the ultimate developer implementation guide! 🚀**

package/.opencode/skills/bmad-create-story/discover-inputs.md

@@ -1,88 +0,0 @@
-# Discover Inputs Protocol
-
-**Objective:** Intelligently load project files (whole or sharded) based on the workflow's Input Files configuration.
-
-**Prerequisite:** Only execute this protocol if the workflow defines an Input Files section. If no input file patterns are configured, skip this entirely.
-
----
-
-## Step 1: Parse Input File Patterns
-
-- Read the Input Files table from the workflow configuration.
-- For each input group (prd, architecture, epics, ux, etc.), note the **load strategy** if specified.
-
-## Step 2: Load Files Using Smart Strategies
-
-For each pattern in the Input Files table, work through the following substeps in order:
-
-### 2a: Try Sharded Documents First
-
-If a sharded pattern exists for this input, determine the load strategy (defaults to **FULL_LOAD** if not specified), then apply the matching strategy:
-
-#### FULL_LOAD Strategy
-
-Load ALL files in the sharded directory. Use this for PRD, Architecture, UX, brownfield docs, or whenever the full picture is needed.
-
-1. Use the glob pattern to find ALL `.md` files (e.g., `{planning_artifacts}/*architecture*/*.md`).
-2. Load EVERY matching file completely.
-3. Concatenate content in logical order: `index.md` first if it exists, then alphabetical.
-4. Store the combined result in a variable named `{pattern_name_content}` (e.g., `{architecture_content}`).
-
-#### SELECTIVE_LOAD Strategy
-
-Load a specific shard using a template variable. Example: used for epics with `{{epic_num}}`.
-
-1. Check for template variables in the sharded pattern (e.g., `{{epic_num}}`).
-2. If the variable is undefined, ask the user for the value OR infer it from context.
-3. Resolve the template to a specific file path.
-4. Load that specific file.
-5. Store in variable: `{pattern_name_content}`.
-
-#### INDEX_GUIDED Strategy
-
-Load index.md, analyze the structure and description of each doc in the index, then intelligently load relevant docs.
-
-**DO NOT BE LAZY** -- use best judgment to load documents that might have relevant information, even if there is only a 5% chance of relevance.
-
-1. Load `index.md` from the sharded directory.
-2. Parse the table of contents, links, and section headers.
-3. Analyze the workflow's purpose and objective.
-4. Identify which linked/referenced documents are likely relevant.
-   - *Example:* If the workflow is about authentication and the index shows "Auth Overview", "Payment Setup", "Deployment" -- load the auth docs, consider deployment docs, skip payment.
-5. Load all identified relevant documents.
-6. Store combined content in variable: `{pattern_name_content}`.
-
-**When in doubt, LOAD IT** -- context is valuable, and being thorough is better than missing critical info.
-
----
-
-After applying the matching strategy, mark the pattern as **RESOLVED** and move to the next pattern.
-
-### 2b: Try Whole Document if No Sharded Found
-
-If no sharded matches were found OR no sharded pattern exists for this input:
-
-1. Attempt a glob match on the "whole" pattern (e.g., `{planning_artifacts}/*prd*.md`).
-2. If matches are found, load ALL matching files completely (no offset/limit).
-3. Store content in variable: `{pattern_name_content}` (e.g., `{prd_content}`).
-4. Mark pattern as **RESOLVED** and move to the next pattern.
-
-### 2c: Handle Not Found
-
-If no matches were found for either sharded or whole patterns:
-
-1. Set `{pattern_name_content}` to empty string.
-2. Note in session: "No {pattern_name} files found" -- this is not an error, just unavailable. Offer the user a chance to provide the file.
-
-## Step 3: Report Discovery Results
-
-List all loaded content variables with file counts. Example:
-
-```
-OK Loaded {prd_content} from 5 sharded files: prd/index.md, prd/requirements.md, ...
-OK Loaded {architecture_content} from 1 file: Architecture.md
-OK Loaded {epics_content} from selective load: epics/epic-3.md
--- No ux_design files found
-```
-
-This gives the workflow transparency into what context is available.

package/.opencode/skills/bmad-create-story/template.md

@@ -1,49 +0,0 @@
-# Story {{epic_num}}.{{story_num}}: {{story_title}}
-
-Status: ready-for-dev
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a {{role}},
-I want {{action}},
-so that {{benefit}}.
-
-## Acceptance Criteria
-
-1. [Add acceptance criteria from epics/PRD]
-
-## Tasks / Subtasks
-
-- [ ] Task 1 (AC: #)
-  - [ ] Subtask 1.1
-- [ ] Task 2 (AC: #)
-  - [ ] Subtask 2.1
-
-## Dev Notes
-
-- Relevant architecture patterns and constraints
-- Source tree components to touch
-- Testing standards summary
-
-### Project Structure Notes
-
-- Alignment with unified project structure (paths, modules, naming)
-- Detected conflicts or variances (with rationale)
-
-### References
-
-- Cite all technical details with source paths and sections, e.g. [Source: docs/<file>.md#Section]
-
-## Dev Agent Record
-
-### Agent Model Used
-
-{{agent_model_name_version}}
-
-### Debug Log References
-
-### Completion Notes List
-
-### File List