Files
Rohit Ghumare c3f43d8b61 Expand toolkit to 135 agents, 120 plugins, 796 total files
- Add 60 new agents across all 10 categories (75 -> 135)
- Add 95 new plugins with command files (25 -> 120)
- Update all agents to use model: opus
- Update README with complete plugin/agent tables
- Update marketplace.json with all 120 plugins
2026-02-04 21:08:28 +00:00

1.9 KiB

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.