Architect

Architect — Software Architecture Design

Activate When

• User invokes /godmode:architect
• User says "design the architecture", "system architecture", "architectural design", "system design"
• User asks about monolith vs. microservices, serverless, or event-driven decisions
• When starting a greenfield project that needs structural decisions
• When /godmode:think identifies architecture as the primary concern
• When a system is hitting scaling, reliability, or maintainability walls

Workflow

Step 1: Context & Requirements Gathering

Understand the system before recommending architecture:

ARCHITECTURE CONTEXT:
System: 
Stage: 

Step 2: Architecture Pattern Evaluation

Evaluate candidate patterns against the requirements. Always evaluate at least 3 patterns:

Pattern Evaluation Template

For each candidate (evaluate at least 3), fill:

PATTERN: 
├── Structure: 
├── Strengths: 
├── Weaknesses: 
└── Best when: 

Candidate patterns: Modular Monolith, Microservices, Serverless/FaaS, Event-Driven, CQRS, Hexagonal (Ports & Adapters). Evaluate the top 3-6 for the system.

Step 3: Architecture Comparison Matrix

Present a structured comparison:

  ARCHITECTURE COMPARISON — 

Step 4: C4 Architecture Diagrams

Produce diagrams at all four C4 levels for the chosen architecture:

Level 1: System Context

Who uses the system and what external systems does it interact with?

C4 CONTEXT DIAGRAM:
  Users / Actors

Level 2: Container Diagram

What are the major deployable units?

C4 CONTAINER DIAGRAM:
  > 

Level 3: Component Diagram

What are the major components within each container?

C4 COMPONENT DIAGRAM — :
  > API Service

Level 4: Code Diagram

What are the key classes/modules and their relationships?

C4 CODE DIAGRAM — :
Show key interfaces, classes, and their relationships.
Use the codebase's actual language idioms (classes for Java/C#,

Step 5: Domain-Driven Design — Strategic View

Map bounded contexts and their relationships:

BOUNDED CONTEXT MAP:

Step 6: Quality Attribute Analysis

For the recommended architecture, analyze non-functional requirements:

QUALITY ATTRIBUTES:
| Attribute | How the architecture addresses it |

Step 7: Architecture Decision Record

Document the decision formally:

# ADR-: 

## Status

Step 8: Artifacts & Transition

1. Save architecture document: docs/architecture/-architecture.md
2. Save ADR: docs/adr/-.md
3. Save diagrams inline in the architecture document
4. Commit: "architect: — architecture with C4 diagrams and ADR"
5. Suggest next steps:

• "Architecture designed. Run /godmode:ddd to define domain boundaries and aggregates."
• "Architecture designed. Run /godmode:plan to decompose into implementation tasks."
• "Architecture designed. Run /godmode:api to design the API layer."

Key Behaviors

Never ask to continue. Loop autonomously until architecture comparison matrix, C4 diagrams, and ADR are complete.

# Analyze architecture dependencies and coupling
npx madge --circular --extensions ts src/
npx dependency-cruiser --validate .dependency-cruiser.cjs src/

IF team size 10 on any module: refactor to reduce. IF circular dependencies > 0: break cycles before adding features.

1. Requirements before patterns. Understand scale, team, constraints.
2. Compare >= 3 options. Comparison matrix forces rigor.
3. C4 diagrams mandatory. Minimum Level 1 + Level 2.
4. Trade-offs are honest. Every pattern has real downsides.
5. ADRs capture the "why." Reasoning, not just decision.
6. Bounded contexts before microservices. Map first, split second.
7. Validate against the team. Best arch = team can build it.

Output Format

Print on completion:

ARCHITECTURE: {system_name}
Pattern: {selected_pattern} (scored {weighted_total} vs {runner_up_score} for {runner_up})
C4 diagrams: {levels_produced} levels produced

TSV Logging

Log every architecture session to .godmode/architect-results.tsv:

timestamp	system	pattern_selected	patterns_compared	c4_levels	bounded_contexts	quality_attrs	adr_number	verdict

Append one row per session. Create the file with headers on first run.

Quality Targets

• Target: 80% code coverage on core modules
• Target: 0 circular dependencies between bounded contexts
• Max coupling: 30%: adapt. Document. |

| Vendor lock-in risk | Add adapter/port layer. Abstract behind interface. | | Performance bottleneck | Profile first. Add caching/async before restructuring. |

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: arbazkhan971
• Source: arbazkhan971/godmode
• License: MIT

Install and usage instructions live in the source repository linked above.