Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

api-contracts

Sterne2

Forks0

Aktualisiert27. Februar 2026 um 11:26

API DTO and response contract rules for LifeOS backend/frontend compatibility. Use when adding or changing endpoints, request/response DTOs, error payloads, versioning decisions, or Swagger/OpenAPI documentation.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

pvidaal07

pvidaal07/LifeOS

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

Datei-Explorer

2 Dateien

SKILL.md

readonly

name	api-contracts
description	API DTO and response contract rules for LifeOS backend/frontend compatibility. Use when adding or changing endpoints, request/response DTOs, error payloads, versioning decisions, or Swagger/OpenAPI documentation.

API Contracts

Objetivo

Mantener contratos HTTP estables y explícitos para evitar roturas entre backend y frontend.

REQUIRED

Definir DTOs de entrada/salida por endpoint.
Mantener envoltorio de éxito consistente (data, statusCode, timestamp) salvo decisión explícita.
Mantener formato de error consistente (statusCode, message, timestamp, path).
Documentar endpoints y DTOs en Swagger.
Preferir cambios aditivos (campos opcionales) para compatibilidad hacia atrás.
Versionar (/api/v1) antes de introducir breaking changes.

NEVER

No devolver entidades internas de ORM directamente.
No cambiar nombres/tipos de campos públicos sin plan de migración.
No mezclar idiomas/formatos en mensajes de error de la misma API.

Checklist

Actualizar DTO + controller/service.
Ajustar tipos frontend (frontend/src/api, frontend/src/types).
Verificar documentación y tests.

Mehr aus diesem Repository

gleiches Repository

nestjs-best-practices

pvidaal07/LifeOS

NestJS best practices and architecture patterns for building production-ready applications. This skill should be used when writing, reviewing, or refactoring NestJS code to ensure proper patterns for modules, dependency injection, security, and performance.

2026-02-272

auth-and-ownership

pvidaal07/LifeOS

Authentication and ownership enforcement rules for LifeOS multi-user isolation. Use when creating or changing auth flows, guarded endpoints, user-scoped queries, or nested resource access checks.

2026-02-272

clean-architecture-ddd

pvidaal07/LifeOS

Clean Architecture + DDD rules for this repo. Triggers: adding/refactoring code across src/domain|application|infrastructure, moving files between layers, creating ports/adapters/use-cases.

2026-02-272

docker-selfhost

pvidaal07/LifeOS

Docker Compose self-hosting conventions for LifeOS development and production. Use when editing compose files, environment variables, service networking, persistent volumes, health checks, or deployment workflows.

2026-02-272

docs

pvidaal07/LifeOS

Repository documentation conventions for LifeOS. Use when creating or updating README, docs/*, architecture notes, API behavior notes, or implementation decisions that must remain clear for future contributors and agents.

2026-02-272

postgresql

pvidaal07/LifeOS

PostgreSQL schema and query safety rules for LifeOS. Use when changing tables, indexes, constraints, migrations, date handling, performance-sensitive queries, or any persistence design decision.

2026-02-272

name	api-contracts
description	API DTO and response contract rules for LifeOS backend/frontend compatibility. Use when adding or changing endpoints, request/response DTOs, error payloads, versioning decisions, or Swagger/OpenAPI documentation.

API Contracts

Objetivo

Mantener contratos HTTP estables y explícitos para evitar roturas entre backend y frontend.

REQUIRED

Definir DTOs de entrada/salida por endpoint.
Mantener envoltorio de éxito consistente (data, statusCode, timestamp) salvo decisión explícita.
Mantener formato de error consistente (statusCode, message, timestamp, path).
Documentar endpoints y DTOs en Swagger.
Preferir cambios aditivos (campos opcionales) para compatibilidad hacia atrás.
Versionar (/api/v1) antes de introducir breaking changes.

NEVER

No devolver entidades internas de ORM directamente.
No cambiar nombres/tipos de campos públicos sin plan de migración.
No mezclar idiomas/formatos en mensajes de error de la misma API.

Checklist

Actualizar DTO + controller/service.
Ajustar tipos frontend (frontend/src/api, frontend/src/types).
Verificar documentación y tests.