• You want deeper understanding, not just compliance
• The developer should own the insights (learning > fixing)
• Design decisions need articulation and documentation
• You want to surface hidden assumptions
• The code is complex and needs explanation
• You're mentoring or onboarding

• Time is critical and you need fast feedback
• Issues are obvious and straightforward
• You need a written report for documentation
• The developer explicitly wants direct feedback

• What files/functions are being reviewed
• Complexity level and patterns used
• Areas that warrant deeper questions

• Design: Why was this approach chosen?
• Edge Cases: What happens in unusual situations?
• Clarity: How would you explain this?
• Philosophy: Does this follow project principles?
• Failure Modes: What could go wrong?
• Testing: How do you know it works?

**Q1** [Category: Design]
Why did you choose to store session data in memory rather than a database?

[WAIT FOR YOUR RESPONSE]

• Ask a follow-up question if the answer reveals uncertainty
• Move to the next question if understanding is solid
• Note insights for the final synthesis

• Insights Revealed: What became clear through dialogue
• Assumptions Surfaced: Hidden assumptions that were exposed
• Recommendations: What should change based on the dialogue
• Strengths: What you clearly understood well

• Small bug fixes
• Simple changes
• Obvious code

• Feature implementations
• Refactoring
• Typical PRs

• Security-sensitive code
• Core infrastructure
• Architectural changes

Your answer: "It was simpler to implement and we don't have many users yet."

Your answer: "Um... I guess when we scale? Or add multiple servers?"

Your answer: "I... actually haven't thought about that."

• Session storage is pragmatic but migration path unclear
• Session timeout during active use is unhandled

• Single server deployment assumption
• Users won't have long form submissions

1. Document session storage migration criteria
2. Add graceful session timeout handling

• Clear awareness of simplicity trade-offs
• Quick recognition of gaps when prompted

undefined

1. Be specific: "It handles null by returning empty array" is better than "It should be fine"
2. Acknowledge uncertainty: "I'm not sure what happens" is valuable - it reveals gaps
3. Think out loud: Explain your reasoning, not just the answer
4. Ask for clarification: If a question is unclear, say so

1. Each question and response is captured
2. Insights are noted inline
3. At the end, a synthesis is produced
4. You can use

   --write-decisions

   to persist insights to DECISIONS.md

1. All questions are asked rhetorically
2. Agent analyzes code to identify likely issues
3. Structured JSON output is produced
4. Output can be posted to PR comments automatically

claude --print

• Not a test: There are no wrong answers
• Not criticism: Questions explore, not judge
• Not a checklist: Questions adapt to your code and answers
• Not replacement for tests: This is for understanding, not verification

1. Feynman Technique: Teaching reveals gaps in understanding
2. Socratic Method: Questions create deeper insight than answers
3. Rubber Duck Debugging: Explaining forces thoroughness
4. Pair Programming: Dialogue catches what solo work misses

• Agent:

  ~/.amplihack/.claude/agents/amplihack/specialized/socratic-reviewer.md

• Traditional Review:

  /reviewing-code

  skill for direct feedback
• Philosophy Check:

  philosophy-guardian

  agent for compliance

1. Parse arguments (file path, depth level, focus)
2. Read and analyze the target code
3. Invoke the socratic-reviewer agent with context
4. Facilitate the dialogue, waiting for user responses
5. Synthesize findings at the end

Task(
  subagent_type="socratic-reviewer",
  prompt="Conduct Socratic review of [file] at [depth] level. Focus on: [areas]"
)