Run any Skill in Manus with one click

backend-openapi-contract-changes

Stars635

Forks136

UpdatedJune 14, 2026 at 22:07

Use when changing public backend API behavior, OpenAPI-owned request or response shapes, generated DTO boundaries, endpoint contracts, or compatibility rules in Iced Latte backend.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Sunagatov

Sunagatov/Iced-Latte

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	backend-openapi-contract-changes
description	Use when changing public backend API behavior, OpenAPI-owned request or response shapes, generated DTO boundaries, endpoint contracts, or compatibility rules in Iced Latte backend.

Backend OpenAPI Contract Changes

Public API work is a boundary change, not just an implementation edit.

Read Order

AGENTS.md
README.md
The smallest relevant contract source or endpoint
Related docs such as docs/order-module-openapi-spec.md when present

Rules

Preserve public API contracts unless the task explicitly changes them.
Keep only stable boundary DTOs, interfaces, and records in feature api/ packages.
Do not hide a contract problem by patching only internal code while leaving generated or documented API surfaces stale.
If a compatibility transition is needed, prefer additive change and explicit migration steps over abrupt replacement.

Verification

Run the narrowest relevant Maven tests first.
Broaden to endpoint or contract-related tests when the change affects request or response shape.
Keep generated/OpenAPI-related changes in the same change set when they are part of one contract edit.

More from this repository

same repository

api-and-interface-design

Sunagatov/Iced-Latte

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

2026-06-14635

backend-feature-packaging

Sunagatov/Iced-Latte

Use when deciding where backend code should live in Iced Latte, especially feature ownership, `api/` boundaries, `common` vs feature placement, or cross-feature module dependencies in the modular monolith.

2026-06-14635

backend-liquibase-migrations

Sunagatov/Iced-Latte

Use when adding or changing database schema, Liquibase changelogs, SQL migration files, rollout order, or schema-backed backend behavior in Iced Latte backend.

2026-06-14635

backend-modulith-boundaries

Sunagatov/Iced-Latte

Use when backend changes risk crossing feature boundaries, changing exported `api/` surfaces, or violating Spring Modulith dependency expectations in Iced Latte.

2026-06-14635

backend-security-auth-boundaries

Sunagatov/Iced-Latte

Use when changing backend JWT auth, sessions, Google OAuth, security filters, auth endpoints, authentication or authorization rules, or security-owned module boundaries in Iced Latte.

2026-06-14635

backend-testcontainers-routing

Sunagatov/Iced-Latte

Use when choosing backend verification for changes that touch integration tests, PostgreSQL, Redis, Kafka, or any test flow that depends on Testcontainers in Iced Latte.

2026-06-14635

name	backend-openapi-contract-changes
description	Use when changing public backend API behavior, OpenAPI-owned request or response shapes, generated DTO boundaries, endpoint contracts, or compatibility rules in Iced Latte backend.

Backend OpenAPI Contract Changes

Public API work is a boundary change, not just an implementation edit.

Read Order

AGENTS.md
README.md
The smallest relevant contract source or endpoint
Related docs such as docs/order-module-openapi-spec.md when present

Rules

Preserve public API contracts unless the task explicitly changes them.
Keep only stable boundary DTOs, interfaces, and records in feature api/ packages.
Do not hide a contract problem by patching only internal code while leaving generated or documented API surfaces stale.
If a compatibility transition is needed, prefer additive change and explicit migration steps over abrupt replacement.

Verification

Run the narrowest relevant Maven tests first.
Broaden to endpoint or contract-related tests when the change affects request or response shape.
Keep generated/OpenAPI-related changes in the same change set when they are part of one contract edit.