| name | architecture-introspector |
| description | Introspect and analyze software architectures using first principles thinking, SpaceX's 5-step engineering methodology (Question, Delete, Simplify, Accelerate, Automate), and software modularity principles. This skill should be used when analyzing existing architectures, evaluating architectural decisions, identifying technical debt, planning refactoring efforts, or assessing whether architectural patterns are justified. |
| license | Complete terms in LICENSE.txt |
Architecture Introspector
Systematically analyze software architectures using first principles thinking, applying SpaceX's 5-step engineering methodology combined with software modularity principles to identify unnecessary complexity, validate architectural decisions, and recommend improvements.
Purpose
This skill provides a rigorous, principle-based framework for evaluating software architectures. It challenges inherited assumptions, identifies unjustified complexity, and applies the "delete first, optimize later" philosophy to architecture. The goal is to achieve simple, justified architectures where every component earns its existence through actual need rather than hypothetical future requirements.
When to Use This Skill
Use this skill when:
- Analyzing existing architectures - Understanding whether current architectural patterns are justified
- Evaluating architectural decisions - Questioning whether a proposed abstraction/layer/pattern is necessary
- Identifying technical debt - Finding components that add complexity without proportional value
- Planning refactoring efforts - Determining what to delete, simplify, or consolidate
- Onboarding to codebases - Understanding architectural rationale and identifying areas for improvement
- Code review of architectural changes - Ensuring new abstractions meet the 2+ consumer threshold
- Modernization efforts - Deciding what to keep, kill, or consolidate during rewrites
Core Philosophy
SpaceX's 5-Step Engineering Methodology
- Question Every Requirement - Trace decisions to their origins, challenge assumptions
- Delete the Part or Process - Remove first, optimize never (if it shouldn't exist)
- Simplify and Optimize - Only after deletion is complete
- Accelerate Cycle Time - Speed up validated, simplified processes
- Automate - Last step only, after deletion and simplification
Software Modularity Principle
"Modularity without reuse is bureaucracy"
Extract and modularize based on actual needs (2+ consumers for services/helpers, 3+ for utilities), not hypothetical futures. Premature abstraction creates overhead without benefit.
How to Use This Skill
Step 1: Load the Framework
Read the comprehensive framework from references/first_principles_framework.md:
Read references/first_principles_framework.md
This document contains:
- Detailed explanation of all 5 SpaceX principles applied to architecture
- The modularity principle and 2-3 rule
- Anti-patterns to identify
- Decision frameworks
- Output format templates
Step 2: Define the Introspection Scope
Clarify what is being analyzed:
- System-wide architecture - Entire application's structure
- Subsystem/module - Specific domain or layer
- Specific pattern - Particular architectural decision (e.g., "Should we extract this service?")
- Feature implementation - How a feature is architecturally structured
Ask the user:
- What architectural area should be analyzed?
- What specific concerns or questions exist?
- Are there performance issues, maintenance pain points, or complexity complaints?
- Is this exploratory or focused on a specific decision?
Step 3: Apply the 6-Phase Introspection Process
Follow the process defined in references/first_principles_framework.md:
Phase 1: Map Current State
- Inventory all components, layers, and abstractions
- Count consumers for each abstraction (critical for deletion phase)
- Trace data/control flow
- Document original decisions and their rationale (if discoverable)
Phase 2: Question Requirements
- For each architectural element, ask "Who required this and why?"
- Validate assumptions against current reality
- Identify cargo-culted patterns (e.g., "We use microservices because Netflix does")
- Separate hard constraints (business/technical necessities) from soft constraints (preferences)
Phase 3: Delete
Most important phase - if not occasionally adding things back, not deleting enough
Identify deletion candidates:
- Abstractions with <2 consumers → Inline them
- Layers adding no value → Remove them
- Duplicated logic → Consolidate
- Unused features → Delete
- Premature generalizations → Simplify to specific need
Apply the modularity principle rigorously:
- Services/helpers with 1 consumer → Move logic into that consumer
- Utilities used <3 times → Inline
- Frameworks for single use case → Replace with simple solution
Phase 4: Simplify
Only for components that survived deletion
- Reduce cognitive complexity
- Unify similar patterns into a single approach
- Improve naming and contracts
- Lower the learning curve
Phase 5: Accelerate
- Identify architectural bottlenecks (deployment dependencies, approval gates)
- Reduce coupling to enable parallel development
- Shorten feedback loops
- Enable incremental deployment
Phase 6: Automate
Only after deletion and simplification
- Automate validated, simplified patterns
- Create guardrails for architectural principles (e.g., linters enforcing 2+ consumer rule)
- Generate boilerplate for necessary patterns
- Build tooling for remaining complexity
Step 4: Generate Analysis Report
Produce a comprehensive report using the template from references/first_principles_framework.md. The report should include:
- Executive Summary - High-level findings and recommendations
- Current State Map - Component inventory with consumer counts
- Challenged Assumptions - Validation results for questioned requirements
- Deletion Candidates - Specific components to remove with justification
- Simplification Plan - How to reduce complexity in remaining components
- Acceleration Opportunities - Bottlenecks and coupling issues
- Automation Candidates - Patterns ready for automation
- Implementation Plan - Phased approach with specific actions
- Metrics - Before/after comparison (LOC, component count, coupling, deployment time)
Step 5: Iterate and Refine
After presenting findings:
- Address user questions and concerns
- Dive deeper into specific areas
- Adjust recommendations based on constraints or context
- Help prioritize changes by impact and risk
Critical Guidelines
The Deletion Mindset
- Start by trying to delete everything - Can always add back if needed
- Optimize nothing until deletion is complete - Most common error is optimizing something that shouldn't exist
- If not occasionally wrong about deletion, not deleting enough - Being too conservative defeats the purpose
The 2-3 Rule Enforcement
- 2+ consumers - Minimum threshold for services, helpers, shared components
- 3+ uses - Minimum for utilities, hooks, small helpers
- Below threshold - Inline the logic, embrace cohesion over decomposition
- Exception handling - Only allow exceptions with explicit justification (not "might need later")
Cargo Cult Detection
Identify patterns adopted without understanding:
- "We use X because Google/Netflix/Amazon does" (different scale, different problems)
- "Everything must be pluggable" (YAGNI - You Aren't Gonna Need It)
- "We need a service mesh for 3 services" (premature distribution)
- "Let's use microservices" (without understanding the operational complexity cost)
Question Authority (Professionally)
- Every requirement needs a name - Who decided this? Why?
- "Best practice" is not a reason - Best for whom? In what context?
- Regulations must be verified - What's the actual requirement vs. interpretation?
- "It's always been done this way" - Weakest possible justification
Common Use Cases
Use Case 1: "Should We Extract This Service?"
User asks: "Should we create a shared service for this authentication logic?"
Introspection process:
- Count consumers - How many components need this logic? (Phase 1)
- Question requirement - Why extract now vs. when 2nd consumer appears? (Phase 2)
- If <2 consumers - Don't extract, keep cohesive (Phase 3: Delete the abstraction idea)
- If 2+ consumers - Extract with simplest possible interface (Phase 4: Simplify)
Use Case 2: "Our Architecture Is Too Complex"
User complains: "It takes 15 files to add a simple feature"
Introspection process:
- Map the files - What are they? What's their purpose? (Phase 1)
- Count consumers - How many use each abstraction? (Phase 1)
- Challenge each layer - Who required it? Why? (Phase 2)
- Delete single-consumer abstractions - Inline them (Phase 3)
- Simplify what remains - Reduce ceremony (Phase 4)
Use Case 3: "Evaluating a Refactoring Plan"
User proposes: "We should create a new abstraction layer for data access"
Introspection process:
- Question the requirement - What problem does this solve? Who needs it? (Phase 2)
- Count potential consumers - Do 2+ components need this? (Phase 1)
- Consider deletion - Can we solve the problem without adding a layer? (Phase 3)
- If justified - What's the simplest implementation? (Phase 4)
Use Case 4: "Onboarding to a Codebase"
User wants to understand: "Why is this codebase structured this way?"
Introspection process:
- Map current state - Inventory components, consumers, patterns (Phase 1)
- Research decisions - Git history, commit messages, comments (Phase 2)
- Identify unjustified complexity - Single-use abstractions, cargo-cult patterns (Phase 3)
- Recommend quick wins - Low-risk deletions and simplifications (Phase 3-4)
Anti-Patterns to Flag
When analyzing architectures, specifically call out these anti-patterns:
1. Enterprise Fizz-Buzz
- 15 files to implement simple logic
- AbstractFactoryFactoryProvider patterns
- Layers upon layers with no clear value
2. Premature Abstraction
- "We might need this later" (YAGNI violation)
- Generic frameworks for single use case
- Abstraction with 0-1 consumers
3. Not-Invented-Here Syndrome
- Rebuilding proven libraries poorly
- Custom frameworks when standard ones exist
- Reinventing wheels
4. Resume-Driven Development
- Latest tech for simple problems
- Over-engineering to learn new framework
- Complexity for complexity's sake
5. Cargo Cult Architecture
- Microservices for everything
- "Netflix does it, so should we"
- Enterprise patterns in startups
Success Metrics
A successful introspection achieves:
- Fewer components - Deleted unnecessary abstractions
- Clear justifications - Every component has a validated reason to exist
- High cohesion - Related functionality stays together
- Low coupling - Independent evolution of modules
- Fast feedback - Quick from change to production
- Easy onboarding - Reduced cognitive load for new developers
- 2+ consumer rule - Every abstraction serves multiple actual (not hypothetical) needs
Output Format
Use the Architecture Analysis Report template from references/first_principles_framework.md, adapted to the scope:
- For system-wide analysis - Full 6-phase report
- For specific decisions - Focused analysis on relevant phases
- For quick evaluations - Executive summary + key findings
- For refactoring plans - Heavy emphasis on Phase 3 (deletion) and Phase 4 (simplification)
Important Notes
- Deletion is the hardest step - Pushback is natural, persist with evidence
- Question respectfully - "Who required this?" seeks understanding, not blame
- Measure before/after - Quantify improvement (LOC, component count, deployment time)
- Start small - Quick wins build momentum for larger changes
- Add back if wrong - The point is to err on the side of deletion, course-correct as needed
Integration with Development Workflows
This skill complements:
- Code review - Ensure new abstractions meet 2+ consumer threshold
- Architectural decision records (ADRs) - Validate decisions against first principles
- Refactoring planning - Systematically identify what to delete, simplify, or keep
- Technical debt assessment - Quantify unjustified complexity
- Onboarding documentation - Explain architectural rationale clearly
Examples of Good Questions to Ask
During introspection, ask:
- "This service has 1 consumer. Why is it extracted?"
- "What problem would occur if we deleted this layer?"
- "Who decided we need this abstraction? What was their reasoning?"
- "Is this pattern solving a problem we actually have or might have?"
- "Can we inline this and extract later when a 2nd consumer appears?"
- "What's the simplest thing that could possibly work?"
- "Are we optimizing something that shouldn't exist?"
Remember
The goal is not to delete everything, but to question everything and keep only what survives rigorous justification. Good architecture is defined more by what it doesn't have than by what it does have.
Most common error: Optimizing something that shouldn't exist.
Solution: Delete first, optimize never (if it shouldn't exist) or later (if it should).
