agentleFS
TheophilusChinomonaTheophilusChinomona/idev/skills/backend-patterns/SKILL.md

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

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.
  • InfopibeSkill

    everything-claude-code

    Also in 10 projects that use this

  • InfopibeSkill

    investor-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

  • niloykumarbarmanSkill

    agent-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

  • tpavanipradeepSkill

    bun-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

  • mryeastcodeSkill

    everything-claude-code-conventions

    Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

    Also in 8 projects that use this

  • gongyijie85Skill

    unified-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

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
  1. Distinctive:

    When creating or modifying backend code and no cached patterns exist yet.

    line 12
  2. Distinctive:

    Run these checks to identify the backend technology.

    line 29
  3. Very specific:

    After scanning, write all discovered patterns to: .claude/idev/backend-patterns/cache.md

    line 190
  4. Distinctive:

    Keep the cache under ~250 lines by trimming examples if it grows beyond that.

    line 243
  5. Distinctive:

    When creating a new backend feature, the scanner detects what files are needed:

    line 250

“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.

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

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:

  1. Detects the backend stack from marker files
  2. Scans for the project's specific conventions
  3. 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" → ORM

Phase 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 framework

Stack-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.rb

Phase 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 accessed

3.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 unified

3.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 number

3.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 models

Phase 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.md or the project config)
  • Tests in [detected test path]

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.

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.