Claude Code command For developers

Design Review (command)

Contributed by Rohit Ghumare (awesome-claude-code-toolkit)

Source: original file · added 2026-10-29

Conduct a structured design review of a module, feature, or system component.

Steps

  1. Identify the scope of review from the argument (module path, feature name, or PR number).
  2. Map the component boundaries:
    • Entry points (APIs, event handlers, CLI commands).
    • Internal modules and their responsibilities.
    • External dependencies and integration points.
    • Data flow from input to output.
  3. Evaluate against design principles:
    • Single Responsibility: Does each module have one clear purpose?
    • Dependency Direction: Do dependencies flow inward (clean architecture)?
    • Interface Segregation: Are interfaces minimal and focused?
    • Error Handling: Are failures handled consistently and explicitly?
    • Testability: Can components be tested in isolation?
  4. Check for common anti-patterns:
    • God objects or modules with too many responsibilities.
    • Circular dependencies between modules.
    • Leaky abstractions exposing internal implementation.
    • Configuration scattered across multiple locations.
  5. Assess scalability and operational concerns:
    • Can this handle 10x current load?
    • What are the failure modes and recovery paths?
    • Is observability built in (logging, metrics, tracing)?
  6. Produce a structured review with actionable recommendations.

Format

php
## Design Review: <Component Name>

### Architecture Score: <1-5>/5

### Strengths
- What is well designed

### Concerns
- CRITICAL: Issues that need immediate attention
- WARNING: Issues to address before next milestone

### Recommendations
1. Specific actionable improvement
2. Specific actionable improvement

### Diagram
<Mermaid diagram of current architecture>

Rules

  • Be constructive; pair every criticism with a concrete suggestion.
  • Focus on structural issues, not cosmetic ones.
  • Consider the team's current constraints and pragmatic tradeoffs.
  • Reference specific files and line numbers where applicable.
Original source file (unmodified)

Conduct a structured design review of a module, feature, or system component. ## Steps 1. Identify the scope of review from the argument (module path, feature name, or PR number). 2. Map the component boundaries: - Entry points (APIs, event handlers, CLI commands). - Internal modules and their responsibilities. - External dependencies and integration points. - Data flow from input to output. 3. Evaluate against design principles: - **Single Responsibility**: Does each module have one clear purpose? - **Dependency Direction**: Do dependencies flow inward (clean architecture)? - **Interface Segregation**: Are interfaces minimal and focused? - **Error Handling**: Are failures handled consistently and explicitly? - **Testability**: Can components be tested in isolation? 4. Check for common anti-patterns: - God objects or modules with too many responsibilities. - Circular dependencies between modules. - Leaky abstractions exposing internal implementation. - Configuration scattered across multiple locations. 5. Assess scalability and operational concerns: - Can this handle 10x current load? - What are the failure modes and recovery paths? - Is observability built in (logging, metrics, tracing)? 6. Produce a structured review with actionable recommendations. ## Format ``` ## Design Review: <Component Name> ### Architecture Score: <1-5>/5 ### Strengths - What is well designed ### Concerns - CRITICAL: Issues that need immediate attention - WARNING: Issues to address before next milestone ### Recommendations 1. Specific actionable improvement 2. Specific actionable improvement ### Diagram <Mermaid diagram of current architecture> ``` ## Rules - Be constructive; pair every criticism with a concrete suggestion. - Focus on structural issues, not cosmetic ones. - Consider the team's current constraints and pragmatic tradeoffs. - Reference specific files and line numbers where applicable.

Our network