Token导航 LogoToken导航TokenDH.com
研究检索需要联网clawhub未标认证来源可访问clear审计提醒

backend-developer后端开发人员

Agent Skill

backend-developer 用于查找、检索和筛选相关信息,适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

3,720

周安装

155

GitHub Stars

公开资料未说明

下载量

1,240
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:backend-developer(后端开发人员)
来源仓库:https://github.com/bayudsatriyo/backend-developer
安装命令:
openclaw skills install backend-developer
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install backend-developer

简介

用于标准化 REST API 开发,遵循分层架构模式构建后端服务。

  • 适合新建 API 接口或维护现有后端系统的开发场景。
  • 通过 clawhub 安装后在 OpenClaw 中使用,按规范生成路由、控制器和服务层代码。
  • 需确认项目技术栈和依赖项,确保兼容性和安全性。
  • 注意文件读写权限,避免覆盖重要配置或泄露敏感信息。

SKILL.md

name
backend-developer
description
Standardized backend REST API development following layered architecture patterns (Route → Controller → Service → Repository). Use when building new REST APIs, implementing features, fixing bugs, or refactoring backend code. Enforces strict separation of concerns, centralized error handling, input validation, DTO/mapper patterns, and Prisma ORM usage.

Backend API Architecture Skill

This skill provides a standardized, production-ready architecture for Node.js/TypeScript REST APIs following the 4-layer pattern proven across multiple production systems.

Core Architecture

Client Request
  ↓
[routes/] HTTP handlers + middleware
  ↓
[controller/] Request parsing + response formatting
  ↓
[service/] Business logic + orchestration
  ↓
[repository/] Database access (Prisma)

Each layer has a single responsibility and clear boundaries.

Quick Start: The Standard Stack

Runtime: Node.js + TypeScript Framework: Express ORM: Prisma Validation: Joi + Zod (request validation) Error Handling: Custom AppError class + centralized middleware Response Format: Standardized JSON with {status, data, meta, error}

File Organization

Each feature gets a feature module with 6 files:

src/
├── app/
│   └── [feature]/
│       ├── [feature].route.ts      ← HTTP routes + middleware
│       ├── [feature].controller.ts ← Request → response
│       ├── [feature].service.ts    ← Business logic
│       ├── [feature].repository.ts ← Database queries
│       ├── [feature].dto.ts        ← TypeScript types
│       ├── [feature].mapper.ts     ← Entity → DTO transformation
│       └── [feature].request.ts    ← Joi/Zod validation schemas
├── config/
│   └── config.ts                   ← Environment loading
├── interface/
│   └── index.ts                    ← Global types, ERROR_CODE, ApiResponse
├── middleware/
│   ├── auth-middleware.ts
│   ├── error-handler.ts            ← Centralized error handling
│   ├── validate-request.ts
│   ├── security.middleware.ts
│   └── index.ts
├── lib/
│   └── prisma.ts                   ← Prisma client singleton
├── utils/
│   ├── response-handler.ts         ← ResponseHandler utilities
│   ├── handle-prisma-error.ts
│   └── clean-joi-error-message.ts
├── routes/
│   └── index.ts                    ← Central route aggregator
└── index.ts                        ← Express app setup

The 4 Layers Explained

1. Route Layer ([feature].route.ts)

Responsibility: HTTP method binding, middleware ordering, parameter extraction Does: Apply auth middleware → validate input → call controller → error handling Does NOT: Business logic, database access

export const [feature]Routes = express.Router();

[feature]Routes.post(
  '/',
  auth('ACCESS', [Roles.Admin]),          // ← Auth middleware
  validate(createSchema, 'body'),         // ← Validation middleware
  catchAsync([feature]Controller.create), // ← Error wrapping
);

[feature]Routes.get(
  '/:id',
  auth('ACCESS', [Roles.User, Roles.Admin]),
  catchAsync([feature]Controller.findById),
);

Key utilities:

  • auth(tokenType, allowedRoles) — JWT verification
  • validate(schema, 'body'|'query'|'params') — Input validation
  • catchAsync(fn) — Wrapper that catches promise rejections

2. Controller Layer ([feature].controller.ts)

Responsibility: Extract request data, call service, format response Does: req.body, req.query, req.params → service call → ResponseHandler.ok() Does NOT: Business logic, database queries

export const [feature]Controller = {
  create: async (req: Request, res: Response, next: NextFunction) => {
    const { body } = req;
    const result = await [feature]Service.create(body);
    
    // Service returns AppError or data
    if (result instanceof AppError) {
      next(result);
      return;
    }
    
    ResponseHandler.created(res, result, 'Created successfully');
  },
  
  findAll: async (req: Request, res: Response, next: NextFunction) => {
    const { query } = req;
    const { data, meta } = await [feature]Service.findAll(query);
    if (data instanceof AppError) {
      next(data);
      return;
    }
    ResponseHandler.ok(res, data, 'Fetched successfully', meta);
  },
};

