OpenClaw v2

AGENTS.md Additions for Compound Engineering

These are exact changes to make to existing AGENTS.md files. Each section specifies WHERE to insert, WHAT to insert, and WHY.

1. Gary's AGENTS.md

File: /Users/agents/.openclaw/workspace-gary/AGENTS.md

Change A: Add "Parallel Swarm Pattern" Section

WHERE: After the "Safety" section (end of file, line 132)

WHAT TO INSERT:

hljs markdown[object Object],

When a build or review task has 3+ independent dimensions that can run simultaneously, use compound engineering instead of sequential execution.

,[object Object],

| Situation | Use |
|-----------|-----|
| Perry, Harry, or Cory building features in parallel | ,[object Object], + ,[object Object], -- each agent gets its own branch |
| Post-build review (security, performance, architecture) | ,[object Object], via Task tool -- reviewers don't write code |
| Research across multiple domains (market, technical, legal) | ,[object Object], via Task tool -- independent research tasks |
| Single agent needs to build one thing | ,[object Object], -- direct ,[object Object], to the agent |

,[object Object],

Spawn specialists via the Task tool with ,[object Object], set to the specialist path:

Task({ subagent_type: "compound-engineering:review:security-sentinel", prompt: "..." }) Task({ subagent_type: "compound-engineering:review:performance-oracle", prompt: "..." }) Task({ subagent_type: "compound-engineering:review:architecture-strategist", prompt: "..." })


All spawns fire BEFORE waiting for ANY to complete. Sequential spawning defeats the purpose.

### Available Specialist Types for Gary's Domain

**Review specialists (post-build):**
- `compound-engineering:review:security-sentinel` -- vulnerability scan, auth flows, input validation
- `compound-engineering:review:performance-oracle` -- bottlenecks, N+1 queries, bundle size, caching
- `compound-engineering:review:architecture-strategist` -- coupling, boundaries, extensibility, patterns
- `compound-engineering:review:code-simplicity-reviewer` -- unnecessary complexity, dead code, readability
- `compound-engineering:review:data-integrity-guardian` -- schema validation, migration safety, data consistency
- `compound-engineering:review:test-coverage-analyzer` -- coverage gaps, edge cases, test quality
- `compound-engineering:review:dependency-risk-assessor` -- outdated deps, license issues, supply chain risk
- `compound-engineering:review:accessibility-compliance-checker` -- WCAG compliance, screen reader, keyboard nav

**Research specialists (pre-build):**
- `compound-engineering:research:framework-docs-researcher` -- current docs, API changes, migration guides
- `compound-engineering:research:technical-debt-archaeologist` -- tech debt mapping, refactor opportunities

### Cleanup Protocol

After a compound engineering swarm completes and findings are synthesized:
1. Collect all specialist outputs
2. Synthesize into a single remediation list
3. Spawn Perry/Harry to fix issues (if needed) via `sessions_spawn` with worktrees
4. The Task tool handles specialist lifecycle automatically -- no manual cleanup needed

### Integration with Build Workflow

In the 6-Phase Build Process, the compound engineering review swarm runs AFTER the build phase as a separate review step:

1. Phases 1-5 proceed as normal (Plan, Spec, Build, Test, Deploy-Prep)
2. **After Phase 3 (BUILD):** Spawn review swarm (security-sentinel + performance-oracle + architecture-strategist run simultaneously)
3. Synthesize review findings into a remediation list
4. Spawn Perry/Harry to fix issues before proceeding to Phase 4 (TEST)
5. Continue with Phase 4-6 once remediation is complete

WHY: Gary needs to know when and how to use compound engineering specialists versus traditional worktree-based parallel builds. The review swarm is Gary's primary use case -- running security, performance, and architecture reviews simultaneously after a build completes, rather than sequentially. This section documents the spawn syntax, available specialist types, and how the pattern integrates with the existing build workflow.

Change B: Add Build Phase Note

WHERE: If Gary's AGENTS.md ever includes a "Build Workflow (6-Phase Process)" section, add to Phase 3 (BUILD):

WHAT TO INSERT:

hljs markdown[object Object],

WHY: Ensures the review swarm is not forgotten during builds. The review step catches security, performance, and architecture issues before they reach testing, when they are cheaper to fix.

2. Lacie's AGENTS.md

File: /Users/agents/.openclaw/workspace-main/AGENTS.md

Change A: Add "When Gary Uses Compound Engineering Swarms" Section

WHERE: After the "Platform Formatting" section (end of file, line 127)

WHAT TO INSERT:

hljs markdown[object Object],

For complex builds, Gary may spawn a parallel review swarm using compound engineering specialists (security-sentinel, performance-oracle, architecture-strategist, etc.). These are Claude Code subagents that run via the Task tool, not OpenClaw named agents.

,[object Object],
,[object Object], Review results collect in Gary's Task tool output, NOT via Telegram or sessions,[object Object]

WHY: Lacie delegates builds to Gary and monitors progress. When Gary uses compound engineering, the communication pattern changes -- results flow through the Task tool rather than Telegram. Without this section, Lacie might wonder why she is not receiving individual specialist reports or try to track down ephemeral subagents that no longer exist.