Coreex Api E2e

---
name: coreex-api-e2e
description: "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."
argument-hint: "Optional: entity name, CRUD operations needed (Get/Query/Create/Update/Patch/Delete), key fields"
tags: ["coreex", "api", "entity", "end-to-end", "crud", "vertical-slice"]
---

<!--
  AI workflow asset — dual-audience notice:
  - In the Avanade/CoreEx repository: this file is the authored source. Edit it here.
  - In a consumer repository: this file was generated by `dotnet new coreex-ai` (or refreshed via
    `dotnet new coreex-ai --force` / the `/coreex-docs-sync` skill). Do not hand-edit it directly —
    propose the change upstream in Avanade/CoreEx instead, then refresh once it is released.
-->

# 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

1. **Read Feature Configuration** — resolve `rop-enabled`, `outbox-enabled`, and `data-provider` from the solution-root `AGENTS.md`, and check whether a `*.Domain` project exists, before asking anything.
2. **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.
3. **Execute L1 sequence** — invoke each L1 skill in order, passing context resolved in steps 1–2; no repeated questions.
4. **Validate** — `dotnet build` across all projects; confirm unit and integration test classes are present.

For full step-by-step guidance see [`references/workflow.md`](references/workflow.md).

## L1 Sequence

| Step | Skill | Condition |
|---|---|---|
| 1 | [`coreex-refdata`](../coreex-refdata/SKILL.md) | Only if a brand-new reference-data type was identified in the interview (must exist before Step 2 can compile) |
| 2 | [`coreex-aggregate`](../coreex-aggregate/SKILL.md) | Only when `*.Domain` project exists |
| 3 | [`coreex-contract`](../coreex-contract/SKILL.md) | Always |
| 4 | [`coreex-db-migration`](../coreex-db-migration/SKILL.md) | Skip when `data-provider = None` |
| 5 | [`coreex-repository`](../coreex-repository/SKILL.md) | Skip when `data-provider = None` |
| 6 | [`coreex-validator`](../coreex-validator/SKILL.md) | Always — also generates `*.Test.Unit/Validators/` unit tests |
| 7 | [`coreex-policy`](../coreex-policy/SKILL.md) | Only if a business guard was identified in the interview — also generates `*.Test.Unit/Policies/` unit tests |
| 8 | [`coreex-app-service`](../coreex-app-service/SKILL.md) | Always |
| 9 | [`coreex-api`](../coreex-api/SKILL.md) | Always |
| 10 | [`coreex-test-api`](../coreex-test-api/SKILL.md) | Always |

## Key References

- [`/.github/instructions/coreex-contracts.instructions.md`](/.github/instructions/coreex-contracts.instructions.md) — entity contract conventions
- [`/.github/instructions/coreex-application-services.instructions.md`](/.github/instructions/coreex-application-services.instructions.md) — layering rules and Result&lt;T&gt; pipeline
- [`/.github/instructions/coreex-api-controllers.instructions.md`](/.github/instructions/coreex-api-controllers.instructions.md) — endpoint conventions
- [`/.github/instructions/coreex-tests.instructions.md`](/.github/instructions/coreex-tests.instructions.md) — integration and unit test conventions
- [`/.github/instructions/coreex-domain.instructions.md`](/.github/instructions/coreex-domain.instructions.md) — DDD aggregate conventions (when `*.Domain` project exists)