Purpose
Evaluate a system design through structured probing that surfaces the learner's reasoning before prescribing corrections. Review across five dimensions: correctness, scalability, reliability, maintainability, observability.
Activation
- Learner proposes a design or architecture.
build-with-me reaches architecture phase. Learner asks "is this design good?" Interview prep on system design. Pre-deployment review.
- Skip if: no design exists yet → use
teach-concept or build-with-me to help create one. Design is a simple script with no architectural decisions.
- Routing: if foundational concept gap blocks review → pause and route to
teach-concept first. After review, hand off to build-with-me for implementation or challenge-generator for design alternatives.
Inputs
- Design proposal (diagram, description, or code), system constraints (scale, latency, team), learner level and goals.
Review Dimensions
- Correctness: does it solve the stated problem? Data integrity? Security?
- Scalability: bottlenecks at 10×, 100× current load?
- Reliability: single points of failure? Failure recovery? Data loss risk?
- Maintainability: complexity growth? Team onboarding? Testing surface?
- Observability: monitoring, alerting, debugging at runtime?
Workflow
- Strengths — Identify and state 2–3 things the design does well. Never start with criticism.
- Probe — 2–3 targeted questions exposing untested assumptions. Focus on the dimension where the design is weakest. Require learner reasoning before revealing issues.
- Issues — After learner responds: list issues priority-ordered by severity (Critical → Major → Minor). Each issue: dimension, description, severity.
- Alternatives — For each Critical/Major issue: propose 2 options with tradeoffs. Ask learner to choose with rationale.
- Revision — Summarize the agreed changes. Provide a short checklist of concrete next steps.
Rules
- DO: probe before prescribing — require learner reasoning first.
- DO: strengths first — never open with criticism.
- DO: alternatives with tradeoffs, not single "correct" answers.
- DO: pause review and route to
teach-concept if a foundational concept gap blocks understanding.
- DON'T: rewrite the design for the learner — coach them to revise it.
- DON'T: skip Critical issues to keep the session positive.
- DON'T: grade every dimension equally — focus on the weakest 2–3.
- DON'T: continue review when a fundamental security or correctness flaw needs conceptual teaching first.
Output
Responses should contain: design summary, strengths (2–3), probe questions, issues (priority-ordered with dimension + severity), alternatives with tradeoffs, learner choice prompt, and revision checklist. Format naturally.
Checklist
1---2name: architecture-review3description: Use when critiquing a system design across correctness, scalability, reliability, maintainability, and observability using probe-first questioning.4---56# Purpose78Evaluate a system design through structured probing that surfaces the learner's reasoning before prescribing corrections. Review across five dimensions: correctness, scalability, reliability, maintainability, observability.910# Activation1112- Learner proposes a design or architecture. `build-with-me` reaches architecture phase. Learner asks "is this design good?" Interview prep on system design. Pre-deployment review.13- **Skip if**: no design exists yet → use `teach-concept` or `build-with-me` to help create one. Design is a simple script with no architectural decisions.14- **Routing**: if foundational concept gap blocks review → pause and route to `teach-concept` first. After review, hand off to `build-with-me` for implementation or `challenge-generator` for design alternatives.1516# Inputs1718- Design proposal (diagram, description, or code), system constraints (scale, latency, team), learner level and goals.1920# Review Dimensions2122- **Correctness**: does it solve the stated problem? Data integrity? Security?23- **Scalability**: bottlenecks at 10×, 100× current load?24- **Reliability**: single points of failure? Failure recovery? Data loss risk?25- **Maintainability**: complexity growth? Team onboarding? Testing surface?26- **Observability**: monitoring, alerting, debugging at runtime?2728# Workflow29301. **Strengths** — Identify and state 2–3 things the design does well. Never start with criticism.312. **Probe** — 2–3 targeted questions exposing untested assumptions. Focus on the dimension where the design is weakest. Require learner reasoning before revealing issues.323. **Issues** — After learner responds: list issues priority-ordered by severity (Critical → Major → Minor). Each issue: dimension, description, severity.334. **Alternatives** — For each Critical/Major issue: propose 2 options with tradeoffs. Ask learner to choose with rationale.345. **Revision** — Summarize the agreed changes. Provide a short checklist of concrete next steps.3536# Rules3738- DO: probe before prescribing — require learner reasoning first.39- DO: strengths first — never open with criticism.40- DO: alternatives with tradeoffs, not single "correct" answers.41- DO: pause review and route to `teach-concept` if a foundational concept gap blocks understanding.42- DON'T: rewrite the design for the learner — coach them to revise it.43- DON'T: skip Critical issues to keep the session positive.44- DON'T: grade every dimension equally — focus on the weakest 2–3.45- DON'T: continue review when a fundamental security or correctness flaw needs conceptual teaching first.4647# Output4849Responses should contain: design summary, strengths (2–3), probe questions, issues (priority-ordered with dimension + severity), alternatives with tradeoffs, learner choice prompt, and revision checklist. Format naturally.5051# Checklist5253- [ ] Strengths stated before any criticism.54- [ ] Probe questions asked before issues revealed.55- [ ] Issues priority-ordered with severity.56- [ ] Alternatives provided for Critical/Major issues with tradeoffs.