mcpbeat

Backend Dev Guidelines

dokhacgiakhoa/backend-dev-guidelines

Opinionated backend development standards for Node.js + Express + TypeScript microservices. Covers layered architecture, BaseController pattern, dependency injection, Prisma repositories, Zod validation, unifiedConfig, Sentry error tracking, async safety, and testing discipline.

33k tokens
context cost
the whole folder, loaded on every use
12
files
instructions only
0
copies elsewhere
how many repositories repackaged it
505
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/Dokhacgiakhoa/Agent-Skills-4-Vibe-Coding-CLI --skill backend-dev-guidelines

What comes with it

125 568 bytes besides the instruction
sub-skills/architecture-overview.md
sub-skills/async-and-errors.md
sub-skills/complete-examples.md
sub-skills/configuration.md
sub-skills/database-patterns.md
sub-skills/middleware-guide.md
sub-skills/routing-and-controllers.md
sub-skills/sentry-and-monitoring.md
sub-skills/services-and-repositories.md
sub-skills/testing-guide.md
sub-skills/validation-patterns.md

The instruction itself

40 sections, as written by the author

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)

| Dimension | Question |

| ----------------------------- | ---------------------------------------------------------------- |

| Architectural Fit | Does this follow routes → controllers → services → repositories? |

| Business Logic Complexity | How complex is the domain logic? |

| Data Risk | Does this affect critical data paths or transactions? |

| Operational Risk | Does this impact auth, billing, messaging, or infra? |

| Testability | Can this be reliably unit + integration tested? |

Score Formula

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

Range: -10 → +10

Interpretation

| BFRI | Meaning | Action |

| -------- | --------- | ---------------------- |

| 6–10 | Safe | Proceed |

| 3–5 | Moderate | Add tests + monitoring |

| 0–2 | Risky | Refactor or isolate |

| < 0 | Dangerous | Redesign before coding |


2. When to Use This Skill

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

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


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

5. Naming Conventions (Strict)

| Layer | Convention |

| ---------- | ------------------------- |

| Controller | PascalCaseController.ts |

| Service | camelCaseService.ts |

| Repository | PascalCaseRepository.ts |

| Routes | camelCaseRoutes.ts |

| Validators | camelCase.schema.ts |


6. 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
  ) {}
}

7. Prisma & Repository Rules

  • Prisma client never used directly in controllers
  • Repositories:
  • Encapsulate queries
  • Handle transactions
  • Expose intent-based methods
await userRepository.findActiveUsers();

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


9. Observability & Monitoring

Required

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

Every critical path must be observable.


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


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


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

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

14. Skill Status

Status: Stable · Enforceable · Production-grade

Intended Use: Long-lived Node.js microservices with real traffic and real risk


🧠 Knowledge Modules (Fractal Skills)

1. architecture-overview

2. async-and-errors

3. complete-examples

4. configuration

5. database-patterns

6. middleware-guide

7. routing-and-controllers

8. sentry-and-monitoring

9. services-and-repositories

10. testing-guide

11. validation-patterns

How to use it

Copy the folder

Take dokhacgiakhoa/backend-dev-guidelines from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.