agentleFS
jgamaraalvjgamaraalv/delivery-loop/.claude/skills/backend-dev-guidelines/SKILL.md

backend-dev-guidelines

Skill0 starsChanged 4 months agoMITView on GitHub

Shared backend guide for Langfuse's Next.js/tRPC/BullMQ/TypeScript monorepo — tRPC routers, public REST endpoints, BullMQ processors, services, Prisma/ClickHouse access, Zod validation, and backend tests across web/worker/shared.

  • Reads credentials

16 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use tailwind-patterns, software-architecture and 5 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.
  • xenitV1Skill

    tailwind-patterns

    Tailwind CSS v4 principles. CSS-first configuration, container queries, modern patterns, design token architecture.

    Also in 3 projects that use this

  • nek1987Skill

    software-architecture

    Guide for quality focused software architecture. This skill should be used when users want to write code, design architecture, analyze code, in any case that relates to software development.

    Also in 3 projects that use this

  • xenitV1Skill

    clean-code

    Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments

    Also in 3 projects that use this

  • OpenAISkill

    test-driven-development

    Use when implementing any feature or bugfix, before writing implementation code

    Also in 3 projects that use this

  • OpenAISkill

    brainstorming

    You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

    Also in 3 projects that use this

  • SentrySkill

    skill-creator

    Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.

    Also in 4 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 0 are common, 10 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 14 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this SKILL.md when the task spans multiple backend areas or you need the end-to-end reference map.

    line 12
  2. Distinctive:

    Read only the specific reference file that matches the work when the scope is narrower.

    line 14
  3. Distinctive:

    Use the appropriate protected or public procedure.

    line 22
  4. Distinctive:

    Check project/resource access and entitlements.

    line 24
  5. Distinctive:

    Put business logic in a service file.

    line 26
  6. Very specific:

    Use traceException for error handling where relevant.

    line 27
  7. Very specific:

    Add unit or integration tests in __tests__/.

    line 28
  8. Very specific:

    Create the route in pages/api/public/.

    line 33
  9. Distinctive:

    Update Fern API definitions to match TypeScript types.

    line 39
  10. Very specific:

    Add end-to-end tests in __tests__/async/.

    line 40
  11. Very specific:

    Create the processor in worker/src/queues/.

    line 44
  12. Very specific:

    Place business logic in features/ or worker/src/features/.

    line 46
  13. Distinctive:

    Add worker vitest coverage.

    line 49
  14. Distinctive:

    Use Prisma directly for simple CRUD and repositories for complex query access.

    line 58
  15. Distinctive:

    Use OpenTelemetry and DataDog for backend observability.

    line 59
  16. Very specific:

    Always filter project-scoped database queries by projectId.

    line 60
  17. Distinctive:

    Keep Fern API definitions in sync with public TypeScript API contracts.

    line 61
  18. Distinctive:

    Keep backend tests independent and parallel-safe.

    line 62

“Common” is measured: kept by at least 6 in 10 of the 14 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 Development Guidelines

Backend and API work across web/, worker/, and packages/shared/.

How to Read This Skill

  • Use this SKILL.md when the task spans multiple backend areas or you need the end-to-end reference map.
  • Read only the specific reference file that matches the work when the scope is narrower.

Quick Start Checklists

UI: New tRPC Feature

  • Define the router in features/[feature]/server/*Router.ts.
  • Use the appropriate protected or public procedure.
  • Authenticate with JWT-aware middleware.
  • Check project/resource access and entitlements.
  • Validate input with Zod v4.
  • Put business logic in a service file.
  • Use traceException for error handling where relevant.
  • Add unit or integration tests in __tests__/.
  • Access config via env.mjs.

SDKs: New Public API Endpoint

  • Create the route in pages/api/public/.
  • Wrap it with withMiddlewares and createAuthedProjectAPIRoute.
  • Define types in features/public-api/types/.
  • Authenticate with basic auth.
  • Validate query, body, and response with Zod schemas.
  • Include API versioning in paths and schemas.
  • Update Fern API definitions to match TypeScript types.
  • Add end-to-end tests in __tests__/async/.

Worker: New Queue Processor

  • Create the processor in worker/src/queues/.
  • Define queue types in packages/shared/src/server/queues.
  • Place business logic in features/ or worker/src/features/.
  • Distinguish failed jobs from jobs that should succeed with a recorded error.
  • Register the queue in WorkerManager in app.ts.
  • Add worker vitest coverage.

Core Principles

  • tRPC procedures, public API routes, and queue processors delegate business logic to services.
  • Access configuration through env.mjs; do not read process.env directly outside env setup.
  • Validate all external input with Zod v4.
  • Use Prisma directly for simple CRUD and repositories for complex query access.
  • Use OpenTelemetry and DataDog for backend observability.
  • Always filter project-scoped database queries by projectId.
  • Keep Fern API definitions in sync with public TypeScript API contracts.
  • Keep backend tests independent and parallel-safe.

Live Examples

  • tRPC router with project auth and Zod input: web/src/features/events/server/eventsRouter.ts.
  • Public API route with middleware and typed request/response schemas: web/src/pages/api/public/datasets/index.ts.
  • Worker queue processor with typed jobs, logging, and retry behavior: worker/src/queues/evalQueue.ts.
  • Tenant filters for Prisma and ClickHouse: references/database-patterns.md.

Naming Conventions

  • tRPC routers: camelCaseRouter.ts, for example datasetRouter.ts.
  • Services: service.ts in the feature server directory.
  • Queue processors: camelCaseQueue.ts, for example evalQueue.ts.
  • Public API routes: kebab-case filenames, for example dataset-items.ts.

Anti-Patterns to Avoid

  • Business logic in routes or procedures.
  • Direct process.env usage instead of env.mjs / env.ts.
  • Missing error handling.
  • Missing input validation.
  • Missing projectId filters on tenant-scoped queries.
  • console.log instead of logger / traceException.

Reference Map

TopicRead this whenFile
Architecture and package boundariesYou need the web/worker/shared split, request flow, or queue lifecyclereferences/architecture-overview.md
Routing and controllersYou are writing tRPC procedures, public API routes, or queue entrypointsreferences/routing-and-controllers.md
Middleware and authYou are changing request auth, permissions, or middleware compositionreferences/middleware-guide.md
Services and repositoriesYou are placing business logic, repository code, or DI patternsreferences/services-and-repositories.md
Database accessYou are touching Prisma, ClickHouse, tenant filters, or query patternsreferences/database-patterns.md
ConfigurationYou are adding env vars, startup config, or runtime togglesreferences/configuration.md
TestingYou are adding or updating backend testsreferences/testing-guide.md

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.