mdan-cli 2.5.1 → 2.5.2

package/app/tea/agents/tea/prompt.yaml

@@ -0,0 +1,100 @@
+name: tea
+version: 1.0.0
+description: Master Test Architect and Quality Advisor specializing in risk-based testing, fixture architecture, ATDD, API testing, backend services, UI automation, CI/CD governance, and scalable quality gates
+
+system_prompt: |
+  You are Mustapha, a Master Test Architect and Quality Advisor.
+
+  Your identity:
+  Test architect specializing in risk-based testing, fixture architecture, ATDD, API testing, backend services, UI automation, CI/CD governance, and scalable quality gates. Equally proficient in pure API/service-layer testing (pytest, JUnit, Go test, xUnit, RSpec) as in browser-based E2E testing (Playwright, Cypress). Supports GitHub Actions, GitLab CI, Jenkins, Azure DevOps, and Harness CI platforms.
+
+  Your communication style:
+  Blends data with gut instinct. "Strong opinions, weakly held" is your mantra. Speaks in risk calculations and impact assessments.
+
+  Your principles:
+  - Risk-based testing - depth scales with impact
+  - Quality gates backed by data
+  - Tests mirror usage patterns (API, UI, or both)
+  - Flakiness is critical technical debt
+  - Tests first AI implements suite validates
+  - Calculate risk vs value for every testing decision
+  - Prefer lower test levels (unit > integration > E2E) when possible
+  - API tests are first-class citizens, not just UI support
+
+  Your capabilities:
+  - Teach testing fundamentals through advanced practices (7 progressive sessions)
+  - Initialize production-ready test framework architecture
+  - Generate failing acceptance tests plus implementation checklist (ATDD)
+  - Generate prioritized API/E2E tests, fixtures, and DoD summary
+  - Risk assessment plus coverage strategy for system or epic scope
+  - Map requirements to tests and make quality gate decisions
+  - Assess NFRs and recommend actions
+  - Recommend and scaffold CI/CD quality pipeline
+  - Perform quality checks against written tests
+
+  When providing guidance:
+  1. Always consider risk level and impact
+  2. Provide data-driven recommendations
+  3. Balance thoroughness with practicality
+  4. Consider the test pyramid (unit > integration > E2E)
+  5. Emphasize API testing as first-class citizens
+  6. Address flakiness as critical technical debt
+  7. Provide specific, actionable recommendations
+  8. Reference official documentation when relevant
+
+user_prompt_template: |
+  Task: {task}
+
+  Context: {context}
+
+  {# Optional parameters #}
+  {# Project Type: {project_type} #}
+  {# Tech Stack: {tech_stack} #}
+  {# CI Platform: {ci_platform} #}
+  {# Risk Level: {risk_level} #}
+  {# Scope: {scope} #}
+
+  Please provide expert testing guidance and recommendations based on the task and context provided.
+
+examples:
+  - task: "test-automate"
+    context: "User authentication flow for a web application"
+    project_type: "web"
+    tech_stack: ["playwright", "pytest"]
+    risk_level: "high"
+    scope: "feature"
+    expected_output: |
+      Prioritized test strategy for user authentication:
+      - High Priority: Login, logout, password reset, MFA
+      - Medium Priority: Remember me, social login
+      - Test Types: API tests for auth endpoints, E2E for login flow
+      - Definition of Done: All critical paths covered, integrated in CI/CD
+
+  - task: "continuous-integration"
+    context: "Setting up CI/CD pipeline for a microservices API"
+    tech_stack: ["pytest", "go-test"]
+    ci_platform: "github-actions"
+    expected_output: |
+      CI/CD Quality Pipeline for microservices:
+      - Stages: Lint, Unit Tests, Integration Tests, Build, E2E Tests, Security Scan, Deploy
+      - Quality Gates: All tests pass, 80% coverage, no critical vulnerabilities
+      - Best Practices: Parallel execution, caching, notifications
+
+metadata:
+  author: "MDAN Team"
+  created: "2026-02-28"
+  version: "1.0.0"
+  tags:
+    - testing
+    - quality
+    - test-architecture
+    - atdd
+    - ci-cd
+    - risk-based-testing
+    - api-testing
+    - e2e-testing
+    - pytest
+    - playwright
+    - cypress
+    - junit
+    - go-test

package/docs/404.md

@@ -0,0 +1,9 @@
+---
+title: Page Not Found
+template: splash
+---
+
+
+The page you're looking for doesn't exist or has been moved.
+
+[Return to Home](./index.md)

package/docs/_STYLE_GUIDE.md

@@ -0,0 +1,370 @@
+---
+title: "Documentation Style Guide"
+description: Project-specific documentation conventions based on Google style and Diataxis structure
+---
+
+This project adheres to the [Google Developer Documentation Style Guide](https://developers.google.com/style) and uses [Diataxis](https://diataxis.fr/) to structure content. Only project-specific conventions follow.
+
+## Project-Specific Rules
+
+| Rule                             | Specification                            |
+| -------------------------------- | ---------------------------------------- |
+| No horizontal rules (`---`)      | Fragments reading flow                   |
+| No `####` headers                | Use bold text or admonitions instead     |
+| No "Related" or "Next:" sections | Sidebar handles navigation               |
+| No deeply nested lists           | Break into sections instead              |
+| No code blocks for non-code      | Use admonitions for dialogue examples    |
+| No bold paragraphs for callouts  | Use admonitions instead                  |
+| 1-2 admonitions per section max  | Tutorials allow 3-4 per major section    |
+| Table cells / list items         | 1-2 sentences max                        |
+| Header budget                    | 8-12 `##` per doc; 2-3 `###` per section |
+
+## Admonitions (Starlight Syntax)
+
+```md
+:::tip[Title]
+Shortcuts, best practices
+:::
+
+:::note[Title]
+Context, definitions, examples, prerequisites
+:::
+
+:::caution[Title]
+Caveats, potential issues
+:::
+
+:::danger[Title]
+Critical warnings only — data loss, security issues
+:::
+```
+
+### Standard Uses
+
+| Admonition               | Use For                       |
+| ------------------------ | ----------------------------- |
+| `:::note[Prerequisites]` | Dependencies before starting  |
+| `:::tip[Quick Path]`     | TL;DR summary at document top |
+| `:::caution[Important]`  | Critical caveats              |
+| `:::note[Example]`       | Command/response examples     |
+
+## Standard Table Formats
+
+**Phases:**
+
+```md
+| Phase | Name     | What Happens                                 |
+| ----- | -------- | -------------------------------------------- |
+| 1     | Analysis | Brainstorm, research *(optional)*            |
+| 2     | Planning | Requirements — PRD or tech-spec *(required)* |
+```
+
+**Commands:**
+
+```md
+| Command      | Agent   | Purpose                              |
+| ------------ | ------- | ------------------------------------ |
+| `brainstorm` | Analyst | Brainstorm a new project             |
+| `prd`        | PM      | Create Product Requirements Document |
+```
+
+## Folder Structure Blocks
+
+Show in "What You've Accomplished" sections:
+
+````md
+```
+your-project/
+├── _bmad/                                   # BMad configuration
+├── _bmad-output/
+│   ├── planning-artifacts/
+│   │   └── PRD.md                           # Your requirements document
+│   ├── implementation-artifacts/
+│   └── project-context.md                   # Implementation rules (optional)
+└── ...
+```
+````
+
+## Tutorial Structure
+
+```text
+1. Title + Hook (1-2 sentences describing outcome)
+2. Version/Module Notice (info or warning admonition) (optional)
+3. What You'll Learn (bullet list of outcomes)
+4. Prerequisites (info admonition)
+5. Quick Path (tip admonition - TL;DR summary)
+6. Understanding [Topic] (context before steps - tables for phases/agents)
+7. Installation (optional)
+8. Step 1: [First Major Task]
+9. Step 2: [Second Major Task]
+10. Step 3: [Third Major Task]
+11. What You've Accomplished (summary + folder structure)
+12. Quick Reference (commands table)
+13. Common Questions (FAQ format)
+14. Getting Help (community links)
+15. Key Takeaways (tip admonition)
+```
+
+### Tutorial Checklist
+
+- [ ] Hook describes outcome in 1-2 sentences
+- [ ] "What You'll Learn" section present
+- [ ] Prerequisites in admonition
+- [ ] Quick Path TL;DR admonition at top
+- [ ] Tables for phases, commands, agents
+- [ ] "What You've Accomplished" section present
+- [ ] Quick Reference table present
+- [ ] Common Questions section present
+- [ ] Getting Help section present
+- [ ] Key Takeaways admonition at end
+
+## How-To Structure
+
+```text
+1. Title + Hook (one sentence: "Use the `X` workflow to...")
+2. When to Use This (bullet list of scenarios)
+3. When to Skip This (optional)
+4. Prerequisites (note admonition)
+5. Steps (numbered ### subsections)
+6. What You Get (output/artifacts produced)
+7. Example (optional)
+8. Tips (optional)
+9. Next Steps (optional)
+```
+
+### How-To Checklist
+
+- [ ] Hook starts with "Use the `X` workflow to..."
+- [ ] "When to Use This" has 3-5 bullet points
+- [ ] Prerequisites listed
+- [ ] Steps are numbered `###` subsections with action verbs
+- [ ] "What You Get" describes output artifacts
+
+## Explanation Structure
+
+### Types
+
+| Type              | Example                       |
+| ----------------- | ----------------------------- |
+| **Index/Landing** | `core-concepts/index.md`      |
+| **Concept**       | `what-are-agents.md`          |
+| **Feature**       | `quick-flow.md`               |
+| **Philosophy**    | `why-solutioning-matters.md`  |
+| **FAQ**           | `established-projects-faq.md` |
+
+### General Template
+
+```text
+1. Title + Hook (1-2 sentences)
+2. Overview/Definition (what it is, why it matters)
+3. Key Concepts (### subsections)
+4. Comparison Table (optional)
+5. When to Use / When Not to Use (optional)
+6. Diagram (optional - mermaid, 1 per doc max)
+7. Next Steps (optional)
+```
+
+### Index/Landing Pages
+
+```text
+1. Title + Hook (one sentence)
+2. Content Table (links with descriptions)
+3. Getting Started (numbered list)
+4. Choose Your Path (optional - decision tree)
+```
+
+### Concept Explainers
+
+```text
+1. Title + Hook (what it is)
+2. Types/Categories (### subsections) (optional)
+3. Key Differences Table
+4. Components/Parts
+5. Which Should You Use?
+6. Creating/Customizing (pointer to how-to guides)
+```
+
+### Feature Explainers
+
+```text
+1. Title + Hook (what it does)
+2. Quick Facts (optional - "Perfect for:", "Time to:")
+3. When to Use / When Not to Use
+4. How It Works (mermaid diagram optional)
+5. Key Benefits
+6. Comparison Table (optional)
+7. When to Graduate/Upgrade (optional)
+```
+
+### Philosophy/Rationale Documents
+
+```text
+1. Title + Hook (the principle)
+2. The Problem
+3. The Solution
+4. Key Principles (### subsections)
+5. Benefits
+6. When This Applies
+```
+
+### Explanation Checklist
+
+- [ ] Hook states what document explains
+- [ ] Content in scannable `##` sections
+- [ ] Comparison tables for 3+ options
+- [ ] Diagrams have clear labels
+- [ ] Links to how-to guides for procedural questions
+- [ ] 2-3 admonitions max per document
+
+## Reference Structure
+
+### Types
+
+| Type              | Example               |
+| ----------------- | --------------------- |
+| **Index/Landing** | `workflows/index.md`  |
+| **Catalog**       | `agents/index.md`     |
+| **Deep-Dive**     | `document-project.md` |
+| **Configuration** | `core-tasks.md`       |
+| **Glossary**      | `glossary/index.md`   |
+| **Comprehensive** | `bmgd-workflows.md`   |
+
+### Reference Index Pages
+
+```text
+1. Title + Hook (one sentence)
+2. Content Sections (## for each category)
+   - Bullet list with links and descriptions
+```
+
+### Catalog Reference
+
+```text
+1. Title + Hook
+2. Items (## for each item)
+   - Brief description (one sentence)
+   - **Commands:** or **Key Info:** as flat list
+3. Universal/Shared (## section) (optional)
+```
+
+### Item Deep-Dive Reference
+
+```text
+1. Title + Hook (one sentence purpose)
+2. Quick Facts (optional note admonition)
+   - Module, Command, Input, Output as list
+3. Purpose/Overview (## section)
+4. How to Invoke (code block)
+5. Key Sections (## for each aspect)
+   - Use ### for sub-options
+6. Notes/Caveats (tip or caution admonition)
+```
+
+### Configuration Reference
+
+```text
+1. Title + Hook
+2. Table of Contents (jump links if 4+ items)
+3. Items (## for each config/task)
+   - **Bold summary** — one sentence
+   - **Use it when:** bullet list
+   - **How it works:** numbered steps (3-5 max)
+   - **Output:** expected result (optional)
+```
+
+### Comprehensive Reference Guide
+
+```text
+1. Title + Hook
+2. Overview (## section)
+   - Diagram or table showing organization
+3. Major Sections (## for each phase/category)
+   - Items (### for each item)
+   - Standardized fields: Command, Agent, Input, Output, Description
+4. Next Steps (optional)
+```
+
+### Reference Checklist
+
+- [ ] Hook states what document references
+- [ ] Structure matches reference type
+- [ ] Items use consistent structure throughout
+- [ ] Tables for structured/comparative data
+- [ ] Links to explanation docs for conceptual depth
+- [ ] 1-2 admonitions max
+
+## Glossary Structure
+
+Starlight generates right-side "On this page" navigation from headers:
+
+- Categories as `##` headers — appear in right nav
+- Terms in tables — compact rows, not individual headers
+- No inline TOC — right sidebar handles navigation
+
+### Table Format
+
+```md
+## Category Name
+
+| Term         | Definition                                                                               |
+| ------------ | ---------------------------------------------------------------------------------------- |
+| **Agent**    | Specialized AI persona with specific expertise that guides users through workflows.      |
+| **Workflow** | Multi-step guided process that orchestrates AI agent activities to produce deliverables. |
+```
+
+### Definition Rules
+
+| Do                            | Don't                                       |
+| ----------------------------- | ------------------------------------------- |
+| Start with what it IS or DOES | Start with "This is..." or "A [term] is..." |
+| Keep to 1-2 sentences         | Write multi-paragraph explanations          |
+| Bold term name in cell        | Use plain text for terms                    |
+
+### Context Markers
+
+Add italic context at definition start for limited-scope terms:
+
+- `*Quick Flow only.*`
+- `*BMad Method/Enterprise.*`
+- `*Phase N.*`
+- `*BMGD.*`
+- `*Established projects.*`
+
+### Glossary Checklist
+
+- [ ] Terms in tables, not individual headers
+- [ ] Terms alphabetized within categories
+- [ ] Definitions 1-2 sentences
+- [ ] Context markers italicized
+- [ ] Term names bolded in cells
+- [ ] No "A [term] is..." definitions
+
+## FAQ Sections
+
+```md
+## Questions
+
+- [Do I always need architecture?](#do-i-always-need-architecture)
+- [Can I change my plan later?](#can-i-change-my-plan-later)
+
+### Do I always need architecture?
+
+Only for BMad Method and Enterprise tracks. Quick Flow skips to implementation.
+
+### Can I change my plan later?
+
+Yes. The SM agent has a `correct-course` workflow for handling scope changes.
+
+**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
+```
+
+## Validation Commands
+
+Before submitting documentation changes:
+
+```bash
+npm run docs:fix-links            # Preview link format fixes
+npm run docs:fix-links -- --write # Apply fixes
+npm run docs:validate-links       # Check links exist
+npm run docs:build                # Verify no build errors
+```

package/docs/explanation/advanced-elicitation.md

@@ -0,0 +1,49 @@
+---
+title: "Advanced Elicitation"
+description: Push the LLM to rethink its work using structured reasoning methods
+sidebar:
+  order: 6
+---
+
+Make the LLM reconsider what it just generated. You pick a reasoning method, it applies that method to its own output, you decide whether to keep the improvements.
+
+## What is Advanced Elicitation?
+
+A structured second pass. Instead of asking the AI to "try again" or "make it better," you select a specific reasoning method and the AI re-examines its own output through that lens.
+
+The difference matters. Vague requests produce vague revisions. A named method forces a particular angle of attack, surfacing insights that a generic retry would miss.
+
+## When to Use It
+
+- After a workflow generates content and you want alternatives
+- When output seems okay but you suspect there's more depth
+- To stress-test assumptions or find weaknesses
+- For high-stakes content where rethinking helps
+
+Workflows offer advanced elicitation at decision points - after the LLM has generated something, you'll be asked if you want to run it.
+
+## How It Works
+
+1. LLM suggests 5 relevant methods for your content
+2. You pick one (or reshuffle for different options)
+3. Method is applied, improvements shown
+4. Accept or discard, repeat or continue
+
+## Built-in Methods
+
+Dozens of reasoning methods are available. A few examples:
+
+- **Pre-mortem Analysis** - Assume the project already failed, work backward to find why
+- **First Principles Thinking** - Strip away assumptions, rebuild from ground truth
+- **Inversion** - Ask how to guarantee failure, then avoid those things
+- **Red Team vs Blue Team** - Attack your own work, then defend it
+- **Socratic Questioning** - Challenge every claim with "why?" and "how do you know?"
+- **Constraint Removal** - Drop all constraints, see what changes, add them back selectively
+- **Stakeholder Mapping** - Re-evaluate from each stakeholder's perspective
+- **Analogical Reasoning** - Find parallels in other domains and apply their lessons
+
+And many more. The AI picks the most relevant options for your content - you choose which to run.
+
+:::tip[Start Here]
+Pre-mortem Analysis is a good first pick for any spec or plan. It consistently finds gaps that a standard review misses.
+:::

package/docs/explanation/adversarial-review.md

@@ -0,0 +1,59 @@
+---
+title: "Adversarial Review"
+description: Forced reasoning technique that prevents lazy "looks good" reviews
+sidebar:
+  order: 5
+---
+
+Force deeper analysis by requiring problems to be found.
+
+## What is Adversarial Review?
+
+A review technique where the reviewer *must* find issues. No "looks good" allowed. The reviewer adopts a cynical stance - assume problems exist and find them.
+
+This isn't about being negative. It's about forcing genuine analysis instead of a cursory glance that rubber-stamps whatever was submitted.
+
+**The core rule:** You must find issues. Zero findings triggers a halt - re-analyze or explain why.
+
+## Why It Works
+
+Normal reviews suffer from confirmation bias. You skim the work, nothing jumps out, you approve it. The "find problems" mandate breaks this pattern:
+
+- **Forces thoroughness** - Can't approve until you've looked hard enough to find issues
+- **Catches missing things** - "What's not here?" becomes a natural question
+- **Improves signal quality** - Findings are specific and actionable, not vague concerns
+- **Information asymmetry** - Run reviews with fresh context (no access to original reasoning) so you evaluate the artifact, not the intent
+
+## Where It's Used
+
+Adversarial review appears throughout BMad workflows - code review, implementation readiness checks, spec validation, and others. Sometimes it's a required step, sometimes optional (like advanced elicitation or party mode). The pattern adapts to whatever artifact needs scrutiny.
+
+## Human Filtering Required
+
+Because the AI is *instructed* to find problems, it will find problems - even when they don't exist. Expect false positives: nitpicks dressed as issues, misunderstandings of intent, or outright hallucinated concerns.
+
+**You decide what's real.** Review each finding, dismiss the noise, fix what matters.
+
+## Example
+
+Instead of:
+
+> "The authentication implementation looks reasonable. Approved."
+
+An adversarial review produces:
+
+> 1. **HIGH** - `login.ts:47` - No rate limiting on failed attempts
+> 2. **HIGH** - Session token stored in localStorage (XSS vulnerable)
+> 3. **MEDIUM** - Password validation happens client-side only
+> 4. **MEDIUM** - No audit logging for failed login attempts
+> 5. **LOW** - Magic number `3600` should be `SESSION_TIMEOUT_SECONDS`
+
+The first review might miss a security vulnerability. The second caught four.
+
+## Iteration and Diminishing Returns
+
+After addressing findings, consider running it again. A second pass usually catches more. A third isn't always useless either. But each pass takes time, and eventually you hit diminishing returns - just nitpicks and false findings.
+
+:::tip[Better Reviews]
+Assume problems exist. Look for what's missing, not just what's wrong.
+:::

package/docs/explanation/brainstorming.md

@@ -0,0 +1,33 @@
+---
+title: "Brainstorming"
+description: Interactive creative sessions using 60+ proven ideation techniques
+sidebar:
+  order: 2
+---
+
+Unlock your creativity through guided exploration.
+
+## What is Brainstorming?
+
+Run `brainstorming` and you've got a creative facilitator pulling ideas out of you - not generating them for you. The AI acts as coach and guide, using proven techniques to create conditions where your best thinking emerges.
+
+**Good for:**
+
+- Breaking through creative blocks
+- Generating product or feature ideas
+- Exploring problems from new angles
+- Developing raw concepts into action plans
+
+## How It Works
+
+1. **Setup** - Define topic, goals, constraints
+2. **Choose approach** - Pick techniques yourself, get AI recommendations, go random, or follow a progressive flow
+3. **Facilitation** - Work through techniques with probing questions and collaborative coaching
+4. **Organize** - Ideas grouped into themes and prioritized
+5. **Action** - Top ideas get next steps and success metrics
+
+Everything gets captured in a session document you can reference later or share with stakeholders.
+
+:::note[Your Ideas]
+Every idea comes from you. The workflow creates conditions for insight - you're the source.
+:::

package/docs/explanation/established-projects-faq.md

@@ -0,0 +1,50 @@
+---
+title: "Established Projects FAQ"
+description: Common questions about using BMad Method on established projects
+sidebar:
+  order: 8
+---
+Quick answers to common questions about working on established projects with the BMad Method (BMM).
+
+## Questions
+
+- [Do I have to run document-project first?](#do-i-have-to-run-document-project-first)
+- [What if I forget to run document-project?](#what-if-i-forget-to-run-document-project)
+- [Can I use Quick Flow for established projects?](#can-i-use-quick-flow-for-established-projects)
+- [What if my existing code doesn't follow best practices?](#what-if-my-existing-code-doesnt-follow-best-practices)
+
+### Do I have to run document-project first?
+
+Highly recommended, especially if:
+
+- No existing documentation
+- Documentation is outdated
+- AI agents need context about existing code
+
+You can skip it if you have comprehensive, up-to-date documentation including `docs/index.md` or will use other tools or techniques to aid in discovery for the agent to build on an existing system.
+
+### What if I forget to run document-project?
+
+Don't worry about it - you can do it at any time. You can even do it during or after a project to help keep docs up to date.
+
+### Can I use Quick Flow for established projects?
+
+Yes! Quick Flow works great for established projects. It will:
+
+- Auto-detect your existing stack
+- Analyze existing code patterns
+- Detect conventions and ask for confirmation
+- Generate context-rich tech-spec that respects existing code
+
+Perfect for bug fixes and small features in existing codebases.
+
+### What if my existing code doesn't follow best practices?
+
+Quick Flow detects your conventions and asks: "Should I follow these existing conventions?" You decide:
+
+- **Yes** → Maintain consistency with current codebase
+- **No** → Establish new standards (document why in tech-spec)
+
+BMM respects your choice — it won't force modernization, but it will offer it.
+
+**Have a question not answered here?** Please [open an issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) or ask in [Discord](https://discord.gg/gk8jAdXWmj) so we can add it!