backend-patterns
Skill0 starsChanged 5 months agoMITView on GitHub
Scans the codebase to auto-detect backend code conventions (controllers, services, entities, DTOs, DI registration) and caches them. Use when creating or modifying backend code so new files follow existing patterns exactly.
88 other projects use a version of this.
Adopted by
Most recently taken up by
- Rojios/everything-claude-codetheir own version, first seen Nov 8, 2026
- lhbsaa/apex-unifiedtheir own version, first seen Nov 8, 2026
- ahmadvahidi/skill-atlastheir own version, first seen Nov 8, 2026
- Ashfaqbs/ai-coding-agent-toolkittheir own version, first seen Nov 8, 2026
- Lukk17/agent-standardstheir own version, first seen Nov 7, 2026
- XD3an/cc-plustheir own version, first seen Nov 7, 2026
Used with
Projects with it also use everything-claude-code, investor-materials and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
InfopibeSkilleverything-claude-code
Also in 10 projects that use this
InfopibeSkillinvestor-materials
Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
Also in 29 projects that use this
niloykumarbarmanSkillagent-sort
Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
Also in 10 projects that use this
tpavanipradeepSkillbun-runtime
Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
Also in 21 projects that use this
mryeastcodeSkilleverything-claude-code-conventions
Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
Also in 8 projects that use this
gongyijie85Skillunified-memory
Share durable, inspectable context and handoffs between Claude, Codex, Hermes, Cursor, OpenCode, and other agents through the local ECC Memory Vault. Use when an agent must save work state, transfer context, resume another agent's task, or search shared project knowledge.
Also in 4 projects that use this
- +1 more from Infopibe
Other versions88 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 88
- affaan-m/ECC★ 246ksame name
- YosemiteCrew/Yosemite-Crew★ 2ksame name
- xu-xiang/everything-claude-code-zh★ 1.9ksame name
- loulanyue/awesome-claude-notes★ 272same name
- cloudnative-co/claude-code-starter-kit★ 153same name
- tpavanipradeep/everything-claude-code★ 104same name
- mturac/everything-openai-codex★ 89same name
- mit-network/everything-claude-code★ 76same name
- tranhieutt/software_development_department★ 71same name
- Fmarzochi/EGC★ 61same name
78 more not listed
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 repository38 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- api-contract-validationSkill
- architecture-scannerSkill
- auto-approve-policySkill
- auto-learningSkill
- branch-syncSkill
- browser-testSkill
- browseSkill
- build-checkSkill
- cache-refreshSkill
- codebase-explainerSkill
- coding-standardsSkill
- commit-styleSkill
- context-switchingSkill
- continuous-learningSkill
- db-preflightSkill
- env-preflightSkill
- eval-harnessSkill
- feature-completenessSkill
- file-indexSkill
- frontend-patternsSkill
- function-extractSkill
- idev-initSkill
- import-graphSkill
- lessons-learnedSkill
- post-creation-verifySkill
- pre-ship-verifySkill
- project-mapSkill
- self-reviewSkill
- session-resumeSkill
- skill-benchmarkSkill
- skilloptSkill
- smart-contextSkill
- strategic-compactSkill
- task-journalSkill
- tdd-workflowSkill
- test-coverageSkill
- test-mapSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 26 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
When creating or modifying backend code and no cached patterns exist yet.
- Distinctive: line 29
Run these checks to identify the backend technology.
- Very specific: line 190
After scanning, write all discovered patterns to: .claude/idev/backend-patterns/cache.md
- Distinctive: line 243
Keep the cache under ~250 lines by trimming examples if it grows beyond that.
- Distinctive: line 250
When creating a new backend feature, the scanner detects what files are needed:
“Common” is measured: kept by at least 6 in 10 of the 26 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.
Files
Backend Pattern Scanner Skill
Purpose
Auto-detect backend code conventions by scanning the codebase. Works on ANY backend stack — .NET, Node.js, Python, Java, Go, Ruby, PHP, Rust, etc.
Activation
When creating or modifying backend code and no cached patterns exist yet.
How It Works
This skill does NOT hardcode patterns or assume any technology. Instead, it:
- Detects the backend stack from marker files
- Scans for the project's specific conventions
- Caches discovered patterns for reuse
Results are cached in .claude/idev/backend-patterns/cache.md after first scan.
Phase 1: Detect Backend Stack
Run these checks to identify the backend technology. Check ALL — do not assume:
Marker File Detection:
*.sln / *.csproj → .NET (C#)
go.mod → Go
Cargo.toml → Rust
pom.xml → Java (Maven)
build.gradle (no /app dir) → Java/Kotlin (Gradle)
requirements.txt / pyproject.toml / setup.py → Python
Gemfile → Ruby
composer.json → PHP
package.json (with express/fastify/nest/koa/hapi) → Node.js
Framework Detection (read marker file contents):
.NET: grep *.csproj for "Microsoft.AspNetCore" → ASP.NET Core
Python: grep for "django|flask|fastapi|starlette" in requirements/pyproject
Java: grep pom.xml for "spring-boot|quarkus|micronaut"
Ruby: grep Gemfile for "rails|sinatra|grape"
PHP: grep composer.json for "laravel|symfony|slim"
Node.js: grep package.json for "express|fastify|nestjs|koa|hapi"
Go: grep go.mod for "gin|echo|fiber|chi|mux"
ORM/Database Detection:
.NET: grep for "DbContext|EntityFramework" → EF Core
Python: grep for "django.db|sqlalchemy|tortoise" → ORM
Java: grep for "JpaRepository|@Entity" → JPA/Hibernate
Node.js: grep for "prisma|typeorm|sequelize|mongoose|knex" → ORM
Ruby: grep for "ActiveRecord" → Rails ORM
Go: grep for "gorm|sqlx|ent" → ORMPhase 2: Discover Project Structure
Based on detected stack, scan for key directories. The scan adapts to the technology:
Generic Scans (run regardless of stack)
1. Find route/controller files → API layer location
2. Find service/business logic files → Service layer location
3. Find model/entity files → Data layer location
4. Find DTO/schema/serializer files → Data transfer layer
5. Find dependency injection/module registration → DI setup
6. Find database config/context → DB layer
7. Find middleware files → Middleware layer
8. Find test files → Test location and frameworkStack-Specific File Patterns
.NET:
Controllers: **/*Controller.cs
Services: **/*Service.cs (exclude I*Service.cs)
Interfaces: **/I*Service.cs
Entities: **/Entities/**/*.cs
DTOs: **/*Dto.cs
DI: file containing "AddTransient|AddScoped"
DB: file containing "DbSet<"
Node.js/Express:
Routes: **/routes/*.ts or **/*.routes.ts
Controllers: **/controllers/*.ts or **/*.controller.ts
Services: **/services/*.ts or **/*.service.ts
Models: **/models/*.ts or **/*.model.ts
Middleware: **/middleware/*.ts
DB: file containing "prisma|mongoose.model|sequelize"
Python/Django:
Views: **/views.py or **/views/*.py
Models: **/models.py or **/models/*.py
Serializers: **/serializers.py
URLs: **/urls.py
Admin: **/admin.py
Python/FastAPI:
Routers: **/routers/*.py or **/*_router.py
Services: **/services/*.py
Models: **/models/*.py or **/schemas/*.py
DB: file containing "SessionLocal|create_engine"
Java/Spring:
Controllers: **/*Controller.java
Services: **/*Service.java or **/*ServiceImpl.java
Repositories: **/*Repository.java
Entities: **/entity/*.java or **/model/*.java
DTOs: **/dto/*.java
Go:
Handlers: **/handlers/*.go or **/*handler.go
Services: **/services/*.go
Models: **/models/*.go
Routes: file containing "HandleFunc|router.GET"
Ruby/Rails:
Controllers: app/controllers/**/*_controller.rb
Models: app/models/**/*.rb
Serializers: app/serializers/**/*.rb
Routes: config/routes.rbPhase 3: Extract Patterns from Existing Code
For each discovered layer, read ONE representative file and extract the exact pattern:
3.1 Route/Controller Pattern
Pick one route handler (not base/abstract)
Extract: namespace/module, routing decorator/attribute, base class/mixin,
constructor/DI params, response wrapper, auth middleware
Detect: how request params are parsed, how responses are formatted,
how errors are returned, how auth context is accessed3.2 Service/Business Logic Pattern
Pick one service implementation
Extract: constructor/init DI params, error handling pattern, repository/DB usage
Detect: transaction handling, logging pattern, exception types,
how service methods are structured (async/sync, return types)3.3 Model/Entity Pattern
Pick one data model
Extract: base class, primary key pattern, common fields (timestamps, soft delete, etc.)
Detect: audit fields, multi-tenancy fields, relationship patterns,
naming conventions (PascalCase, camelCase, snake_case)3.4 DTO/Schema/Serializer Pattern
Find data transfer objects (DTOs, schemas, serializers, validators)
Extract: naming convention, validation approach, field types
Detect: mapping methods (manual, AutoMapper, extension methods, serializer classes)
separate Create/Update/Response types or unified3.5 Dependency Injection / Module Registration
Find where services are registered/configured
Extract: registration method (DI container, module imports, middleware chain)
Detect: grouping convention, insertion point for new registrations
Note: exact file path and line number3.6 Database Configuration
Find database setup (DbContext, Prisma schema, models.py, etc.)
Extract: how models are registered, connection config
Detect: migration approach, seeding pattern
Note: exact file path and insertion point for new modelsPhase 4: Generate Cache
After scanning, write all discovered patterns to:
.claude/idev/backend-patterns/cache.md
Format:
# Backend Patterns Cache
## Generated: [date]
## Project: [detected project name]
## Stack: [framework] + [language] + [ORM] + [other key libs]
### Paths
[All discovered paths with descriptions]
### Route/Controller Template
[extracted pattern with {{PLACEHOLDERS}}]
### Service Template
[extracted pattern with {{PLACEHOLDERS}}]
### Model/Entity Template
[extracted pattern with {{PLACEHOLDERS}}]
### DTO/Schema Templates
[extracted patterns - create, update, response]
### Registration Points
DI/Module File: [path] → Insert at line [N]
DB Config: [path] → Insert after line [N]
### Conventions
- Language: [detected]
- Naming: [PascalCase/camelCase/snake_case]
- Soft delete: [pattern or "not used"]
- Multi-tenancy: [pattern or "not used"]
- Audit fields: [list or "not used"]
- Error handling: [pattern]
- Response wrapper: [pattern]
- Auth context: [how user identity is accessed]
- Testing: [framework and pattern]
### Function Index
[Compact list of exported/public functions, one per line:]
functionName — file:line — one-line purpose
[Cap at ~100 entries, most-used first. Used by function-extract for targeted
reads and by cache-refresh for incremental updates. Update entries whenever
adding or modifying functions.]Phase 5: Usage
On subsequent tasks, load only the cache file instead of rescanning. Keep the cache under ~250 lines by trimming examples if it grows beyond that. Rescan if user says "refresh patterns" or if cache is older than 7 days.
Checklist (generic, auto-populated from scan)
When creating a new backend feature, the scanner detects what files are needed:
- Model/Entity in [detected path]
- DTOs/Schemas in [detected path]
- Interface/Abstract (if applicable) in [detected path]
- Service in [detected path]
- Route/Controller in [detected path]
- DI/Module registration in [detected file] at line [N]
- DB registration in [detected file] at line [N]
- Database change file (if a migration-free rule exists — check the project rules file:
.claude/idev/rules.mdor the project config) - Tests in [detected test path]
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

