bmad-method 6.10.1-next.2 → 6.10.1-next.21

package/src/core-skills/bmad-index-docs/SKILL.md

@@ -1,66 +0,0 @@
----
-name: bmad-index-docs
-description: 'Generates or updates an index.md to reference all docs in the folder. Use if user requests to create or update an index of all files in a specific folder'
----
-
-# Index Docs
-
-**Goal:** Generate or update an index.md to reference all docs in a target folder.
-
-
-## EXECUTION
-
-### Step 1: Scan Directory
-
-- List all files and subdirectories in the target location
-
-### Step 2: Group Content
-
-- Organize files by type, purpose, or subdirectory
-
-### Step 3: Generate Descriptions
-
-- Read each file to understand its actual purpose and create brief (3-10 word) descriptions based on the content, not just the filename
-
-### Step 4: Create/Update Index
-
-- Write or update index.md with organized file listings
-
-
-## OUTPUT FORMAT
-
-```markdown
-# Directory Index
-
-## Files
-
-- **[filename.ext](./filename.ext)** - Brief description
-- **[another-file.ext](./another-file.ext)** - Brief description
-
-## Subdirectories
-
-### subfolder/
-
-- **[file1.ext](./subfolder/file1.ext)** - Brief description
-- **[file2.ext](./subfolder/file2.ext)** - Brief description
-
-### another-folder/
-
-- **[file3.ext](./another-folder/file3.ext)** - Brief description
-```
-
-
-## HALT CONDITIONS
-
-- HALT if target directory does not exist or is inaccessible
-- HALT if user does not have write permissions to create index.md
-
-
-## VALIDATION
-
-- Use relative paths starting with ./
-- Group similar files together
-- Read file contents to generate accurate descriptions - don't guess from filenames
-- Keep descriptions concise but informative (3-10 words)
-- Sort alphabetically within groups
-- Skip hidden files (starting with .) unless specified

package/src/core-skills/bmad-review-adversarial-general/SKILL.md

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

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

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

package/src/core-skills/bmad-review-edge-case-hunter/references/deletion-check.md

@@ -1,14 +0,0 @@
-# Deletion Check
-
-Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code. Subordinate to the edge-case pass; findings are usually few or none.
-
-For each chunk of removed or replaced code (ignore pure renames and whitespace), ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired? Add a finding for any resulting regression, orphaned reference, or newly-dead code. Skip anything already covered by your edge-case findings.
-
-Append each finding to the same JSON array as the edge-case findings, with the four standard fields plus:
-
-- `kind`: `"deletion"`
-- `confidence`: `"high"`, `"medium"`, or `"low"` — these are inferences; rate them
-
-For a deletion finding the standard fields read as: `location` = the removed item; `trigger_condition` = the behavior or contract it enforced; `guard_snippet` = where or how to re-establish it; `potential_consequence` = the regression or orphan.
-
-Add nothing if nothing qualifies.

package/src/core-skills/bmad-shard-doc/SKILL.md

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