Conversation
|
This pull request is too large for Augment to review. The PR exceeds the maximum size limit of 100000 tokens (approximately 400000 characters) for automated code review. Please consider breaking this PR into smaller, more focused changes. |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 10 minutes and 49 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (25)
WalkthroughThis pull request introduces a comprehensive update to the BMad Builder ecosystem, including a new module-builder skill for planning and scaffolding BMad modules, revised path conventions for configuration and project-scope paths, updated CSV schemas for module help documentation, and extensive documentation improvements across setup flows, configuration management, and builder capabilities. Changes
Sequence Diagram(s)The changes introduce multiple new features with complex multi-component interactions that meet the criteria for visualization: sequenceDiagram
participant User
participant ModuleBuilder as Module Builder Skill
participant IM as Ideate Module<br/>(IM)
participant CM as Create Module<br/>(CM)
participant ScaffoldScript as scaffold-setup-skill.py
participant VM as Validate Module<br/>(VM)
participant ValidateScript as validate-module.py
User->>ModuleBuilder: Request: Plan New Module
ModuleBuilder->>IM: Route to Ideate Module
IM->>IM: Check for existing plan
IM->>User: Interactive planning session
User->>IM: Define module architecture
IM->>User: Generate module.yaml plan
User->>User: Build individual skills
User->>ModuleBuilder: Request: Create Module
ModuleBuilder->>CM: Route to Create Module
CM->>CM: Discover skills from folder
CM->>CM: Ingest module plan (optional)
CM->>CM: Generate module.yaml & CSV
CM->>ScaffoldScript: Run scaffold-setup-skill.py
ScaffoldScript->>ScaffoldScript: Copy template
ScaffoldScript->>ScaffoldScript: Substitute frontmatter
ScaffoldScript->>ScaffoldScript: Write module files
ScaffoldScript->>User: Setup skill folder created
User->>ModuleBuilder: Request: Validate Module
ModuleBuilder->>VM: Route to Validate Module
VM->>ValidateScript: Run validate-module.py
ValidateScript->>ValidateScript: Parse module.yaml
ValidateScript->>ValidateScript: Validate CSV schema
ValidateScript->>ValidateScript: Check skill references
ValidateScript->>ValidateScript: Verify field completeness
ValidateScript->>User: Validation report (pass/fail)
sequenceDiagram
participant User
participant WorkflowBuilder as Workflow Builder Skill
participant OriginalSkill as Original Skill<br/>(Input)
participant BuildProcess as Build Process<br/>(Headless)
participant RebuiltSkill as Rebuilt Skill<br/>(Output)
participant AnalysisEngine as Convert Analysis<br/>Engine
participant ReportGenerator as generate-convert-report.py
participant HTMLReport as HTML Report<br/>(Browser)
User->>WorkflowBuilder: --convert <path-or-url>
WorkflowBuilder->>OriginalSkill: Capture content
OriginalSkill->>AnalysisEngine: Store original metrics
AnalysisEngine->>BuildProcess: Invoke (headless)
BuildProcess->>BuildProcess: Auto-answer discovery
BuildProcess->>BuildProcess: Rebuild from outcomes
BuildProcess->>RebuiltSkill: Generate new skill
RebuiltSkill->>AnalysisEngine: Calculate metrics
AnalysisEngine->>AnalysisEngine: Categorize changes
AnalysisEngine->>ReportGenerator: Pass analysis JSON
ReportGenerator->>ReportGenerator: Measure both skills
ReportGenerator->>ReportGenerator: Calculate reductions
ReportGenerator->>ReportGenerator: Generate HTML
ReportGenerator->>HTMLReport: Open in browser
HTMLReport->>User: Display comparison
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
…O specs
Addresses issues found in test run:
- Module identity (name, code, description) locked down in phase 1 before
skill names are written, preventing expensive find-and-replace later
- Writing discipline: raw ideas in phases 1-2, structured sections from phase 3+
- Orchestrator pattern presented as valid multi-agent option
- Output check: verify every agent produces tangible output
- Single-sidecar with daily/curated memory as recommended pattern
- Cross-agent interaction patterns explicitly prompted
- Config section must be filled even if empty ("no config needed")
- Skill briefs now self-contained with persona, inputs/outputs, memory contract
- New mandatory phase 6: capability review with user before finalizing
- HTML report output suggested where appropriate
- Plan template updated with matching structure
1. Parallel/subagent file-reading (CM, VM, IM)
- CM and VM: parallel batch reads for ≤4 skills, subagent delegation
for 5+ returning compact JSON instead of bloating parent context
- CM: selective plan doc reading (structured sections only)
- IM: cp command for template init instead of reading into context
2. Completion markers and session-resume protocol
- VM: explicit "Validation complete" signal with follow-up guidance
- IM: "Session complete" marker at Phase 7 end
- IM: Session Resume section for re-entry from existing plan documents
- IM: mandatory soft gate at Phase 2→3 transition
3. Headless output contracts and automation interfaces
- CM: specified temp file paths at {bmad_builder_reports}, defined
required vs inferrable inputs, structured JSON output contract with
inferred object for surfacing wrong inferences
- VM: added --headless mode with structured JSON for CI gating
- SKILL.md: updated args to reflect VM headless support
4. Active handoff and workflow continuity
- IM Phase 7: offers to invoke builder for first skill in roadmap
- CM: plan doc intake reframed as recommended path with auto-extraction
- VM: optional durable findings file-write after presenting results
- CM, VM: config headers now include output format
5. IM writing discipline reinforcement
- Phase 1: writes "Not ready — complete in Phase 3+" placeholder in
all structured sections on template init
- Phase 2: explicitly restricts writes to Ideas Captured only
…ersion Add a new Convert (CW) capability to the Workflow Builder that takes any existing skill — bloated, poorly structured, or simply non-BMad-compliant — and produces a clean, outcome-driven equivalent with a visual before/after HTML comparison report. New files: - references/convert-process.md: 3-step conversion workflow (capture original, delegate to build-process for headless rebuild, generate comparison report with categorized changes) - scripts/generate-convert-report.py: Self-contained HTML report generator with dark/light mode, hero reduction banner, metrics table with visual bars, expandable cut/retained categories, and verdict - scripts/tests/test_generate_convert_report.py: 11 unit tests covering measurement, reduction calculation, report assembly, HTML generation, XSS escaping, and end-to-end pipeline Modified files: - SKILL.md: Added --convert arg, Convert section, routing table entry, updated frontmatter description with convert trigger phrase - module-help.csv (both installed and source copies): Added CW row - docs/reference/builder-commands.md: Added Convert to capabilities overview, new Convert (CW) section with usage/process/report docs, comparison table vs other modes, new trigger phrase row
The path standards scanner incorrectly enforced that {project-root} was
only valid before /_bmad. The correct semantic is that {project-root} is
valid for ANY project-scope path — the distinction is project-scope vs
skill-internal, not _bmad vs everything else.
Changes across workflow-builder and agent-builder (12 files):
Scanner scripts (scan-path-standards.py):
- Removed PROJECT_ROOT_NOT_BMAD_RE (false-positive on valid paths like
{project-root}/docs/report.md)
- Added DOUBLE_PREFIX_RE to catch {project-root}/{config-var} where
config variables already contain {project-root} at runtime
- Updated category from project-root-not-bmad to double-prefix
- Bumped version to 2.1.0
Reference docs (standard-fields.md, quality-dimensions.md):
- Renamed "Project _bmad Paths" to "Project-Scope Paths"
- Added non-_bmad example ({project-root}/docs/report.md)
- Changed rule from "Only use {project-root} for _bmad paths" to
"Use {project-root} for any project-scope path"
Build process docs (build-process.md):
- Updated path conventions section in both builders
Additional docs:
- convert-process.md: updated change-signal table
- script-opportunities-reference.md: fixed comment in script example
- builder-commands.md: updated scanner description
- skill-authoring-best-practices.md: updated path construction rule
merge-help-csv.py defined a 15-column HEADER (agent-name, skill-name, capability, trailing empty) that diverged from the 13-column schema used by validate-module.py, all module-help.csv files, and create-module.md. This would silently corrupt or misalign CSV data during module setup.
9ce60a1 to
38bf61a
Compare
Module builder was merged via #48 but marketplace.json was not updated with the new skill entry, description, or keywords.
83f17e2 to
0da1de6
Compare
Summary
{project-root}path standard across both builders (workflow + agent). The old rule wrongly restricted{project-root}to only_bmadpaths; the correct semantic is that{project-root}is valid for any project-scope path. ReplacedPROJECT_ROOT_NOT_BMAD_REwithDOUBLE_PREFIX_REto catch{project-root}/{config-var}double-prefixing. Updated 12 files across scanners, reference docs, build process docs, and authoring guides.Test plan
scan-path-standards.pyagainst both builder skills — verify no falseproject-root-not-bmadfindingsscan-path-standards.pyagainst a skill with{project-root}/{config-var}— verifydouble-prefixfinding firesvalidate-module.pyagainst an existing module to verify module builder validationscaffold-setup-skill.pyto verify module scaffolding--convertflag on workflow builder with a sample skill🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
New Features
--headless/-H) support for Module validation and conversion operations.Documentation
{project-root}usage for all project-scope paths and clarify./for skill-internal paths.