emerge/architecture-methodology
Enforces a 4-phase architecture design workflow by reading `.arch/state.json` on every request to gate responses by phase. Phase 1 extracts and validates requirements from PRDs; Phase 2 selects architecture patterns and establishes high-level structure; Phase 3 designs and accepts components sequentially; Phase 4 finalises and documents the solution. Use when discussing system design, solution architecture, PRD analysis, component design, technology selection, or architecture patterns — distinct from general coding help by its strict phase-gating, anti-pattern detection, and state-tracked component acceptance.
93
97%
Does it follow best practices?
Impact
89%
1.07xAverage score across 5 eval scenarios
Passed
No known issues
Evaluation results
93%
30%Analyse Requirements for a Handmade Marketplace Platform
Phase 1 Execution and NFR Capture
Functional requirements
100%
100%
Availability NFR
40%
100%
Security NFR
100%
100%
Cost NFR
25%
100%
Monitoring NFR
0%
100%
Constraints identified
100%
100%
Risks identified
100%
100%
Phase 1 marked accepted in state
0%
53%
No technology recommendations
84%
100%
No component design details
100%
100%
77%
22%Respond to a Developer's Request During Requirements Gathering
Phase Boundary Enforcement
No tech recommendation
0%
50%
No architecture pattern
0%
13%
No component design
66%
100%
Explicit redirect
75%
100%
Phase gate referenced
100%
100%
Future path stated
100%
100%
100%
Review an Architecture Proposal for a Healthcare Analytics Platform
Anti-Pattern Detection
Flags unjustified technology
100%
100%
Asks for alternatives
100%
100%
Flags over-engineering
100%
100%
Flags missing availability NFR
100%
100%
Flags missing security NFR
100%
100%
Flags missing monitoring NFR
100%
100%
Challenges deferral
100%
100%
Challenges copy-paste
100%
100%
Does not approve
100%
100%
98%
-1%Propose Architecture Methodology for a Retail Inventory Platform
Phase 2 Methodology Proposal
Pattern chosen
100%
100%
Pattern justified
100%
100%
Component list defined
100%
100%
Technology stack specified
100%
100%
Technology rationale provided
100%
100%
Cross-cutting concerns addressed
100%
100%
Phase 2 marked accepted in state
100%
100%
No component API contracts
100%
100%
No detailed tech config
90%
80%
Linked to Phase 1 requirements
100%
100%
80%
-20%Continue Component Design for a Logistics Route Optimisation Platform
Phase 3 Sequential Component Design
Auth Service designed
100%
100%
No Notification Service design
100%
100%
Auth Service status updated
100%
0%
Notification Service status unchanged
100%
100%
No finalization transition
100%
100%
- Evaluated
- Agent
- Claude Code
- Model
- Claude Sonnet 4.6
Table of Contents