What this prompt does
This prompt scaffolds a production-ready FastAPI microservice rather than a prototype. It lists ten requirements: an async [database] via SQLAlchemy/SQLModel, JWT auth with refresh tokens, CRUD endpoints for [resources], Pydantic v2 validation, background processing with [task_queue], health and readiness endpoints, structured logging with correlation IDs, Docker plus docker-compose, Alembic migrations, and a pytest suite targeting [coverage]% — all following the [architecture] pattern.
The structure works because it bakes in the operational scaffolding that usually gets skipped until it's painful. The [service_purpose] variable frames what the service does, [resources] defines the CRUD surface, and [architecture] (defaulting to clean architecture with the repository pattern) shapes how the layers separate. Health checks, migrations, Docker, and a real test suite from the first commit are what keep the service deployable instead of rotting into a prototype.
When to use it
- You're starting a new Python microservice and want production scaffolding from commit one.
- You need async DB access, JWT auth, and CRUD for
[resources]wired together cleanly. - You want background task processing via
[task_queue]designed in, not retrofitted. - You need Docker, Alembic migrations, and health/readiness endpoints for real deployment.
- You want a clean-architecture layering and a pytest suite hitting a
[coverage]target.
Example output
Expect a structured FastAPI project: an async [database] layer with SQLAlchemy/SQLModel models, JWT auth with refresh tokens, CRUD routes for [resources] validated by Pydantic v2, a [task_queue] integration, health and readiness endpoints, correlation-ID logging, a Dockerfile and docker-compose, Alembic migration setup, and a pytest suite aiming at [coverage]% — organized into the layers of [architecture] so the service is deployable rather than a single-file prototype.
Pro tips
- Keep
[resources]to the core entities of the service; CRUD for every imaginable model bloats the scaffold. - Match
[database]to your real engine (the default is PostgreSQL) so the async driver and migrations are correct. - Treat
[coverage]as a target, not a guarantee — the AI writes tests toward it, but verify they're meaningful, not padding. - Choose
[task_queue]deliberately; Celery + Redis suits heavy jobs, but lighter needs may not warrant it. - Keep
[architecture]consistent across services so your team isn't context-switching between patterns. - Run the docker-compose stack and the migrations locally before building features, to confirm the scaffold actually boots.
