Re-vendoring BMAD-METHOD

vendor-skills/BMAD/ is a pinned, manually-updated vendor copy of eight skills from bmad-code-org/BMAD-METHOD's bmm module (see vendor-skills/BMAD/ATTRIBUTION.md for the current pin). It is never auto-updated — re-vendoring is a deliberate act, run only when this skill is invoked by name or the user explicitly asks to update BMAD.

What's vendored, and why these specific paths

Eight skill directories plus two shared scripts they all depend on:

• src/core-skills/bmad-forge-idea — pressure-tests an idea before any artifact gets written; runs first in the shelf, ahead of bmad-brainstorming. Carries its own script, resolve_personas.py (not shared with the other skills — vendored inside this skill's own scripts/, not in the shared vendor-skills/BMAD/scripts/).
• src/core-skills/bmad-brainstorming
• src/core-skills/bmad-advanced-elicitation
• src/core-skills/bmad-deep-recon
• src/bmm-skills/plan/bmad-product-brief
• src/bmm-skills/plan/bmad-prfaq
• src/bmm-skills/plan/bmad-prd
• src/bmm-skills/plan/bmad-ux
• src/scripts/memlog.py, src/scripts/resolve_customization.py — shared utilities every one of the eight skills calls. Not inside any single skill directory upstream; vendored separately into vendor-skills/BMAD/scripts/.

Upstream keeps the four bmm-skills above under a single flat bmm-skills/plan/ directory as of the v6.11.0 vendor pass — it used to be split across numbered 1-analysis/ and 2-plan-workflows/ directories. If upstream has moved them again since, update these paths to match rather than leaving a stale layout here.

bmad-deep-recon was, before the v6.11.0 pass, the one skill in this set that existed only on BMAD-METHOD's main branch — not in any tagged release; it is now in v6.11.0. If a newer addition to this set is ever unreleased, pin to main at a specific commit SHA rather than a release tag (see "Pinning," below) instead of silently dropping it; ask the user how to resolve the conflict if it's not obvious (this came up during the original vendor pass — see git history on vendor-skills/BMAD/).

Not vendored, deliberately: bmad-party-mode (BMAD-METHOD's multi-agent roster skill) and the bmm-skills/agents/bmad-agent-* persona skills it needs for a real roster. bmad-forge-idea can optionally draw on party-mode's roster but degrades gracefully without it — its resolve_personas.py returns an empty roster and the skill falls back to generating personas on the fly, which is its documented normal path. Vendoring party-mode for real would mean also vendoring the five bmad-agent-* skills, a parallel persona system to Hedgehog's own src/agents/ that's out of scope for the planning shelf. Don't add it without raising this tradeoff to the user again.

Procedure

1. Find the ref to vendor against. Check gh repo view bmad-code-org/BMAD-METHOD --json defaultBranchRef and gh api repos/bmad-code-org/BMAD-METHOD/tags for available release tags. If every one of the eight skills above exists in the newest tag, pin to that tag. If any of them is unreleased, pin to main at its current commit SHA instead — get it via gh api repos/bmad-code-org/BMAD-METHOD/commits/main --jq '.sha'. Don't silently drop a skill just because it's unreleased; ask the user how to resolve the conflict if it's not obvious (this came up during the original vendor pass — see git history on vendor-skills/BMAD/).

2. List the file tree at that ref, scoped to the eight skill directories plus src/scripts/ (adjust the path segments below if upstream has moved any of them again since the last pass):

   gh api "repos/bmad-code-org/BMAD-METHOD/git/trees/<ref>?recursive=true" \
     --jq '.tree[] | select(.type=="blob") | .path' \
     | grep -E "^src/(core-skills/(bmad-forge-idea|bmad-brainstorming|bmad-advanced-elicitation|bmad-deep-recon)|bmm-skills/plan/(bmad-product-brief|bmad-prfaq|bmad-prd|bmad-ux)|scripts)/"
   

   Diff this against the current file list in vendor-skills/BMAD/ (excluding LICENSE, ATTRIBUTION.md, and any files this skill's step 4 strips) to see what's new, removed, or moved upstream before blindly overwriting — a file that moved to a new path upstream needs its path updated here too, not a stale copy left behind.

3. Fetch every file at that ref via gh api repos/bmad-code-org/BMAD-METHOD/contents/<path>?ref=<sha> (the .content field is base64), decoding with base64 --decode (BSD base64 on macOS needs -i/-o flags, not -d <file>) into vendor-skills/BMAD/<path-with-src/-stripped>. Also re-fetch LICENSE from the repo root the same way.

4. Re-apply the strip pass. Every vendored SKILL.md and its references/*.md files have BMAD's own orchestration layer removed — this doesn't survive a raw re-fetch and must be redone by hand each time:

   • Central config resolution (_bmad/scripts/resolve_config.py, _bmad/config.toml, _bmad/bmm/config.yaml) — not vendored; replace with trivial inline defaults for {user_name}, {communication_language} (English), {date} (today), {project_name}.
   • _bmad/scripts/resolve_customization.py and _bmad/scripts/memlog.py calls — these ARE vendored (in vendor-skills/BMAD/scripts/); rewrite their paths to {bmad-root}/scripts/<name>.py, where {bmad-root} is defined once per file (in a "Conventions" section) as the vendored vendor-skills/BMAD/ root.
   • bmad-party-mode mentions/invocations — remove (not vendored).
   • Chain-forward "common next skill" suggestions, bmad-help references, and misroute-detection pointing at non-vendored BMAD skills — remove. Control returns to Hedgehog's planner after each skill, not to BMAD's own routing.
   • Keep bmad-advanced-elicitation invocations — it IS vendored.
   • Re-apply every entry under ATTRIBUTION.md's "Local changes (not upstream)" section to the freshly-fetched files — a raw re-fetch overwrites them silently otherwise, and a hand-patch that isn't re-applied is worse than one that was never made.
   • Verify when done:

     cd vendor-skills/BMAD && grep -rn "_bmad/\|resolve_config\.py\|party-mode\|party_mode\|bmad-help\|common next\|scan for misroute" --include="*.md" .
     

     Zero matches is the bar. Read each match before deciding it's really orchestration — don't blind-strip a line that happens to contain one of these words for an unrelated reason.

5. Verify self-containment. Every vendored Python script must compile and its own test suite must pass, standalone, from inside vendor-skills/BMAD/:

   cd vendor-skills/BMAD
   for f in $(find . -name "*.py" -not -path "*/tests/*"); do python3 -c "import py_compile; py_compile.compile('$f', doraise=True)"; done
   uv run --with pytest python3 -m pytest scripts/tests/ core-skills/*/scripts/tests/ -q
   

   Also confirm no vendored file references an absolute path outside vendor-skills/BMAD/ or a project path from the machine that did the vendoring.

6. Update vendor-skills/BMAD/ATTRIBUTION.md: new pinned ref (tag or commit SHA), new date, and a note if the vendored file set itself changed (a skill added/removed upstream, a shared script renamed, etc.).

7. One commit, chore(bmad): re-vendor to <ref> — the whole re-vendor pass is one unit of work, not split across the fetch and the strip pass.

Constraints

• Never auto-run this on a schedule or "while you're in the area" — only on explicit request, same posture as a core package's own workspace regeneration.
• Never hand-patch a single vendored file to fix an upstream bug without also updating ATTRIBUTION.md — a silent local fork is worse than a stale pin, since nothing records that vendor-skills/BMAD/ has diverged from what its own attribution claims.
• If BMAD-METHOD has restructured upstream (skill renamed, moved to a different module, split into multiple skills) since the last vendor pass, don't force a mechanical file-for-file replace — read the new shape and decide whether Hedgehog's list of eight skills still makes sense, or whether src/agents/planner.md's shelf-invocation list (Section "Planning intake" in that file) itself needs updating to match. Surface this to the user rather than silently adapting.