Generate full CRUD (Create, Read, List, Update, Delete) for the entity $ARGUMENTS, mirroring the exact patterns, layering, and naming already used in this repository.
Parse $ARGUMENTS into an entity name and a field spec (name + type + required/optional per field). If either the entity name or the fields are missing — including the common case of a bare name like "Product" with no fields — stop and ask for the missing part. Never guess a field list or scaffold from an inferred schema.
Learn the conventions first
Before writing any code, study an existing entity end to end and copy its structure. Do not invent a stack.
- Find a comparable entity (an existing resource with a model, endpoints/UI, and tests). Read its full slice: model/schema, migration, validation, service/repository, controller/route or UI component, and its tests.
- Detect the frameworks and tools from
package.json/pyproject.toml/go.mod/composer.json: the ORM (Prisma, TypeORM, Sequelize, Drizzle, SQLAlchemy, ActiveRecord, GORM…), the validation lib (Zod, Yup, class-validator, Pydantic…), the router, and the test runner. - Detect the repo's conventions for three choices that silently vary and must be copied, not assumed: update semantics (PATCH/partial vs PUT/full-replace), delete semantics (soft-delete via
deleted_at/status flag vs hard-delete), and the list contract (pagination style, filter, sort). Match whichever the sibling entity uses. - Match the repo's file layout, module boundaries, casing, pluralization, import style, error-handling helpers, and response envelope. If a layer (service, repository, DTO mapper) exists for other entities, replicate it — do not collapse layers.
Build the slice
Using the confirmed field list, create, in the repo's own idioms:
- Model / entity with correct types, nullability, timestamps, relations, and the soft-delete column if the repo soft-deletes.
- Migration generated the way the repo generates them (ORM CLI if present) — never hand-edit schema state the tool owns. Include indexes on foreign keys and unique indexes on columns the repo treats as unique.
- Validation schema with the repo's validation lib. Provide a create schema; for update, match the repo's semantics — a partial schema if it uses PATCH, a full schema if it uses PUT. Enforce types, lengths, formats, enums, and required fields at the boundary.
- Data access + endpoints or UI:
- Endpoints branch: implement create, get-by-id, list (repo's pagination/filter/sort), update, and delete (soft or hard per the repo) via the existing service/controller/route pattern.
- UI branch: build create/edit forms, list, and detail views using the repo's component and form-state patterns. Mirror the server validation schema client-side (reuse the shared schema if the repo shares one), render explicit loading, error, and empty states, and follow the repo's convention for optimistic vs pessimistic mutation updates and cache invalidation.
- Tests at the level(s) the repo tests other entities (unit + integration/e2e), covering happy path, validation rejection, not-found, duplicate/uniqueness conflict (the repo's 409 or equivalent) on the unique columns, list pagination/filter/sort behavior, delete semantics (row gone vs flagged and excluded from list), and the auth/permission rule that applies.
Hard rules
- Always return the repo's standard not-found response (e.g. 404) for missing IDs and its standard 400/422 for invalid input — never a 500 for expected cases.
- Never leak the internal model: return through the same DTO/serializer/select-projection other endpoints use. Never expose password hashes, internal flags, soft-delete columns, or unrequested relations.
- Always parameterize queries via the ORM/query builder — no string-concatenated SQL.
- Always apply the same authentication/authorization guard, input sanitization, and rate limiting as sibling endpoints. Scope list/get/update/delete to the caller's tenant/owner if the repo does.
- Wire the new routes/module/pages into the app the way siblings are registered (router index, DI container, module exports, nav). Leave no orphan files.
- Never introduce a new library, pattern, or response shape when an equivalent already exists in the repo.
Finish
Run the repo's linter, type-checker, and the new tests. Generate the migration but apply it only when the target is a safe local/dev database and it is not already applied; otherwise leave it unapplied. Report the files created/modified as absolute paths, the migration name, and the exact commands to apply the migration and run the tests. Do not commit unless asked.