create-byan-agent 2.18.0 → 2.19.0

package/install/templates/_byan/workflow/simple/testarch/trace/workflow.yaml

@@ -0,0 +1,55 @@
+# Test Architect workflow: trace (enhanced with gate decision)
+name: testarch-trace
+description: "Generate requirements-to-tests traceability matrix, analyze coverage, and make quality gate decision (PASS/CONCERNS/FAIL/WAIVED)"
+author: "BMad"
+
+# Critical variables from config
+config_source: "{project-root}/_byan/tea/config.yaml"
+output_folder: "{config_source}:output_folder"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+date: system-generated
+
+# Workflow components
+installed_path: "{project-root}/_byan/workflow/simple/testarch/trace"
+instructions: "{installed_path}/instructions.md"
+validation: "{installed_path}/checklist.md"
+template: "{installed_path}/trace-template.md"
+
+# Variables and inputs
+variables:
+  # Directory paths
+  test_dir: "{project-root}/tests" # Root test directory
+  source_dir: "{project-root}" # Source code directory (customize if needed, e.g., {project-root}/src or {project-root}/lib)
+
+  # Workflow behavior
+  coverage_levels: "e2e,api,component,unit" # Which test levels to trace
+  gate_type: "story" # story | epic | release | hotfix - determines gate scope
+  decision_mode: "deterministic" # deterministic (rule-based) | manual (team decision)
+
+# Output configuration
+default_output_file: "{output_folder}/traceability-matrix.md"
+
+# Required tools
+required_tools:
+  - read_file # Read story, test files, BMad artifacts
+  - write_file # Create traceability matrix, gate YAML
+  - list_files # Discover test files
+  - search_repo # Find tests by test ID, describe blocks
+  - glob # Find test files matching patterns
+
+tags:
+  - qa
+  - traceability
+  - test-architect
+  - coverage
+  - requirements
+  - gate
+  - decision
+  - release
+
+execution_hints:
+  interactive: false # Minimize prompts
+  autonomous: true # Proceed without user input unless blocked
+  iterative: true

package/install/templates/_byan/workflow/simple/workflow/data/common-workflow-tools.csv

@@ -0,0 +1,19 @@
+propose,type,tool_name,description,url,requires_install
+always,workflow,party-mode,"Enables collaborative idea generation by managing turn-taking, summarizing contributions, and synthesizing ideas from multiple AI personas in structured conversation sessions about workflow steps or work in progress.",{project-root}/_byan/workflow/simple/party-mode/workflow.md,no
+always,workflow,advanced-elicitation,"Employs diverse elicitation strategies such as Socratic questioning, role-playing, and counterfactual analysis to critically evaluate and enhance LLM outputs, forcing assessment from multiple perspectives and techniques.",{project-root}/_byan/workflow/simple/advanced-elicitation/workflow.xml,no
+always,task,brainstorming,"Facilitates idea generation by prompting users with targeted questions, encouraging divergent thinking, and synthesizing concepts into actionable insights through collaborative creative exploration.",{project-root}/_byan/command/brainstorming.xml,no
+always,llm-tool-feature,web-browsing,"Provides LLM with capabilities to perform real-time web searches, extract relevant data, and incorporate current information into responses when up-to-date information is required beyond training knowledge.",,no
+always,llm-tool-feature,file-io,"Enables LLM to manage file operations such as creating, reading, updating, and deleting files, facilitating seamless data handling, storage, and document management within user environments.",,no
+always,llm-tool-feature,sub-agents,"Allows LLM to create and manage specialized sub-agents that handle specific tasks or modules within larger workflows, improving efficiency through parallel processing and modular task delegation.",,no
+always,llm-tool-feature,sub-processes,"Enables LLM to initiate and manage subprocesses that operate independently, allowing for parallel processing of complex tasks and improved resource utilization during long-running operations.",,no
+always,tool-memory,sidecar-file,"Creates a persistent history file that gets written during workflow execution and loaded on future runs, enabling continuity through session-to-session state management. Used for agent or workflow initialization with previous session context, learning from past interactions, and maintaining progress across multiple executions.",,no
+example,tool-memory,vector-database,"Stores and retrieves semantic information through embeddings for intelligent memory access, enabling workflows to find relevant past experiences, patterns, or context based on meaning rather than exact matches. Useful for complex learning systems, pattern recognition, and semantic search across workflow history.",https://github.com/modelcontextprotocol/servers/tree/main/src/rag-agent,yes
+example,mcp,context-7,"A curated knowledge base of API documentation and third-party tool references, enabling LLM to access accurate and current information for integration and development tasks when specific technical documentation is needed.",https://github.com/modelcontextprotocol/servers/tree/main/src/context-7,yes
+example,mcp,playwright,"Provides capabilities for LLM to perform web browser automation including navigation, form submission, data extraction, and testing actions on web pages, facilitating automated web interactions and quality assurance.",https://github.com/modelcontextprotocol/servers/tree/main/src/playwright,yes
+example,workflow,security-auditor,"Analyzes workflows and code for security vulnerabilities, compliance issues, and best practices violations, providing detailed security assessments and remediation recommendations for production-ready systems.",,no
+example,task,code-review,"Performs systematic code analysis with peer review perspectives, identifying bugs, performance issues, style violations, and architectural problems through adversarial review techniques.",,no
+example,mcp,git-integration,"Enables direct Git repository operations including commits, branches, merges, and history analysis, allowing workflows to interact with version control systems for code management and collaboration.",https://github.com/modelcontextprotocol/servers/tree/main/src/git,yes
+example,mcp,database-connector,"Provides direct database connectivity for querying, updating, and managing data across multiple database types, enabling workflows to interact with structured data sources and perform data-driven operations.",https://github.com/modelcontextprotocol/servers/tree/main/src/postgres,yes
+example,task,api-testing,"Automated API endpoint testing with request/response validation, authentication handling, and comprehensive reporting for REST, GraphQL, and other API types through systematic test generation.",,no
+example,workflow,deployment-manager,"Orchestrates application deployment across multiple environments with rollback capabilities, health checks, and automated release pipelines for continuous integration and delivery workflows.",,no
+example,task,data-validator,"Validates data quality, schema compliance, and business rules through comprehensive data profiling with detailed reporting and anomaly detection for data-intensive workflows.",,no

