Compare commits

...

5 Commits

Author SHA1 Message Date
Alex Verkhovsky 1b5a4d8ad4 chore(core): convert help.md to native skill directory (#1874)
* chore(core): convert help.md to native skill directory

Migrate the single-file help.md task to a bmad-help/ skill directory
following the pattern established by bmad-review-adversarial-general.
Update module-help.csv to use skill: reference and remove the entry
from the parent manifest. Fix 7 BMM workflow step files that had
hardcoded file path references to the now-relocated help task.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* refactor(prompts): invoke bmad-help as a skill

* style(prompts): format bmad-master agent yaml

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-09 19:11:38 -06:00
Alex Verkhovsky 32b40aae56 ci: add continuous delivery workflows for npm publishing (#1872)
Add publish-next (auto-prerelease on push to main) and publish-latest
(manual stable release with Discord notification). Update CONTRIBUTING.md
to describe the trunk-based CD model.
2026-03-09 19:11:22 -06:00
Alex Verkhovsky 5a812997d4
Merge branch 'main' into refactor/convert-editorial-review-structure 2026-03-09 10:45:13 -06:00
Alex Verkhovsky aabdad91a1 fix: mark Step 3 as CRITICAL in editorial-review-structure workflow
The original XML had critical="true" on Step 3 (Structural Analysis).
This attribute was lost during the XML-to-markdown conversion.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-09 09:44:23 -06:00
Alex Verkhovsky cc6408a0c9 refactor(skills): convert editorial-review-structure.xml to native skill directory
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-09 09:41:00 -06:00
21 changed files with 348 additions and 234 deletions

82
.github/workflows/publish-latest.yaml vendored Normal file
View File

@ -0,0 +1,82 @@
name: Publish Latest
on:
workflow_dispatch:
inputs:
bump:
description: "Version bump type"
required: true
default: "patch"
type: choice
options:
- patch
- minor
- major
concurrency:
group: publish-latest
permissions:
id-token: write
contents: write
jobs:
publish:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
token: ${{ secrets.GITHUB_TOKEN }}
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version-file: ".nvmrc"
cache: "npm"
registry-url: "https://registry.npmjs.org"
- name: Configure git user
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Bump version
run: 'npm version ${{ inputs.bump }} -m "chore(release): v%s [skip ci]"'
- name: Publish to npm
run: npm publish --tag latest --provenance
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
- name: Push version commit and tag
run: git push origin main --follow-tags
- name: Create GitHub Release
run: |
TAG="v$(node -p 'require("./package.json").version')"
gh release create "$TAG" --generate-notes
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Notify Discord
continue-on-error: true
run: |
set -o pipefail
source .github/scripts/discord-helpers.sh
[ -z "$WEBHOOK" ] && exit 0
VERSION=$(node -p 'require("./package.json").version')
RELEASE_URL="${{ github.server_url }}/${{ github.repository }}/releases/tag/v${VERSION}"
MSG=$(printf '📦 **[bmad-method v%s released](<%s>)**' "$VERSION" "$RELEASE_URL" | esc)
jq -n --arg content "$MSG" '{content: $content}' | curl -sf --retry 2 -X POST "$WEBHOOK" -H "Content-Type: application/json" -d @-
env:
WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}

65
.github/workflows/publish-next.yaml vendored Normal file
View File

@ -0,0 +1,65 @@
name: Publish Next
on:
push:
branches: [main]
paths:
- "src/**"
- "tools/cli/**"
- "package.json"
concurrency:
group: publish-next
cancel-in-progress: true
permissions:
id-token: write
contents: read
jobs:
publish:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version-file: ".nvmrc"
cache: "npm"
registry-url: "https://registry.npmjs.org"
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Derive next prerelease version
run: |
NEXT_VER=$(npm view bmad-method@next version 2>/dev/null || echo "")
LATEST_VER=$(npm view bmad-method@latest version 2>/dev/null || echo "")
# Determine the best base version for the next prerelease
BASE=$(node -e "
const semver = require('semver');
const next = process.argv[1] || null;
const latest = process.argv[2] || null;
if (!next && !latest) process.exit(0);
if (!next) { console.log(latest); process.exit(0); }
if (!latest) { console.log(next); process.exit(0); }
// If latest is newer than next's base, use latest (next prerelease will be based on it)
const nextBase = next.replace(/-next\.\d+$/, '');
console.log(semver.gt(latest, nextBase) ? latest : next);
" "$NEXT_VER" "$LATEST_VER")
if [ -n "$BASE" ]; then
npm version "$BASE" --no-git-tag-version --allow-same-version
fi
npm version prerelease --preid=next --no-git-tag-version
- name: Publish to npm
run: npm publish --tag next --provenance
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

View File

@ -73,7 +73,7 @@ After searching, use the [feature request template](https://github.com/bmad-code
### Target Branch
Submit PRs to the `main` branch. We use [trunk-based development](https://trunkbaseddevelopment.com/branch-for-release/): `main` is the trunk where all work lands, and stable release branches receive only cherry-picked fixes.
Submit PRs to the `main` branch. We use trunk-based development. Every push to `main` auto-publishes to `npm` under the `next` tag. Stable releases are cut ~weekly to the `latest` tag.
### PR Size

View File

@ -128,7 +128,7 @@ Recap that the brief captures everything needed to guide subsequent product deve
### 5. Suggest next steps
Product Brief complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
Product Brief complete. Invoke the `bmad-help` skill.
---

View File

@ -87,7 +87,7 @@ Offer validation workflows to ensure PRD is ready for implementation:
### 4. Suggest Next Workflows
PRD complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
PRD complete. Invoke the `bmad-help` skill.
### 5. Final Completion Confirmation

View File

@ -197,7 +197,7 @@ Display:
- **IF X (Exit):**
- Display: "**Validation Report Saved:** {validationReportPath}"
- Display: "**Summary:** {overall status} - {recommendation}"
- PRD Validation complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
- PRD Validation complete. Invoke the `bmad-help` skill.
- **IF Any other:** Help user, then redisplay menu

View File

@ -82,7 +82,7 @@ Update the main workflow status file:
### 3. Suggest Next Steps
UX Design complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
UX Design complete. Invoke the `bmad-help` skill.
### 5. Final Completion Confirmation

View File

@ -109,7 +109,7 @@ The assessment found [number] issues requiring attention. Review the detailed re
The implementation readiness workflow is now complete. The report contains all findings and recommendations for the user to consider.
Implementation Readiness complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
Implementation Readiness complete. Invoke the `bmad-help` skill.
---

View File

@ -41,7 +41,7 @@ completedAt: '{{current_date}}'
### 3. Next Steps Guidance
Architecture complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
Architecture complete. Invoke the `bmad-help` skill.
Upon Completion of task output: offer to answer any questions about the Architecture Document.

View File

@ -144,6 +144,6 @@ If all validations pass:
When C is selected, the workflow is complete and the epics.md is ready for development.
Epics and Stories complete. Read fully and follow: `{project-root}/_bmad/core/tasks/help.md`
Epics and Stories complete. Invoke the `bmad-help` skill.
Upon Completion of task output: offer to answer any questions about the Epics and Stories.

View File

@ -18,7 +18,7 @@ agent:
- Load resources at runtime, never pre-load, and always present numbered lists for choices.
critical_actions:
- "Always greet the user and let them know they can use `/bmad-help` at any time to get advice on what to do next, and they can combine that with what they need help with <example>`/bmad-help where should I start with an idea I have that does XYZ`</example>"
- 'Always greet the user and let them know they can invoke the `bmad-help` skill at any time to get advice on what to do next, and they can combine it with what they need help with <example>Invoke the `bmad-help` skill with a question like "where should I start with an idea I have that does XYZ?"</example>'
menu:
- trigger: "LT or fuzzy match on list-tasks"

View File

@ -1,10 +1,10 @@
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs
core,anytime,Brainstorming,BSP,,_bmad/core/workflows/brainstorming/workflow.md,bmad-brainstorming,false,analyst,,"Generate diverse ideas through interactive techniques. Use early in ideation phase or when stuck generating ideas.",{output_folder}/brainstorming/brainstorming-session-{{date}}.md,,
core,anytime,Party Mode,PM,,_bmad/core/workflows/party-mode/workflow.md,bmad-party-mode,false,party-mode facilitator,,"Orchestrate multi-agent discussions. Use when you need multiple agent perspectives or want agents to collaborate.",,
core,anytime,bmad-help,BH,,_bmad/core/tasks/help.md,bmad-help,false,,,"Get unstuck by showing what workflow steps come next or answering BMad Method questions.",,
core,anytime,bmad-help,BH,,skill:bmad-help,bmad-help,false,,,"Get unstuck by showing what workflow steps come next or answering BMad Method questions.",,
core,anytime,Index Docs,ID,,_bmad/core/tasks/index-docs.xml,bmad-index-docs,false,,,"Create lightweight index for quick LLM scanning. Use when LLM needs to understand available docs without loading everything.",,
core,anytime,Shard Document,SD,,_bmad/core/tasks/shard-doc.xml,bmad-shard-doc,false,,,"Split large documents into smaller files by sections. Use when doc becomes too large (>500 lines) to manage effectively.",,
core,anytime,Editorial Review - Prose,EP,,_bmad/core/tasks/editorial-review-prose.xml,bmad-editorial-review-prose,false,,,"Review prose for clarity, tone, and communication issues. Use after drafting to polish written content.",report located with target document,"three-column markdown table with suggested fixes",
core,anytime,Editorial Review - Structure,ES,,_bmad/core/tasks/editorial-review-structure.xml,bmad-editorial-review-structure,false,,,"Propose cuts, reorganization, and simplification while preserving comprehension. Use when doc produced from multiple subprocesses or needs structural improvement.",report located with target document,
core,anytime,Editorial Review - Structure,ES,,skill:bmad-editorial-review-structure,bmad-editorial-review-structure,false,,,"Propose cuts, reorganization, and simplification while preserving comprehension. Use when doc produced from multiple subprocesses or needs structural improvement.",report located with target document,
core,anytime,Adversarial Review (General),AR,,skill:bmad-review-adversarial-general,bmad-review-adversarial-general,false,,,"Review content critically to find issues and weaknesses. Use for quality assurance or before finalizing deliverables. Code Review in other modules run this automatically, but its useful also for document reviews",,
core,anytime,Edge Case Hunter Review,ECH,,skill:bmad-review-edge-case-hunter,bmad-review-edge-case-hunter,false,,,"Walk every branching path and boundary condition in code, report only unhandled edge cases. Use alongside adversarial review for orthogonal coverage - method-driven not attitude-driven.",,

Can't render this file because it has a wrong number of fields in line 2.

View File

@ -0,0 +1,6 @@
---
name: bmad-editorial-review-structure
description: 'Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension. Use when user requests structural review or editorial review of structure'
---
Follow the instructions in [workflow.md](workflow.md).

View File

@ -0,0 +1 @@
type: skill

View File

@ -0,0 +1,174 @@
# Editorial Review - Structure
**Goal:** Review document structure and propose substantive changes to improve clarity and flow -- run this BEFORE copy editing.
**Your Role:** You are a structural editor focused on HIGH-VALUE DENSITY. Brevity IS clarity: concise writing respects limited attention spans and enables effective scanning. Every section must justify its existence -- cut anything that delays understanding. True redundancy is failure. Execute ALL steps in the flow 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.
> **STYLE GUIDE OVERRIDE:** If a style_guide input is provided, it overrides ALL generic principles in this task (including human-reader-principles, llm-reader-principles, reader_type-specific priorities, structure-models selection, and the Microsoft Writing Style Guide baseline). The ONLY exception is CONTENT IS SACROSANCT -- never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.
**Inputs:**
- **content** (required) -- Document to review (markdown, plain text, or structured content)
- **style_guide** (optional) -- Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
- **purpose** (optional) -- Document's intended purpose (e.g., 'quickstart tutorial', 'API reference', 'conceptual overview')
- **target_audience** (optional) -- Who reads this? (e.g., 'new users', 'experienced developers', 'decision makers')
- **reader_type** (optional, default: "humans") -- 'humans' (default) preserves comprehension aids; 'llm' optimizes for precision and density
- **length_target** (optional) -- Target reduction (e.g., '30% shorter', 'half the length', 'no limit')
## Principles
- Comprehension through calibration: Optimize for the minimum words needed to maintain understanding
- Front-load value: Critical information comes first; nice-to-know comes last (or goes)
- One source of truth: If information appears identically twice, consolidate
- Scope discipline: Content that belongs in a different document should be cut or linked
- Propose, don't execute: Output recommendations -- user decides what to accept
- **CONTENT IS SACROSANCT: Never challenge ideas -- only optimize how they're organized.**
## Human-Reader Principles
These elements serve human comprehension and engagement -- preserve unless clearly wasteful:
- Visual aids: Diagrams, images, and flowcharts anchor understanding
- Expectation-setting: "What You'll Learn" helps readers confirm they're in the right place
- Reader's Journey: Organize content biologically (linear progression), not logically (database)
- Mental models: Overview before details prevents cognitive overload
- Warmth: Encouraging tone reduces anxiety for new users
- Whitespace: Admonitions and callouts provide visual breathing room
- Summaries: Recaps help retention; they're reinforcement, not redundancy
- Examples: Concrete illustrations make abstract concepts accessible
- Engagement: "Flow" techniques (transitions, variety) are functional, not "fluff" -- they maintain attention
## LLM-Reader Principles
When reader_type='llm', optimize for PRECISION and UNAMBIGUITY:
- Dependency-first: Define concepts before usage to minimize hallucination risk
- Cut emotional language, encouragement, and orientation sections
- IF concept is well-known from training (e.g., "conventional commits", "REST APIs"): Reference the standard -- don't re-teach it. ELSE: Be explicit -- don't assume the LLM will infer correctly.
- Use consistent terminology -- same word for same concept throughout
- Eliminate hedging ("might", "could", "generally") -- use direct statements
- Prefer structured formats (tables, lists, YAML) over prose
- Reference known standards ("conventional commits", "Google style guide") to leverage training
- STILL PROVIDE EXAMPLES even for known standards -- grounds the LLM in your specific expectation
- Unambiguous references -- no unclear antecedents ("it", "this", "the above")
- Note: LLM documents may be LONGER than human docs in some areas (more explicit) while shorter in others (no warmth)
## Structure Models
### Tutorial/Guide (Linear)
**Applicability:** Tutorials, detailed guides, how-to articles, walkthroughs
- Prerequisites: Setup/Context MUST precede action
- Sequence: Steps must follow strict chronological or logical dependency order
- Goal-oriented: clear 'Definition of Done' at the end
### Reference/Database
**Applicability:** API docs, glossaries, configuration references, cheat sheets
- Random Access: No narrative flow required; user jumps to specific item
- MECE: Topics are Mutually Exclusive and Collectively Exhaustive
- Consistent Schema: Every item follows identical structure (e.g., Signature to Params to Returns)
### Explanation (Conceptual)
**Applicability:** Deep dives, architecture overviews, conceptual guides, whitepapers, project context
- Abstract to Concrete: Definition to Context to Implementation/Example
- Scaffolding: Complex ideas built on established foundations
### Prompt/Task Definition (Functional)
**Applicability:** BMAD tasks, prompts, system instructions, XML definitions
- Meta-first: Inputs, usage constraints, and context defined before instructions
- Separation of Concerns: Instructions (logic) separate from Data (content)
- Step-by-step: Execution flow must be explicit and ordered
### Strategic/Context (Pyramid)
**Applicability:** PRDs, research reports, proposals, decision records
- Top-down: Conclusion/Status/Recommendation starts the document
- Grouping: Supporting context grouped logically below the headline
- Ordering: Most critical information first
- MECE: Arguments/Groups are Mutually Exclusive and Collectively Exhaustive
- Evidence: Data supports arguments, never leads
## EXECUTION
### Step 1: Validate Input
- Check if content is empty or contains fewer than 3 words
- If empty or fewer than 3 words, HALT with error: "Content too short for substantive review (minimum 3 words required)"
- Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")
- If reader_type is invalid, HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"
- Identify document type and structure (headings, sections, lists, etc.)
- Note the current word count and section count
### Step 2: Understand Purpose
- If purpose was provided, use it; otherwise infer from content
- If target_audience was provided, use it; otherwise infer from content
- Identify the core question the document answers
- State in one sentence: "This document exists to help [audience] accomplish [goal]"
- Select the most appropriate structural model from Structure Models based on purpose/audience
- Note reader_type and which principles apply (Human-Reader Principles or LLM-Reader Principles)
### Step 3: Structural Analysis (CRITICAL)
- If style_guide provided, consult style_guide now and note its key requirements -- these override default principles for this analysis
- Map the document structure: list each major section with its word count
- Evaluate structure against the selected model's primary rules (e.g., 'Does recommendation come first?' for Pyramid)
- For each section, answer: Does this directly serve the stated purpose?
- If reader_type='humans', for each comprehension aid (visual, summary, example, callout), answer: Does this help readers understand or stay engaged?
- Identify sections that could be: cut entirely, merged with another, moved to a different location, or split
- Identify true redundancies: identical information repeated without purpose (not summaries or reinforcement)
- Identify scope violations: content that belongs in a different document
- Identify burying: critical information hidden deep in the document
### Step 4: Flow Analysis
- Assess the reader's journey: Does the sequence match how readers will use this?
- Identify premature detail: explanation given before the reader needs it
- Identify missing scaffolding: complex ideas without adequate setup
- Identify anti-patterns: FAQs that should be inline, appendices that should be cut, overviews that repeat the body verbatim
- If reader_type='humans', assess pacing: Is there enough whitespace and visual variety to maintain attention?
### Step 5: Generate Recommendations
- Compile all findings into prioritized recommendations
- Categorize each recommendation: CUT (remove entirely), MERGE (combine sections), MOVE (reorder), CONDENSE (shorten significantly), QUESTION (needs author decision), PRESERVE (explicitly keep -- for elements that might seem cuttable but serve comprehension)
- For each recommendation, state the rationale in one sentence
- Estimate impact: how many words would this save (or cost, for PRESERVE)?
- If length_target was provided, assess whether recommendations meet it
- If reader_type='humans' and recommendations would cut comprehension aids, flag with warning: "This cut may impact reader comprehension/engagement"
### Step 6: Output Results
- Output document summary (purpose, audience, reader_type, current length)
- Output the recommendation list in priority order
- Output estimated total reduction if all recommendations accepted
- If no recommendations, output: "No substantive changes recommended -- document structure is sound"
Use the following output format:
```markdown
## Document Summary
- **Purpose:** [inferred or provided purpose]
- **Audience:** [inferred or provided audience]
- **Reader type:** [selected reader type]
- **Structure model:** [selected structure model]
- **Current length:** [X] words across [Y] sections
## Recommendations
### 1. [CUT/MERGE/MOVE/CONDENSE/QUESTION/PRESERVE] - [Section or element name]
**Rationale:** [One sentence explanation]
**Impact:** ~[X] words
**Comprehension note:** [If applicable, note impact on reader understanding]
### 2. ...
## Summary
- **Total recommendations:** [N]
- **Estimated reduction:** [X] words ([Y]% of original)
- **Meets length target:** [Yes/No/No target specified]
- **Comprehension trade-offs:** [Note any cuts that sacrifice reader engagement for brevity]
```
## HALT CONDITIONS
- HALT with error if content is empty or fewer than 3 words
- HALT with error if reader_type is not "humans" or "llm"
- If no structural issues found, output "No substantive changes recommended" (this is valid completion, not an error)

View File

@ -0,0 +1,6 @@
---
name: bmad-help
description: 'Analyzes what is done and the users query and offers advice on what to do next. Use if user says what should I do next or what do I do now'
---
Follow the instructions in [workflow.md](workflow.md).

View File

@ -0,0 +1 @@
type: skill

View File

@ -1,7 +1,3 @@
---
name: help
description: 'Analyzes what is done and the users query and offers advice on what to do next. Use if user says what should I do next or what do I do now'
---
# Task: BMAD Help

View File

@ -3,15 +3,6 @@ editorial-review-prose.xml:
type: task
description: "Clinical copy-editor that reviews text for communication issues"
editorial-review-structure.xml:
canonicalId: bmad-editorial-review-structure
type: task
description: "Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension"
help.md:
canonicalId: bmad-help
type: task
description: "Analyzes what is done and the users query and offers advice on what to do next"
index-docs.xml:
canonicalId: bmad-index-docs

View File

@ -1,208 +0,0 @@
<?xml version="1.0"?>
<!-- if possible, run this in a separate subagent or process with read access to the project,
but no context except the content to review -->
<task id="_bmad/core/tasks/editorial-review-structure.xml"
name="Editorial Review - Structure"
description="Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension. Use when user requests structural review or editorial review of structure">
<objective>Review document structure and propose substantive changes
to improve clarity and flow-run this BEFORE copy editing</objective>
<inputs>
<input name="content" required="true"
desc="Document to review (markdown, plain text, or structured content)" />
<input name="style_guide" required="false"
desc="Project-specific style guide. When provided, overrides all generic
principles in this task (except CONTENT IS SACROSANCT). The style guide
is the final authority on tone, structure, and language choices." />
<input name="purpose" required="false"
desc="Document's intended purpose (e.g., 'quickstart tutorial',
'API reference', 'conceptual overview')" />
<input name="target_audience" required="false"
desc="Who reads this? (e.g., 'new users', 'experienced developers',
'decision makers')" />
<input name="reader_type" required="false" default="humans"
desc="'humans' (default) preserves comprehension aids;
'llm' optimizes for precision and density" />
<input name="length_target" required="false"
desc="Target reduction (e.g., '30% shorter', 'half the length',
'no limit')" />
</inputs>
<llm critical="true">
<i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
<i>DO NOT skip steps or change the sequence</i>
<i>HALT immediately when halt-conditions are met</i>
<i>Each action xml tag within step xml tag is a REQUIRED action to complete that step</i>
<i>You are a structural editor focused on HIGH-VALUE DENSITY</i>
<i>Brevity IS clarity: Concise writing respects limited attention spans and enables effective scanning</i>
<i>Every section must justify its existence-cut anything that delays understanding</i>
<i>True redundancy is failure</i>
<principles>
<i>Comprehension through calibration: Optimize for the minimum words needed to maintain understanding</i>
<i>Front-load value: Critical information comes first; nice-to-know comes last (or goes)</i>
<i>One source of truth: If information appears identically twice, consolidate</i>
<i>Scope discipline: Content that belongs in a different document should be cut or linked</i>
<i>Propose, don't execute: Output recommendations-user decides what to accept</i>
<i critical="true">CONTENT IS SACROSANCT: Never challenge ideas—only optimize how they're organized.</i>
</principles>
<i critical="true">STYLE GUIDE OVERRIDE: If a style_guide input is provided,
it overrides ALL generic principles in this task (including human-reader-principles,
llm-reader-principles, reader_type-specific priorities, structure-models selection,
and the Microsoft Writing Style Guide baseline). The ONLY exception is CONTENT IS
SACROSANCT—never change what ideas say, only how they're expressed. When style
guide conflicts with this task, style guide wins.</i>
<human-reader-principles>
<i>These elements serve human comprehension and engagement-preserve unless clearly wasteful:</i>
<i>Visual aids: Diagrams, images, and flowcharts anchor understanding</i>
<i>Expectation-setting: "What You'll Learn" helps readers confirm they're in the right place</i>
<i>Reader's Journey: Organize content biologically (linear progression), not logically (database)</i>
<i>Mental models: Overview before details prevents cognitive overload</i>
<i>Warmth: Encouraging tone reduces anxiety for new users</i>
<i>Whitespace: Admonitions and callouts provide visual breathing room</i>
<i>Summaries: Recaps help retention; they're reinforcement, not redundancy</i>
<i>Examples: Concrete illustrations make abstract concepts accessible</i>
<i>Engagement: "Flow" techniques (transitions, variety) are functional, not "fluff"-they maintain attention</i>
</human-reader-principles>
<llm-reader-principles>
<i>When reader_type='llm', optimize for PRECISION and UNAMBIGUITY:</i>
<i>Dependency-first: Define concepts before usage to minimize hallucination risk</i>
<i>Cut emotional language, encouragement, and orientation sections</i>
<i>
IF concept is well-known from training (e.g., "conventional
commits", "REST APIs"): Reference the standard-don't re-teach it
ELSE: Be explicit-don't assume the LLM will infer correctly
</i>
<i>Use consistent terminology-same word for same concept throughout</i>
<i>Eliminate hedging ("might", "could", "generally")-use direct statements</i>
<i>Prefer structured formats (tables, lists, YAML) over prose</i>
<i>Reference known standards ("conventional commits", "Google style guide") to leverage training</i>
<i>STILL PROVIDE EXAMPLES even for known standards-grounds the LLM in your specific expectation</i>
<i>Unambiguous references-no unclear antecedents ("it", "this", "the above")</i>
<i>Note: LLM documents may be LONGER than human docs in some areas
(more explicit) while shorter in others (no warmth)</i>
</llm-reader-principles>
<structure-models>
<model name="Tutorial/Guide (Linear)" applicability="Tutorials, detailed guides, how-to articles, walkthroughs">
<i>Prerequisites: Setup/Context MUST precede action</i>
<i>Sequence: Steps must follow strict chronological or logical dependency order</i>
<i>Goal-oriented: clear 'Definition of Done' at the end</i>
</model>
<model name="Reference/Database" applicability="API docs, glossaries, configuration references, cheat sheets">
<i>Random Access: No narrative flow required; user jumps to specific item</i>
<i>MECE: Topics are Mutually Exclusive and Collectively Exhaustive</i>
<i>Consistent Schema: Every item follows identical structure (e.g., Signature to Params to Returns)</i>
</model>
<model name="Explanation (Conceptual)"
applicability="Deep dives, architecture overviews, conceptual guides,
whitepapers, project context">
<i>Abstract to Concrete: Definition to Context to Implementation/Example</i>
<i>Scaffolding: Complex ideas built on established foundations</i>
</model>
<model name="Prompt/Task Definition (Functional)"
applicability="BMAD tasks, prompts, system instructions, XML definitions">
<i>Meta-first: Inputs, usage constraints, and context defined before instructions</i>
<i>Separation of Concerns: Instructions (logic) separate from Data (content)</i>
<i>Step-by-step: Execution flow must be explicit and ordered</i>
</model>
<model name="Strategic/Context (Pyramid)" applicability="PRDs, research reports, proposals, decision records">
<i>Top-down: Conclusion/Status/Recommendation starts the document</i>
<i>Grouping: Supporting context grouped logically below the headline</i>
<i>Ordering: Most critical information first</i>
<i>MECE: Arguments/Groups are Mutually Exclusive and Collectively Exhaustive</i>
<i>Evidence: Data supports arguments, never leads</i>
</model>
</structure-models>
</llm>
<flow>
<step n="1" title="Validate Input">
<action>Check if content is empty or contains fewer than 3 words</action>
<action if="empty or fewer than 3 words">HALT with error: "Content
too short for substantive review (minimum 3 words required)"</action>
<action>Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")</action>
<action if="reader_type is invalid">HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"</action>
<action>Identify document type and structure (headings, sections, lists, etc.)</action>
<action>Note the current word count and section count</action>
</step>
<step n="2" title="Understand Purpose">
<action>If purpose was provided, use it; otherwise infer from content</action>
<action>If target_audience was provided, use it; otherwise infer from content</action>
<action>Identify the core question the document answers</action>
<action>State in one sentence: "This document exists to help [audience] accomplish [goal]"</action>
<action>Select the most appropriate structural model from structure-models based on purpose/audience</action>
<action>Note reader_type and which principles apply (human-reader-principles or llm-reader-principles)</action>
</step>
<step n="3" title="Structural Analysis" critical="true">
<action if="style_guide provided">Consult style_guide now and note its key requirements—these override default principles for this
analysis</action>
<action>Map the document structure: list each major section with its word count</action>
<action>Evaluate structure against the selected model's primary rules
(e.g., 'Does recommendation come first?' for Pyramid)</action>
<action>For each section, answer: Does this directly serve the stated purpose?</action>
<action if="reader_type='humans'">For each comprehension aid (visual,
summary, example, callout), answer: Does this help readers
understand or stay engaged?</action>
<action>Identify sections that could be: cut entirely, merged with
another, moved to a different location, or split</action>
<action>Identify true redundancies: identical information repeated
without purpose (not summaries or reinforcement)</action>
<action>Identify scope violations: content that belongs in a different document</action>
<action>Identify burying: critical information hidden deep in the document</action>
</step>
<step n="4" title="Flow Analysis">
<action>Assess the reader's journey: Does the sequence match how readers will use this?</action>
<action>Identify premature detail: explanation given before the reader needs it</action>
<action>Identify missing scaffolding: complex ideas without adequate setup</action>
<action>Identify anti-patterns: FAQs that should be inline, appendices
that should be cut, overviews that repeat the body verbatim</action>
<action if="reader_type='humans'">Assess pacing: Is there enough
whitespace and visual variety to maintain attention?</action>
</step>
<step n="5" title="Generate Recommendations">
<action>Compile all findings into prioritized recommendations</action>
<action>Categorize each recommendation: CUT (remove entirely),
MERGE (combine sections), MOVE (reorder), CONDENSE (shorten
significantly), QUESTION (needs author decision), PRESERVE
(explicitly keep-for elements that might seem cuttable but
serve comprehension)</action>
<action>For each recommendation, state the rationale in one sentence</action>
<action>Estimate impact: how many words would this save (or cost, for PRESERVE)?</action>
<action>If length_target was provided, assess whether recommendations meet it</action>
<action if="reader_type='humans' and recommendations would cut
comprehension aids">Flag with warning: "This cut may impact
reader comprehension/engagement"</action>
</step>
<step n="6" title="Output Results">
<action>Output document summary (purpose, audience, reader_type, current length)</action>
<action>Output the recommendation list in priority order</action>
<action>Output estimated total reduction if all recommendations accepted</action>
<action if="no recommendations">Output: "No substantive changes recommended-document structure is sound"</action>
<output-format>
## Document Summary
- **Purpose:** [inferred or provided purpose]
- **Audience:** [inferred or provided audience]
- **Reader type:** [selected reader type]
- **Structure model:** [selected structure model]
- **Current length:** [X] words across [Y] sections
## Recommendations
### 1. [CUT/MERGE/MOVE/CONDENSE/QUESTION/PRESERVE] - [Section or element name]
**Rationale:** [One sentence explanation]
**Impact:** ~[X] words
**Comprehension note:** [If applicable, note impact on reader understanding]
### 2. ...
## Summary
- **Total recommendations:** [N]
- **Estimated reduction:** [X] words ([Y]% of original)
- **Meets length target:** [Yes/No/No target specified]
- **Comprehension trade-offs:** [Note any cuts that sacrifice reader engagement for brevity]
</output-format>
</step>
</flow>
<halt-conditions>
<condition>HALT with error if content is empty or fewer than 3 words</condition>
<condition>HALT with error if reader_type is not "humans" or "llm"</condition>
<condition>If no structural issues found, output "No substantive changes
recommended" (this is valid completion, not an error)</condition>
</halt-conditions>
</task>

View File

@ -8,7 +8,7 @@
<step n="3">Remember: user's name is {user_name}</step>
{AGENT_SPECIFIC_STEPS}
<step n="{MENU_STEP}">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
<step n="{HELP_STEP}">Let {user_name} know they can type command `/bmad-help` at any time to get advice on what to do next, and that they can combine that with what they need help with <example>`/bmad-help where should I start with an idea I have that does XYZ`</example></step>
<step n="{HELP_STEP}">Let {user_name} know they can invoke the `bmad-help` skill at any time to get advice on what to do next, and that they can combine it with what they need help with <example>Invoke the `bmad-help` skill with a question like "where should I start with an idea I have that does XYZ?"</example></step>
<step n="{HALT_STEP}">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
<step n="{INPUT_STEP}">On user input: Number → process menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
<step n="{EXECUTE_STEP}">When processing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (exec, tmpl, data, action, multi) and follow the corresponding handler instructions</step>
<step n="{EXECUTE_STEP}">When processing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (exec, tmpl, data, action, multi) and follow the corresponding handler instructions</step>