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
1.07x
Quality
97%
Does it follow best practices?
Impact
89%
1.07xAverage score across 5 eval scenarios
Securityby
Passed
No known issues
criteria.jsonevals/scenario-4/
{
"context": "Tests whether the agent produces a complete Phase 2 methodology output covering all three sub-phases (2A pattern, 2B component map, 2C cross-cutting concerns) — and correctly marks all three sub-phase acceptance flags and advances `phases.methodology.status` to `accepted` in state.json — while avoiding component implementation details, API contracts, and detailed tech configurations.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Pattern chosen",
"description": "phase2-methodology.md names a specific architecture pattern (e.g. modular monolith, microservices, event-driven)",
"max_score": 8
},
{
"name": "Pattern justified",
"description": "phase2-methodology.md provides a rationale for why the chosen pattern fits the requirements, constraints, or team context",
"max_score": 10
},
{
"name": "Component list defined",
"description": "phase2-methodology.md includes a list of high-level components or modules (at least 3)",
"max_score": 8
},
{
"name": "Technology stack specified",
"description": "phase2-methodology.md names specific technologies for at least two distinct concerns (e.g. language, database, infrastructure)",
"max_score": 8
},
{
"name": "Technology rationale provided",
"description": "phase2-methodology.md explains the rationale for each or most technology choices — not just a list",
"max_score": 8
},
{
"name": "Cross-cutting concerns addressed",
"description": "phase2-methodology.md (or a separate phase2-cross-cutting.md) documents at least two cross-cutting decisions such as authentication, observability, data consistency, or security posture",
"max_score": 12
},
{
"name": "Phase 2 marked accepted in state",
"description": "The output .arch/state.json has `phases.methodology.status` set to `\"accepted\"`, all three sub-phase flags set to `true` (`pattern_accepted`, `components_overview_accepted`, `cross_cutting_accepted`), and `current_phase` advanced to `\"components\"`",
"max_score": 15
},
{
"name": "No component API contracts",
"description": "phase2-methodology.md does NOT include specific API endpoint definitions, request/response schemas, or data models for individual components",
"max_score": 10
},
{
"name": "No detailed tech config",
"description": "phase2-methodology.md does NOT include detailed technology configurations (e.g. specific database index settings, Kubernetes manifests, environment variable lists)",
"max_score": 10
},
{
"name": "Linked to Phase 1 requirements",
"description": "phase2-methodology.md references at least one constraint, NFR, or requirement from Phase 1 when justifying the pattern or technology choices",
"max_score": 11
}
]
}