buildwright 0.0.12 → 0.0.13
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +89 -388
- package/bin/buildwright.js +1 -1
- package/package.json +2 -2
- package/src/commands/commands.js +3 -5
- package/src/commands/init.js +4 -4
- package/src/commands/update.js +8 -29
- package/templates/.buildwright/agents/README.md +6 -50
- package/templates/.buildwright/commands/bw-analyse.md +12 -13
- package/templates/.buildwright/commands/bw-plan.md +7 -4
- package/templates/.buildwright/commands/bw-ship.md +5 -2
- package/templates/.buildwright/commands/bw-verify.md +2 -2
- package/templates/.buildwright/commands/bw-work.md +149 -0
- package/templates/.buildwright/steering/philosophy.md +45 -0
- package/templates/BUILDWRIGHT.md +2 -5
- package/templates/CLAUDE.md +89 -126
- package/templates/Makefile +1 -1
- package/templates/scripts/sync-agents.sh +18 -25
- package/templates/scripts/validate-docs.sh +1 -4
- package/templates/.buildwright/agents/architect.md +0 -143
- package/templates/.buildwright/claws/README.md +0 -89
- package/templates/.buildwright/claws/TEMPLATE.md +0 -71
- package/templates/.buildwright/claws/backend.md +0 -114
- package/templates/.buildwright/claws/database.md +0 -120
- package/templates/.buildwright/claws/devops.md +0 -175
- package/templates/.buildwright/claws/frontend.md +0 -111
- package/templates/.buildwright/commands/bw-claw.md +0 -332
- package/templates/.buildwright/commands/bw-help.md +0 -88
- package/templates/.buildwright/commands/bw-new-feature.md +0 -539
- package/templates/.buildwright/commands/bw-quick.md +0 -336
- package/templates/.buildwright/steering/naming-conventions.md +0 -40
- package/templates/.buildwright/steering/product.md +0 -16
- package/templates/.buildwright/steering/quality-gates.md +0 -35
- package/templates/.buildwright/steering/tech.md +0 -27
- package/templates/.buildwright/tasks/TEMPLATE.md +0 -79
- package/templates/.github/workflows/quality-gates.yml +0 -135
- package/templates/docs/requirements/TEMPLATE.md +0 -33
package/templates/CLAUDE.md
CHANGED
|
@@ -1,160 +1,123 @@
|
|
|
1
1
|
# Buildwright Development
|
|
2
2
|
|
|
3
3
|
## Mission
|
|
4
|
-
|
|
4
|
+
|
|
5
|
+
Agent-first disciplined development. Humans approve intent when needed; agents
|
|
6
|
+
understand, test, implement, document, verify, review, and ship.
|
|
5
7
|
|
|
6
8
|
## Steering Documents
|
|
7
9
|
|
|
8
|
-
At the start of every session, read
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
10
|
+
At the start of every session, recursively discover and read all `.md` files
|
|
11
|
+
under `.buildwright/steering/`. Use:
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
find .buildwright/steering -type f -name "*.md" | sort
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
The default steering file is `philosophy.md`.
|
|
12
18
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
19
|
+
Also recursively read all `.md` files under `.buildwright/codebase/` if that
|
|
20
|
+
directory exists. These are codebase analysis docs generated by `/bw-analyse`.
|
|
21
|
+
|
|
22
|
+
Do not assume a fixed set of project steering files. `tech.md` and `product.md`
|
|
23
|
+
are created only when Buildwright has real project-specific content.
|
|
18
24
|
|
|
19
25
|
## Project Structure
|
|
20
26
|
|
|
21
|
-
`.buildwright/` is the canonical configuration directory
|
|
27
|
+
`.buildwright/` is the canonical configuration directory committed to git.
|
|
28
|
+
Tool-specific directories are generated from it and gitignored:
|
|
22
29
|
|
|
23
30
|
```
|
|
24
|
-
.buildwright/
|
|
25
|
-
agents/
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
.
|
|
33
|
-
.
|
|
34
|
-
.cursor/rules/ ← Generated by `make sync` (gitignored)
|
|
35
|
-
AGENTS.md ← Generated by `make sync` (gitignored)
|
|
31
|
+
.buildwright/
|
|
32
|
+
agents/ # Staff Engineer, Security Engineer
|
|
33
|
+
codebase/ # Generated by /bw-analyse
|
|
34
|
+
commands/ # bw-work, bw-plan, bw-verify, bw-ship, bw-analyse
|
|
35
|
+
steering/ # philosophy.md plus lazy-created tech.md/product.md
|
|
36
|
+
|
|
37
|
+
.claude/ # Generated by make sync
|
|
38
|
+
.opencode/ # Generated by make sync
|
|
39
|
+
.cursor/rules/ # Generated by make sync
|
|
40
|
+
AGENTS.md # Generated by make sync
|
|
36
41
|
```
|
|
37
42
|
|
|
38
|
-
After cloning or editing `.buildwright/`, run `make sync
|
|
43
|
+
After cloning or editing `.buildwright/`, run `make sync`.
|
|
39
44
|
|
|
40
|
-
##
|
|
45
|
+
## Commands
|
|
41
46
|
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
48
|
-
|
|
49
|
-
### Workflow Priority
|
|
50
|
-
1. **New features (single domain)**: /bw-new-feature → Research → Spec → Approval → Implement → Ship
|
|
51
|
-
2. **Cross-domain features**: /bw-claw → Architect decomposes → Claws execute per domain → Integrate → Ship
|
|
52
|
-
3. **Small tasks/bugs**: /bw-quick → Quick research → Implement → Verify → Commit
|
|
53
|
-
4. **Refactors**: /bw-new-feature (if scope unclear) or /bw-quick (if scope clear)
|
|
54
|
-
5. **Ship existing work**: /bw-ship → Verify → Security → Review → Push → PR
|
|
55
|
-
6. **Quick quality check**: /bw-verify → typecheck, lint, test, build
|
|
56
|
-
7. **Show commands**: /bw-help
|
|
57
|
-
8. **Analyse existing codebase**: /bw-analyse → reads codebase → writes structured docs to .buildwright/codebase/ → updates tech.md. Run first on any brownfield project.
|
|
58
|
-
9. **Research/planning without implementation**: /bw-plan → Understand question → Research (read-only) → Synthesize → Write deliverable. No code changes, no commits.
|
|
47
|
+
Use the smallest command that matches the intent:
|
|
48
|
+
|
|
49
|
+
1. `/bw-plan` — think/research only; no code changes, commits, or PRs.
|
|
50
|
+
2. `/bw-work` — implement bug fixes, refactors, and features.
|
|
51
|
+
3. `/bw-verify` — run typecheck, lint, test, and build gates.
|
|
52
|
+
4. `/bw-ship` — verify, security review, code review, push, and PR.
|
|
53
|
+
5. `/bw-analyse` — analyse brownfield codebases and write `.buildwright/codebase/` docs.
|
|
59
54
|
|
|
60
55
|
## Command Discovery
|
|
61
56
|
|
|
62
|
-
Run once per session
|
|
57
|
+
Run once per session and cache the result.
|
|
58
|
+
|
|
59
|
+
1. Read `.buildwright/steering/tech.md` if it exists. If it has real commands,
|
|
60
|
+
use them.
|
|
61
|
+
2. Otherwise auto-detect from project files in priority order:
|
|
62
|
+
`package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `setup.py`,
|
|
63
|
+
`requirements.txt`, `Makefile`.
|
|
64
|
+
3. Derive typecheck, lint, test, build, and dev commands. Mark unavailable
|
|
65
|
+
gates as `SKIP`.
|
|
66
|
+
4. Write discovered commands to `.buildwright/steering/tech.md`.
|
|
67
|
+
5. If still ambiguous, ask for the missing commands.
|
|
63
68
|
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
+
## Operating Mode
|
|
70
|
+
|
|
71
|
+
- Execute autonomously unless information is genuinely missing.
|
|
72
|
+
- Verify your own work through tests and checks.
|
|
73
|
+
- Commit only after verification passes.
|
|
74
|
+
- Stop only when genuinely blocked.
|
|
69
75
|
|
|
70
|
-
|
|
76
|
+
`BUILDWRIGHT_AUTO_APPROVE=true` means autonomous mode. If a step fails after
|
|
77
|
+
retries, commit completed work, push, create a PR with failure details, and
|
|
78
|
+
exit non-zero. In interactive mode (`BUILDWRIGHT_AUTO_APPROVE=false`), stop and
|
|
79
|
+
report the blocker.
|
|
71
80
|
|
|
72
|
-
|
|
73
|
-
|----------|---------|----------|---------|
|
|
74
|
-
| `GITHUB_TOKEN` | — | Yes | Push branches and open PRs via `gh`. Needs `repo` scope. |
|
|
75
|
-
| `BUILDWRIGHT_AUTO_APPROVE` | `true` | No | Autonomous mode — skip human approval, fail gracefully on errors |
|
|
76
|
-
| `BUILDWRIGHT_AGENT_RETRIES` | `2` | No | Number of verify retries before giving up |
|
|
81
|
+
## Verification Loop
|
|
77
82
|
|
|
78
|
-
|
|
83
|
+
Before every commit, run discovered gates:
|
|
79
84
|
|
|
80
|
-
|
|
85
|
+
1. Typecheck
|
|
86
|
+
2. Lint
|
|
87
|
+
3. Test
|
|
88
|
+
4. Build
|
|
81
89
|
|
|
82
|
-
|
|
90
|
+
Skip only gates that are unavailable for the stack. If a required step fails,
|
|
91
|
+
fix and retry up to `BUILDWRIGHT_AGENT_RETRIES` times, default 2.
|
|
83
92
|
|
|
84
|
-
|
|
85
|
-
2. **Lint** — run DISCOVERED_LINT (SKIP gracefully if this stack has none)
|
|
86
|
-
3. **Test** — run DISCOVERED_TEST
|
|
87
|
-
4. **Build** — run DISCOVERED_BUILD (SKIP gracefully if this stack has no build step, e.g. Python)
|
|
93
|
+
## Documentation Discipline
|
|
88
94
|
|
|
89
|
-
|
|
95
|
+
Documentation is part of done.
|
|
96
|
+
|
|
97
|
+
Before every commit, update affected README, docs, command text, API docs,
|
|
98
|
+
examples, changelog, or generated user-facing docs. If no docs need updating,
|
|
99
|
+
say why in the final report.
|
|
90
100
|
|
|
91
101
|
## Git Rules
|
|
92
|
-
|
|
93
|
-
-
|
|
94
|
-
-
|
|
95
|
-
- Never edit
|
|
96
|
-
- Never run destructive git operations without explicit instruction
|
|
97
|
-
-
|
|
98
|
-
- Only `.buildwright/` is
|
|
99
|
-
|
|
100
|
-
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
2. Architect registers new fields in `.buildwright/steering/naming-conventions.md` BEFORE spawning claws
|
|
107
|
-
3. Each claw (`.buildwright/claws/*.md`) executes its domain task using TDD
|
|
108
|
-
4. Claws derive naming from the conventions registry — they never invent their own
|
|
109
|
-
5. Architect integrates and runs quality gates
|
|
110
|
-
|
|
111
|
-
## Design Principles (ALWAYS APPLY)
|
|
112
|
-
|
|
113
|
-
1. **KISS (Keep It Simple, Stupid)**
|
|
114
|
-
- Prefer simple solutions over clever ones
|
|
115
|
-
- If it feels complex, step back and simplify
|
|
116
|
-
- Code should be readable by a junior developer
|
|
117
|
-
|
|
118
|
-
2. **YAGNI (You Aren't Gonna Need It)**
|
|
119
|
-
- Build only what's required NOW
|
|
120
|
-
- No speculative features "for later"
|
|
121
|
-
- Avoid abstractions until they're proven needed
|
|
122
|
-
- No wrapper types, adapter layers, or extension points "just in case"
|
|
123
|
-
- If the requirements don't ask for it, don't build it
|
|
124
|
-
|
|
125
|
-
3. **No Premature Optimization**
|
|
126
|
-
- Make it work first, then make it fast (if needed)
|
|
127
|
-
- Optimize only with profiling data
|
|
128
|
-
- Readability > micro-optimizations
|
|
129
|
-
|
|
130
|
-
4. **Boring Technology**
|
|
131
|
-
- Prefer proven, well-documented solutions
|
|
132
|
-
- New tech only when it solves a real problem
|
|
133
|
-
- Consider maintenance burden
|
|
134
|
-
|
|
135
|
-
5. **Fail Fast, Fail Loud**
|
|
136
|
-
- Validate inputs at boundaries
|
|
137
|
-
- Throw errors early with clear messages
|
|
138
|
-
- No silent failures
|
|
139
|
-
|
|
140
|
-
6. **DRY (Don't Repeat Yourself)**
|
|
141
|
-
- Before writing new code, search for existing functions, types, and utilities that already do the job
|
|
142
|
-
- Reuse existing structures — if `User` exists, don't create `UserDTO` or `UserEntity` unless the codebase already separates those concerns
|
|
143
|
-
- If two pieces of code do similar things, extract the common part rather than duplicating
|
|
144
|
-
- Prefer importing over reimplementing
|
|
145
|
-
|
|
146
|
-
## Code Standards
|
|
147
|
-
- Follow existing patterns in the codebase exactly
|
|
148
|
-
- Keep files under 500 lines; split proactively
|
|
149
|
-
- Write tests for all new functionality (TDD preferred)
|
|
150
|
-
- Avoid type system escape hatches (`any` in TypeScript, untyped `interface{}` in Go, `Any` in Python) — use proper types
|
|
151
|
-
- Use Decimal/BigDecimal for financial calculations, NEVER floating point
|
|
152
|
-
- All user inputs must be validated
|
|
102
|
+
|
|
103
|
+
- Atomic commits: only commit files you changed.
|
|
104
|
+
- Conventional commits: `feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`.
|
|
105
|
+
- Never edit `.env` files.
|
|
106
|
+
- Never run destructive git operations without explicit instruction.
|
|
107
|
+
- Never use `git stash`.
|
|
108
|
+
- Only `.buildwright/` is canonical. Do not commit generated `.claude/`,
|
|
109
|
+
`.opencode/`, `.cursor/rules/`, `skills/`, or `AGENTS.md`.
|
|
110
|
+
- After editing `.buildwright/`, run `make sync`.
|
|
111
|
+
|
|
112
|
+
## Philosophy
|
|
113
|
+
|
|
114
|
+
Always apply `.buildwright/steering/philosophy.md`: KISS, YAGNI, DRY, boring
|
|
115
|
+
technology, fail fast, Red -> Green -> Refactor, and documentation discipline.
|
|
153
116
|
|
|
154
117
|
## Self-Improvement
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
- Keep entries concise (one line each)
|
|
118
|
+
|
|
119
|
+
When you discover a reusable pattern or gotcha, add it below.
|
|
158
120
|
|
|
159
121
|
## Learned Patterns
|
|
122
|
+
|
|
160
123
|
<!-- Agent adds entries here as it learns -->
|
package/templates/Makefile
CHANGED
|
@@ -25,7 +25,7 @@ dist: sync
|
|
|
25
25
|
cursor: sync
|
|
26
26
|
@echo "Cursor rules generated at .cursor/rules/"
|
|
27
27
|
@echo "Open this project in Cursor — rules are applied automatically."
|
|
28
|
-
@echo "Settings > Rules shows steering rules as 'Always' and commands/agents
|
|
28
|
+
@echo "Settings > Rules shows steering rules as 'Always' and commands/agents as 'Intelligent'."
|
|
29
29
|
|
|
30
30
|
# OpenCode — install skill to user global config
|
|
31
31
|
opencode: sync
|
|
@@ -5,17 +5,13 @@
|
|
|
5
5
|
# Generates:
|
|
6
6
|
# .claude/commands/ ← from .buildwright/commands/ (paths rewritten to .claude/)
|
|
7
7
|
# .claude/agents/ ← from .buildwright/agents/
|
|
8
|
-
# .claude/claws/ ← from .buildwright/claws/
|
|
9
8
|
# .claude/steering/ ← from .buildwright/steering/
|
|
10
|
-
# .claude/tasks/ ← from .buildwright/tasks/
|
|
11
9
|
# .opencode/commands/ ← from .buildwright/commands/ (paths rewritten to .opencode/)
|
|
12
10
|
# .opencode/agents/ ← from .buildwright/agents/
|
|
13
|
-
# .opencode/claws/ ← from .buildwright/claws/
|
|
14
11
|
# .opencode/steering/ ← from .buildwright/steering/
|
|
15
12
|
# .cursor/rules/steering/ ← .mdc files with alwaysApply: true
|
|
16
13
|
# .cursor/rules/commands/ ← .mdc files with alwaysApply: false
|
|
17
14
|
# .cursor/rules/agents/ ← .mdc files with alwaysApply: false
|
|
18
|
-
# .cursor/rules/claws/ ← .mdc files with alwaysApply: false
|
|
19
15
|
# AGENTS.md ← CLAUDE.md with OpenCode header prepended
|
|
20
16
|
# dist/buildwright/ ← SKILL.md packaged for ClawHub
|
|
21
17
|
#
|
|
@@ -95,35 +91,29 @@ CURSOR_DESCRIPTION=""
|
|
|
95
91
|
set_cursor_frontmatter() {
|
|
96
92
|
local preset="$1"
|
|
97
93
|
local filename="$2"
|
|
94
|
+
local base_filename
|
|
95
|
+
base_filename=$(basename "$filename")
|
|
98
96
|
|
|
99
97
|
case "$preset" in
|
|
100
98
|
steering|codebase) CURSOR_ALWAYS_APPLY="true" ;;
|
|
101
99
|
*) CURSOR_ALWAYS_APPLY="false" ;;
|
|
102
100
|
esac
|
|
103
101
|
|
|
104
|
-
case "${preset}:${
|
|
102
|
+
case "${preset}:${base_filename}" in
|
|
105
103
|
steering:product) CURSOR_DESCRIPTION="Buildwright product context: goals, features, user personas, business constraints" ;;
|
|
106
104
|
steering:tech) CURSOR_DESCRIPTION="Buildwright technical context: stack, commands, architecture patterns" ;;
|
|
107
|
-
steering:
|
|
108
|
-
steering:naming-conventions) CURSOR_DESCRIPTION="Buildwright naming conventions: canonical field and endpoint registry" ;;
|
|
105
|
+
steering:philosophy) CURSOR_DESCRIPTION="Buildwright engineering philosophy: KISS, YAGNI, TDD, docs discipline" ;;
|
|
109
106
|
codebase:STACK) CURSOR_DESCRIPTION="Codebase tech stack: languages, runtime, frameworks, dependencies, integrations" ;;
|
|
110
107
|
codebase:ARCHITECTURE) CURSOR_DESCRIPTION="Codebase architecture: layers, data flow, entry points, directory structure" ;;
|
|
111
108
|
codebase:CONVENTIONS) CURSOR_DESCRIPTION="Codebase conventions: naming, code style, imports, error handling, testing patterns" ;;
|
|
112
109
|
codebase:CONCERNS) CURSOR_DESCRIPTION="Codebase concerns: tech debt, bugs, security risks, performance bottlenecks" ;;
|
|
113
|
-
command:bw-
|
|
114
|
-
command:bw-claw) CURSOR_DESCRIPTION="Buildwright bw-claw: multi-agent cross-domain feature development" ;;
|
|
115
|
-
command:bw-quick) CURSOR_DESCRIPTION="Buildwright bw-quick: fast path for bug fixes and small tasks" ;;
|
|
110
|
+
command:bw-work) CURSOR_DESCRIPTION="Buildwright bw-work: implement bug fixes, refactors, and features" ;;
|
|
116
111
|
command:bw-ship) CURSOR_DESCRIPTION="Buildwright bw-ship: quality pipeline then commit, push, and PR" ;;
|
|
117
112
|
command:bw-verify) CURSOR_DESCRIPTION="Buildwright bw-verify: quick quality checks (typecheck, lint, test, build)" ;;
|
|
118
|
-
command:bw-help) CURSOR_DESCRIPTION="Buildwright bw-help: list all available Buildwright commands" ;;
|
|
119
113
|
command:bw-analyse) CURSOR_DESCRIPTION="Buildwright bw-analyse: analyse codebase, write structured docs to .buildwright/codebase/, update tech.md" ;;
|
|
120
|
-
|
|
114
|
+
command:bw-plan) CURSOR_DESCRIPTION="Buildwright bw-plan: research a question, produce a written deliverable — no implementation" ;;
|
|
121
115
|
agent:staff-engineer) CURSOR_DESCRIPTION="Buildwright Staff Engineer agent persona" ;;
|
|
122
116
|
agent:security-engineer) CURSOR_DESCRIPTION="Buildwright Security Engineer agent persona" ;;
|
|
123
|
-
claw:frontend) CURSOR_DESCRIPTION="Buildwright Frontend domain specialist claw" ;;
|
|
124
|
-
claw:backend) CURSOR_DESCRIPTION="Buildwright Backend domain specialist claw" ;;
|
|
125
|
-
claw:database) CURSOR_DESCRIPTION="Buildwright Database domain specialist claw" ;;
|
|
126
|
-
claw:devops) CURSOR_DESCRIPTION="Buildwright DevOps domain specialist claw" ;;
|
|
127
117
|
*) CURSOR_DESCRIPTION="Buildwright ${preset}: ${filename}" ;;
|
|
128
118
|
esac
|
|
129
119
|
}
|
|
@@ -143,20 +133,25 @@ sync_cursor_dir() {
|
|
|
143
133
|
fi
|
|
144
134
|
|
|
145
135
|
if [ "$CHECK_ONLY" = false ]; then
|
|
136
|
+
rm -rf "$dst"
|
|
146
137
|
mkdir -p "$dst"
|
|
147
138
|
fi
|
|
148
139
|
|
|
149
|
-
|
|
140
|
+
while IFS= read -r src_file; do
|
|
150
141
|
[ -f "$src_file" ] || continue
|
|
151
|
-
local filename
|
|
152
|
-
|
|
142
|
+
local rel_file filename base_filename
|
|
143
|
+
rel_file="${src_file#$src/}"
|
|
144
|
+
filename="${rel_file%.md}"
|
|
145
|
+
base_filename=$(basename "$filename")
|
|
153
146
|
|
|
154
147
|
# Skip meta files — they're internal docs, not rules
|
|
155
|
-
case "$
|
|
148
|
+
case "$base_filename" in
|
|
156
149
|
README|TEMPLATE) continue ;;
|
|
157
150
|
esac
|
|
158
151
|
|
|
159
152
|
local dst_file="$dst/$filename.mdc"
|
|
153
|
+
local dst_parent
|
|
154
|
+
dst_parent=$(dirname "$dst_file")
|
|
160
155
|
set_cursor_frontmatter "$preset" "$filename"
|
|
161
156
|
|
|
162
157
|
if [ "$CHECK_ONLY" = true ]; then
|
|
@@ -181,6 +176,7 @@ sync_cursor_dir() {
|
|
|
181
176
|
rm -f "$tmpfile"
|
|
182
177
|
fi
|
|
183
178
|
else
|
|
179
|
+
mkdir -p "$dst_parent"
|
|
184
180
|
{
|
|
185
181
|
printf '%s\n' "---"
|
|
186
182
|
printf 'description: "%s"\n' "$CURSOR_DESCRIPTION"
|
|
@@ -190,7 +186,7 @@ sync_cursor_dir() {
|
|
|
190
186
|
sed 's|@\.buildwright/|@.cursor/rules/|g' "$src_file"
|
|
191
187
|
} > "$dst_file"
|
|
192
188
|
fi
|
|
193
|
-
done
|
|
189
|
+
done < <(find "$src" -type f -name "*.md" | sort)
|
|
194
190
|
|
|
195
191
|
if [ "$CHECK_ONLY" = false ]; then
|
|
196
192
|
echo " synced $src → $dst (*.mdc)"
|
|
@@ -210,10 +206,8 @@ SYNC_NEEDED=false
|
|
|
210
206
|
|
|
211
207
|
sync_dir ".buildwright/commands" ".claude/commands" ".buildwright/" ".claude/"
|
|
212
208
|
sync_dir ".buildwright/agents" ".claude/agents" ".buildwright/" ".claude/"
|
|
213
|
-
sync_dir ".buildwright/claws" ".claude/claws" ".buildwright/" ".claude/"
|
|
214
209
|
sync_dir ".buildwright/steering" ".claude/steering"
|
|
215
210
|
sync_dir ".buildwright/codebase" ".claude/codebase"
|
|
216
|
-
sync_dir ".buildwright/tasks" ".claude/tasks"
|
|
217
211
|
|
|
218
212
|
# ============================================================================
|
|
219
213
|
# 2. .buildwright/ → .opencode/ (rewrite .buildwright/ → .opencode/)
|
|
@@ -221,7 +215,6 @@ sync_dir ".buildwright/tasks" ".claude/tasks"
|
|
|
221
215
|
|
|
222
216
|
sync_dir ".buildwright/commands" ".opencode/commands" ".buildwright/" ".opencode/"
|
|
223
217
|
sync_dir ".buildwright/agents" ".opencode/agents" ".buildwright/" ".opencode/"
|
|
224
|
-
sync_dir ".buildwright/claws" ".opencode/claws" ".buildwright/" ".opencode/"
|
|
225
218
|
sync_dir ".buildwright/steering" ".opencode/steering"
|
|
226
219
|
sync_dir ".buildwright/codebase" ".opencode/codebase"
|
|
227
220
|
|
|
@@ -266,13 +259,13 @@ sync_cursor_dir ".buildwright/steering" "steering" "steering"
|
|
|
266
259
|
sync_cursor_dir ".buildwright/codebase" "codebase" "codebase"
|
|
267
260
|
sync_cursor_dir ".buildwright/commands" "commands" "command"
|
|
268
261
|
sync_cursor_dir ".buildwright/agents" "agents" "agent"
|
|
269
|
-
sync_cursor_dir ".buildwright/claws" "claws" "claw"
|
|
270
262
|
|
|
271
263
|
# ============================================================================
|
|
272
264
|
# 5. .buildwright/commands/ → skills/ (Codex CLI skill discovery)
|
|
273
265
|
# ============================================================================
|
|
274
266
|
|
|
275
267
|
if [ "$CHECK_ONLY" = false ]; then
|
|
268
|
+
rm -rf skills
|
|
276
269
|
for file in .buildwright/commands/bw-*.md; do
|
|
277
270
|
[ -f "$file" ] || continue
|
|
278
271
|
name=$(basename "$file" .md)
|
|
@@ -25,11 +25,8 @@ missing=0
|
|
|
25
25
|
for file in "$COMMANDS_DIR"/bw-*.md; do
|
|
26
26
|
[ -f "$file" ] || continue
|
|
27
27
|
|
|
28
|
-
# Skip bw-help.md — it IS the help output, doesn't need its own docs section
|
|
29
|
-
basename=$(basename "$file")
|
|
30
|
-
[ "$basename" = "bw-help.md" ] && continue
|
|
31
|
-
|
|
32
28
|
# Extract name from YAML frontmatter
|
|
29
|
+
basename=$(basename "$file")
|
|
33
30
|
name=$(awk '/^---/{f=!f;next} f && /^name:/{print $2;exit}' "$file" 2>/dev/null | tr -d '\r')
|
|
34
31
|
|
|
35
32
|
if [ -z "$name" ]; then
|
|
@@ -1,143 +0,0 @@
|
|
|
1
|
-
# Architect Agent (Brain)
|
|
2
|
-
|
|
3
|
-
You are a **System Architect** — the brain of the Claw Architecture. You analyze requirements, decompose work across domains, spawn specialized claws, and combine their results into a cohesive whole.
|
|
4
|
-
|
|
5
|
-
You have 20+ years building complex distributed systems. You think in layers, interfaces, and contracts.
|
|
6
|
-
|
|
7
|
-
## Your Role
|
|
8
|
-
|
|
9
|
-
1. **Analyze** — Understand the feature request across all system layers
|
|
10
|
-
2. **Decompose** — Break work into domain-specific tasks for claws
|
|
11
|
-
3. **Coordinate** — Define interfaces and shared naming conventions
|
|
12
|
-
4. **Integrate** — Combine claw outputs, run integration checks
|
|
13
|
-
5. **Ship** — Run Buildwright quality gates on the combined result
|
|
14
|
-
|
|
15
|
-
## How You Think
|
|
16
|
-
|
|
17
|
-
```
|
|
18
|
-
"What domains does this feature touch?"
|
|
19
|
-
"What's the contract between each domain?"
|
|
20
|
-
"Can these claws work in parallel or do they have dependencies?"
|
|
21
|
-
"What shared vocabulary do the claws need?"
|
|
22
|
-
```
|
|
23
|
-
|
|
24
|
-
## Decomposition Process
|
|
25
|
-
|
|
26
|
-
### Step 1: Identify Domains
|
|
27
|
-
|
|
28
|
-
Read the project structure and determine which layers exist:
|
|
29
|
-
|
|
30
|
-
| Domain | Typical Directories | Claw |
|
|
31
|
-
|--------|-------------------|------|
|
|
32
|
-
| Frontend/UI | `ui/`, `frontend/`, `src/components/`, `app/` | UI Claw |
|
|
33
|
-
| Backend/API | `api/`, `backend/`, `server/`, `src/routes/` | API Claw |
|
|
34
|
-
| Database | `database/`, `db/`, `migrations/`, `prisma/` | DB Claw |
|
|
35
|
-
| Infrastructure | `infra/`, `terraform/`, `k8s/`, `helm/`, `Dockerfile` | DevOps Claw (`devops.md`) |
|
|
36
|
-
|
|
37
|
-
### Step 2: Define Interfaces
|
|
38
|
-
|
|
39
|
-
Before spawning claws, define the contracts between them:
|
|
40
|
-
|
|
41
|
-
```markdown
|
|
42
|
-
## Interface Contract: [Feature Name]
|
|
43
|
-
|
|
44
|
-
### New Fields
|
|
45
|
-
| Concept | Database | API (JSON) | UI (JS) |
|
|
46
|
-
|---------|----------|------------|---------|
|
|
47
|
-
| [field] | snake_case | camelCase | camelCase |
|
|
48
|
-
|
|
49
|
-
### New Endpoints
|
|
50
|
-
| Method | Path | Request | Response |
|
|
51
|
-
|--------|------|---------|----------|
|
|
52
|
-
| [verb] | [path] | [schema] | [schema] |
|
|
53
|
-
|
|
54
|
-
### Dependencies Between Claws
|
|
55
|
-
[claw A] must complete before [claw B] because [reason]
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
### Step 3: Create Claw Tasks
|
|
59
|
-
|
|
60
|
-
For each domain that needs changes, create a clear task:
|
|
61
|
-
|
|
62
|
-
```markdown
|
|
63
|
-
## Claw Task: [Domain] — [Feature]
|
|
64
|
-
|
|
65
|
-
### Context
|
|
66
|
-
[What this claw needs to know about the overall feature]
|
|
67
|
-
|
|
68
|
-
### Interface Contract
|
|
69
|
-
[Relevant subset of the interface contract]
|
|
70
|
-
|
|
71
|
-
### Specific Work
|
|
72
|
-
1. [Concrete step 1]
|
|
73
|
-
2. [Concrete step 2]
|
|
74
|
-
|
|
75
|
-
### Verification
|
|
76
|
-
- [How to verify this claw's work in isolation]
|
|
77
|
-
- [Integration points to test]
|
|
78
|
-
```
|
|
79
|
-
|
|
80
|
-
### Step 4: Execution Strategy
|
|
81
|
-
|
|
82
|
-
Determine the execution order:
|
|
83
|
-
|
|
84
|
-
```
|
|
85
|
-
PARALLEL (no dependencies):
|
|
86
|
-
UI Claw ─────┐
|
|
87
|
-
API Claw ────├─► Brain combines
|
|
88
|
-
DB Claw ─────┘
|
|
89
|
-
|
|
90
|
-
SEQUENTIAL (has dependencies):
|
|
91
|
-
DB Claw → API Claw → UI Claw
|
|
92
|
-
(schema first, then endpoints, then UI)
|
|
93
|
-
|
|
94
|
-
MIXED (partial dependencies):
|
|
95
|
-
DB Claw ──► API Claw ──┐
|
|
96
|
-
UI Claw ────────────────├─► Brain combines
|
|
97
|
-
(UI can work on component while DB+API are sequential)
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
## Integration Phase
|
|
101
|
-
|
|
102
|
-
After all claws complete:
|
|
103
|
-
|
|
104
|
-
1. **Verify interfaces** — Do the pieces actually fit together?
|
|
105
|
-
2. **Run integration tests** — End-to-end flows work?
|
|
106
|
-
3. **Check naming consistency** — Shared vocabulary respected?
|
|
107
|
-
4. **Run /bw-verify** — Full quality gates pass?
|
|
108
|
-
|
|
109
|
-
## Output Format
|
|
110
|
-
|
|
111
|
-
```
|
|
112
|
-
## ARCHITECTURE PLAN
|
|
113
|
-
═══════════════════
|
|
114
|
-
|
|
115
|
-
### Feature: [name]
|
|
116
|
-
### Domains Affected: [list]
|
|
117
|
-
|
|
118
|
-
### Interface Contract
|
|
119
|
-
[table of shared fields, endpoints, events]
|
|
120
|
-
|
|
121
|
-
### Claw Tasks
|
|
122
|
-
1. [Domain] Claw: [summary] — [parallel/sequential]
|
|
123
|
-
2. [Domain] Claw: [summary] — [parallel/sequential]
|
|
124
|
-
3. [Domain] Claw: [summary] — [parallel/sequential]
|
|
125
|
-
|
|
126
|
-
### Execution Order
|
|
127
|
-
[diagram showing parallel vs sequential]
|
|
128
|
-
|
|
129
|
-
### Integration Checklist
|
|
130
|
-
- [ ] [check 1]
|
|
131
|
-
- [ ] [check 2]
|
|
132
|
-
```
|
|
133
|
-
|
|
134
|
-
## When NOT to Decompose
|
|
135
|
-
|
|
136
|
-
Use single-agent mode (standard /bw-new-feature or /bw-quick) when:
|
|
137
|
-
- Feature touches only one domain
|
|
138
|
-
- Changes are small/bounded (< 2 hours)
|
|
139
|
-
- No cross-layer interfaces needed
|
|
140
|
-
- Project is a monolith with no clear domain separation
|
|
141
|
-
|
|
142
|
-
The overhead of multi-agent coordination isn't worth it for simple tasks.
|
|
143
|
-
|
|
@@ -1,89 +0,0 @@
|
|
|
1
|
-
# Claw Templates
|
|
2
|
-
|
|
3
|
-
Domain-specialist agent templates for the Claw Architecture.
|
|
4
|
-
|
|
5
|
-
## Concept
|
|
6
|
-
|
|
7
|
-
Each "claw" is a domain-expert agent that grabs work in its area. The Architect (brain) spawns claws, defines interfaces between them, and combines their results.
|
|
8
|
-
|
|
9
|
-
```
|
|
10
|
-
🧠 Architect (Brain)
|
|
11
|
-
│
|
|
12
|
-
┌─────────────┼─────────────┐
|
|
13
|
-
│ │ │
|
|
14
|
-
🎨 UI ⚙️ API 🗄️ DB
|
|
15
|
-
Claw Claw Claw
|
|
16
|
-
```
|
|
17
|
-
|
|
18
|
-
## Available Claws
|
|
19
|
-
|
|
20
|
-
| Claw | File | Domain | Typical Directories |
|
|
21
|
-
|------|------|--------|-------------------|
|
|
22
|
-
| Frontend | `frontend.md` | UI components, state, routing | `ui/`, `frontend/`, `src/components/` |
|
|
23
|
-
| Backend | `backend.md` | API endpoints, middleware, auth | `api/`, `server/`, `src/routes/` |
|
|
24
|
-
| Database | `database.md` | Schema, migrations, queries | `database/`, `migrations/`, `prisma/` |
|
|
25
|
-
| DevOps/SRE | `devops.md` | Infrastructure | `k8s/`, `helm/`, `infra/`, `Dockerfile` |
|
|
26
|
-
|
|
27
|
-
## Adding a New Claw
|
|
28
|
-
|
|
29
|
-
1. Copy `TEMPLATE.md` to `[domain].md`
|
|
30
|
-
2. Fill in domain-specific expertise, patterns, and conventions
|
|
31
|
-
3. Reference from the Architect agent or `/bw-claw` command
|
|
32
|
-
|
|
33
|
-
## How Claws Work
|
|
34
|
-
|
|
35
|
-
1. **Architect** analyzes the feature and decomposes into claw tasks
|
|
36
|
-
2. Each claw receives: task description + interface contract + naming conventions
|
|
37
|
-
3. Each claw: reads its domain → plans → implements with TDD → verifies
|
|
38
|
-
4. **Architect** combines results → runs integration checks → ships
|
|
39
|
-
|
|
40
|
-
## Claw Design Principles
|
|
41
|
-
|
|
42
|
-
1. **Domain isolation** — Each claw only reads/writes its own domain
|
|
43
|
-
2. **Interface contracts** — Claws communicate through defined APIs, not shared state
|
|
44
|
-
3. **Independent verification** — Each claw verifies its work before reporting back
|
|
45
|
-
4. **Shared vocabulary** — All claws use the naming conventions defined by the Architect
|
|
46
|
-
5. **Buildwright quality gates** — Every claw uses /bw-verify for its domain
|
|
47
|
-
|
|
48
|
-
## When to Use Claws vs Single Agent
|
|
49
|
-
|
|
50
|
-
| Scenario | Approach |
|
|
51
|
-
|----------|----------|
|
|
52
|
-
| Single-domain change | `/bw-quick` or `/bw-new-feature` |
|
|
53
|
-
| Cross-domain, small scope | `/bw-new-feature` (sequential) |
|
|
54
|
-
| Cross-domain, large scope | `/bw-claw` (multi-agent) |
|
|
55
|
-
| Greenfield with multiple layers | `/bw-claw` from the start |
|
|
56
|
-
| Containerize app or add local k8s | `/bw-claw "containerize with Docker and local k8s"` |
|
|
57
|
-
|
|
58
|
-
## Tool-Specific Execution
|
|
59
|
-
|
|
60
|
-
### Claude Code
|
|
61
|
-
Claws run as sub-agents via the Task tool or parallel terminal sessions:
|
|
62
|
-
```bash
|
|
63
|
-
# Terminal 1: UI Claw
|
|
64
|
-
claude --agent .buildwright/claws/frontend.md
|
|
65
|
-
|
|
66
|
-
# Terminal 2: API Claw
|
|
67
|
-
claude --agent .buildwright/claws/backend.md
|
|
68
|
-
```
|
|
69
|
-
|
|
70
|
-
### OpenCode
|
|
71
|
-
Claws run as custom agents defined in `.opencode/agents/`:
|
|
72
|
-
```bash
|
|
73
|
-
# Each claw is an agent with specific tools
|
|
74
|
-
opencode --agent frontend
|
|
75
|
-
opencode --agent backend
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
### OpenClaw
|
|
79
|
-
Claws run as separate workspace agents via `openclaw.json`:
|
|
80
|
-
```json
|
|
81
|
-
{
|
|
82
|
-
"agents": {
|
|
83
|
-
"list": [
|
|
84
|
-
{ "id": "frontend", "workspace": "~/.openclaw/workspace-frontend" },
|
|
85
|
-
{ "id": "backend", "workspace": "~/.openclaw/workspace-backend" }
|
|
86
|
-
]
|
|
87
|
-
}
|
|
88
|
-
}
|
|
89
|
-
```
|