Pattern:

  1. Extract req data
  2. Call service (which returns AppError | data)
  3. Check for AppErrornext(error)
  4. Otherwise → ResponseHandler.ok() or .created()

3. Service Layer ([feature].service.ts)

Responsibility: Business logic, data orchestration, mapper usage Does: Calls repository → transforms data (via mappers) → returns AppError | data Does NOT: Direct database queries, HTTP handling

export const [feature]Service = {
  create: async (input: CreateDto): Promise<AppError | [Feature]Dto> => {
    // Validate business rules (not input format — that's the request layer)
    const existing = await [feature]Repository.findByEmail(input.email);
    if (existing) {
      return new AppError('CONFLICT', 'Email already exists');
    }
    
    // Call repository
    const entity = await [feature]Repository.create(input);
    
    // Transform entity to DTO via mapper
    return [feature]Mapper.toDtoArray([entity])[0];
  },
  
  findAll: async (query: QueryParams) => {
    const { page = 1, perPage = 10 } = query;
    const result = await [feature]Repository.findAll(page, perPage);
    
    return {
      data: [feature]Mapper.toDtoArray(result.data),
      meta: {
        currentPage: page,
        totalPages: Math.ceil(result.count / perPage),
        perPage,
        totalEntries: result.count,
      },
    };
  },
};

Pattern:

  • Accept DTOs (validated input from request layer)
  • Call repository for data access
  • Use mapper to transform entities → DTOs
  • Return AppError | data (union type)

4. Repository Layer ([feature].repository.ts)

Responsibility: Raw database access via Prisma Does: prisma.model.query() — nothing else Does NOT: Business logic, data transformation

export const [feature]Repository = {
  create: async (input: CreateDto) => {
    return prisma.[feature].create({
      data: input,
    });
  },
  
  findAll: async (page: number, perPage: number) => {
    const skip = (page - 1) * perPage;
    const [data, count] = await Promise.all([
      prisma.[feature].findMany({
        skip,
        take: perPage,
        where: { deletedAt: null }, // Soft delete filter
      }),
      prisma.[feature].count({
        where: { deletedAt: null },
      }),
    ]);
    return { data, count };
  },
};

Pattern:

  • Direct Prisma calls
  • No business logic
  • Return raw entity objects

DTO & Mapper Pattern

DTO (Data Transfer Object) — TypeScript interface defining what data leaves the system:

// [feature].dto.ts
export interface [Feature]Dto {
  id: string;
  name: string;
  email: string;
  createdAt: Date;
}

Mapper — Transform database entity to DTO:

// [feature].mapper.ts
export const [feature]Mapper = {
  toDto(entity: [FeatureEntity]): [Feature]Dto {
    return {
      id: entity.id,
      name: entity.name,
      email: entity.email,
      createdAt: entity.createdAt,
    };
  },
  
  toDtoArray(entities: [FeatureEntity][]): [Feature]Dto[] {
    return entities.map(e => this.toDto(e));
  },
};

Error Handling

Central error class:

export class AppError extends Error {
  constructor(
    public readonly code: ErrorCode, // 'BAD_REQUEST', 'UNAUTHORIZED', etc.
    message?: string,
  ) {
    super(message);
  }
}

Error codes (from interface/index.ts):

export const ERROR_CODE = {
  BAD_REQUEST: { code: 'BAD_REQUEST', message: 'Bad Request', httpStatus: 400 },
  UNAUTHORIZED: { code: 'UNAUTHORIZED', message: 'Unauthorized', httpStatus: 401 },
  FORBIDDEN: { code: 'FORBIDDEN', message: 'Forbidden', httpStatus: 403 },
  NOT_FOUND: { code: 'NOT_FOUND', message: 'Not Found', httpStatus: 404 },
  CONFLICT: { code: 'CONFLICT', message: 'Resource already exists', httpStatus: 409 },
  INTERNAL_SERVER_ERROR: { code: 'INTERNAL_SERVER_ERROR', httpStatus: 500 },
  // ... extend as needed
};

Centralized error handler middleware:

export const errorHandler: ErrorRequestHandler = (
  err: AppError | Error,
  req: Request,
  res: Response,
) => {
  if (err instanceof AppError) {
    return res.status(err.httpStatus).json({
      status: 'error',
      error: {
        code: err.code,
        message: err.message,
      },
    });
  }
  
  // Fallback for unhandled errors
  console.error(err.stack);
  res.status(500).json({
    status: 'error',
    error: { code: 'INTERNAL_SERVER_ERROR', message: 'Internal Server Error' },
  });
};

