13 Operating Modes
Talk to @buildcrew naturally. It auto-detects the mode from your message.
| Mode | Example | Pipeline |
|---|---|---|
| Feature | "Add user dashboard" | Plan → Design → Dev → QA → Browser QA → Review |
| Project Audit | "full project audit" | Scan → Prioritize → Fix → Verify |
| Browser QA | "browser qa localhost:3000" | Playwright tests + health score |
| Security | "security audit" | OWASP + STRIDE + secrets + deps |
| Debug | "debug: login broken" | 4-phase root cause investigation |
| Health | "health check" | Quality dashboard (0-10 score) |
| Canary | "canary https://myapp.com (opens in a new tab)" | Post-deploy monitoring |
| Review | "code review" | Multi-specialist + auto-fix |
| Ship | "ship" | Test → version → changelog → PR |
| QA Audit | "qa" | 3 parallel subagent audit on git diff |
| Think | "is this worth building?" | 6 forcing questions + design doc |
| Arch Review | "architecture review" | Scope + diagrams + failure modes |
| Design Review | "design review" | 8-dimension scoring + fixes |
Mode Priority
When a message matches multiple modes, a priority table resolves conflicts:
- Debug always wins (bug/error/broken)
- Think beats Feature ("is this worth", "should we build")
- Security beats Review ("security", "vulnerability")
- Specific reviews beat generic Review (architecture, design, QA audit)
- Feature is the default fallback
If truly ambiguous, the orchestrator asks you to choose.
Second Opinion
After any mode completes, buildcrew offers an independent second opinion:
- Codex CLI available: different AI model reviews the work
- No Codex: fresh Claude subagent with no session memory
Iterations
Each iteration runs the full pipeline from scratch:
@buildcrew Add user dashboard, 5 iterations