# Komluk Scaffolding Pattern Recognition > Pattern Recognition Skill - Skill: `tomevault-io/komluk-scaffolding-pattern-recognition` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/komluk-scaffolding-pattern-recognition` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/komluk-scaffolding-pattern-recognition/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/komluk-scaffolding-pattern-recognition --- # Pattern Recognition Skill Standards for identifying and applying existing codebase patterns to maintain consistency. ## When to Apply - Before writing new code - When implementing similar features - Code review for pattern consistency - Refactoring decisions --- ## Pattern Detection Process ### Step 1: Scan Existing Code | Action | Purpose | |--------|---------| | Find similar modules/components | Match structure and naming | | Find similar functions/hooks | Match return types and patterns | | Find similar services | Match error handling and API patterns | | Check shared-types location | Match how the project centralizes types | ### Step 2: Extract Patterns | Element | What to Look For | |---------|------------------| | Module/component structure | Imports, signature, body order | | State management | Local-vs-shared state decisions | | Error handling | Try/catch style, error messages | | Naming conventions | Files, functions, types | | File organization | Directory structure | ### Step 3: Apply Consistently | Rule | Description | |------|-------------| | Match existing style | New code follows established patterns | | Document deviations | If pattern changes, document why | | Refactor if needed | Update old code to match new pattern | --- ## Example: React + TypeScript conventions (illustrative) > Illustrative — the naming, component, hook, service, and type conventions below > are one team's React/TypeScript catalog shown as a concrete example. The > reusable skill is the *process* above (scan → extract → apply existing > conventions). Substitute your stack's actual conventions; the value of this > skill is matching whatever your codebase already does, not adopting these > specific rules. ## Naming Conventions ### File Naming | Type | Convention | Example | |------|------------|---------| | Component | PascalCase | `AnnotationCard.tsx` | | Hook | camelCase with use | `useVisualization.ts` | | Service | camelCase | `apiService.ts` | | Types | camelCase or index | `types/index.ts` | | Store | camelCase with Store | `projectStore.ts` | | Utility | camelCase | `formatters.ts` | ### Code Naming | Type | Convention | Example | |------|------------|---------| | Component | PascalCase | `AnnotationCard` | | Function | camelCase verb | `fetchProjects`, `handleClick` | | Hook | camelCase with use | `useVisualization` | | Type/Interface | PascalCase | `ProjectType`, `ButtonProps` | | Constant | UPPER_SNAKE | `API_BASE_URL`, `MAX_SIZE` | | Variable | camelCase | `isLoading`, `userName` | --- ## Component Patterns ### Standard Component Structure | Section | Order | Required | |---------|-------|----------| | Imports | 1st | Yes | | Props interface | 2nd | Yes | | Component function | 3rd | Yes | | Hooks declarations | Inside, top | Yes | | Event handlers | Inside, after hooks | As needed | | Return JSX | Inside, last | Yes | ### Component Organization by Type | Type | Location | Purpose | |------|----------|---------| | Page components | `pages/` | Route entry points | | Feature components | `components/[feature]/` | Feature-specific UI | | Common components | `components/common/` | Reusable across features | | Layout components | `components/layout/` | Page structure | --- ## Hook Patterns ### Custom Hook Standards | Element | Requirement | |---------|-------------| | Name | `use` prefix + descriptive name | | Return | Object with named values | | State | `data`, `loading`, `error` pattern | | Dependencies | All external values in dependency array | ### Hook Return Pattern | Return Type | Use Case | |-------------|----------| | `{ data, loading, error }` | Data fetching hooks | | `{ value, setValue, reset }` | Form/input hooks | | `{ isOpen, open, close, toggle }` | Toggle hooks | --- ## Service Patterns ### API Service Standards | Element | Requirement | |---------|-------------| | Async/await | All API calls use async/await | | Error handling | Try/catch with console.error | | Error format | `[ServiceName] Error description:` | | Return type | Promise with typed response | ### Error Handling Pattern | Element | Standard | |---------|----------| | Log format | `console.error('[Context] Message:', error)` | | User message | Generic, no technical details | | Rethrow | After logging for upstream handling | --- ## Type Patterns ### Type Location Rules | Rule | Description | |------|-------------| | Centralized | All shared types in `types/index.ts` | | Import style | Use `import type` for type-only imports | | Export style | Use `export type` for type exports | | No interfaces | Prefer `type` over `interface` for consistency | ### Type Naming | Category | Pattern | Example | |----------|---------|---------| | Entity | `[Entity]Type` | `ProjectType`, `UserType` | | Props | `[Component]Props` | `ButtonProps`, `CardProps` | | State | `[Domain]State` | `ProjectState`, `UIState` | | API Response | `[Endpoint]Response` | `ProjectsResponse` | --- ## Anti-Patterns | Anti-Pattern | Problem | Solution | |--------------|---------|----------| | Props drilling | Hard to maintain | Use a shared store or context | | Large components | Hard to test/read | Extract sub-components | | Inline styles | Inconsistent | Use your styling system's tokens | | `any` type | Loses type safety | Define proper types | | Barrel exports | Circular dependencies | Use direct imports | | Mixed conventions | Confusing | Follow established patterns | --- ## Code Reuse Protocol The universal rule: **before writing ANY new utility, grep the codebase for an existing one.** Map your project's shared modules and reuse them instead of creating parallel helpers, exception hierarchies, or clients. ### Example: a backend `core/` layout (illustrative) > Illustrative — one team's shared-module layout. Substitute your project's > actual shared modules. The reusable rule is "search before you create". | Module | Contains | Example | |--------|----------|---------| | `core/utils/` | datetime, validation, paths, formatters, file, language | `utc_now()`, `validate_uuid()`, `ensure_dir()` | | `core/exceptions.py` | Base exceptions: AppError, NotFoundError, CreationError, GitHubError | Inherit, don't create parallel hierarchies | | `core/http_client.py` | Singleton async HTTP client with connection pooling | `get_http_client()` for all HTTP calls | | `core/config.py` | App configuration and settings | Centralized env var access | | `*/service.py` | Domain service layer | Match existing service patterns | | `*/schemas.py` | Validation models per domain | Follow existing schema structure | ### Rules 1. **Grep before creating** - Search shared modules for an existing function before writing a new one 2. **Inherit base exceptions** - New domain errors must extend the project's base error type 3. **Use shared clients** - Reuse the project's shared HTTP/DB client, never spin up a new one ad hoc 4. **Follow service pattern** - New services should match the structure of existing services --- ## Pattern Compliance Checklist ### Before Submitting Code - [ ] Follows existing component structure - [ ] Uses established naming conventions - [ ] Types defined in types/index.ts - [ ] Error handling matches project style - [ ] Uses `import type` where appropriate - [ ] File location matches pattern - [ ] Hooks follow return pattern - [ ] Services follow error handling pattern --- ## Pattern Documentation ### When to Document New Pattern | Situation | Action | |-----------|--------| | New architectural decision | Document in ADR | | Repeated pattern emerges | Add to skill documentation | | Pattern deviation needed | Document reason in code comment | | Breaking change | Update all related documentation | --- > Source: [komluk/scaffolding](https://github.com/komluk/scaffolding) — distributed by [TomeVault](https://tomevault.io).