komlukkomluk/scaffolding/skills/pattern-recognition/SKILL.md

pattern-recognition

Skill16 starsChanged 4 days agoMITView on GitHub

Identify and apply existing codebase patterns for consistency. TRIGGER when: writing new code that should match conventions, or reviewing code for pattern drift. SKIP: language-specific patterns (use python-patterns or react-patterns); security review (use security-review-checklists); should this exist (use necessity-first).

4 other projects use a version of this.

Adopted by

Most recently taken up by

GiangGiangTran/ba-skillstheir own version, first seen Oct 20, 2026
xiejianjun000/FlowWikitheir own version, first seen Jul 27, 2026
rudraksha132/pattern-recognitiontheir own version, first seen Jul 19, 2026
VAMFI/claude-user-memorytheir own version, first seen Nov 23, 2025

Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
VAMFI/claude-user-memory★ 206same name
GiangGiangTran/ba-skills★ 8same name
xiejianjun000/FlowWiki★ 4same name
rudraksha132/pattern-recognition★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository39 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- agent-commsSkill
- agent-memorySkill
- api-designSkill
- context-engineeringSkill
- database-optimizationSkill
- distillSkill
- docker-templatesSkill
- error-handlingSkill
- frontend-designSkill
- github-actions-templateSkill
- git-operationsSkill
- logging-standardsSkill
- mcp-toolsSkill
- monitoring-observabilitySkill
- mui-stylingSkill
- necessity-firstSkill
- planning-methodologySkill
- python-patternsSkill
- quality-validationSkill
- react-patternsSkill
- research-methodologySkill
- reverse-engineer-anythingSkill
- security-review-checklistsSkill
- semantic-memory-mcpSkill
- skill-authoringSkill
- sofa-searchSkill
- spec-designSkill
- spec-developSkill
- spec-researchSkill
- spec-reviewSkill
- spec-workflowSkill
- state-managementSkill
- systematic-debuggingSkill
- testing-strategySkill
- ui-ux-pro-maxSkill
- verification-before-completionSkill
- watch-patternsSkill
- worktree-managementSkill

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

0
Common
Most of the 3 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Before writing new code
line 12
Distinctive:
When implementing similar features
line 13
Distinctive:
Grep before creating: - Search shared modules for an existing function before writing a new one
line 194

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

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

Grep before creating - Search shared modules for an existing function before writing a new one
Inherit base exceptions - New domain errors must extend the project's base error type
Use shared clients - Reuse the project's shared HTTP/DB client, never spin up a new one ad hoc
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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free