mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-09-19 08:11:52 +08:00
do-operator
116e703d67
* docs: refresh the README banner, restore its diagram, and fix the favicon Three things the READMEs and the site were carrying wrong. The banner is the current one from bmadcode.com: the BMad tile and wordmark over the line art, at 2x for retina. It replaces a 1408x224 crop, and is smaller on disk than what it replaces. The delivery-loop diagram in the README has been broken since the diagrams moved to `docs-site/src/diagrams`. It cannot simply be pointed at the new path: an authored diagram carries geometry and classes only, so it needs the site's stylesheet to have any colour at all, and a README loads an SVG as an `<img>` where no stylesheet can reach it. So `docs/images/` now holds exports of the source, generated by `npm run export-readme-diagrams` with the dark ramp substituted in as literal colours. Literals rather than custom properties because an export has to survive renderers thinner than a browser - resvg drops `var()` and paints the fallback black. The Korean README's copy is exported from the same geometry through the existing labels file, so the two can no longer drift apart. The favicon was a teal `B` that matched neither the header tile nor blog.bmadcode.com. It is now the BMad mark, drawn from the same path data the header already carries, on the same navy the blog uses. The .ico is generated from the SVG and stays listed for browsers that ignore `image/svg+xml`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(diagrams): draw the bulbs as bulbs, not as coloured circles The earlier version leaned on gold to say "idea". Once the diagrams lost their own colours, a circle over a rounded tab in the body ink read as neither a bulb nor anything else. So the glyph now carries its meaning in the drawing: a filament arch inside the globe, a tapered neck, and a ribbed screw base, plus a third ray overhead. The small bulb takes the same construction one size down, with a single rib rather than two, which is all that reads at that scale. Both hold up on the light and dark ramps. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: give the delivery loop an English page, at the house type scale The diagram the README leads with appeared on exactly one page of the site: the Korean `how-to/choose-a-development-path`, a leftover from before the English tree was restructured into start/plan/build. An English reader never saw it. It now opens "Find Your Starting Point" on the docs index, where it says in a picture what the list underneath says in prose. Putting it in a docs column for the first time showed its type was tuned for a README: drawn at a 1120 viewBox, its labels came out at 11.0px and 8.3px against the 12.8px and 10.9px the other diagrams hold at the same 736px content width. The sizes are scaled to match; the geometry is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs-site: guard locale coverage, and give the footer band an edge Two unrelated things a reader can see, and one they cannot. The invisible one first. When a locale has no page at a route, Starlight serves the English one and says nothing, so a missing translation and a working one look identical from the outside — which is how all five locales ended up stranded on the pre-restructure tree unnoticed (#2855). Starlight does mark the substitution: a fallback page carries `lang="en"` on `<main>` inside a document that declares the locale. The build now checks the built site for that mismatch, which measures the symptom rather than inferring it from the sidebar. The existing backlog is far too large to fix here, so it is recorded in `locale-coverage-baseline.json` and tolerated. The build fails only when the picture changes: a route starts falling back, or a baseline entry stops. Both are one `--update` away. The second failing is deliberate — it is what keeps the baseline from outliving the problem it records. The visible one: the footer band sets its own dark ground, which on the dark ramp is the page's ground, so there was no band — only 297px of unexplained space where one should have started. It now lifts a step and takes a hairline in dark mode, and sits flush against the article instead of adding a margin on top of its own padding. The last-updated line gives up some of its air too; between them the gap is 234px, and every part of it is now doing something. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs-site: stack the footer columns on mobile, and add the touch icon The footer's three link groups were laid out in two columns below 32rem, so one group always dropped onto a row of its own with the space beside it left empty, and "Plan inside an organization" wrapped inside a 155px column. Three groups do not fit two columns; on a phone they get one each. The favicon already matches bmadcode.com exactly - same viewBox, same navy tile, same three paths, since the mark is the one the header carries. What was missing is the apple-touch-icon the site also ships, so an icon saved to an iOS home screen fell back to a screenshot. It is generated from the same SVG, flattened onto the tile navy because iOS applies its own mask and does not want the transparency our rounded corners would leave. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(diagrams): raise the delivery loop's type, and give it back a colour Alex is right about what he saw, and wrong about it being new. His screenshot is the version before the type was scaled for a docs column, where the title rendered at 9.2px against GitHub's 16px body. That is already fixed. But the original diagram this replaced ran 14/16/21 and the fix brought it to 14.5/16.5/19.5 - a hair under where it always was, and his objection would have applied to the original too. So rather than argue the point, take it past the original: 17.5/18/21, which puts the node labels at body size and the title at 14.5px in a README. The colour is the other half of his complaint's cause. The original said "here is where each kind of work joins" in gold; when the diagrams lost their own colours that meaning went with it and nothing replaced it. The three entry drops now carry the accent, which is the vocabulary's existing job for an edge the drawing has to single out, so it works on both ramps. The marker was still called `arrow-gold`; it is `arrow-entry` now. The README export also gets a ground rather than a flat fill: a near-black lifting across the diagonal with one soft accent wash behind the row the work enters from, which is the register bmadcode.com uses - almost all ground and one blue. The wash sits high on purpose, because centred it pooled behind the boxes and their flat fill then read as darker than the ground around them. The docs site keeps a ground that follows the reader's theme, so this belongs to the export alone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(diagrams): drop the gradient ground from the README export It read as an effect rather than a surface. The drawing's colour is the accent on the three entry drops, and it says more with a flat ground behind it and nothing competing. The larger type and the accent stay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(diagrams): space the delivery loop's two band labels evenly They were not spaced at all, only placed. The title's baseline fell three units BELOW the big bulb's top ray - the two only looked separate because they are far apart horizontally - while the lower band had 35 units of air. That mismatch is what read as wrong. Both now sit 40 units clear of the nearest mark. The drawing keeps its size and shifts down inside a taller canvas, 420 to 460, with the labels lifted out of its group so the shift leaves them where they are; the remaining padding above and below the pair is 15 and 16. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2.9 KiB
2.9 KiB
title, description, hero
| title | description | hero | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Build Software with BMad | BMad helps you decide what to build and then build it. Start here to install it, make your first change, or find the path that fits the work in front of you. |
|
BMad adds a set of named commands, called skills, to AI coding tools such as
Claude Code and Cursor. Some of them help you think: explore an idea, research
it, argue against it, and write down what you have settled on. Others help you
build: give bmad-build a change you want made, and it writes the code and
reviews it.
You can use either group on its own. Many people run the thinking skills and never ask BMad to write a line of code, and a small fix can go straight to building with no planning at all.
Find Your Starting Point
Every path runs the same loop. Bigger work enters it earlier and goes round it more often; it does not become a different way of delivering.
You are not sure how much process the change needs. Choose a Planning Path.
You want to see it work. Build Your First Change walks through one build in an empty project.
You know exactly what needs to change, and it is small.
Run bmad-build and describe the change. See Build a Change.
You are working in an existing codebase.
Consider running bmad-project-context, then build as usual. See
Start in an Existing Codebase and
Set and Maintain Project Context.
You are building a larger feature or a whole product.
If you can give bmad-spec a complete intent, start there. If you need to
go through the ideation/planning paces first, choose a path in
Choose a Planning Path.
Your idea is still vague, or you are not sure it is a good one. Generate options or pressure-test the idea, then gather evidence with Deep Recon.
You want BMad to follow your team's own rules and practices. See Customize BMad and Adopt BMad Across a Team.
:::tip[Unsure where to start?]
Run bmad-help. If that is not enough, see
Get Answers About BMad.
:::