"Create a complete new entity with CRUD API endpoints end-to-end in a single guided workflow: DTO contract, database migration, EF Core repository, validator (+ unit tests), optional policy guard (+ unit tests), application service, API endpoint, and integration tests. USE FOR: adding a brand-new entity to an existing CoreEx solution where the full stack — from database table to HTTP endpoint — is needed. DO NOT USE FOR: modifying an existing entity or endpoint (use the targeted L1 skill directly), read-only façade entities backed by an external adapter with no local table (use individual L1 skills), or any partial-stack additions."
Resources
1Install
npx skillscat add avanade/coreex/coreex-api-e2e Install via the SkillsCat registry.
CoreEx: Add API (End-to-End)
Guides you through adding a complete new entity and its CRUD API in one sitting: gathers all context upfront, then invokes the appropriate L1 skills in sequence so you are never asked the same question twice.
When to Use
- Adding a brand-new entity to an existing CoreEx solution — full stack from database table to HTTP endpoint
- The entity will be owned and persisted locally (not sourced purely from an external adapter)
- You want the entire vertical slice — contract, migration, repository, validator, app-service, API, and tests — in one workflow
When Not to Use
- Modifying an existing entity, endpoint, or validator — invoke the targeted L1 skill directly (e.g.
coreex-validator,coreex-api) - Read-only façade entity backed by an external adapter with no local table — use individual L1 skills and skip migration/repository
- Adding only a subset of layers (e.g. validator only, API only) — call the relevant L1 skill directly
Workflow Overview
- Read Feature Configuration — resolve
rop-enabled,outbox-enabled, anddata-provider(SqlServer/Postgres/Cosmos/None) from the solution-rootAGENTS.md, and check whether a*.Domainproject exists, before asking anything. - Interview — gather entity name, fields, operations (Get/Query/Create/Update/Patch/Delete), identifier type, whether a policy guard is needed, and (if any field is ref-data) whether that reference-data type already exists; batch all questions into one turn.
- Execute L1 sequence — invoke each L1 skill in order, passing context resolved in steps 1–2; no repeated questions.
- Validate —
dotnet buildacross all projects; confirm unit and integration test classes are present.
For full step-by-step guidance see `references/workflow.md`.
L1 Sequence
| Step | Skill | Condition |
|---|---|---|
| 1 | `coreex-refdata` | Only if a brand-new reference-data type was identified in the interview (must exist before Step 2 can compile) |
| 2 | `coreex-aggregate` | Only when *.Domain project exists |
| 3 | `coreex-contract` | Always |
| 4 | `coreex-db-migration` | Skip when data-provider = None |
| 5 | `coreex-repository` | Skip when data-provider = None |
| 6 | `coreex-validator` | Always — also generates *.Test.Unit/Validators/ unit tests |
| 7 | `coreex-policy` | Only if a business guard was identified in the interview — also generates *.Test.Unit/Policies/ unit tests |
| 8 | `coreex-app-service` | Always |
| 9 | `coreex-api` | Always |
| 10 | `coreex-test-api` | Always |
Key References
- `/.github/instructions/coreex-contracts.instructions.md` — entity contract conventions
- `/.github/instructions/coreex-application-services.instructions.md` — layering rules and Result<T> pipeline
- `/.github/instructions/coreex-api-controllers.instructions.md` — endpoint conventions
- `/.github/instructions/coreex-tests.instructions.md` — integration and unit test conventions
- `/.github/instructions/coreex-domain.instructions.md` — DDD aggregate conventions (when
*.Domainproject exists)