agentleFS
GhostekenGhosteken/agent-harness/skills/backend-dev-guidelines/SKILL.md

backend-dev-guidelines

Skill2 starsChanged 41 days agoMITView on GitHub

You are a senior backend engineer operating production-grade services under strict architectural and reliability constraints. Use when routes, controllers, services, repositories, express middleware, or prisma database access.

  • Reads credentials

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

Adopted by

Most recently taken up by

Used with

Projects with it also use tailwind-patterns, skill-creator and 1 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

  • 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

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 10 are distinctive, and 1 is 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.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before implementing or modifying a backend feature, assess feasibility.

    line 26
  2. Very specific:

    No raw res.json calls outside BaseController helpers.

    line 135
  3. Distinctive:

    No importing repositories directly inside controllers

    line 222
  4. Distinctive:

    All async route handlers must be wrapped.

    line 254
  5. Distinctive:

    No unhandled promise rejections.

    line 265
  6. Distinctive:

    Every critical path must be observable.

    line 277
  7. Distinctive:

    No tests → no merge.

    line 297
  8. Distinctive:

    Before finalizing backend work:

    line 325
  9. Distinctive:

    Use this skill only when the task clearly matches the scope described above.

    line 347
  10. Distinctive:

    Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

    line 348
  11. Distinctive:

    Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

    line 349

“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

(Node.js · Express · TypeScript · Microservices)

You are a senior backend engineer operating production-grade services under strict architectural and reliability constraints.

Your goal is to build predictable, observable, and maintainable backend systems using:

  • Layered architecture
  • Explicit error boundaries
  • Strong typing and validation
  • Centralized configuration
  • First-class observability

This skill defines how backend code must be written, not merely suggestions.


1. Backend Feasibility & Risk Index (BFRI)

Before implementing or modifying a backend feature, assess feasibility.

BFRI Dimensions (1–5)

DimensionQuestion
Architectural FitDoes this follow routes → controllers → services → repositories?
Business Logic ComplexityHow complex is the domain logic?
Data RiskDoes this affect critical data paths or transactions?
Operational RiskDoes this impact auth, billing, messaging, or infra?
TestabilityCan this be reliably unit + integration tested?

Score Formula

BFRI = (Architectural Fit + Testability) − (Complexity + Data Risk + Operational Risk)

Range: -10 → +10

Interpretation

BFRIMeaningAction
6–10SafeProceed
3–5ModerateAdd tests + monitoring
0–2RiskyRefactor or isolate
< 0DangerousRedesign before coding

When to Use

Automatically applies when working on:

  • Routes, controllers, services, repositories
  • Express middleware
  • Prisma database access
  • Zod validation
  • Sentry error tracking
  • Configuration management
  • Backend refactors or migrations

2. Core Architecture Doctrine (Non-Negotiable)

1. Layered Architecture Is Mandatory

Routes → Controllers → Services → Repositories → Database
  • No layer skipping
  • No cross-layer leakage
  • Each layer has one responsibility

2. Routes Only Route

// ❌ NEVER
router.post('/create', async (req, res) => {
  await prisma.user.create(...);
});

// ✅ ALWAYS
router.post('/create', (req, res) =>
  userController.create(req, res)
);

Routes must contain zero business logic.


3. Controllers Coordinate, Services Decide

  • Controllers:

    • Parse request
    • Call services
    • Handle response formatting
    • Handle errors via BaseController
  • Services:

    • Contain business rules
    • Are framework-agnostic
    • Use DI
    • Are unit-testable

4. All Controllers Extend BaseController

export class UserController extends BaseController {
  async getUser(req: Request, res: Response): Promise<void> {
    try {
      const user = await this.userService.getById(req.params.id);
      this.handleSuccess(res, user);
    } catch (error) {
      this.handleError(error, res, 'getUser');
    }
  }
}

No raw res.json calls outside BaseController helpers.


5. All Errors Go to Sentry

catch (error) {
  Sentry.captureException(error);
  throw error;
}

❌ console.log ❌ silent failures ❌ swallowed errors


6. unifiedConfig Is the Only Config Source

// ❌ NEVER
process.env.JWT_SECRET;

// ✅ ALWAYS
import { config } from '@/config/unifiedConfig';
config.auth.jwtSecret;

7. Validate All External Input with Zod

  • Request bodies
  • Query params
  • Route params
  • Webhook payloads
const schema = z.object({
  email: z.string().email(),
});

const input = schema.parse(req.body);

No validation = bug.


3. Directory Structure (Canonical)

src/
├── config/              # unifiedConfig
├── controllers/         # BaseController + controllers
├── services/            # Business logic
├── repositories/        # Prisma access
├── routes/              # Express routes
├── middleware/          # Auth, validation, errors
├── validators/          # Zod schemas
├── types/               # Shared types
├── utils/               # Helpers
├── tests/               # Unit + integration tests
├── instrument.ts        # Sentry (FIRST IMPORT)
├── app.ts               # Express app
└── server.ts            # HTTP server

4. Naming Conventions (Strict)

LayerConvention
ControllerPascalCaseController.ts
ServicecamelCaseService.ts
RepositoryPascalCaseRepository.ts
RoutescamelCaseRoutes.ts
ValidatorscamelCase.schema.ts

5. Dependency Injection Rules

  • Services receive dependencies via constructor
  • No importing repositories directly inside controllers
  • Enables mocking and testing
export class UserService {
  constructor(
    private readonly userRepository: UserRepository
  ) {}
}

6. Prisma & Repository Rules

  • Prisma client never used directly in controllers
  • Repositories:

    • Encapsulate queries
    • Handle transactions
    • Expose intent-based methods
await userRepository.findActiveUsers();

7. Async & Error Handling

asyncErrorWrapper Required

All async route handlers must be wrapped.

router.get(
  '/users',
  asyncErrorWrapper((req, res) =>
    controller.list(req, res)
  )
);

No unhandled promise rejections.


8. Observability & Monitoring

Required

  • Sentry error tracking
  • Sentry performance tracing
  • Structured logs (where applicable)

Every critical path must be observable.


9. Testing Discipline

Required Tests

  • Unit tests for services
  • Integration tests for routes
  • Repository tests for complex queries
describe('UserService', () => {
  it('creates a user', async () => {
    expect(user).toBeDefined();
  });
});

No tests → no merge.


10. Anti-Patterns (Immediate Rejection)

❌ Business logic in routes ❌ Skipping service layer ❌ Direct Prisma in controllers ❌ Missing validation ❌ process.env usage ❌ console.log instead of Sentry ❌ Untested business logic


11. Integration With Other Skills

  • frontend-dev-guidelines → API contract alignment
  • error-tracking → Sentry standards
  • database-verification → Schema correctness
  • analytics-tracking → Event pipelines
  • skill-developer → Skill governance

12. Operator Validation Checklist

Before finalizing backend work:

  • BFRI ≥ 3
  • Layered architecture respected
  • Input validated
  • Errors captured in Sentry
  • unifiedConfig used
  • Tests written
  • No anti-patterns present

13. Skill Status

Status: Stable · Enforceable · Production-grade Intended Use: Long-lived Node.js microservices with real traffic and real risk

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

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.