Architecture review
Find choices that could make a technical proposal wrong, unsafe, or impossible
to prove. Review the proposed behavior and tradeoffs, not the document's size
or format.
Use one fresh subagent that did not write the proposal. Give the reviewer the
complete context. Tell the reviewer to work directly without delegating. If
you are that reviewer, review directly. Stay read-only.
If fresh subagents are unavailable, stop and report that independent review is
blocked. Continue only if the user explicitly accepts a documented self-review.
Process
- Read the goal, proposal, repository instructions, relevant current code,
tests, schemas, configuration, and linked material. Treat claims about the
current system as unverified until code, tests, schemas, configuration,
infrastructure, or relevant runtime evidence supports them.
- State the problem, affected user, intended outcome, success measure, scope,
constraints, and main tradeoff. Report any that the proposal leaves unclear.
- Trace one real case from input to observable outcome. Include ownership,
validation, state changes, side effects, response timing, failure, retry,
cleanup, and what the user sees where they matter.
- Challenge the chosen design with the review focus below. Look for a simpler
choice that reaches the same outcome and proof with less state, coupling,
duplication, or operational work.
- Surface material open questions. Recommend an answer when evidence supports
one. Do not invent questions that cannot change the design.
- Return findings, open questions, a short assessment, and one verdict.
Do not rewrite the proposal, plan the work, review implementation code, or
implement changes.
Review focus
- Check fit with the current system, ownership, boundaries, interfaces, data,
compatibility, migration, rollout, and rollback.
- Trace partial failure, retry, cancellation, concurrency, startup, shutdown,
and recovery where they affect the proposal.
- Check claimed scale, limited resources, latency, throughput, storage, cost,
dependency failure, and operator recovery only where they can change the choice.
- Check identity, authorization, untrusted input, credentials, destructive
authority, and sensitive data handling.
- Require observable acceptance criteria and proof for important rules and
failure paths. Do not let implementation invent user-visible behavior,
interfaces, data rules, security policy, or failure behavior.
Material questions
Report an open question only when two capable implementations could answer it
differently in a way that affects users, data, interfaces, security, scale,
performance, operations, cost, compatibility, or proof.
- Blocking: implementation should not start without the answer.
- Important: the proposal should record the answer, but the reviewer can
recommend a safe default from available evidence.
Omit questions that are stylistic, safely local to implementation, outside the
stated scope, or speculative beyond the scale the proposal claims to support.
Findings
Report only flaws that can change the design or its safety:
- Blocker: the choice is unsafe, contradicts the goal or current system, or
cannot recover from an important failure.
- Important: the proposal permits materially different implementations or
leaves a meaningful risk in behavior, scale, performance, security,
operations, compatibility, or proof.
For each finding or open question include its location, concrete failure or
ambiguity, impact, evidence, and the smallest correction or recommended answer.
Report unclear wording when it prevents a new teammate from explaining,
evaluating, or implementing the design. Omit other writing preferences.
Use plain words. State the exact condition, failure, and effect. Do not hide an
unknown behind vague language such as may have issues or could be risky.
Verdict
Approve: no blocker or important findings or open questions remain.Request changes: the proposal has a fixable blocker or important finding or
open question.Blocked: the review lacks required context, repository evidence, specialist
coverage, or an independent reviewer.
State what remains unverified. Do not approve because the document is detailed
or because every template section exists.
1---2name: architecture-review3description: Reviews a technical proposal before implementation. Use for designs, RFCs, ADRs, architecture proposals, and issues that define how a system change should work. Finds material ambiguity and flaws in correctness, scalability, performance, security, operations, and proof.4---5
6# Architecture review
7
8Find choices that could make a technical proposal wrong, unsafe, or impossible
9to prove. Review the proposed behavior and tradeoffs, not the document's size
10or format.
11
12Use one fresh subagent that did not write the proposal. Give the reviewer the
13complete context. Tell the reviewer to work directly without delegating. If
14you are that reviewer, review directly. Stay read-only.
15
16If fresh subagents are unavailable, stop and report that independent review is
17blocked. Continue only if the user explicitly accepts a documented self-review.
18
19## Process
20
211. Read the goal, proposal, repository instructions, relevant current code,
22 tests, schemas, configuration, and linked material. Treat claims about the
23 current system as unverified until code, tests, schemas, configuration,
24 infrastructure, or relevant runtime evidence supports them.
252. State the problem, affected user, intended outcome, success measure, scope,
26 constraints, and main tradeoff. Report any that the proposal leaves unclear.
273. Trace one real case from input to observable outcome. Include ownership,
28 validation, state changes, side effects, response timing, failure, retry,
29 cleanup, and what the user sees where they matter.
304. Challenge the chosen design with the review focus below. Look for a simpler
31 choice that reaches the same outcome and proof with less state, coupling,
32 duplication, or operational work.
335. Surface material open questions. Recommend an answer when evidence supports
34 one. Do not invent questions that cannot change the design.
356. Return findings, open questions, a short assessment, and one verdict.
36 Do not rewrite the proposal, plan the work, review implementation code, or
37 implement changes.
38
39## Review focus
40
41- Check fit with the current system, ownership, boundaries, interfaces, data,
42 compatibility, migration, rollout, and rollback.
43- Trace partial failure, retry, cancellation, concurrency, startup, shutdown,
44 and recovery where they affect the proposal.
45- Check claimed scale, limited resources, latency, throughput, storage, cost,
46 dependency failure, and operator recovery only where they can change the choice.
47- Check identity, authorization, untrusted input, credentials, destructive
48 authority, and sensitive data handling.
49- Require observable acceptance criteria and proof for important rules and
50 failure paths. Do not let implementation invent user-visible behavior,
51 interfaces, data rules, security policy, or failure behavior.
52
53## Material questions
54
55Report an open question only when two capable implementations could answer it
56differently in a way that affects users, data, interfaces, security, scale,
57performance, operations, cost, compatibility, or proof.
58
59- **Blocking:** implementation should not start without the answer.
60- **Important:** the proposal should record the answer, but the reviewer can
61 recommend a safe default from available evidence.
62
63Omit questions that are stylistic, safely local to implementation, outside the
64stated scope, or speculative beyond the scale the proposal claims to support.
65
66## Findings
67
68Report only flaws that can change the design or its safety:
69
70- **Blocker:** the choice is unsafe, contradicts the goal or current system, or
71 cannot recover from an important failure.
72- **Important:** the proposal permits materially different implementations or
73 leaves a meaningful risk in behavior, scale, performance, security,
74 operations, compatibility, or proof.
75
76For each finding or open question include its location, concrete failure or
77ambiguity, impact, evidence, and the smallest correction or recommended answer.
78Report unclear wording when it prevents a new teammate from explaining,
79evaluating, or implementing the design. Omit other writing preferences.
80
81Use plain words. State the exact condition, failure, and effect. Do not hide an
82unknown behind vague language such as `may have issues` or `could be risky`.
83
84## Verdict
85
86- `Approve`: no blocker or important findings or open questions remain.
87- `Request changes`: the proposal has a fixable blocker or important finding or
88 open question.
89- `Blocked`: the review lacks required context, repository evidence, specialist
90 coverage, or an independent reviewer.
91
92State what remains unverified. Do not approve because the document is detailed
93or because every template section exists.
owainlewis