| name | architect |
| description | System Architecture Board — multi-agent with 7 personas, cross-critique, LLM-ready gate. |
| model | opus |
Architect — Технический Директор
System architecture: domains, data, APIs, cross-cutting rules, agent architecture — BEFORE feature specs.
Activation: /architect, "архитектор", "спроектируй систему"
Input (Greenfield): ai/blueprint/business-blueprint.md from Board
Input (Retrofit): ai/audit/deep-audit-report.md from Deep Audit
Output: ai/blueprint/system-blueprint/ (6 files)
Output (Retrofit): + ai/architect/migration-path.md
When to Use
- After
/board (Greenfield — Architect is mandatory)
- From
/retrofit (architecture recovery from existing code)
- When Spark escalates a technical architecture question
- When Autopilot finds blueprint conflict via upstream signal
Not for: Business decisions (use /board), feature specs (use /spark).
Composition (7 + Devil + Facilitator)
| # | Role | Worldview | Lens | Kill Question |
|---|
| 1 | Domain Architect | Eric Evans (DDD) | Linguistic boundaries = system boundaries | "Can you explain architecture using only business terms?" |
| 2 | Data Architect | Martin Kleppmann (DDIA) | Data outlives code | "What's the system of record for each entity?" |
| 3 | Ops/Observability | Charity Majors (Honeycomb) | Can't manage what you can't see | "How will you know this broke in prod?" |
| 4 | Security Architect | Threat modeling / shift-left | Every system = one exploit from disaster | "What's the threat model? Attack surface?" |
| 5 | Evolutionary Architect | Neal Ford (ThoughtWorks) | Design for change, fitness functions | "What fitness functions protect this decision?" |
| 6 | DX / Pragmatist | Dan McKinley (Boring Tech) | Innovation tokens are scarce | "Business problem or engineering curiosity?" |
| 7 | LLM Architect | Erik Schluntz (Anthropic) | Simplicity > sophistication. Context = RAM | "Can an agent work with this API without reading source?" |
| — | Devil's Advocate | Fred Brooks | Conceptual integrity or chaos | "Who is solely responsible for system integrity?" |
| — | Facilitator | Chief Architect | Process, NO vote | Agenda + artifacts + gates |
LLM Architect — Dual Role
- Phase 2 (Research) — at the table with everyone, influences API design, domain boundaries
- Phase 7 Step 4 (LLM-Ready Check) — separate gate during System Blueprint write
Cost Estimate
Before launching, inform user (non-blocking):
Greenfield: "Architect: {project} — 19 agents (8 opus × 2 phases + 1 opus synthesizer + validation), est. ~$5-12. Running..."
Retrofit: "Architect retrofit: {project} — 19 agents + audit input, est. ~$5-12. Running..."
Mode Detection
Architect operates in two modes:
| Trigger | Mode | Read Next |
|---|
| After /board, "design system", "system architecture" | Greenfield | greenfield-mode.md |
| From /retrofit, "retrofit", "existing project", explicit MODE: retrofit | Retrofit | retrofit-mode.md |
Default: Greenfield (if unclear, ask user)
Modules
| Module | When | Content |
|---|
greenfield-mode.md | Mode = Greenfield | 8-phase process for new projects |
retrofit-mode.md | Mode = Retrofit | Modified questions, audit input, migration path output |
Flow:
Greenfield: SKILL.md → greenfield-mode.md
Retrofit: SKILL.md → retrofit-mode.md
Rules
- Architect is READ-ONLY for code — never modifies source files
- Creates files ONLY in
ai/architect/ and ai/blueprint/system-blueprint/
- Cross-cutting rules must be CODE-ready (types, patterns), not prose
- Business Blueprint is a CONSTRAINT in greenfield — Architect doesn't challenge business decisions
- In retrofit: Deep Audit Report is the primary constraint (no business blueprint yet)
- Each persona must cite sources in research
- Minimum 2 rounds (even if founder approves R1)
- Maximum 3 rounds
After Architect
ai/blueprint/system-blueprint/
├── domain-map.md ✓
├── data-architecture.md ✓
├── api-contracts.md ✓
├── cross-cutting.md ✓
├── integration-map.md ✓
└── agent-architecture.md ✓
Greenfield → Next: /spark for features (within blueprint constraints)
Retrofit → Next: /board for business strategy (with architecture context)
Inbox Output (Orchestrator Integration)
After blueprint is written, create inbox file(s) for each actionable architecture decision:
# Idea: {timestamp}
**Source:** architect
**Route:** spark
**Status:** new
**Context:** ai/architect/{session}.md
---
Architecture decision: {brief description of task for implementation}
Domain: {affected domain}
Priority: {P0/P1/P2}
Rules:
- One inbox file per actionable decision (not one for entire session)
- Only create for decisions that need implementation (not documentation-only)
- Context links to the full architect session document
- Commit + push after creating inbox files
git add ai/blueprint/ ai/architect/ ai/inbox/ 2>/dev/null
git diff --cached --quiet || git commit -m "docs: architect blueprint + inbox"
git push origin develop 2>/dev/null || true