package/install/templates/_byan/workflow/simple/workflow/data/frontmatter-standards.md

@@ -0,0 +1,225 @@
+# Frontmatter Standards
+
+**Purpose:** Variables, paths, and frontmatter rules for workflow steps.
+
+---
+
+## Golden Rules
+
+1. **Only variables USED in the step** may be in frontmatter
+2. **All file references MUST use `{variable}` format** - no hardcoded paths
+3. **Paths within workflow folder MUST be relative** - NO `workflow_path` variable allowed
+
+---
+
+## Standard Variables (Always Available)
+
+| Variable                     | Example Value                        |
+| ---------------------------- | ------------------------------------ |
+| `{project-root}`             | `/Users/user/dev/BMAD-METHOD`        |
+| `{project_name}`             | `my-project`                         |
+| `{output_folder}`            | `/Users/user/dev/BMAD-METHOD/output` |
+| `{user_name}`                | `Brian`                              |
+| `{communication_language}`   | `english`                            |
+| `{document_output_language}` | `english`                            |
+
+---
+
+## Module-Specific Variables
+
+Workflows in a MODULE can access additional variables from its `module.yaml`.
+
+**BMB Module example:**
+```yaml
+bmb_creations_output_folder: '{project-root}/_byan/bmb-creations'
+```
+
+**Standalone workflows:** Only have access to standard variables.
+
+---
+
+## Frontmatter Structure
+
+### Required Fields
+```yaml
+---
+name: 'step-[N]-[name]'
+description: '[what this step does]'
+---
+```
+
+### File References - ONLY variables used in this step
+```yaml
+---
+# Step to step (SAME folder) - use ./filename.md
+nextStepFile: './step-02-vision.md'
+
+# Step to template (PARENT folder) - use ../filename.md
+productBriefTemplate: '../product-brief.template.md'
+
+# Step to data (SUBFOLDER) - use ./data/filename.md
+someData: './data/config.csv'
+
+# Output files - use variable
+outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
+
+# External references - use {project-root}
+advancedElicitationTask: '{project-root}/_byan/workflow/simple/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_byan/workflow/simple/party-mode/workflow.md'
+---
+```
+
+---
+
+## Critical Rule: Unused Variables Forbidden
+
+### ❌ VIOLATION - Variable defined but never used
+```yaml
+---
+outputFile: '{output_folder}/output.md'
+thisStepFile: './step-01-init.md'      # ❌ NEVER USED in body
+workflowFile: './workflow.md'           # ❌ NEVER USED in body
+---
+# Step body never mentions {thisStepFile} or {workflowFile}
+```
+
+### ✅ CORRECT - Only variables that are used
+```yaml
+---
+outputFile: '{output_folder}/output.md'
+nextStepFile: './step-02-foo.md'
+---
+# Step body uses {outputFile} and {nextStepFile}
+```
+
+**Detection Rule:** For EVERY variable in frontmatter, search the step body for `{variableName}`. If not found, it's a violation.
+
+---
+
+## Path Rules - NO EXCEPTIONS
+
+### 1. Step to Step (SAME folder) = ./filename.md
+```yaml
+# ❌ WRONG
+nextStepFile: './step-02.md'
+nextStepFile: '{project-root}/_byan/workflow/simple/foo/steps/step-02.md'
+
+# ✅ CORRECT
+nextStepFile: './step-02-vision.md'
+```
+
+### 2. Step to Template (PARENT folder) = ../filename.md
+```yaml
+# ❌ WRONG
+someTemplate: '{workflow_path}/templates/template.md'
+
+# ✅ CORRECT
+someTemplate: '../template.md'
+```
+
+### 3. Step to Subfolder = ./subfolder/file.md
+```yaml
+# ❌ WRONG
+dataFile: '{workflow_path}/data/config.csv'
+
+# ✅ CORRECT
+dataFile: './data/config.csv'
+```
+
+### 4. External References = {project-root}/...
+```yaml
+# ✅ CORRECT
+advancedElicitationTask: '{project-root}/_byan/workflow/simple/advanced-elicitation/workflow.xml'
+```
+
+### 5. Output Files = Use folder variable
+```yaml
+# ✅ CORRECT
+outputFile: '{planning_artifacts}/workflow-output-{project_name}.md'
+outputFile: '{output_folder}/output.md'
+```
+
+---
+
+## ❌ FORBIDDEN Patterns
+
+These patterns are **NEVER ALLOWED** in workflow step frontmatter:
+
+| Pattern                               | Why It's Wrong                                        |
+| ------------------------------------- | ----------------------------------------------------- |
+| `workflow_path: '{project-root}/...'` | Use relative paths instead                            |
+| `thisStepFile: './step-XX.md'`        | Almost never used - remove unless actually referenced |
+| `workflowFile: './workflow.md'`       | Almost never used - remove unless actually referenced |
+| `./...`                               | Use `./step-XX.md` (same folder)                      |
+| `{workflow_path}/templates/...`       | Use `../template.md` (parent folder)                  |
+| `{workflow_path}/data/...`            | Use `./data/file.md` (subfolder)                      |
+
+---
+
+## Variable Naming
+
+Use `snake_case` with descriptive prefixes:
+
+| Pattern        | Usage               | Example                      |
+| -------------- | ------------------- | ---------------------------- |
+| `{*_File}`     | File references     | `outputFile`, `nextStepFile` |
+| `{*_Task}`     | Task references     | `advancedElicitationTask`    |
+| `{*_Workflow}` | Workflow references | `partyModeWorkflow`          |
+| `{*_Template}` | Templates           | `productBriefTemplate`       |
+| `{*_Data}`     | Data files          | `dietaryData`                |
+
+---
+
+## Defining New Variables
+
+Steps can define NEW variables that future steps will use.
+
+**Step 01 defines:**
+```yaml
+---
+targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
+---
+# Uses {targetWorkflowPath} in body
+```
+
+**Step 02 uses:**
+```yaml
+---
+targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
+workflowPlanFile: '{targetWorkflowPath}/plan.md'
+---
+# Uses {targetWorkflowPath} and {workflowPlanFile} in body
+```
+
+---
+
+## Continuable Workflow Frontmatter
+
+```yaml
+---
+stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
+lastStep: 'step-03-design'
+lastContinued: '2025-01-02'
+date: '2025-01-01'
+---
+```
+
+**Step tracking:** Each step appends its NAME to `stepsCompleted`.
+
+---
+
+## Validation Checklist
+
+For EVERY step frontmatter, verify:
+
+- [ ] `name` present, kebab-case format
+- [ ] `description` present
+- [ ] Extract ALL variable names from frontmatter (between `---` markers)
+- [ ] For EACH variable, search body: is `{variableName}` present?
+- [ ] If variable NOT in body → ❌ VIOLATION, remove from frontmatter
+- [ ] All step-to-step paths use `./filename.md` format (same folder)
+- [ ] All parent-folder paths use `../filename.md` format
+- [ ] All subfolder paths use `./subfolder/filename.md` format
+- [ ] NO `{workflow_path}` variable exists
+- [ ] External paths use `{project-root}` variable
+- [ ] Module variables only used if workflow belongs to that module

