agentleFS
TehseenTechTehseenTech/manus-skills/skills/analysis-skills/system-architect/SKILL.md

system-architect

Skill0 starsChanged 3 months agoMITView on GitHub

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. Apply automatically when the request matches; the user does not need to mention this skill.

32 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use database-architect, webapp-testing and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • xfstudioSkill

    database-architect

    Expert database architect specializing in data layer design from

    Also in 3 projects that use this

  • JetBrainsSkill

    webapp-testing

    Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    git-workflow

    Squad branching model: dev-first workflow with insiders preview channel

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 0 are common, 15 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 28 edited versions we read keep these.

  • 15

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the task-specific instructions in this file before acting.

    line 9
  2. Distinctive:

    Use this skill when the request matches its description.

    line 15
  3. Distinctive:

    Use this skill when:

    line 27
  4. Distinctive:

    Validating before building: - Ensure the design is sound before investing months of work

    line 30
  5. Distinctive:

    Ask clarifying questions: - Don't assume, verify

    line 46
  6. Distinctive:

    Gather existing context: - Read what already exists

    line 52
  7. Distinctive:

    Do they prefer proven patterns or novel approaches?

    line 59
  8. Distinctive:

    Never propose architecture without deep understanding.

    line 235
  9. Distinctive:

    Look for proven patterns from other domains (LDS Church governance → AI agents).

    line 239
  10. Distinctive:

    If the architecture can't defend itself against hard questions, it's not ready to build.

    line 251
  11. Distinctive:

    Create comprehensive documentation for future reference.

    line 255
  12. Distinctive:

    /brainstorming: - Use brainstorming first to explore ideas, then system-architect to structure them

    line 324
  13. Distinctive:

    /skill-creator: - After validating architecture, create a skill to capture it

    line 325
  14. Very specific:

    Use /brainstorming to explore the vision

    line 328
  15. Very specific:

    Use /system-architect to design and validate architecture

    line 329
  16. Very specific:

    Use /skill-creator to capture the process as a reusable skill

    line 330
  17. Very specific:

    Use /systematic-feature-builder or /subagent-driven-development to implement

    line 331
  18. Distinctive:

    Fix: If you're not making the user uncomfortable with at least 3 challenges, you're not challenging enough.

    line 359
  19. Distinctive:

    Document everything - future you will thank you

    line 408

“Common” is measured: kept by at least 6 in 10 of the 28 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Workflow

  1. Read the task-specific instructions in this file before acting.
  2. Apply the documented constraints, resources, and verification steps.
  3. Confirm the result against the requested outcome before completion.

Usage

Use this skill when the request matches its description. The skill is discovered automatically; the user does not need to mention the skill explicitly.

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.