Buildwright — Testing skill for Claude Code

Buildwright

Buildwright is a lightweight engineering discipline layer for agent-led software work: understand, test, implement, document, verify, review, ship.

It is not a multi-agent framework. It keeps a small command surface and stores only useful project context.

Commands

Command	Purpose
/bw-plan	Think/research only; no code changes
/bw-work	Implement bug fixes, refactors, and features
/bw-verify	Run typecheck, lint, test, and build gates
/bw-review	Independent code + security review of a PR or the current changes
/bw-ship	Verify, review, push, and PR
/bw-analyse	Analyse a brownfield codebase and write context docs
/bw-cleaner	Sweep the repo at rest for stale docs, dead files, and gates that stopped biting

Workflow

Use `/bw-work` for implementation:

Understand -> Research -> Plan if needed -> Red -> Green -> Refactor -> Docs -> Verify -> Security -> Review -> Commit/Ship

Small tasks use lightweight research. Larger features produce `docs/specs/[feature]/research.md` and `docs/specs/[feature]/spec.md`. Cross-domain work uses a normal implementation plan; there is no separate multi-agent architecture.

TDD is explicit:

• Red: write a failing test for the bug or expected behavior.
• Green: make the smallest passing implementation.
• Refactor: improve structure while tests stay green.

Documentation is part of done. Every user-facing change must update affected README, docs, command text, API docs, examples, or changelog. If no docs apply, the agent must say why.

Framework behavior vs. steering

Buildwright separates **how the framework operates** from **your project's choices**.

**Framework behavior** lives in `.buildwright/framework/`. It is Buildwright-owned and fixed — identical in every install, refreshed on update, not meant to be customized:

.buildwright/framework/autonomy.md        # the single autonomy behaviour, auto-continue, cont