package/install/templates/_byan/workflow/simple/workflow/steps-c/step-02-classification.md

@@ -0,0 +1,269 @@
+---
+name: 'step-02-classification'
+description: 'Classify the workflow by answering the 4 key structural decisions'
+
+nextStepFile: './step-03-requirements.md'
+workflowTypeCriteria: '../data/workflow-type-criteria.md'
+workflowPlanFile: '{bmb_creations_output_folder}/workflows/{new_workflow_name}/workflow-plan-{new_workflow_name}.md'
+bmbCreationsOutputFolder: '{bmb_creations_output_folder}'
+customWorkflowLocation: '{custom_workflow_location}'
+---
+
+# Step 2: Workflow Classification
+
+## STEP GOAL:
+
+To determine the 4 key structural decisions that define how the workflow will be built: module affiliation, continuable vs single-session, tri-modal vs create-only, and document output.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a workflow architect helping classify their workflow
+- ✅ Explain the trade-offs of each decision clearly
+- ✅ Help them make informed choices
+- ✅ These 4 decisions affect the entire workflow structure
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on the 4 key structural decisions
+- 🚫 FORBIDDEN to skip any of the 4 decisions
+- 💬 Explain each decision in plain language before asking
+- 🚪 These decisions determine file structure, naming, and location
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load workflowTypeCriteria for the decision framework
+- 💾 Document each decision in the plan
+- 📖 Update frontmatter stepsCompleted when complete
+- 🚫 FORBIDDEN to load next step until all 4 decisions are made
+
+## CONTEXT BOUNDARIES:
+
+- Discovery from Step 1 informs these decisions
+- These are STRUCTURAL decisions that affect everything else
+- Once made, changing them is difficult
+- Take time to explain trade-offs
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 0. Load Decision Framework
+
+Load `{workflowTypeCriteria}` to understand the 4 key decisions and their implications.
+
+### 1. Decision 1: Document Output (FIRST - It's Fundamental)
+
+"**Let's classify your workflow. I'll walk you through 4 key decisions that determine how it's built.**
+
+**Decision 1: What does your workflow produce?**
+
+Based on your idea from discovery, let me clarify:"
+
+- [If unclear from discovery] "Does this workflow produce a document or file at the end? A report, a plan, a story, a checklist?"
+
+Present the two options:
+
+**A. Document-Producing**
+- Creates a persistent output file
+- Examples: reports, plans, stories, checklists, forms
+- Uses templates for structure
+
+**B. Non-Document**
+- Performs actions without creating a document
+- Examples: refactoring code, running tests, orchestrating tools
+- May produce temporary files but no persistent output
+
+"Which describes your workflow?"
+
+**Think about their response before continuing...**
+
+Once decided:
+- Document: `workflowProducesDocuments: true`
+- Non-document: `workflowProducesDocuments: false`
+
+### 2. Decision 2: Module Affiliation
+
+"**Decision 2: Where will this workflow live?**
+
+Workflows can be standalone or part of a module:"
+
+**Standalone:**
+- NOT part of any module
+- Stored in your custom location
+- Only standard variables available
+
+**Module-Based (BMB, BMM, CIS, BMGD, etc.):**
+- Part of a specific module
+- Has access to module-specific variables
+- Stored in that module's workflows directory
+
+"Is this workflow:
+- **A)** Standalone - just for you/custom use
+- **B)** Part of a module - which one?"
+
+**If they don't know modules:**
+"Modules are specialized areas:
+- **BMB** - Module building workflows
+- **BMM** - Software development workflows (PRDs, architecture, etc.)
+- **CIS** - Innovation and creative workflows
+- **BMGD** - Game development workflows
+- **Custom** - Your own workflows
+
+Does your workflow fit into one of these areas, or is it standalone?"
+
+Document the result.
+
+### 3. Decision 3: Continuable or Single-Session
+
+"**Decision 3: Could this workflow take multiple sessions to complete?**
+
+Think about: Will this workflow consume many tokens or take a long time? Might users need to pause and come back later?"
+
+**Single-Session:**
+- Quick, focused workflows (15-30 minutes)
+- Simpler structure
+- No continuation logic needed
+
+**Continuable:**
+- Can span multiple sessions
+- Complex, many steps
+- Saves progress, can resume later
+- Needs `step-01b-continue.md`
+
+"Is your workflow:
+- **A)** Single-session - quick and focused
+- **B)** Continuable - could take multiple sessions"
+
+**Help them think:**
+- "Walk me through how long you think this would take..."
+- "What happens if someone gets halfway through and has to stop?"
+
+Document the result.
+
+### 4. Decision 4: Create-Only or Tri-Modal
+
+"**Decision 4: Will this workflow need Edit and Validate capabilities?**
+
+Some workflows are simple - you create them once and use them. Others need full lifecycle support:**
+
+**Create-Only:**
+- Just `steps-c/` (create steps)
+- Simpler, faster to build
+- Good for: experimental workflows, one-off use, simple tools
+
+**Tri-Modal (Create + Edit + Validate):**
+- Has `steps-c/`, `steps-e/` (edit), and `steps-v/` (validate)
+- Full lifecycle support
+- Can be modified and validated after creation
+- Good for: complex workflows, maintained workflows, team use
+
+"Do you envision:
+- **A)** Create-only - build it and use it
+- **B)** Tri-modal - create, edit, AND validate capabilities"
+
+**If they're unsure:**
+"Think: Will you or others want to modify this workflow later? Does it need quality checking/validation?"
+
+Document the result.
+
+### 5. Name the Workflow
+
+"Now that we understand what this workflow IS, let's name it properly.
+
+Based on everything we've discovered, what would you call this?
+
+Some guidance:
+- Use kebab-case: `my-workflow-name`
+- Be descriptive but concise
+- Think: What would someone search for to find this?
+
+[Offer suggestions based on their vision]"
+
+**Check for uniqueness:**
+- Look for folder at `{bmb_creationsOutputFolder}/workflows/{proposed-name}/`
+- If exists: "That name is taken. Want to try a variant like...?"
+- Loop until unique name confirmed
+
+Document the final name.
+
+### 6. Confirm Target Location
+
+Based on module decision, confirm and document the target path:
+
+**For standalone/custom:**
+- Target: `{customWorkflowLocation}/{workflow-name}/`
+- Typically: `_byan/custom/src/workflows/{workflow-name}/`
+
+**For modules:**
+- Check module's workflow location from module.yaml
+- Confirm path with user
+
+Document: `targetWorkflowPath: [confirmed path]`
+
+### 7. Update Plan with Classification
+
+Update `{workflowPlanFile}`:
+
+```markdown
+## Classification Decisions
+
+**Workflow Name:** {name}
+**Target Path:** {targetWorkflowPath}
+
+**4 Key Decisions:**
+1. **Document Output:** {true/false}
+2. **Module Affiliation:** {standalone/module-name}
+3. **Session Type:** {single-session/continuable}
+4. **Lifecycle Support:** {create-only/tri-modal}
+
+**Structure Implications:**
+- [Document what this means: e.g., "Needs steps-c/, steps-e/, steps-v/", "Needs step-01b-continue.md", etc.]
+```
+
+### 8. Present MENU OPTIONS
+
+Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and redisplay menu
+
+#### Menu Handling Logic:
+
+- IF A: Execute {project-root}/_byan/workflow/simple/advanced-elicitation/workflow.xml
+- IF P: Execute {project-root}/_byan/workflow/simple/party-mode/workflow.md
+- IF C: Update plan frontmatter with stepsCompleted and classification, then load `{nextStepFile}`
+- IF Any other: Help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All 4 key decisions made and documented
+- Workflow named appropriately
+- Target location confirmed
+- Structural implications understood
+- Plan updated with classification
+
+### ❌ SYSTEM FAILURE:
+
+- Skipping any of the 4 key decisions
+- Naming before understanding (old pattern)
+- Not explaining trade-offs
+- Not checking for name conflicts
+
+**Master Rule:** The 4 key decisions determine everything else. Get them right before proceeding.