- name
- system-architect
- description
- Design complex systems from vision to validated architecture using pattern recognition, wisdom extraction, and challenge-driven validation. Use when building infrastructure, organizational systems, or any complex architecture that needs to survive hard questions before implementation.
# System Architect: From Vision to Validated Architecture
## Overview
This skill transforms raw vision into production-ready system architecture through a rigorous 5-phase process: deep understanding, pattern recognition, wisdom extraction, strategic structuring, and challenge-driven validation.
**Key Principle**: Great architecture survives hard questions. Build systems that can defend themselves before writing a single line of code.
## When to Use This Skill
Use this skill when:
- **Designing complex systems** - Multi-agent orchestration, distributed systems, organizational infrastructure
- **Building from vision** - User has a concept but needs concrete architecture
- **Validating before building** - Ensure the design is sound before investing months of work
- **Challenging assumptions** - Act as sovereign partner, not yes-person
- **Creating sellable systems** - Architecture needs to be explainable and defensible
**Do NOT use for**:
- Simple feature additions (use systematic-feature-builder)
- Bug fixes (use systematic-debugging)
- Quick prototypes (just build it)
## The 5-Phase Process
### Phase 1: Deep Understanding
**Goal**: Understand the vision, context, and constraints before proposing solutions
**Process**:
1. **Ask clarifying questions** - Don't assume, verify
- What problem are you solving?
- Who is this for? (You or customers?)
- What constraints exist? (Time, budget, team size)
- What's the success criteria?
2. **Gather existing context** - Read what already exists
- Database schemas (Supabase, etc.)
- Existing code/systems
- Previous architectural decisions
- Related skills or documentation
3. **Understand the user's operating system** - How do they work?
- Do they prefer proven patterns or novel approaches?
- What's their tolerance for complexity?
- What's their timeline/urgency?
- What's their "the right way" vs "ship fast" balance?
**Output**: Clear understanding of vision, context, and constraints documented
---
### Phase 2: Pattern Recognition
**Goal**: Identify behavioral, cognitive, strategic, and meta-patterns
**Process**:
1. **Analyze behavioral patterns** - How do they operate?
- Pressure-creation mechanisms
- Decision-making triggers
- Organizational preferences (e.g., "insanely organized")
2. **Analyze cognitive patterns** - How do they think?
- Systems thinking vs linear thinking
- Recursive patterns (fractals, hierarchies)
- Proven patterns vs novel approaches
3. **Analyze strategic patterns** - How do they approach goals?
- Infrastructure-first vs agents-first
- Snap-on modularity vs monolithic
- Visibility as control mechanism
4. **Identify meta-patterns** - Patterns of patterns
- Core operating principles
- Origin story (building what saved them)
- Evolution trajectory (where they're heading)
**Framework**: Use `/home/ubuntu/skills/brainstorm-logos/references/pattern_framework.md`
**Output**: Pattern analysis document with 5-10 major patterns identified
---
### Phase 3: Extract Gems of Wisdom
**Goal**: Pull out concentrated insights that reveal deep truths
**Process**:
1. **Look for compressed wisdom** - Single sentences that reveal how they operate
2. **Identify paradoxes** - Contradictions that point to deeper complexity
3. **Note repeated themes** - What shows up across contexts
4. **Surface unspoken assumptions** - What they take for granted
**Gem Structure**:
```
## Gem N: "[Quote or insight]"
**What this reveals**: [The underlying truth]
**The wisdom**: [What this teaches]
**The application**: [How to use this practically]
**The danger**: [What could go wrong]
```
**Output**: Gems document with 8-12 concentrated insights + meta-gem
---
### Phase 4: Strategic Structuring
**Goal**: Design the complete system architecture
**Process**:
1. **Define system overview** - High-level structure
- Hierarchy levels / layers
- Component types
- Current vs future implementation
2. **Design core protocols** - How components interact
- Identity and registration
- Authorities and constraints
- Lifecycle (spawn, execute, delegate, escalate, terminate)
3. **Create data model** - Persistence layer
- Database tables with SQL
- Indexes for performance
- Relationships and constraints
4. **Document key algorithms** - Critical logic
- Delegation protocol (when to delegate vs execute vs escalate)
- Spawning protocol (how new components are added)
- Health monitoring
5. **Design interfaces** - How humans interact with the system
- CLI tools
- Web dashboards
- Integration points
6. **Plan implementation phases** - Roadmap
- Phase 1: Foundation
- Phase 2: MVP
- Phase 3-N: Incremental expansion
- Timeline estimates
**Output**: Complete architecture document (500-1000 lines) with:
- Executive summary
- System overview
- Core protocols
- Data model
- Key algorithms
- Interface designs
- Implementation phases
- Success metrics
- Risks and mitigations
---
### Phase 5: Challenge & Validate
**Goal**: Stress-test the architecture with hard questions before implementation
**Process**:
1. **Challenge assumptions** - What are they taking for granted?
2. **Question priorities** - Is this the right problem to solve?
3. **Probe timeline** - Is "the right way" compatible with their deadline?
4. **Test feasibility** - Who actually implements this?
5. **Validate value** - What specific outcome proves this was worth it?
**Challenge Categories**:
**1. Problem Validation**
- Are you solving the right problem?
- Is this for you or customers?
- What specific outcome would prove success?
**2. Timeline & Resources**
- Is the timeline realistic for "the right way, no shortcuts"?
- Who implements this? (You, hired dev, agents?)
- What's the opportunity cost?
**3. Technical Feasibility**
- Does this technology/approach actually work?
- What are the failure modes?
- How do you enforce constraints?
**4. Scope & MVP**
- Is this the minimum to prove the concept?
- What can be cut without losing core value?
- Are you over-engineering?
**5. Integration & Dependencies**
- Does this integrate with existing systems?
- What external dependencies exist?
- What happens if a dependency fails?
**Challenge Format**:
```
## Challenge N: [Question]
**The Question**: [Specific challenge]
**Why This Matters**: [Consequences if not addressed]
**The Challenge**: [Direct question requiring commitment or pushback]
**If Yes**: [What happens next]
**If No**: [Alternative path]
```
**Output**: Challenges document with 8-12 hard questions + deepest challenge
---
## Key Principles
### 1. Understand Before Designing
Never propose architecture without deep understanding. Ask questions until you can articulate their vision better than they can.
### 2. Patterns Over Invention
Look for proven patterns from other domains (LDS Church governance → AI agents). Don't reinvent what already works.
### 3. Wisdom Over Data
10 concentrated insights beat 100 scattered observations. Extract gems that reveal deep truths.
### 4. Challenge Appropriately
Challenge when you understand deeply. Don't challenge just to challenge. But don't hold back when it matters.
### 5. Architecture Survives Questions
If the architecture can't defend itself against hard questions, it's not ready to build.
### 6. Document Everything
Create comprehensive documentation for future reference. Patterns, gems, architecture, challenges - all documented.
## Deliverables
At the end of the process, deliver:
1. **Pattern Analysis Document** (`{system-name}-pattern-analysis.md`)
- 5-10 major patterns with evidence
- Meta-patterns and core principles
- Origin story and evolution trajectory
2. **Gems of Wisdom Document** (`{system-name}-gems.md`)
- 8-12 concentrated insights
- Each with: reveals, wisdom, application, danger
- Meta-gem that ties everything together
3. **Architecture Document** (`{system-name}-architecture.md`)
- Complete technical specification
- System overview, protocols, data model
- Implementation phases and timeline
- Success metrics and risks
4. **Challenges Document** (`{system-name}-challenges.md`)
- 8-12 hard questions
- Deepest challenge that questions the premise
- Forces clarity before implementation
5. **Execution Plan** (optional, `{system-name}-execution-plan.md`)
- Week-by-week breakdown
- Deliverables and milestones
- Accountability structures
## Example: Hierarchical Agent System
**Context**: User wants to build LDS-inspired AI agent hierarchy (Wade → Apostles → PAs)
**Phase 1: Deep Understanding**
- Asked about LDS structure mapping
- Queried Maverick Town database for existing apostles
- Clarified delegation mechanics and PA roles
**Phase 2: Pattern Recognition**
- Identified 7 patterns (theologically-inspired governance, snap-on architecture, personal assistant as force multiplier, etc.)
- Found meta-pattern: "Proven patterns over innovation"
**Phase 3: Gems of Wisdom**
- 10 gems including "Build the architecture integrated with expansion capabilities like a snap-on"
- Meta-gem: "The System is the Product"
**Phase 4: Strategic Structuring**
- 782-line architecture document
- Agent protocol, data model, delegation protocol
- 12 Apostles + 12 PAs MVP
- Mission Control interface design
- 6-phase implementation plan (10 weeks)
**Phase 5: Challenge & Validate**
- 10 challenges including "Are you building this for you or customers?"
- Deepest challenge: "You might be solving the wrong problem"
- User response: "Holy shit you are right!!"
**Outcome**: Validated architecture before investing 10-20 weeks of implementation
---
## Integration with Other Skills
**Complements**:
- **/brainstorm-logos** - This skill uses brainstorm-logos patterns for Phase 2-3
- **/brainstorming** - Use brainstorming first to explore ideas, then system-architect to structure them
- **/skill-creator** - After validating architecture, create a skill to capture it
**Workflow**:
1. Use `/brainstorming` to explore the vision
2. Use `/system-architect` to design and validate architecture
3. Use `/skill-creator` to capture the process as a reusable skill
4. Use `/systematic-feature-builder` or `/subagent-driven-development` to implement
---
## Common Pitfalls
### Pitfall 1: Designing Without Understanding
**Symptom**: Proposing solutions in first 5 minutes
**Fix**: Force yourself to ask 10+ clarifying questions before proposing anything
### Pitfall 2: Agreeing Too Quickly
**Symptom**: User says "build X" and you say "great idea, let's build X"
**Fix**: Challenge the premise. "Why X? What problem does X solve? Is X the right solution?"
### Pitfall 3: Over-Engineering
**Symptom**: Architecture supports every possible future scenario
**Fix**: Design for 2x scale, not 100x. Add complexity when needed, not preemptively.
### Pitfall 4: Under-Challenging
**Symptom**: Delivering architecture without hard questions
**Fix**: If you're not making the user uncomfortable with at least 3 challenges, you're not challenging enough.
### Pitfall 5: Analysis Paralysis
**Symptom**: Spending weeks on architecture, never building
**Fix**: Set a time limit. Phase 1-5 should take 1-3 days max, then start building MVP.
---
## Success Criteria
A great system architecture has:
- ✅ Deep understanding of vision and constraints
- ✅ 5-10 patterns identified with evidence
- ✅ 8-12 gems of wisdom extracted
- ✅ Complete technical specification (500-1000 lines)
- ✅ 8-12 hard questions that challenge assumptions
- ✅ User response: "Holy shit, you're right!" or "This makes me think differently"
- ✅ Clear decision: Build it, refine it, or abandon it
---
## Templates
See `templates/` directory for:
- Pattern analysis template
- Gems of wisdom template
- Architecture document template
- Challenges document template
---
## Related Skills
- **/brainstorm-logos** - Deep pattern analysis and execution planning
- **/brainstorming** - Explore ideas through questions
- **/skill-creator** - Capture the process as a skill
- **/systematic-feature-builder** - Implement the architecture
- **/subagent-driven-development** - Build complex systems systematically
---
## Notes
- This skill requires significant time investment (1-3 days for full process)
- Works best for complex systems, not simple features
- Requires user engagement - can't do this in isolation
- The challenge phase is critical - don't skip it
- Document everything - future you will thank you
Ver en GitHub