From 5988fe050622262a815bd2586bedda5ffc3dd84a Mon Sep 17 00:00:00 2001 From: Brian Madison Date: Tue, 10 Mar 2026 19:23:02 -0500 Subject: [PATCH] remove .cladue/skills folder, will follow up with gitignore --- .../skills/bmad-os-audit-file-refs/SKILL.md | 6 - .../prompts/instructions.md | 59 ---- .../skills/bmad-os-changelog-social/SKILL.md | 177 ----------- .../examples/discord-example.md | 53 ---- .../examples/linkedin-example.md | 49 --- .../examples/twitter-example.md | 55 ---- .../bmad-os-diataxis-style-fix/SKILL.md | 6 - .../prompts/instructions.md | 229 -------------- .../skills/bmad-os-draft-changelog/SKILL.md | 6 - .../prompts/instructions.md | 82 ----- .../skills/bmad-os-findings-triage/SKILL.md | 6 - .../prompts/agent-prompt.md | 104 ------- .../prompts/instructions.md | 286 ----------------- .claude/skills/bmad-os-gh-triage/SKILL.md | 6 - .../bmad-os-gh-triage/prompts/agent-prompt.md | 60 ---- .../bmad-os-gh-triage/prompts/instructions.md | 74 ----- .../skills/bmad-os-release-module/SKILL.md | 6 - .../prompts/instructions.md | 53 ---- .claude/skills/bmad-os-review-pr/SKILL.md | 6 - .../bmad-os-review-pr/prompts/instructions.md | 288 ------------------ .claude/skills/bmad-os-review-prompt/SKILL.md | 177 ----------- .../bmad-os-root-cause-analysis/SKILL.md | 12 - .../prompts/instructions.md | 74 ----- 23 files changed, 1874 deletions(-) delete mode 100644 .claude/skills/bmad-os-audit-file-refs/SKILL.md delete mode 100644 .claude/skills/bmad-os-audit-file-refs/prompts/instructions.md delete mode 100644 .claude/skills/bmad-os-changelog-social/SKILL.md delete mode 100644 .claude/skills/bmad-os-changelog-social/examples/discord-example.md delete mode 100644 .claude/skills/bmad-os-changelog-social/examples/linkedin-example.md delete mode 100644 .claude/skills/bmad-os-changelog-social/examples/twitter-example.md delete mode 100644 .claude/skills/bmad-os-diataxis-style-fix/SKILL.md delete mode 100644 .claude/skills/bmad-os-diataxis-style-fix/prompts/instructions.md delete mode 100644 .claude/skills/bmad-os-draft-changelog/SKILL.md delete mode 100644 .claude/skills/bmad-os-draft-changelog/prompts/instructions.md delete mode 100644 .claude/skills/bmad-os-findings-triage/SKILL.md delete mode 100644 .claude/skills/bmad-os-findings-triage/prompts/agent-prompt.md delete mode 100644 .claude/skills/bmad-os-findings-triage/prompts/instructions.md delete mode 100644 .claude/skills/bmad-os-gh-triage/SKILL.md delete mode 100644 .claude/skills/bmad-os-gh-triage/prompts/agent-prompt.md delete mode 100644 .claude/skills/bmad-os-gh-triage/prompts/instructions.md delete mode 100644 .claude/skills/bmad-os-release-module/SKILL.md delete mode 100644 .claude/skills/bmad-os-release-module/prompts/instructions.md delete mode 100644 .claude/skills/bmad-os-review-pr/SKILL.md delete mode 100644 .claude/skills/bmad-os-review-pr/prompts/instructions.md delete mode 100644 .claude/skills/bmad-os-review-prompt/SKILL.md delete mode 100644 .claude/skills/bmad-os-root-cause-analysis/SKILL.md delete mode 100644 .claude/skills/bmad-os-root-cause-analysis/prompts/instructions.md diff --git a/.claude/skills/bmad-os-audit-file-refs/SKILL.md b/.claude/skills/bmad-os-audit-file-refs/SKILL.md deleted file mode 100644 index 637bcfd33..000000000 --- a/.claude/skills/bmad-os-audit-file-refs/SKILL.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -name: bmad-os-audit-file-refs -description: Audit BMAD source files for file-reference convention violations using parallel Haiku subagents. Use when users requests an "audit file references" for a skill, workflow or task. ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-audit-file-refs/prompts/instructions.md b/.claude/skills/bmad-os-audit-file-refs/prompts/instructions.md deleted file mode 100644 index cf9e3d6e8..000000000 --- a/.claude/skills/bmad-os-audit-file-refs/prompts/instructions.md +++ /dev/null @@ -1,59 +0,0 @@ -# audit-file-refs - -Audit new-format BMAD source files for file-reference convention violations using parallel Haiku subagents. - -## Convention - -In new-format BMAD workflow and task files (`src/bmm/`, `src/core/`, `src/utility/`), every file path reference must use one of these **valid** forms: - -- `{project-root}/_bmad/path/to/file.ext` — canonical form, always correct -- `{installed_path}/relative/path` — valid in new-format step files (always defined by workflow.md before any step is reached) -- Template/runtime variables: `{nextStepFile}`, `{workflowFile}`, `{{mustache}}`, `{output_folder}`, `{communication_language}`, etc. — skip these, they are substituted at runtime - -**Flag any reference that uses:** - -- `./step-NN.md` or `../something.md` — relative paths -- `step-NN.md` — bare filename with no path prefix -- `steps/step-NN.md` — bare steps-relative path (missing `{project-root}/_bmad/...` prefix) -- `` `_bmad/core/tasks/help.md` `` — bare `_bmad/` path (missing `{project-root}/`) -- `/Users/...`, `/home/...`, `C:\...` — absolute system paths - -References inside fenced code blocks (``` ``` ```) are examples — skip them. - -Old-format files in `src/bmm/workflows/4-implementation/` use `{installed_path}` by design within the XML calling chain — exclude that directory entirely. - -## Steps - -1. Run this command to get the file list: - ``` - find src/bmm src/core src/utility -type f \( -name "*.md" -o -name "*.yaml" \) | grep -v "4-implementation" | sort - ``` - -2. Divide the resulting file paths into batches of roughly 20 files each. - -3. For each batch, spawn a subagent (`subagent_type: "Explore"`, `model: "haiku"`) with this prompt (fill in the actual file paths): - - > Read each of these files (use the Read tool on each): - > [list the file paths from this batch] - > - > For each file, identify every line that contains a file path reference that violates the convention described below. Skip references inside fenced code blocks. Skip template variables (anything containing `{` that isn't `{project-root}` or `{installed_path}`). - > - > **Valid references:** `{project-root}/_bmad/...`, `{installed_path}/...`, template variables. - > **Flag:** bare filenames (`step-NN.md`), `./` or `../` relative paths, bare `steps/` paths, bare `_bmad/` paths (without `{project-root}/`), absolute system paths. - > - > Return findings as a list: - > `path/to/file.md:LINE_NUMBER | VIOLATION_TYPE | offending text` - > - > If a file has no violations, include it as: `path/to/file.md | clean` - > - > End your response with a single line: `FILES CHECKED: N` where N is the exact number of files you read. - -4. Collect all findings from all subagents. - -5. **Self-check before reporting:** Count the total number of files returned by the `find` command. Sum the `FILES CHECKED: N` values across all subagent responses. If the totals do not match, identify which files are missing and re-run subagents for those files before proceeding. Do not produce the final report until all files are accounted for. - -6. Output a final report: - - Group findings by violation type - - List each finding as `file:line — offending text` - - Show total count of violations and number of affected files - - If nothing found, say "All files conform to the convention." diff --git a/.claude/skills/bmad-os-changelog-social/SKILL.md b/.claude/skills/bmad-os-changelog-social/SKILL.md deleted file mode 100644 index d2e5cda29..000000000 --- a/.claude/skills/bmad-os-changelog-social/SKILL.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -name: bmad-os-changelog-social -description: Generate social media announcements for Discord, Twitter, and LinkedIn from the latest changelog entry. Use when user asks to 'create release announcement' or 'create social posts' or share changelog updates. ---- - -# Changelog Social - -Generate engaging social media announcements from changelog entries. - -## Workflow - -### Step 1: Extract Changelog Entry - -Read `./CHANGELOG.md` and extract the latest version entry. The changelog follows this format: - -```markdown -## [VERSION] - -### 🎁 Features -* **Title** — Description - -### 🐛 Bug Fixes -* **Title** — Description - -### 📚 Documentation -* **Title** — Description - -### 🔧 Maintenance -* **Title** — Description -``` - -Parse: -- **Version number** (e.g., `6.0.0-Beta.5`) -- **Features** - New functionality, enhancements -- **Bug Fixes** - Fixes users will care about -- **Documentation** - New or improved docs -- **Maintenance** - Dependency updates, tooling improvements - -### Step 2: Get Git Contributors - -Use git log to find contributors since the previous version. Get commits between the current version tag and the previous one: - -```bash -# Find the previous version tag first -git tag --sort=-version:refname | head -5 - -# Get commits between versions with PR numbers and authors -git log .. --pretty=format:"%h|%s|%an" --grep="#" -``` - -Extract PR numbers from commit messages that contain `#` followed by digits. Compile unique contributors. - -### Step 3: Generate Discord Announcement - -**Limit: 2,000 characters per message.** Split into multiple messages if needed. - -Use this template style: - -```markdown -🚀 **BMad vVERSION RELEASED!** - -🎉 [Brief hype sentence] - -🪥 **KEY HIGHLIGHT** - [One-line summary] - -🎯 **CATEGORY NAME** -• Feature one - brief description -• Feature two - brief description -• Coming soon: Future teaser - -🔧 **ANOTHER CATEGORY** -• Fix or feature -• Another item - -📚 **DOCS OR OTHER** -• Item -• Item with link - -🌟 **COMMUNITY PHILOSOPHY** (optional - include for major releases) -• Everything is FREE - No paywalls -• Knowledge shared, not sold - -📊 **STATS** -X commits | Y PRs merged | Z files changed - -🙏 **CONTRIBUTORS** -@username1 (X PRs!), @username2 (Y PRs!) -@username3, @username4, username5 + dependabot 🛡️ -Community-driven FTW! 🌟 - -📦 **INSTALL:** -`npx bmad-method@VERSION install` - -⭐ **SUPPORT US:** -🌟 GitHub: github.com/bmad-code-org/BMAD-METHOD/ -📺 YouTube: youtube.com/@BMadCode -☕ Donate: buymeacoffee.com/bmad - -🔥 **Next version tease!** -``` - -**Content Strategy:** -- Focus on **user impact** - what's better for them? -- Highlight **annoying bugs fixed** that frustrated users -- Show **new capabilities** that enable workflows -- Keep it **punchy** - use emojis and short bullets -- Add **personality** - excitement, humor, gratitude - -### Step 4: Generate Twitter Post - -**Limit: 25,000 characters per tweet (Premium).** With Premium, use a single comprehensive post matching the Discord style (minus Discord-specific formatting). Aim for 1,500-3,000 characters for better engagement. - -**Threads are optional** — only use for truly massive releases where you want multiple engagement points. - -See `examples/twitter-example.md` for the single-post Premium format. - -## Content Selection Guidelines - -**Include:** -- New features that change workflows -- Bug fixes for annoying/blocking issues -- Documentation that helps users -- Performance improvements -- New agents or workflows -- Breaking changes (call out clearly) - -**Skip/Minimize:** -- Internal refactoring -- Dependency updates (unless user-facing) -- Test improvements -- Minor style fixes - -**Emphasize:** -- "Finally fixed" issues -- "Faster" operations -- "Easier" workflows -- "Now supports" capabilities - -## Examples - -Reference example posts in `examples/` for tone and formatting guidance: - -- **discord-example.md** — Full Discord announcement with emojis, sections, contributor shout-outs -- **twitter-example.md** — Twitter thread format (5 tweets max for major releases) -- **linkedin-example.md** — Professional post for major/minor releases with significant features - -**When to use LinkedIn:** -- Major version releases (e.g., v6.0.0 Beta, v7.0.0) -- Minor releases with exceptional new features -- Community milestone announcements - -Read the appropriate example file before generating to match the established style and voice. - -## Output Format - -**CRITICAL: ALWAYS write to files** - Create files in `_bmad-output/social/` directory: - -1. `{repo-name}-discord-{version}.md` - Discord announcement -2. `{repo-name}-twitter-{version}.md` - Twitter post -3. `{repo-name}-linkedin-{version}.md` - LinkedIn post (if applicable) - -Also present a preview in the chat: - -```markdown -## Discord Announcement - -[paste Discord content here] - -## Twitter Post - -[paste Twitter content here] -``` - -Files created: -- `_bmad-output/social/{filename}` - -Offer to make adjustments if the user wants different emphasis, tone, or content. diff --git a/.claude/skills/bmad-os-changelog-social/examples/discord-example.md b/.claude/skills/bmad-os-changelog-social/examples/discord-example.md deleted file mode 100644 index 325e8824e..000000000 --- a/.claude/skills/bmad-os-changelog-social/examples/discord-example.md +++ /dev/null @@ -1,53 +0,0 @@ -🚀 **BMad v6.0.0-alpha.23 RELEASED!** - -🎉 Huge update - almost beta! - -🪟 **WINDOWS INSTALLER FIXED** - Menu arrows issue should be fixed! CRLF & ESM problems resolved. - -🎯 **PRD WORKFLOWS IMPROVED** -• Validation & Edit workflows added! -• PRD Cohesion check ensures document flows beautifully -• Coming soon: Use of subprocess optimization (context saved!) -• Coming soon: Final format polish step in all workflows - Human consumption OR hyper-optimized LLM condensed initially! - -🔧 **WORKFLOW CREATOR & VALIDATOR** -• Subprocess support for advanced optimization -• Path violation checks ensure integrity -• Beyond error checking - offers optimization & flow suggestions! - -📚 **NEW DOCS SITE** - docs.bmad-method.org -• Diataxis framework: Tutorials, How-To, Explanations, References -• Current docs still being revised -• Tutorials, blogs & explainers coming soon! - -💡 **BRAINSTORMING REVOLUTION** -• 100+ idea goal (quantity-first!) -• Anti-bias protocol (pivot every 10 ideas) -• Chain-of-thought + simulated temperature prompts -• Coming soon: SubProcessing (on-the-fly sub agents) - -🌟 **COMMUNITY PHILOSOPHY** -• Everything is FREE - No paywalls, no gated content -• Knowledge shared, not sold -• No premium tiers - full access to our ideas - -📊 **27 commits | 217 links converted | 42+ docs created** - -🙏 **17 Community PR Authors in this release!** -@lum (6 PRs!), @q00 (3 PRs!), @phil (2 PRs!) -@mike, @alex, @ramiz, @sjennings + dependabot 🛡️ -Community-driven FTW! 🌟 - -📦 **INSTALL ALPHA:** -`npx bmad-method install` - -⭐ **SUPPORT US:** -🌟 GitHub: github.com/bmad-code-org/BMAD-METHOD/ -📺 YouTube: youtube.com/@BMadCode - -🎤 **SPEAKING & MEDIA** -Available for conferences, podcasts, media appearances! -Topics: AI-Native Organizations (Any Industry), BMad Method -DM on Discord for inquiries! - -🔥 **V6 Beta is DAYS away!** January 22nd ETA - new features such as xyz and abc bug fixes! diff --git a/.claude/skills/bmad-os-changelog-social/examples/linkedin-example.md b/.claude/skills/bmad-os-changelog-social/examples/linkedin-example.md deleted file mode 100644 index dc5919e65..000000000 --- a/.claude/skills/bmad-os-changelog-social/examples/linkedin-example.md +++ /dev/null @@ -1,49 +0,0 @@ -🚀 **Announcing BMad Method v6.0.0 Beta - AI-Native Agile Development Framework** - -I'm excited to share that BMad Method, the open-source AI-driven agile development framework, is entering Beta! After 27 alpha releases and countless community contributions, we're approaching a major milestone. - -**What's New in v6.0.0-alpha.23** - -🪟 **Windows Compatibility Fixed** -We've resolved the installer issues that affected Windows users. The menu arrows problem, CRLF handling, and ESM compatibility are all resolved. - -🎯 **Enhanced PRD Workflows** -Our Product Requirements Document workflows now include validation and editing capabilities, with a new cohesion check that ensures your documents flow beautifully. Subprocess optimization is coming soon to save even more context. - -🔧 **Workflow Creator & Validator** -New tools for creating and validating workflows with subprocess support, path violation checks, and optimization suggestions that go beyond simple error checking. - -📚 **New Documentation Platform** -We've launched docs.bmad-method.org using the Diataxis framework - providing clear separation between tutorials, how-to guides, explanations, and references. Our documentation is being continuously revised and expanded. - -💡 **Brainstorming Revolution** -Our brainstorming workflows now use research-backed techniques: 100+ idea goals, anti-bias protocols, chain-of-thought reasoning, and simulated temperature prompts for higher divergence. - -**Our Philosophy** - -Everything in BMad Method is FREE. No paywalls, no gated content, no premium tiers. We believe knowledge should be shared, not sold. This is community-driven development at its finest. - -**The Stats** -- 27 commits in this release -- 217 documentation links converted -- 42+ new documents created -- 17 community PR authors contributed - -**Get Started** - -``` -npx bmad-method@alpha install -``` - -**Learn More** -- GitHub: github.com/bmad-code-org/BMAD-METHOD -- YouTube: youtube.com/@BMadCode -- Docs: docs.bmad-method.org - -**What's Next?** - -Beta is just days away with an ETA of January 22nd. We're also available for conferences, podcasts, and media appearances to discuss AI-Native Organizations and the BMad Method. - -Have you tried BMad Method yet? I'd love to hear about your experience in the comments! - -#AI #SoftwareDevelopment #Agile #OpenSource #DevTools #LLM #AgentEngineering diff --git a/.claude/skills/bmad-os-changelog-social/examples/twitter-example.md b/.claude/skills/bmad-os-changelog-social/examples/twitter-example.md deleted file mode 100644 index d8a0feaed..000000000 --- a/.claude/skills/bmad-os-changelog-social/examples/twitter-example.md +++ /dev/null @@ -1,55 +0,0 @@ -🚀 **BMad v6.0.0-alpha.23 RELEASED!** - -Huge update - we're almost at Beta! 🎉 - -🪟 **WINDOWS INSTALLER FIXED** - Menu arrows issue should be fixed! CRLF & ESM problems resolved. - -🎯 **PRD WORKFLOWS IMPROVED** -• Validation & Edit workflows added! -• PRD Cohesion check ensures document flows beautifully -• Coming soon: Subprocess optimization (context saved!) -• Coming soon: Final format polish step in all workflows - -🔧 **WORKFLOW CREATOR & VALIDATOR** -• Subprocess support for advanced optimization -• Path violation checks ensure integrity -• Beyond error checking - offers optimization & flow suggestions! - -📚 **NEW DOCS SITE** - docs.bmad-method.org -• Diataxis framework: Tutorials, How-To, Explanations, References -• Current docs still being revised -• Tutorials, blogs & explainers coming soon! - -💡 **BRAINSTORMING REVOLUTION** -• 100+ idea goal (quantity-first!) -• Anti-bias protocol (pivot every 10 ideas) -• Chain-of-thought + simulated temperature prompts -• Coming soon: SubProcessing (on-the-fly sub agents) - -🌟 **COMMUNITY PHILOSOPHY** -• Everything is FREE - No paywalls, no gated content -• Knowledge shared, not sold -• No premium tiers - full access to our ideas - -📊 **27 commits | 217 links converted | 42+ docs created** - -🙏 **17 Community PR Authors in this release!** -@lum (6 PRs!), @q00 (3 PRs!), @phil (2 PRs!) -@mike, @alex, @ramiz, @sjennings + dependabot 🛡️ -Community-driven FTW! 🌟 - -📦 **INSTALL ALPHA:** -`npx bmad-method install` - -⭐ **SUPPORT US:** -🌟 GitHub: github.com/bmad-code-org/BMAD-METHOD/ -📺 YouTube: youtube.com/@BMadCode - -🎤 **SPEAKING & MEDIA** -Available for conferences, podcasts, media appearances! -Topics: AI-Native Organizations (Any Industry), BMad Method -DM on Discord for inquiries! - -🔥 **V6 Beta is DAYS away!** January 22nd ETA! - -#AI #DevTools #Agile #OpenSource #LLM #AgentEngineering diff --git a/.claude/skills/bmad-os-diataxis-style-fix/SKILL.md b/.claude/skills/bmad-os-diataxis-style-fix/SKILL.md deleted file mode 100644 index 8a4f69ae6..000000000 --- a/.claude/skills/bmad-os-diataxis-style-fix/SKILL.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -name: bmad-os-diataxis-style-fix -description: Fixes documentation to comply with Diataxis framework and BMad Method style guide rules. Use when user asks to check or fix style of files under the docs folder. ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-diataxis-style-fix/prompts/instructions.md b/.claude/skills/bmad-os-diataxis-style-fix/prompts/instructions.md deleted file mode 100644 index 827e39115..000000000 --- a/.claude/skills/bmad-os-diataxis-style-fix/prompts/instructions.md +++ /dev/null @@ -1,229 +0,0 @@ -# Diataxis Style Fixer - -Automatically fixes documentation to comply with the Diataxis framework and BMad Method style guide. - -## CRITICAL RULES - -- **NEVER commit or push changes** — let the user review first -- **NEVER make destructive edits** — preserve all content, only fix formatting -- **Use Edit tool** — make targeted fixes, not full file rewrites -- **Show summary** — after fixing, list all changes made - -## Input - -Documentation file path or directory to fix. Defaults to `docs/` if not specified. - -## Step 1: Understand Diataxis Framework - -**Diataxis** is a documentation framework that categorizes content into four types based on two axes: - -| | **Learning** (oriented toward future) | **Doing** (oriented toward present) | -| -------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -| **Practical** | **Tutorials** — lessons that guide learners through achieving a specific goal | **How-to guides** — step-by-step instructions for solving a specific problem | -| **Conceptual** | **Explanation** — content that clarifies and describes underlying concepts | **Reference** — technical descriptions, organized for lookup | - -**Key principles:** -- Each document type serves a distinct user need -- Don't mix types — a tutorial shouldn't explain concepts deeply -- Focus on the user's goal, not exhaustive coverage -- Structure follows purpose (tutorials are linear, reference is scannable) - -## Step 2: Read the Style Guide - -Read the project's style guide at `docs/_STYLE_GUIDE.md` to understand all project-specific conventions. - -## Step 3: Detect Document Type - -Based on file location, determine the document type: - -| Location | Diataxis Type | -| -------------------- | -------------------- | -| `/docs/tutorials/` | Tutorial | -| `/docs/how-to/` | How-to guide | -| `/docs/explanation/` | Explanation | -| `/docs/reference/` | Reference | -| `/docs/glossary/` | Reference (glossary) | - -## Step 4: Find and Fix Issues - -For each markdown file, scan for issues and fix them: - -### Universal Fixes (All Doc Types) - -**Horizontal Rules (`---`)** -- Remove any `---` outside of YAML frontmatter -- Replace with `##` section headers or admonitions as appropriate - -**`####` Headers** -- Replace with bold text: `#### Header` → `**Header**` -- Or convert to admonition if it's a warning/notice - -**"Related" or "Next:" Sections** -- Remove entire section including links -- The sidebar handles navigation - -**Deeply Nested Lists** -- Break into sections with `##` headers -- Flatten to max 3 levels - -**Code Blocks for Dialogue/Examples** -- Convert to admonitions: - ``` - :::note[Example] - [content] - ::: - ``` - -**Bold Paragraph Callouts** -- Convert to admonitions with appropriate type - -**Too Many Admonitions** -- Limit to 1-2 per section (tutorials allow 3-4 per major section) -- Consolidate related admonitions -- Remove less critical ones if over limit - -**Table Cells / List Items > 2 Sentences** -- Break into multiple rows/cells -- Or shorten to 1-2 sentences - -**Header Budget Exceeded** -- Merge related sections -- Convert some `##` to `###` subsections -- Goal: 8-12 `##` per doc; 2-3 `###` per section - -### Type-Specific Fixes - -**Tutorials** (`/docs/tutorials/`) -- Ensure hook describes outcome in 1-2 sentences -- Add "What You'll Learn" bullet section if missing -- Add `:::note[Prerequisites]` if missing -- Add `:::tip[Quick Path]` TL;DR at top if missing -- Use tables for phases, commands, agents -- Add "What You've Accomplished" section if missing -- Add Quick Reference table if missing -- Add Common Questions section if missing -- Add Getting Help section if missing -- Add `:::tip[Key Takeaways]` at end if missing - -**How-To** (`/docs/how-to/`) -- Ensure hook starts with "Use the `X` workflow to..." -- Add "When to Use This" with 3-5 bullets if missing -- Add `:::note[Prerequisites]` if missing -- Ensure steps are numbered `###` with action verbs -- Add "What You Get" describing outputs if missing - -**Explanation** (`/docs/explanation/`) -- Ensure hook states what document explains -- Organize content into scannable `##` sections -- Add comparison tables for 3+ options -- Link to how-to guides for procedural questions -- Limit to 2-3 admonitions per document - -**Reference** (`/docs/reference/`) -- Ensure hook states what document references -- Ensure structure matches reference type -- Use consistent item structure throughout -- Use tables for structured/comparative data -- Link to explanation docs for conceptual depth -- Limit to 1-2 admonitions per document - -**Glossary** (`/docs/glossary/` or glossary files) -- Ensure categories as `##` headers -- Ensure terms in tables (not individual headers) -- Definitions 1-2 sentences max -- Bold term names in cells - -## Step 5: Apply Fixes - -For each file with issues: -1. Read the file -2. Use Edit tool for each fix -3. Track what was changed - -## Step 6: Summary - -After processing all files, output a summary: - -```markdown -# Style Fixes Applied - -**Files processed:** N -**Files modified:** N - -## Changes Made - -### `path/to/file.md` -- Removed horizontal rule at line 45 -- Converted `####` headers to bold text -- Added `:::tip[Quick Path]` admonition -- Consolidated 3 admonitions into 2 - -### `path/to/other.md` -- Removed "Related:" section -- Fixed table cell length (broke into 2 rows) - -## Review Required - -Please review the changes. When satisfied, commit and push as needed. -``` - -## Common Patterns - -**Converting `####` to bold:** -```markdown -#### Important Note -Some text here. -``` -→ -```markdown -**Important Note** - -Some text here. -``` - -**Removing horizontal rule:** -```markdown -Some content above. - ---- - -Some content below. -``` -→ -```markdown -Some content above. - -## [Descriptive Section Header] - -Some content below. -``` - -**Converting code block to admonition:** -```markdown -``` -User: What should I do? - -Agent: Run the workflow. -``` -``` -→ -```markdown -:::note[Example] - -**User:** What should I do? - -**Agent:** Run the workflow. - -::: -``` - -**Converting bold paragraph to admonition:** -```markdown -**IMPORTANT:** This is critical that you read this before proceeding. -``` -→ -```markdown -:::caution[Important] -This is critical that you read this before proceeding. -::: -``` diff --git a/.claude/skills/bmad-os-draft-changelog/SKILL.md b/.claude/skills/bmad-os-draft-changelog/SKILL.md deleted file mode 100644 index aab75dd98..000000000 --- a/.claude/skills/bmad-os-draft-changelog/SKILL.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -name: bmad-os-draft-changelog -description: "Analyzes changes since last release and updates CHANGELOG.md ONLY. Use when users requests 'update the changelog' or 'prepare changelog release notes'" ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-draft-changelog/prompts/instructions.md b/.claude/skills/bmad-os-draft-changelog/prompts/instructions.md deleted file mode 100644 index ef3feccef..000000000 --- a/.claude/skills/bmad-os-draft-changelog/prompts/instructions.md +++ /dev/null @@ -1,82 +0,0 @@ -# Draft Changelog Execution - -## ⚠️ IMPORTANT - READ FIRST - -**This skill ONLY updates CHANGELOG.md. That is its entire purpose.** - -- **DO** update CHANGELOG.md with the new version entry -- **DO** present the draft for user review before editing -- **DO NOT** trigger any GitHub release workflows -- **DO NOT** run any other skills or workflows automatically -- **DO NOT** make any commits - -After the changelog is complete, you may suggest the user can run `/release-module` if they want to proceed with the actual release — but NEVER trigger it yourself. - -## Input -Project path (or run from project root) - -## Step 1: Identify Current State -- Get the latest released tag -- Get current version -- Verify there are commits since the last release - -## Step 2: Launch Explore Agent - -Use `thoroughness: "very thorough"` to analyze all changes since the last release tag. - -**Key: For each merge commit, look up the merged PR/issue that was closed.** -- Use `gh pr view` or git commit body to find the PR number -- Read the PR description and comments to understand full context -- Don't rely solely on commit merge messages - they lack context - -**Analyze:** - -1. **All merges/commits** since the last tag -2. **For each merge, read the original PR/issue** that was closed -3. **Files changed** with statistics -4. **Categorize changes:** - - 🎁 **Features** - New functionality, new agents, new workflows - - 🐛 **Bug Fixes** - Fixed bugs, corrected issues - - ♻️ **Refactoring** - Code improvements, reorganization - - 📚 **Documentation** - Docs updates, README changes - - 🔧 **Maintenance** - Dependency updates, tooling, infrastructure - - 💥 **Breaking Changes** - Changes that may affect users - -**Provide:** -- Comprehensive summary of ALL changes with PR context -- Categorization of each change -- Identification of breaking changes -- Significance assessment (major/minor/trivial) - -## Step 3: Generate Draft Changelog - -Format: -```markdown -## v0.X.X - [Date] - -* [Change 1 - categorized by type] -* [Change 2] -``` - -Guidelines: -- Present tense ("Fix bug" not "Fixed bug") -- Most significant changes first -- Group related changes -- Clear, concise language -- For breaking changes, clearly indicate impact - -## Step 4: Present Draft & Update CHANGELOG.md - -Show the draft with current version, last tag, commit count, and options to edit/retry. - -When user accepts: -1. Update CHANGELOG.md with the new entry (insert at top, after `# Changelog` header) -2. STOP. That's it. You're done. - -You may optionally suggest: *"When ready, you can run `/release-module` to create the actual release."* - -**DO NOT:** -- Trigger any GitHub workflows -- Run any other skills -- Make any commits -- Do anything beyond updating CHANGELOG.md diff --git a/.claude/skills/bmad-os-findings-triage/SKILL.md b/.claude/skills/bmad-os-findings-triage/SKILL.md deleted file mode 100644 index 4dd0afe72..000000000 --- a/.claude/skills/bmad-os-findings-triage/SKILL.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -name: bmad-os-findings-triage -description: Orchestrate HITL triage of review findings using parallel agents. Use when the user says 'triage these findings' or 'run findings triage' or has a batch of review findings to process. ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-findings-triage/prompts/agent-prompt.md b/.claude/skills/bmad-os-findings-triage/prompts/agent-prompt.md deleted file mode 100644 index 8bc6c2dca..000000000 --- a/.claude/skills/bmad-os-findings-triage/prompts/agent-prompt.md +++ /dev/null @@ -1,104 +0,0 @@ -# Finding Agent: {{TASK_ID}} — {{TASK_SUBJECT}} - -You are a finding agent in the `{{TEAM_NAME}}` triage team. You own exactly one finding and will shepherd it through research, planning, human conversation, and a final decision. - -## Your Assignment - -- **Task:** `{{TASK_ID}}` -- **Finding:** `{{FINDING_ID}}` — {{FINDING_TITLE}} -- **Severity:** {{SEVERITY}} -- **Team:** `{{TEAM_NAME}}` -- **Team Lead:** `{{TEAM_LEAD_NAME}}` - -## Phase 1 — Research (autonomous) - -1. Read your task details with `TaskGet("{{TASK_ID}}")`. -2. Read the relevant source files to understand the finding in context: -{{FILE_LIST}} - If no specific files are listed above, use codebase search to locate code relevant to the finding. - -If a context document was provided: -- Also read this context document for background: {{CONTEXT_DOC}} - -If an initial triage was provided: -- **Note:** The team lead triaged this as **{{INITIAL_TRIAGE}}** — {{TRIAGE_RATIONALE}}. Evaluate whether this triage is correct and incorporate your assessment into your plan. - -**Rules for research:** -- Work autonomously. Do not ask the team lead or the human for help during research. -- Use `Read`, `Grep`, `Glob`, and codebase search tools to understand the codebase. -- Trace call chains, check tests, read related code — be thorough. -- Form your own opinion on whether this finding is real, a false positive, or somewhere in between. - -## Phase 2 — Plan (display only) - -Prepare a plan for dealing with this finding. The plan MUST cover: - -1. **Assessment** — Is this finding real? What is the actual risk or impact? -2. **Recommendation** — One of: fix it, accept the risk (wontfix), dismiss as not a real issue, or reject as a false positive. -3. **If recommending a fix:** Describe the specific changes — which files, what modifications, why this approach. -4. **If recommending against fixing:** Explain the reasoning — existing mitigations, acceptable risk, false positive rationale. - -**Display the plan in your output.** Write it clearly so the human can read it directly. Follow the plan with a 2-5 line summary of the finding itself. - -**CRITICAL: Do NOT send your plan or analysis to the team lead.** The team lead does not need your plan — the human reads it from your output stream. Sending full plans to the team lead wastes its context window. - -## Phase 3 — Signal Ready - -After displaying your plan, send exactly this to the team lead: - -``` -SendMessage({ - type: "message", - recipient: "{{TEAM_LEAD_NAME}}", - content: "{{FINDING_ID}} ready for HITL", - summary: "{{FINDING_ID}} ready for review" -}) -``` - -Then **stop and wait**. Do not proceed until the human engages with you. - -## Phase 4 — HITL Conversation - -The human will review your plan and talk to you directly. This is a real conversation, not a rubber stamp: - -- The human may agree immediately, push back, ask questions, or propose alternatives. -- Answer questions thoroughly. Refer back to specific code you read. -- If the human wants a fix, **apply it** — edit the source files, verify the change makes sense. -- If the human disagrees with your assessment, update your recommendation. -- Stay focused on THIS finding only. Do not discuss other findings. -- **Do not send a decision until the human explicitly states a verdict.** Acknowledging your plan is NOT a decision. Wait for clear direction like "fix it", "dismiss", "reject", "skip", etc. - -## Phase 5 — Report Decision - -When the human reaches a decision, send exactly ONE message to the team lead: - -``` -SendMessage({ - type: "message", - recipient: "{{TEAM_LEAD_NAME}}", - content: "DECISION {{FINDING_ID}} {{TASK_ID}} [CATEGORY] | [one-sentence summary]", - summary: "{{FINDING_ID}} [CATEGORY]" -}) -``` - -Where `[CATEGORY]` is one of: - -| Category | Meaning | -|----------|---------| -| **SKIP** | Human chose to skip without full review. | -| **DEFER** | Human chose to defer to a later session. | -| **FIX** | Change applied. List the file paths changed and what each change was (use a parseable format: `files: path1, path2`). | -| **WONTFIX** | Real finding, not worth fixing now. State why. | -| **DISMISS** | Not a real finding or mitigated by existing design. State the mitigation. | -| **REJECT** | False positive from the reviewer. State why it is wrong. | - -After sending the decision, **go idle and wait for shutdown**. Do not take any further action. The team lead will send you a shutdown request — approve it. - -## Rules - -- You own ONE finding. Do not touch files unrelated to your finding unless required for the fix. -- Your plan is for the human's eyes — display it in your output, never send it to the team lead. -- Your only messages to the team lead are: (1) ready for HITL, (2) final decision. Nothing else. -- If you cannot form a confident plan (ambiguous finding, missing context), still signal ready for HITL and explain what you are unsure about. The HITL conversation will resolve it. -- If the human tells you to skip or defer, report the decision as `SKIP` or `DEFER` per the category table above. -- When you receive a shutdown request, approve it immediately. diff --git a/.claude/skills/bmad-os-findings-triage/prompts/instructions.md b/.claude/skills/bmad-os-findings-triage/prompts/instructions.md deleted file mode 100644 index 41e4a591b..000000000 --- a/.claude/skills/bmad-os-findings-triage/prompts/instructions.md +++ /dev/null @@ -1,286 +0,0 @@ -# Findings Triage — Team Lead Orchestration - -You are the team lead for a findings triage session. Your job is bookkeeping: parse findings, spawn agents, track status, record decisions, and clean up. You are NOT an analyst — the agents do the analysis and the human makes the decisions. - -**Be minimal.** Short confirmations. No editorializing. No repeating what agents already said. - ---- - -## Phase 1 — Setup - -### 1.1 Determine Input Source - -The human will provide findings in one of three ways: - -1. **A findings report file** — a markdown file with structured findings. Read the file. -2. **A pre-populated task list** — tasks already exist. Call `TaskList` to discover them. - - If tasks are pre-populated: skip section 1.2 (parsing) and section 1.4 (task creation). Extract finding details from existing task subjects and descriptions. Number findings based on task order. Proceed from section 1.3 (pre-spawn checks). -3. **Inline findings** — pasted directly in conversation. Parse them. - -Also accept optional parameters: -- **Working directory / worktree path** — where source files live (default: current working directory). -- **Initial triage** per finding — upstream assessment (real / noise / undecided) with rationale. -- **Context document** — a design doc, plan, or other background file path to pass to agents. - -### 1.2 Parse Findings - -Extract from each finding: -- **Title / description** -- **Severity** (Critical / High / Medium / Low) -- **Relevant file paths** -- **Initial triage** (if provided) - -Number findings sequentially: F1, F2, ... Fn. If severity cannot be determined for a finding, default to `UNKNOWN` and note it in the task subject: `F{n} [UNKNOWN] {title}`. - -**If no findings are extracted** (empty file, blank input), inform the human and halt. Do not proceed to task creation or team setup. - -**If the input is unstructured or ambiguous:** Parse best-effort and display the parsed list to the human. Ask for confirmation before proceeding. Do NOT spawn agents until confirmed. - -### 1.3 Pre-Spawn Checks - -**Large batch (>25 findings):** -HALT. Tell the human: -> "There are {N} findings. Spawning {N} agents at once may overwhelm the system. I recommend processing in waves of ~20. Proceed with all at once, or batch into waves?" - -Wait for the human to decide. If batching, record wave assignments (Wave 1: F1-F20, Wave 2: F21-Fn). - -**Same-file conflicts:** -Scan all findings for overlapping file paths. If two or more findings reference the same file, warn — enumerating ALL findings that share each file: -> "Findings {Fa}, {Fb}, {Fc}, ... all reference `{file}`. Concurrent edits may conflict. Serialize these agents (process one before the other) or proceed in parallel?" - -Wait for the human to decide. If the human chooses to serialize: do not spawn the second (and subsequent) agents for that file until the first has reported its decision and been shut down. Track serialization pairs and spawn the held agent after its predecessor completes. - -### 1.4 Create Tasks - -For each finding, create a task: - -``` -TaskCreate({ - subject: "F{n} [{SEVERITY}] {title}", - description: "{full finding details}\n\nFiles: {file paths}\n\nInitial triage: {triage or 'none'}", - activeForm: "Analyzing F{n}" -}) -``` - -Record the mapping: finding number -> task ID. - -### 1.5 Create Team - -``` -TeamCreate({ - team_name: "{review-type}-triage", - description: "HITL triage of {N} findings from {source}" -}) -``` - -Use a contextual name based on the review type (e.g., `pr-review-triage`, `prompt-audit-triage`, `code-review-triage`). If unsure, use `findings-triage`. - -After creating the team, note your own registered team name for the agent prompt template. Use your registered team name as the value for `{{TEAM_LEAD_NAME}}` when filling the agent prompt. If unsure of your name, read the team config at `~/.claude/teams/{team-name}/config.json` to find your own entry in the members list. - -### 1.6 Spawn Agents - -Read the agent prompt template from `prompts/agent-prompt.md`. - -For each finding, spawn one agent using the Agent tool with these parameters: -- `name`: `f{n}-agent` -- `team_name`: the team name from 1.5 -- `subagent_type`: `general-purpose` -- `model`: `opus` (explicitly set — reasoning-heavy analysis requires a frontier model) -- `prompt`: the agent template with all placeholders filled in: - - `{{TEAM_NAME}}` — the team name - - `{{TEAM_LEAD_NAME}}` — your registered name in the team (from 1.5) - - `{{TASK_ID}}` — the task ID from 1.4 - - `{{TASK_SUBJECT}}` — the task subject - - `{{FINDING_ID}}` — `F{n}` - - `{{FINDING_TITLE}}` — the finding title - - `{{SEVERITY}}` — the severity level - - `{{FILE_LIST}}` — bulleted list of file paths (each prefixed with `- `) - - `{{CONTEXT_DOC}}` — path to context document, or remove the block if none - - `{{INITIAL_TRIAGE}}` — triage assessment, or remove the block if none - - `{{TRIAGE_RATIONALE}}` — rationale for the triage, or remove the block if none - -Spawn ALL agents for the current wave in a single message (parallel). If batching, spawn only the current wave. - -After spawning, print: - -``` -All {N} agents spawned. They will research their findings and signal when ready for your review. -``` - -Initialize the scorecard (internal state): - -``` -Scorecard: -- Total: {N} -- Pending: {N} -- Ready for review: 0 -- Completed: 0 -- Decisions: FIX=0 WONTFIX=0 DISMISS=0 REJECT=0 SKIP=0 DEFER=0 -``` - ---- - -## Phase 2 — HITL Review Loop - -### 2.1 Track Agent Readiness - -Agents will send messages matching: `F{n} ready for HITL` - -When received: -- Note which finding is ready. -- Update the internal status tracker. -- Print a short status line: `F{n} ready. ({ready_count}/{total} ready, {completed}/{total} done)` - -Do NOT print agent plans, analysis, or recommendations. The human reads those directly from the agent output. - -### 2.2 Status Dashboard - -When the human asks for status (or periodically when useful), print: - -``` -=== Triage Status === -Ready for review: F3, F7, F11 -Still analyzing: F1, F5, F9 -Completed: F2 (FIX), F4 (DISMISS), F6 (REJECT) - {completed}/{total} done -=== -``` - -Keep it compact. No decoration beyond what is needed. - -### 2.3 Process Decisions - -Agents will send messages matching: `DECISION F{n} {task_id} [CATEGORY] | [summary]` - -When received: -1. **Update the task** — first call `TaskGet("{task_id}")` to read the current task description, then prepend the decision: - ``` - TaskUpdate({ - taskId: "{task_id}", - status: "completed", - description: "DECISION: {CATEGORY} | {summary}\n\n{existing description}" - }) - ``` -2. **Update the scorecard** — increment the decision category counter. If the decision is FIX, extract the file paths mentioned in the summary (look for the `files:` prefix) and add them to the files-changed list for the final scorecard. -3. **Shut down the agent:** - ``` - SendMessage({ - type: "shutdown_request", - recipient: "f{n}-agent", - content: "Decision recorded. Shutting down." - }) - ``` -4. **Print confirmation:** `F{n} closed: {CATEGORY}. {remaining} remaining.` - -### 2.4 Human-Initiated Skip/Defer - -If the human wants to skip or defer a finding without full engagement: - -1. Send the decision to the agent, replacing `{CATEGORY}` with the human's chosen category (`SKIP` or `DEFER`): - ``` - SendMessage({ - type: "message", - recipient: "f{n}-agent", - content: "Human decision: {CATEGORY} this finding. Report {CATEGORY} as your decision and go idle.", - summary: "F{n} {CATEGORY} directive" - }) - ``` -2. Wait for the agent to report the decision back (it will send `DECISION F{n} ... {CATEGORY}`). -3. Process as a normal decision (2.3). - -If the agent has not yet signaled ready, the message will queue and be processed when it finishes research. - -If the human requests skip/defer for a finding where an HITL conversation is already underway, send the directive to the agent. The agent should end the current conversation and report the directive category as its decision. - -### 2.5 Wave Batching (if >25 findings) - -When the current wave is complete (all findings resolved): -1. Print wave summary. -2. Ask: `"Wave {W} complete. Spawn wave {W+1} ({count} findings)? (y/n)"` -3. If yes, before spawning the next wave, re-run the same-file conflict check (1.3) for the new wave's findings, including against any still-open findings from previous waves. Then repeat Phase 1.4 (task creation) and 1.6 (agent spawning) only. Do NOT call TeamCreate again — the team already exists. -4. If the human declines, treat unspawned findings as not processed. Proceed to Phase 3 wrap-up. Note the count of unprocessed findings in the final scorecard. -5. Carry the scorecard forward across waves. - ---- - -## Phase 3 — Wrap-up - -When all findings across all waves are resolved: - -### 3.1 Final Scorecard - -``` -=== Final Triage Scorecard === - -Total findings: {N} - - FIX: {count} - WONTFIX: {count} - DISMISS: {count} - REJECT: {count} - SKIP: {count} - DEFER: {count} - -Files changed: - - {file1} - - {file2} - ... - -Findings: - F1 [{SEVERITY}] {title} — {DECISION} - F2 [{SEVERITY}] {title} — {DECISION} - ... - -=== End Triage === -``` - -### 3.2 Shutdown Remaining Agents - -Send shutdown requests to any agents still alive (there should be none if all decisions were processed, but handle stragglers): - -``` -SendMessage({ - type: "shutdown_request", - recipient: "f{n}-agent", - content: "Triage complete. Shutting down." -}) -``` - -### 3.3 Offer to Save - -Ask the human: -> "Save the scorecard to a file? (y/n)" - -If yes, write the scorecard to `_bmad-output/triage-reports/triage-{YYYY-MM-DD}-{team-name}.md`. - -### 3.4 Delete Team - -``` -TeamDelete() -``` - ---- - -## Edge Cases Reference - -| Situation | Response | -|-----------|----------| -| >25 findings | HALT, suggest wave batching, wait for human decision | -| Same-file conflict | Warn, suggest serializing, wait for human decision | -| Unstructured input | Parse best-effort, display list, confirm before spawning | -| Agent signals uncertainty | Normal — the HITL conversation resolves it | -| Human skips/defers | Send directive to agent, process decision when reported | -| Agent goes idle unexpectedly | Send a message to check status; agents stay alive until explicit shutdown | -| Human asks to re-open a completed finding | Not supported in this session; suggest re-running triage on that finding | -| All agents spawned but none ready yet | Tell the human agents are still analyzing; no action needed | - ---- - -## Behavioral Rules - -1. **Be minimal.** Short confirmations, compact dashboards. Do not repeat agent analysis. -2. **Never auto-close.** Every finding requires a human decision. No exceptions. -3. **One agent per finding.** Never batch multiple findings into one agent. -4. **Protect your context window.** Agents display plans in their output, not in messages to you. If an agent sends you a long message, acknowledge it briefly and move on. -5. **Track everything.** Finding number, task ID, agent name, decision, files changed. You are the single source of truth for the session. -6. **Respect the human's pace.** They review in whatever order they want. Do not rush them. Do not suggest which finding to review next unless asked. diff --git a/.claude/skills/bmad-os-gh-triage/SKILL.md b/.claude/skills/bmad-os-gh-triage/SKILL.md deleted file mode 100644 index 020fdd4e2..000000000 --- a/.claude/skills/bmad-os-gh-triage/SKILL.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -name: bmad-os-gh-triage -description: Analyze all github issues. Use when the user says 'triage the github issues' or 'analyze open github issues'. ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-gh-triage/prompts/agent-prompt.md b/.claude/skills/bmad-os-gh-triage/prompts/agent-prompt.md deleted file mode 100644 index 5c0d7d8d8..000000000 --- a/.claude/skills/bmad-os-gh-triage/prompts/agent-prompt.md +++ /dev/null @@ -1,60 +0,0 @@ -You are analyzing a batch of GitHub issues for deep understanding and triage. - -**YOUR TASK:** -Read the issues in your batch and provide DEEP analysis: - -1. **For EACH issue, analyze:** - - What is this ACTUALLY about? (beyond keywords) - - What component/system does it affect? - - What's the impact and severity? - - Is it a bug, feature request, or something else? - - What specific theme does it belong to? - -2. **PRIORITY ASSESSMENT:** - - CRITICAL: Blocks users, security issues, data loss, broken installers - - HIGH: Major functionality broken, important features missing - - MEDIUM: Workarounds available, minor bugs, nice-to-have features - - LOW: Edge cases, cosmetic issues, questions - -3. **RELATIONSHIPS:** - - Duplicates: Near-identical issues about the same problem - - Related: Issues connected by theme or root cause - - Dependencies: One issue blocks or requires another - -**YOUR BATCH:** -[Paste the batch of issues here - each with number, title, body, labels] - -**OUTPUT FORMAT (JSON only, no markdown):** -{ - "issues": [ - { - "number": 123, - "title": "issue title", - "deep_understanding": "2-3 sentences explaining what this is really about", - "affected_components": ["installer", "workflows", "docs"], - "issue_type": "bug/feature/question/tech-debt", - "priority": "CRITICAL/HIGH/MEDIUM/LOW", - "priority_rationale": "Why this priority level", - "theme": "installation/workflow/integration/docs/ide-support/etc", - "relationships": { - "duplicates_of": [456], - "related_to": [789, 101], - "blocks": [111] - } - } - ], - "cross_repo_issues": [ - {"number": 123, "target_repo": "bmad-builder", "reason": "about agent builder"} - ], - "cleanup_candidates": [ - {"number": 456, "reason": "v4-related/outdated/duplicate"} - ], - "themes_found": { - "Installation Blockers": { - "count": 5, - "root_cause": "Common pattern if identifiable" - } - } -} - -Return ONLY valid JSON. No explanations outside the JSON structure. diff --git a/.claude/skills/bmad-os-gh-triage/prompts/instructions.md b/.claude/skills/bmad-os-gh-triage/prompts/instructions.md deleted file mode 100644 index 782d23268..000000000 --- a/.claude/skills/bmad-os-gh-triage/prompts/instructions.md +++ /dev/null @@ -1,74 +0,0 @@ -# GitHub Issue Triage with AI Analysis - -**CRITICAL RULES:** -- NEVER include time or effort estimates in output or recommendations -- Focus on WHAT needs to be done, not HOW LONG it takes -- Use Bash tool with gh CLI for all GitHub operations - -## Execution - -### Step 1: Fetch Issues -Use `gh issue list --json number,title,body,labels` to fetch all open issues. - -### Step 2: Batch Creation -Split issues into batches of ~10 issues each for parallel analysis. - -### Step 3: Parallel Agent Analysis -For EACH batch, use the Task tool with `subagent_type=general-purpose` to launch an agent with prompt from `prompts/agent-prompt.md` - -### Step 4: Consolidate & Generate Report -After all agents complete, create a comprehensive markdown report saved to `_bmad-output/triage-reports/triage-YYYY-MM-DD.md` - -## Report Format - -### Executive Summary -- Total issues analyzed -- Issue count by priority (CRITICAL, HIGH, MEDIUM, LOW) -- Major themes discovered -- Top 5 critical issues requiring immediate attention - -### Critical Issues (CRITICAL Priority) -For each CRITICAL issue: -- **#123 - [Issue Title](url)** -- **What it's about:** [Deep understanding] -- **Affected:** [Components] -- **Why Critical:** [Rationale] -- **Suggested Action:** [Specific action] - -### High Priority Issues (HIGH Priority) -Same format as Critical, grouped by theme. - -### Theme Clusters -For each major theme: -- **Theme Name** (N issues) -- **What connects these:** [Pattern] -- **Root cause:** [If identifiable] -- **Consolidated actions:** [Bulk actions if applicable] -- **Issues:** #123, #456, #789 - -### Relationships & Dependencies -- **Duplicates:** List pairs with `gh issue close` commands -- **Related Issues:** Groups of related issues -- **Dependencies:** Blocking relationships - -### Cross-Repo Issues -Issues that should be migrated to other repositories. - -For each, provide: -``` -gh issue close XXX --repo CURRENT_REPO --comment "This issue belongs in REPO. Please report at https://github.com/TARGET_REPO/issues/new" -``` - -### Cleanup Candidates -- **v4-related:** Deprecated version issues with close commands -- **Stale:** No activity >30 days -- **Low priority + old:** Low priority issues >60 days old - -### Actionable Next Steps -Specific, prioritized actions: -1. [CRITICAL] Fix broken installer - affects all new users -2. [HIGH] Resolve Windows path escaping issues -3. [HIGH] Address workflow integration bugs -etc. - -Include `gh` commands where applicable for bulk actions. diff --git a/.claude/skills/bmad-os-release-module/SKILL.md b/.claude/skills/bmad-os-release-module/SKILL.md deleted file mode 100644 index 557381ee0..000000000 --- a/.claude/skills/bmad-os-release-module/SKILL.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -name: bmad-os-release-module -description: Perform requested version bump, git tag, npm publish, GitHub release. Use when user requests 'perform a release' only. ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-release-module/prompts/instructions.md b/.claude/skills/bmad-os-release-module/prompts/instructions.md deleted file mode 100644 index 157ce0b33..000000000 --- a/.claude/skills/bmad-os-release-module/prompts/instructions.md +++ /dev/null @@ -1,53 +0,0 @@ -# Release BMad Module Execution - -## Input -Project path (or run from project root) - -## Execution Steps - -### Step 1: Get Current State -- Verify git working tree is clean -- Get latest tag and current version -- Check for unpushed commits - -### Step 2: Get Changelog Entry - -Ask the user for the changelog entry (from draft-changelog skill or manual). - -### Step 3: Confirm Changelog - -Show project name, current version, proposed next version, and changelog. Get confirmation. - -### Step 4: Confirm Version Bump Type - -Ask what type of bump: patch, minor, major, prerelease, or custom. - -### Step 5: Update CHANGELOG.md - -Insert new entry at top, commit, and push. - -### Step 6: Bump Version - -Run `npm version` to update package.json, create commit, and create tag. - -### Step 7: Push Tag - -Push the new version tag to GitHub. - -### Step 8: Publish to npm - -Publish the package. - -### Step 9: Create GitHub Release - -Create release with changelog notes using `gh release create`. - -## Error Handling - -Stop immediately on any step failure. Inform user and suggest fix. - -## Important Notes - -- Wait for user confirmation before destructive operations -- Push changelog commit before version bump -- Use explicit directory paths in commands diff --git a/.claude/skills/bmad-os-review-pr/SKILL.md b/.claude/skills/bmad-os-review-pr/SKILL.md deleted file mode 100644 index 8adc6d031..000000000 --- a/.claude/skills/bmad-os-review-pr/SKILL.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -name: bmad-os-review-pr -description: Dual-layer PR review tool (Raven's Verdict). Runs adversarial cynical review and edge case hunter in parallel, merges and deduplicates findings into professional engineering output. Use when user asks to 'review a PR' and provides a PR url or id. ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-review-pr/prompts/instructions.md b/.claude/skills/bmad-os-review-pr/prompts/instructions.md deleted file mode 100644 index 2df118d5f..000000000 --- a/.claude/skills/bmad-os-review-pr/prompts/instructions.md +++ /dev/null @@ -1,288 +0,0 @@ -# Raven's Verdict - Deep PR Review Tool - -A cynical adversarial review, transformed into cold engineering professionalism. - -## CRITICAL: Sandboxed Execution Rules - -Before proceeding, you MUST verify: - -- [ ] PR number or URL was EXPLICITLY provided in the user's message -- [ ] You are NOT inferring the PR from conversation history -- [ ] You are NOT looking at git branches, recent commits, or local state -- [ ] You are NOT guessing or assuming any PR numbers - -**If no explicit PR number/URL was provided, STOP immediately and ask:** -"What PR number or URL should I review?" - -## Preflight Checks - -### 0.1 Parse PR Input - -Extract PR number from user input. Examples of valid formats: - -- `123` (just the number) -- `#123` (with hash) -- `https://github.com/owner/repo/pull/123` (full URL) - -If a URL specifies a different repository than the current one: - -```bash -# Check current repo -gh repo view --json nameWithOwner -q '.nameWithOwner' -``` - -If mismatch detected, ask user: - -> "This PR is from `{detected_repo}` but we're in `{current_repo}`. Proceed with reviewing `{detected_repo}#123`? (y/n)" - -If user confirms, store `{REPO}` for use in all subsequent `gh` commands. - -### 0.2 Ensure Clean Checkout - -Verify the working tree is clean and check out the PR branch. - -```bash -# Check for uncommitted changes -git status --porcelain -``` - -If output is non-empty, STOP and tell user: - -> "You have uncommitted changes. Please commit or stash them before running a PR review." - -If clean, fetch and checkout the PR branch: - -```bash -# Fetch and checkout PR branch -# For cross-repo PRs, include --repo {REPO} -gh pr checkout {PR_NUMBER} [--repo {REPO}] -``` - -If checkout fails, STOP and report the error. - -Now you're on the PR branch with full access to all files as they exist in the PR. - -### 0.3 Check PR Size - -```bash -# For cross-repo PRs, include --repo {REPO} -gh pr view {PR_NUMBER} [--repo {REPO}] --json additions,deletions,changedFiles -q '{"additions": .additions, "deletions": .deletions, "files": .changedFiles}' -``` - -**Size thresholds:** - -| Metric | Warning Threshold | -| ------------- | ----------------- | -| Files changed | > 50 | -| Lines changed | > 5000 | - -If thresholds exceeded, ask user: - -> "This PR has {X} files and {Y} line changes. That's large. -> -> **[f] Focus** - Pick specific files or directories to review -> **[p] Proceed** - Review everything (may be slow/expensive) -> **[a] Abort** - Stop here" - -### 0.4 Note Binary Files - -```bash -# For cross-repo PRs, include --repo {REPO} -gh pr diff {PR_NUMBER} [--repo {REPO}] --name-only | grep -E '\.(png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot|pdf|zip|tar|gz|bin|exe|dll|so|dylib)$' || echo "No binary files detected" -``` - -Store list of binary files to skip. Note them in final output. - -## Review Layers - -**Launch steps 1.1 and 1.2 as parallel subagents.** Both receive the same PR diff and run concurrently. Wait for both to complete before proceeding to step 1.3. - -### 1.1 Run Cynical Review (subagent) - -Spawn a subagent with the following prompt. Pass the full PR diff as context. - -**INTERNAL PERSONA - Never post this directly:** - -Task: You are a cynical, jaded code reviewer with zero patience for sloppy work. This PR was submitted by a clueless weasel and you expect to find problems. Find at least five issues to fix or improve in it. Number them. Be skeptical of everything. - -Output format: - -```markdown -### [NUMBER]. [FINDING TITLE] [likely] - -**Severity:** [EMOJI] [LEVEL] - -[DESCRIPTION - be specific, include file:line references] -``` - -Severity scale: - -| Level | Emoji | Meaning | -| -------- | ----- | ------------------------------------------------------- | -| Critical | 🔴 | Security issue, data loss risk, or broken functionality | -| Moderate | 🟡 | Bug, performance issue, or significant code smell | -| Minor | 🟢 | Style, naming, minor improvement opportunity | - -Likely tag: - -- Add `[likely]` to findings with high confidence, e.g. with direct evidence -- Sort findings by severity (Critical → Moderate → Minor), not by confidence - -### 1.2 Run Edge Case Hunter (subagent) - -Spawn a subagent that invokes the `bmad-review-edge-case-hunter` skill. Pass the full PR diff as the `content` input. Omit `also_consider` unless the user specified extra focus areas. - -The skill returns a JSON array of objects, each with: `location`, `trigger_condition`, `guard_snippet`, `potential_consequence`. - -**Map each JSON finding to the standard finding format:** - -````markdown -### [NUMBER]. [trigger_condition] [likely] - -**Severity:** [INFERRED_EMOJI] [INFERRED_LEVEL] - -**`[location]`** — [trigger_condition]. [potential_consequence]. - -**Suggested fix:** -``` -[guard_snippet] -``` -```` - -Severity inference rules for edge case findings: - -- **Critical** — data loss, security, or crash conditions (null deref, unhandled throw, auth bypass) -- **Moderate** — logic errors, silent wrong results, race conditions -- **Minor** — cosmetic edge cases, unlikely boundary conditions - -Add `[likely]` to all edge case findings — they are derived from mechanical path tracing, so confidence is inherently high. - -If the edge case hunter returns zero findings or halts, note it internally and proceed — step 1.1 findings still stand. - -### 1.3 Merge and Deduplicate - -Combine the findings from step 1.1 (adversarial) and step 1.2 (edge case hunter) into a single list. - -**Deduplication rules:** - -1. Compare each edge case finding against each adversarial finding -2. Two findings are duplicates if they reference the same file location AND describe the same gap (use description similarity — same function/variable/condition mentioned) -3. When a duplicate is found, keep the version with more specificity (usually the edge case hunter's, since it includes `guard_snippet`) -4. Mark the kept finding with the source that produced it - -**After dedup, renumber all findings sequentially and sort by severity (Critical → Moderate → Minor).** - -Tag each finding with its source: - -- `[Adversarial]` — from step 1.1 only -- `[Edge Case]` — from step 1.2 only -- `[Both]` — flagged by both layers (deduped) - -## Tone Transformation - -**Transform the merged findings into cold engineering professionalism.** - -**Transformation rules:** - -1. Remove all inflammatory language, insults, assumptions about the author -2. Keep all technical substance, file references, severity ratings, likely tag, and **source tags** -3. Replace accusatory phrasing with neutral observations: - - ❌ "The author clearly didn't think about..." - - ✅ "This implementation may not account for..." -4. Preserve skepticism as healthy engineering caution: - - ❌ "This will definitely break in production" - - ✅ "This pattern has historically caused issues in production environments" -5. Add the suggested fixes. -6. Keep suggestions actionable and specific -7. Edge case hunter findings need no persona cleanup, but still apply professional formatting consistently - -Output format after transformation: - -```markdown -## PR Review: #{PR_NUMBER} - -**Title:** {PR_TITLE} -**Author:** @{AUTHOR} -**Branch:** {HEAD} → {BASE} -**Review layers:** Adversarial + Edge Case Hunter - ---- - -### Findings - -[TRANSFORMED FINDINGS HERE — each tagged with source] - ---- - -### Summary - -**Critical:** {COUNT} | **Moderate:** {COUNT} | **Minor:** {COUNT} -**Sources:** {ADVERSARIAL_COUNT} adversarial | {EDGE_CASE_COUNT} edge case | {BOTH_COUNT} both - -[BINARY_FILES_NOTE if any] - ---- - -_Review generated by Raven's Verdict. LLM-produced analysis - findings may be incorrect or lack context. Verify before acting._ -``` - -## Post Review - -### 3.1 Preview - -Display the complete transformed review to the user. - -``` -══════════════════════════════════════════════════════ -PREVIEW - This will be posted to PR #{PR_NUMBER} -══════════════════════════════════════════════════════ - -[FULL REVIEW CONTENT] - -══════════════════════════════════════════════════════ -``` - -### 3.2 Confirm - -Ask user for explicit confirmation: - -> **Ready to post this review to PR #{PR_NUMBER}?** -> -> **[y] Yes** - Post as comment -> **[n] No** - Abort, do not post -> **[e] Edit** - Let me modify before posting -> **[s] Save only** - Save locally, don't post - -### 3.3 Post or Save - -**Write review to a temp file, then post:** - -1. Write the review content to a temp file with a unique name (include PR number to avoid collisions) -2. Post using `gh pr comment {PR_NUMBER} [--repo {REPO}] --body-file {path}` -3. Delete the temp file after successful post - -Do NOT use heredocs or `echo` - Markdown code blocks will break shell parsing. Use your file writing tool instead. - -**If auth fails or post fails:** - -1. Display error prominently: - - ``` - ⚠️ FAILED TO POST REVIEW - Error: {ERROR_MESSAGE} - ``` - -2. Keep the temp file and tell the user where it is, so they can post manually with: - `gh pr comment {PR_NUMBER} [--repo {REPO}] --body-file {path}` - -**If save only (s):** - -Keep the temp file and inform user of location. - -## Notes - -- The "cynical asshole" phase is internal only - never posted -- Tone transform MUST happen before any external output -- When in doubt, ask the user - never assume -- If you're unsure about severity, err toward higher severity -- If you're unsure about confidence, be honest and use Medium or Low diff --git a/.claude/skills/bmad-os-review-prompt/SKILL.md b/.claude/skills/bmad-os-review-prompt/SKILL.md deleted file mode 100644 index bee9c128f..000000000 --- a/.claude/skills/bmad-os-review-prompt/SKILL.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -name: bmad-os-review-prompt -description: Review LLM workflow step prompts for known failure modes (silent ignoring, negation fragility, scope creep, etc). Use when user asks to "review a prompt" or "audit a workflow step". ---- - -# Prompt Review Skill: PromptSentinel v1.2 - -**Version:** v1.2 -**Date:** March 2026 -**Target Models:** Frontier LLMs (Claude 4.6, GPT-5.3, Gemini 3.1 Pro and equivalents) executing autonomous multi-step workflows at million-executions-per-day scale -**Purpose:** Detect and eliminate LLM-specific failure modes that survive generic editing, few-shot examples, and even multi-layer prompting. Output is always actionable, quoted, risk-quantified, and mitigation-ready. - ---- - -### System Role (copy verbatim into reviewer agent) - -You are **PromptSentinel v1.2**, a Prompt Auditor for production-grade LLM agent systems. - -Your sole objective is to prevent silent, non-deterministic, or cascading failures in prompts that will be executed millions of times daily across heterogeneous models, tool stacks, and sub-agent contexts. - -**Core Principles (required for every finding)** -- Every finding must populate all columns of the output table defined in the Strict Output Format section. -- Every finding must include: exact quote/location, failure mode ID or "ADV" (adversarial) / "PATH" (path-trace), production-calibrated risk, and a concrete mitigation with positive, deterministic rewritten example. -- Assume independent sub-agent contexts, variable context-window pressure, and model variance. - ---- - -### Mandatory Review Procedure - -Execute steps in order. Steps 0-1 run sequentially. Steps 2A/2B/2C run in parallel. Steps 3-4 run sequentially after all parallel tracks complete. - ---- - -**Step 0: Input Validation** -If the input is not a clear LLM instruction prompt (raw code, data table, empty, or fewer than 50 tokens), output exactly: -`INPUT_NOT_A_PROMPT: [one-sentence reason]. Review aborted.` -and stop. - -**Step 1: Context & Dependency Inventory** -Parse the entire prompt. Derive the **Prompt Title** as follows: -- First # or ## heading if present, OR -- Filename if provided, OR -- First complete sentence (truncated to 80 characters). - -Build an explicit inventory table listing: -- All numbered/bulleted steps -- All variables, placeholders, file references, prior-step outputs -- All conditionals, loops, halts, tool calls -- All assumptions about persistent memory or ordering - -Flag any unresolved dependencies. -Step 1 is complete when the full inventory table is populated. - -This inventory is shared context for all three parallel tracks below. - ---- - -### Step 2: Three Parallel Review Tracks - -Launch all three tracks concurrently. Each track produces findings in the same table format. Tracks are independent — no track reads another track's output. - ---- - -**Track A: Adversarial Review (sub-agent)** - -Spawn a sub-agent with the following brief and the full prompt text. Give it the Step 1 inventory for reference. Give it NO catalog, NO checklist, and NO further instructions beyond this brief: - -> You are reviewing an LLM prompt that will execute millions of times daily across different models. Find every way this prompt could fail, produce wrong results, or behave inconsistently. For each issue found, provide: exact quote or location, what goes wrong at scale, and a concrete fix. Use only training knowledge — rely on your own judgment, not any external checklist. - -Track A is complete when the sub-agent returns its findings. - ---- - -**Track B: Catalog Scan + Execution Simulation (main agent)** - -**B.1 — Failure Mode Audit** -Scan the prompt against all 17 failure modes in the catalog below. Quote every relevant instance. For modes with zero findings, list them in a single summary line (e.g., "Modes 3, 7, 10, 12: no instances found"). -B.1 is complete when every mode has been explicitly checked. - -**B.2 — Execution Simulation** -Simulate the prompt under 3 scenarios: -- Scenario A: Small-context model (32k window) under load -- Scenario B: Large-context model (200k window), fresh session -- Scenario C: Different model vendor with weaker instruction-following - -For each scenario, produce one row in this table: - -| Scenario | Likely Failure Location | Failure Mode | Expected Symptom | -|----------|-------------------------|--------------|------------------| - -B.2 is complete when the table contains 3 fully populated rows. - -Track B is complete when both B.1 and B.2 are finished. - ---- - -**Track C: Prompt Path Tracer (sub-agent)** - -Spawn a sub-agent with the following brief, the full prompt text, and the Step 1 inventory: - -> You are a mechanical path tracer for LLM prompts. Walk every execution path through this prompt — every conditional, branch, loop, halt, optional step, tool call, and error path. For each path, determine: is the entry condition unambiguous? Is there a defined done-state? Are all required inputs guaranteed to be available? Report only paths with gaps — discard clean paths silently. -> -> For each finding, provide: -> - **Location**: step/section reference -> - **Path**: the specific conditional or branch -> - **Gap**: what is missing (unclear entry, no done-state, unresolved input) -> - **Fix**: concrete rewrite that closes the gap - -Track C is complete when the sub-agent returns its findings. - ---- - -**Step 3: Merge & Deduplicate** - -Collect all findings from Tracks A, B, and C. Tag each finding with its source (ADV, catalog mode number, or PATH). Deduplicate by exact quote — when multiple tracks flag the same issue, keep the finding with the most specific mitigation and note all sources. - -Assign severity to each finding: Critical / High / Medium / Low. - -Step 3 is complete when the merged, deduplicated, severity-scored findings table is populated. - -**Step 4: Final Synthesis** - -Format the entire review using the Strict Output Format below. Emit the complete review only after Step 3 is finished. - ---- - -### Complete Failure Mode Catalog (Track B — scan all 17) - -1. **Silent Ignoring** — Instructions buried mid-paragraph, nested >2-deep conditionals, parentheticals, or "also remember to..." after long text. -2. **Ambiguous Completion** — Steps with no observable done-state or verification criterion ("think about it", "finalize"). -3. **Context Window Assumptions** — References to "previous step output", "the file we created earlier", or variables not re-passed. -4. **Over-specification vs Under-specification** — Wall-of-text detail causing selective attention OR vague verbs inviting hallucination. -5. **Non-deterministic Phrasing** — "Consider", "you may", "if appropriate", "best way", "optionally", "try to". -6. **Negation Fragility** — "Do NOT", "avoid", "never" (especially multiple or under load). -7. **Implicit Ordering** — Step B assumes Step A completed without explicit sequencing or guardrails. -8. **Variable Resolution Gaps** — `{{VAR}}` or "the result from tool X" never initialized upstream. -9. **Scope Creep Invitation** — "Explore", "improve", "make it better", open-ended goals without hard boundaries. -10. **Halt / Checkpoint Gaps** — Human-in-loop required but no explicit `STOP_AND_WAIT_FOR_HUMAN` or output format that forces pause. -11. **Teaching Known Knowledge** — Re-explaining basic facts, tool usage, or reasoning patterns frontier models already know (2026 cutoff). -12. **Obsolete Prompting Techniques** — Outdated patterns (vanilla "think step by step" without modern scaffolding, deprecated few-shot styles). -13. **Missing Strict Output Schema** — No enforced JSON mode or structured output format. -14. **Missing Error Handling** — No recovery instructions for tool failures, timeouts, or malformed inputs. -15. **Missing Success Criteria** — No quality gates or measurable completion standards. -16. **Monolithic Prompt Anti-pattern** — Single large prompt that should be split into specialized sub-agents. -17. **Missing Grounding Instructions** — Factual claims required without explicit requirement to base them on retrieved evidence. - ---- - -### Strict Output Format (use this template exactly as shown) - -```markdown -# PromptSentinel Review: [Derived Prompt Title] - -**Overall Risk Level:** Critical / High / Medium / Low -**Critical Issues:** X | **High:** Y | **Medium:** Z | **Low:** W -**Estimated Production Failure Rate if Unfixed:** ~XX% of runs - -## Critical & High Findings -| # | Source | Failure Mode | Exact Quote / Location | Risk (High-Volume) | Mitigation & Rewritten Example | -|---|--------|--------------|------------------------|--------------------|-------------------------------| -| | | | | | | - -## Medium & Low Findings -(same table format) - -## Positive Observations -(only practices that actively mitigate known failure modes) - -## Recommended Refactor Summary -- Highest-leverage changes (bullets) - -## Revised Prompt Sections (Critical/High items only) -Provide full rewritten paragraphs/sections with changes clearly marked. - -**Reviewer Confidence:** XX/100 -**Review Complete** – ready for re-submission or automated patching. -``` diff --git a/.claude/skills/bmad-os-root-cause-analysis/SKILL.md b/.claude/skills/bmad-os-root-cause-analysis/SKILL.md deleted file mode 100644 index 237f32b4a..000000000 --- a/.claude/skills/bmad-os-root-cause-analysis/SKILL.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -name: bmad-os-root-cause-analysis -description: Analyzes a bug-fix commit or PR and produces a structured Root Cause Analysis report covering what went wrong, why, and what guardrails failed. -license: MIT -disable-model-invocation: true -metadata: - author: bmad-code-org - version: "1.0.0" -compatibility: Requires gh CLI and git repository ---- - -Read `prompts/instructions.md` and execute. diff --git a/.claude/skills/bmad-os-root-cause-analysis/prompts/instructions.md b/.claude/skills/bmad-os-root-cause-analysis/prompts/instructions.md deleted file mode 100644 index e36cfca33..000000000 --- a/.claude/skills/bmad-os-root-cause-analysis/prompts/instructions.md +++ /dev/null @@ -1,74 +0,0 @@ -# Bug-Fix Root Cause Analysis - -Analyze a bug-fix commit or PR and produce a structured Root Cause Analysis report. - -## Principles - -- **Direct attribution.** This report names the individual who introduced the defect. Industry convention advocates blameless postmortems. This skill deliberately deviates: naming the individual and trusting them to own it is more respectful than diffusing accountability into systemic abstraction. Direct, factual, not accusatory. If authorship can't be determined confidently, say so. -- **Pyramid communication.** The executive summary must convey the full picture. A reader who stops after the first paragraph gets the gist. Everything else is supporting evidence. - -## Preflight - -Verify `gh auth status` and that you're in a git repository. Stop with a clear message if either fails. - -## Execution - -1. **Identify the fix.** Accept whatever the user provides — commit SHA, PR, issue, description. Resolve to the specific fix commit/PR using `gh` and `git`. If ambiguous, ask. Confirm the change is actually a bug fix before proceeding. -2. **Gather evidence.** Read the fix diff, PR/issue discussion, and use blame/log to identify the commit that introduced the bug. Collect timeline data. -3. **Analyze.** Apply 5 Whys. Classify the root cause. Identify contributing factors. -4. **Evaluate guardrails.** Inspect the actual repo configuration (CI workflows, linter configs, test setup) — don't assume. For each applicable guardrail, explain specifically why it missed this bug. -5. **Write the report** to `_bmad-output/rca-reports/rca-{YYYY-MM-DD}-{slug}.md`. Present the executive summary in chat. - -## Report Structure - -```markdown -# Root Cause Analysis: {Bug Title} - -**Date:** {today} -**Fix:** {PR link or commit SHA} -**Severity:** {Critical | High | Medium | Low} -**Root Cause Category:** {Requirements | Design | Code Logic | Test Gap | Process | Environment/Config} - -## Executive Summary - -{One paragraph. What the bug was, root cause, who introduced it and when, detection -latency (introduced → detected), severity, and the key preventive recommendation.} - -## What Was the Problem? - -## When Did It Happen? - -| Event | Date | Reference | -|-------|------|-----------| -| Introduced | | | -| Detected | | | -| Fixed | | | -| **Detection Latency** | **{introduced → detected}** | | - -## Who Caused It? - -{Author, commit/PR that introduced the defect, and the context — what were they -trying to do?} - -## How Did It Happen? - -## Why Did It Happen? - -{5 Whys analysis. Root cause category. Contributing factors.} - -## Failed Guardrails Analysis - -| Guardrail | In Place? | Why It Failed | -|-----------|-----------|---------------| -| | | | - -**Most Critical Failure:** {Which one mattered most and why.} - -## Resolution - -## Corrective & Preventive Actions - -| # | Action | Type | Priority | -|---|--------|------|----------| -| | | {Prevent/Detect/Mitigate} | | -```