Pattern Recognition

---
name: pattern-recognition
description: Identify existing codebase patterns (naming conventions, architectural patterns, testing patterns) to maintain consistency. Use when generating code, reviewing changes, or understanding established practices. Ensures new code aligns with project conventions.
---

# Pattern Recognition

## When to Use

- Before writing new code to ensure consistency with existing patterns
- During code review to verify alignment with established conventions
- When onboarding to understand project-specific practices
- Before refactoring to preserve intentional design decisions

## Core Methodology

### Pattern Discovery Process

1. **Survey representative files**: Read 3-5 files of the type you will create or modify
2. **Identify recurring structures**: Note repeated patterns in naming, organization, imports
3. **Verify intentionality**: Check if patterns are documented or consistently applied
4. **Apply discovered patterns**: Use the same conventions in new code

### Priority Order for Pattern Sources

1. **Existing code in the same module/feature** - Most authoritative
2. **Project style guides or CONTRIBUTING.md** - Explicit documentation
3. **Test files** - Often reveal expected patterns and naming
4. **Similar files in adjacent modules** - Fallback when no direct examples exist

## Naming Convention Recognition

### File Naming Patterns

Detect and follow the project's file naming style:

| Pattern | Example | Common In |
|---------|---------|-----------|
| kebab-case | `user-profile.ts` | Node.js, Vue, Angular |
| PascalCase | `UserProfile.tsx` | React components |
| snake_case | `user_profile.py` | Python |
| camelCase | `userProfile.js` | Legacy JS, Java |

### Function/Method Naming

Identify the project's verb conventions:

- **get** vs **fetch** vs **retrieve** for data access
- **create** vs **add** vs **new** for creation
- **update** vs **set** vs **modify** for mutations
- **delete** vs **remove** vs **destroy** for deletion
- **is/has/can/should** prefixes for booleans

### Variable Naming

Detect pluralization and specificity patterns:

- Singular vs plural for collections (`user` vs `users` vs `userList`)
- Hungarian notation presence (`strName`, `iCount`)
- Private member indicators (`_private`, `#private`, `mPrivate`)

## Architectural Pattern Recognition

### Layer Identification

Recognize how the codebase separates concerns:

```
COMMON LAYERING PATTERNS:
- MVC: controllers/, models/, views/
- Clean Architecture: domain/, application/, infrastructure/
- Hexagonal: core/, adapters/, ports/
- Feature-based: features/auth/, features/billing/
- Type-based: components/, services/, utils/
```

### Dependency Direction

Identify import patterns that reveal architecture:

- Which modules import from which (dependency flow)
- Shared vs feature-specific code boundaries
- Framework code vs application code separation

### State Management Patterns

Recognize how state flows through the application:

- Global stores (Redux, Vuex, MobX patterns)
- React Context usage patterns
- Service layer patterns for backend state
- Event-driven vs request-response patterns

## Testing Pattern Recognition

### Test Organization

Identify how tests are structured:

| Pattern | Structure | Example |
|---------|-----------|---------|
| Co-located | `src/user.ts`, `src/user.test.ts` | Common in modern JS/TS |
| Mirror tree | `src/user.ts`, `tests/src/user.test.ts` | Traditional, Java-style |
| Feature-based | `src/user/`, `src/user/__tests__/` | React, organized features |

### Test Naming Conventions

Detect the project's test description style:

- **BDD style**: `it('should return user when found')`
- **Descriptive**: `test('getUser returns user when id exists')`
- **Function-focused**: `test_get_user_returns_user_when_found`

### Test Structure Patterns

Recognize Arrange-Act-Assert or Given-When-Then patterns:

- Setup block conventions (beforeEach, fixtures, factories)
- Assertion style (expect vs assert vs should)
- Mock/stub patterns (jest.mock vs sinon vs manual)

## Code Organization Patterns

### Import Organization

Identify import ordering and grouping:

```
COMMON IMPORT PATTERNS:
1. External packages first, internal modules second
2. Grouped by type (React, libraries, local)
3. Alphabetized within groups
4. Absolute imports vs relative imports preference
```

### Export Patterns

Recognize module boundary conventions:

- Default exports vs named exports preference
- Barrel files (index.ts re-exports) presence
- Public API definition patterns

### Comment and Documentation Patterns

Identify documentation conventions:

- JSDoc/TSDoc presence and style
- Inline comment frequency and style
- README conventions per module/feature

## Best Practices

- **Follow existing patterns even if imperfect** - Consistency trumps personal preference
- **Document deviations explicitly** - When breaking patterns intentionally, explain why
- **Pattern changes require migration** - Dont introduce new patterns without updating existing code
- **Check tests for patterns too** - Test code often reveals expected conventions
- **Prefer explicit over implicit** - When patterns are unclear, ask or document assumptions

## Anti-Patterns to Avoid

- Mixing naming conventions in the same codebase
- Introducing new architectural patterns without team consensus
- Assuming patterns from other projects apply here
- Ignoring test patterns when writing implementation
- Creating "special" files that dont follow established structure

## References

- `examples/common-patterns.md` - Concrete examples of pattern recognition in action