Skip to main content

system-architect

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.

Ir a la instalación

Datos de origen

Repositorio
abcnuts/manus-skills
Última actividad en el origen
12 de febrero de 2026 a las 04:11
Idioma detectado de SKILL.md
inglés
Estrellas
69
Forks
46

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
6 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
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