feat(skill): code review skill spectrum

[KemingHe]

Related

• feat(skill): add idiomatic-review skill #101: idiomatic-review skill (level 1)
• feat(skill): add design-pattern-review skill #102: design-pattern-review skill (level 2)

Problem

Code review feedback spans multiple levels of abstraction. The skill catalog currently has no structured approach to code review at any level. Issues #101 and #102 address levels 1 and 2, but the broader spectrum needs a roadmap to avoid ad-hoc skill creation and ensure each skill has a clear, non-overlapping scope.

Proposed Spectrum

Level	Skill Name	Scope	Status
1 - Language idioms	idiomatic-review	Single expression or statement: language-native constructs, built-ins, standard library usage	Active (#101)
2 - Code design	design-pattern-review	Function, class, or component: DI, composition vs inheritance, guard clauses, strategy pattern, error handling patterns	Active (#102)
3 - Module design	TBD	Package boundaries, dependency direction, circular imports, public API surface, layering	Parked
4 - Application architecture	TBD	Whole-app structural decisions: MVC, hexagonal, clean architecture	Parked
5 - System design	TBD	Multi-service, infrastructure, distributed systems	Parked

Design Principles

• Each level is a standalone skill with no dependency on other levels
• All skills are language-agnostic with auto language detection
• Composable with other skills (e.g., senior-mentor) via loose coupling
• SOLID principles cut across levels 2-4 and are referenced within relevant skills rather than forming their own skill
• Each skill includes a self-contained triage report template for structured output (see cross-cutting concern below)

Cross-Cutting Concern: Triage Report Template

All code review skills in this spectrum should include a structured triage report as their output format:

| Tier | Location | Current Pattern | Suggested Pattern | Reference |
| :--- | :--- | :--- | :--- | :--- |
| High/Medium/Low | File + line range or function/class name | What the code does now | The suggested alternative | Doc link (when available) |

Each skill defines its own triage template independently for self-containment, but implementers should be aware that sibling skills use a parallel format to enable consistent user experience across review levels.

Parked Items

Level 3 - Module design

• Naming: "module-design-review" is ambiguous across language ecosystems (Python module vs TypeScript module vs Go package)
• Scope limitation: Module-level review requires whole-codebase context (import graphs, package structure, dependency direction) which is harder for a lightweight skill to deliver reliably without project-specific configuration
• Action: Revisit naming and feasibility after levels 1-2 are implemented and field-tested

Level 4 - Application architecture

• Scope limitation: Whole-app structural decisions are highly context-dependent and opinionated, making a generic skill harder to deliver without project-specific configuration
• Action: Revisit after levels 1-3 are explored

Level 5 - System design

• Scope limitation: Multi-service and infrastructure concerns extend beyond single-codebase review into deployment, networking, and operational domains
• Action: Revisit if demand emerges from levels 1-4 usage