Force the review scope to converge onthe five dimensions most likely to cause a proposal to structurally fail. For each dimensionreflective questions, based on the answers construct averifiable failure chain("if X → then Y → ultimately Z fails"), then provide aminimal alternative design。
When to Use
- The user asks to review a proposal, stress-test a design, or asks "what structural problems does this proposal have".
- The user wantsan improvement plan that can continue to move forward, not a list of risks.
Working Method
1. Confirm the review object and boundaries
Restate the proposal's goals, constraints,scope: and scope, listing facts, assumptions, and decisive unknowns separately. When uncertain, stop guessing and ask the user rather than silently choosing.
2. Enforce the five reflective dimensions
Dimension 1: Is the path planning clear?
- Can the chain from start to end beenumerated segment by segment? Are there vague segments of "do this first and figure it out later"?
- Is the data flow unidirectional and traceable? Is the data structure defined first and the logic filled in afterward, or is it the reverse with dependency inversion?
- Are initialization and loading order clear? Are there circular dependencies, implicit timing, or things that happen to work due to runtime order?
- How large is the blast radius? How many modules are affected by changing this step? Where is the rollback path?
Dimension 2: Are module responsibilities clear?
- Does this modulehave the name it should have? Do the name and the actual logic match, and are there abbreviations in the external interface?
- Can you say in one sentence theone thingit does? If you cannot say it clearly, it has mixed multiple things.
- Is code for "compatibility/fallback/temporary/effective only in a specific mode" mixed into the main path?
- Are trust boundary validation and business invariantsexplicitly expressed, or scattered everywhere and left to comments as reminders?
Dimension 3: Has extensibility worsened?
- How many places need to change to add a similar requirement?The same code appearing three timesis a sign it should be refactored.
- Are mutually exclusive states expressed with one
state, or is there a pile ofbooleach maintained separately? - Can the change be expressed withdata structures, or is it forced through process control (if/switch)?
- Are edge caseseliminated(unified into the main path), or patched one by one with ifs?
Dimension 4: Has decision-making made a choice error?
- Is the technology selection based on real constraints (performance, ecosystem, team familiarity), or decided based on impressions/popularity? Have alternatives been compared?
- Does the chosen tool/framework/library truly match the scenario? Is it using a cannon to shoot mosquitoes, or forcing the wrong tool to fit?
- Is the tool being used in a way consistent with its design intent? Are there anti-pattern uses, bypassing official recommendations, or inventing a custom set of conventions?
- Has the decision ladder been skipped (standard library > platform native > existing dependencies > smaller model > only then write code)?
Dimension 5: Does the artifact cause project pollution?
- Do new files/directories conform to the existingplanning and hierarchy? Do they break directory responsibilities or create orphan directories?
- Do the changes produce orphan code (unused imports, dead variables, functions invalidated by the changes)?
- Is the naming compliant: external interfaces not abbreviated, variables semantic rather than numbered, boolean functions starting with
is? - Is the artifacteasy to accept? During design, were the testing rules thought through, can it be located via Log, or can it only rely on manual review?
3. Output format
For each reflection point, produce a before/after comparison and integrate them into a markdown table:
| Feature | Before | After |
|---|---|---|
| <feature description> | <the original approach and its flaws> | <alternative design> |
| ... | ... | ... |
It is not limited to code; it also applies to architecture design, change impact, solution decisions, and process design.