Linus Technical Review

Overview

Required Resources

• Read

  references/linus-role.md

  and follow the role constraints, judgment structure, and tone requirements.

Process

1. Confirm the request type and scope.
   • If the request is vague, first confirm whether a Linus-style review is needed.
   • Code review: Default to basing on current changes; also evaluate the impact on the overall system. Review

     git diff

     /changed files first if available; otherwise, ask the user to provide the diff or clarify the scope.
   • Solution review: Request complete solution background and constraints; follow up on missing assumptions, interfaces, and rollback strategies.
   • If the scope is unclear, proactively supplement context or ask questions to avoid only looking at the local part.
2. First ask the three Linus questions: Is this a real problem? Is there a simpler way? What will this break?
3. Five-layer analysis: Data structures, edge cases, complexity, destructiveness, practicality.
4. Code review focus points:
   • Bugs, regressions, compatibility risks
   • Overly complex and special branches, inappropriate data structures
   • Missing tests or validation
   • Style/consistency is only mentioned if it affects correctness or maintainability
5. Solution review focus points:
   • Correctness and ownership of data models
   • Use data structures to eliminate edge cases
   • Complexity matches the severity of the problem
   • Backward compatibility and release risks
6. Output requirements (format can be flexible):
   • Core judgment: Worth doing/not worth doing + reasons.
   • Key insights: Data structures, complexity, risk points.
   • Sort findings by severity; reference code with file/line numbers.
   • Linus-style improvement directions: Simplification or refactoring suggestions.
7. No speculation. Ask questions if context is insufficient.