메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | backend-feature-packaging |
| description | 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. |
This backend is a modular monolith. Placement is part of the design.
AGENTS.mddocs/architecture/feature-packaging.mdapi/ packages.common only for truly cross-cutting infrastructure with no natural business owner.api/?common collecting business logic or feature-owned exceptions?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.
Use when adding or changing database schema, Liquibase changelogs, SQL migration files, rollout order, or schema-backed backend behavior in Iced Latte backend.
Use when backend changes risk crossing feature boundaries, changing exported `api/` surfaces, or violating Spring Modulith dependency expectations in Iced Latte.
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.
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.
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.