Response Format

Success response:

{
  "status": "success",
  "message": "User created successfully",
  "data": { "id": "123", "name": "John", "email": "john@example.com" },
  "meta": null
}

Paginated response:

{
  "status": "success",
  "data": [{ "id": "1" }, { "id": "2" }],
  "meta": {
    "currentPage": 1,
    "totalPages": 5,
    "perPage": 10,
    "totalEntries": 42
  }
}

Error response:

{
  "status": "error",
  "error": {
    "code": "NOT_FOUND",
    "message": "User not found"
  }
}

Validation Pattern

Request file defines Joi schema + TypeScript type:

// [feature].request.ts
import Joi from 'joi';

export const createSchema = Joi.object({
  name: Joi.string().required(),
  email: Joi.string().email().required(),
  phone: Joi.string().optional(),
});

export type CreateRequest = {
  name: string;
  email: string;
  phone?: string;
};

Route uses it:

[feature]Routes.post(
  '/',
  validate(createSchema, 'body'), // Validates against schema
  catchAsync([feature]Controller.create),
);

Controller receives typed input:

create: async (req: Request, res: Response) => {
  const body = req.body as CreateRequest; // Already validated + typed
  // ...
};

Middleware Stack

Standard middleware order in index.ts:

app.use(express.json());
app.use(cors());
app.use(securityHeaders());
app.use(requestLogger());

app.use('/api', routes);

app.use(errorHandler); // Must be last

Authentication Pattern

JWT middleware extracts and verifies token:

export const auth = (tokenType: 'ACCESS' | 'REFRESH', roles?: Role[]) => {
  return async (req: Request, res: Response, next: NextFunction) => {
    const token = req.headers.authorization?.split(' ')[1];
    if (!token) {
      return next(new AppError('UNAUTHORIZED'));
    }
    
    try {
      const payload = jwt.verify(token, process.env.JWT_SECRET!);
      if (roles && !roles.includes(payload.role)) {
        return next(new AppError('FORBIDDEN'));
      }
      (req as any).user = payload;
      next();
    } catch {
      next(new AppError('UNAUTHORIZED'));
    }
  };
};

Key Utilities

See references/utilities.md for helper functions:

  • catchAsync(fn) — Promise error wrapper
  • ResponseHandler — Response formatting
  • validate(schema, field) — Request validation middleware
  • handlePrismaError(err) — Convert Prisma errors to AppError

When Implementing Features

  1. Define request schema[feature].request.ts
  2. Define DTOs[feature].dto.ts
  3. Create repository[feature].repository.ts (Prisma queries only)
  4. Create service[feature].service.ts (business logic)
  5. Create controller[feature].controller.ts (request/response)
  6. Create mapper[feature].mapper.ts (entity → DTO)
  7. Create routes[feature].route.ts (HTTP endpoints)
  8. Register routes — Add to routes/index.ts

Checklist Before Merge

  • [ ] All layers follow the pattern (route → controller → service → repository)
  • [ ] Service returns AppError | data (union type)
  • [ ] Controller checks for AppError before responding
  • [ ] Validation happens in request layer, not service
  • [ ] DTOs defined, mappers used for entity transformation
  • [ ] Error codes added to ERROR_CODE if new errors introduced
  • [ ] Prisma queries in repository layer only
  • [ ] Business logic in service layer only
  • [ ] No database access in controller
  • [ ] Response uses ResponseHandler
  • [ ] Auth middleware applied where needed
  • [ ] Tests written for service layer (unit tests easy to write with pure functions)

References

  • See references/senior-engineer-mindset.mdREAD THIS FIRST — Thinking patterns, API design, security, performance, code quality standards
  • See references/error-handling.md — Error patterns and Prisma error conversion
  • See references/validation.md — Joi + Zod usage
  • See references/utilities.md — Helper functions explained
  • See assets/templates/ — Boilerplate code samples

Senior Engineer Standard

Before implementing anything, read references/senior-engineer-mindset.md. It defines the quality bar expected of every implementation:

  • REST API design: correct status codes, resource naming, nesting rules
  • Data modeling: audit fields, soft delete, naming conventions
  • Error philosophy: explicit errors, meaningful messages, no swallowing
  • Performance: no N+1, always paginate, parallel queries, select only needed fields
  • Security: validate everything, never expose sensitive data, service-level authorization
  • Code quality: early return, no magic values, explicit naming, short focused functions

An implementation that passes functionality but violates these principles is not complete.

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

88.79%
按下载量换算1,101

安全审计

VirusTotal

通过

ClawScan

可疑

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills