Core

/laravel-agent:patterns

View current pattern usage (max 5 patterns per project)

Overview

The /patterns command displays the current design pattern usage in your Laravel project. It provides a comprehensive overview of which patterns are being used, where they're located, and how many slots remain available (projects are limited to a maximum of 5 patterns to maintain architectural consistency).

Usage

/laravel-agent:patterns

Examples

# View current pattern usage
/laravel-agent:patterns

What Gets Analyzed

The command scans your codebase to detect the following design patterns:

Pattern Detection Method Typical Location
Repository Files matching *Repository.php app/Repositories/
Action Files matching *Action.php in Actions directory app/Actions/
Service Files matching *Service.php in Services directory app/Services/
DTO Readonly classes ending with Data app/Data/
Strategy Classes implementing *Strategy interfaces app/Strategies/
Observer Files in Events directory app/Events/

How It Works

The command executes a three-step process to generate the pattern usage report:

1. Read Pattern Registry

First, it checks for an existing pattern registry file that tracks officially registered patterns:

cat .ai/patterns/registry.json 2>/dev/null || echo '{"patterns": [], "limit": 5}'

2. Scan Codebase

Next, it performs automated detection of patterns throughout your application code:

# Count Repository pattern implementations
find app -name "*Repository.php" 2>/dev/null | wc -l

# Count Action pattern implementations
find app/Actions -name "*Action.php" 2>/dev/null | wc -l

# Count Service pattern implementations
find app/Services -name "*Service.php" 2>/dev/null | wc -l

# Count DTO pattern implementations (readonly Data classes)
grep -r "readonly class.*Data" app/ --include="*.php" -l 2>/dev/null | wc -l

# Count Strategy pattern implementations
grep -r "implements.*Strategy" app/ --include="*.php" -l 2>/dev/null | wc -l

# Count Observer pattern implementations (Events)
find app/Events -name "*.php" 2>/dev/null | wc -l

3. Generate Report

Finally, it compiles the results into a comprehensive report showing:

  • Current pattern usage count (X out of 5 maximum)
  • A table listing each detected pattern with counts and locations
  • Number of available pattern slots remaining
  • List of all available patterns you can implement

Example Output

A typical pattern report looks like this:

## Pattern Registry

### Usage: 3/5 patterns

| Pattern    | Count | Location              |
|------------|-------|-----------------------|
| Repository | 8     | app/Repositories/     |
| Action     | 12    | app/Actions/          |
| DTO        | 15    | app/Data/             |

### Available Slots: 2

### Available Patterns
Repository, DTO, Strategy, Action, Factory, Pipeline, Observer, QueryObject, Presenter, Builder

Pattern Limit Rationale

The 5-pattern limit is an architectural guardrail designed to:

  1. Prevent over-engineering - Too many patterns increase complexity without proportional benefit
  2. Encourage consistency - A focused set of patterns is easier for teams to learn and apply correctly
  3. Maintain readability - Fewer patterns mean less cognitive load when navigating the codebase
  4. Promote pragmatism - Forces thoughtful selection of patterns that truly add value

Available Design Patterns

The Laravel Agent supports these design patterns:

  • Repository - Data access abstraction layer
  • DTO (Data Transfer Object) - Type-safe data structures using readonly classes
  • Strategy - Interchangeable algorithms or behaviors
  • Action - Single-purpose, focused business logic classes
  • Factory - Object creation abstraction
  • Pipeline - Sequential processing of data through stages
  • Observer - Event-driven communication between objects
  • QueryObject - Encapsulated complex database queries
  • Presenter - View-specific data formatting
  • Builder - Step-by-step object construction

Best Practices

  1. Choose patterns wisely - Only adopt patterns that solve real problems in your codebase
  2. Run regularly - Check pattern usage before adding new patterns to avoid exceeding the limit
  3. Document decisions - Keep the pattern registry updated to track intentional architectural choices
  4. Consolidate when possible - If approaching the limit, consider whether some patterns can be merged or eliminated
  5. Follow conventions - Use consistent naming and directory structures for each pattern

See Also