What this prompt does
This prompt asks the AI to architect a complete Flask application around the application factory pattern and Blueprints. You describe the app with [app_purpose], tell it how many feature modules exist via [module_count], and name the [deployment_target], and it produces a create_app factory inside [package_name]/__init__.py that accepts a config class name, initializes extensions (SQLAlchemy, Migrate, Login, CORS, Limiter), registers blueprints with URL prefixes, wires logging to [log_destination], and adds JSON error handlers for 400/404/422/500.
The structure works because it forces separation of concerns up front. Each module in [blueprint_list] gets its own package with routes, models, schemas, and services, so features stay isolated as the app grows and the test suite stays honest. The config hierarchy keyed off [env_loader] lets the same code run safely in development, testing, and production, while [sensitive_configs] are handled through environment variables rather than hardcoding. Naming [auth_strategy] and [user_roles] shapes the role-based access-control layer, [serialization_lib] decides whether validation flows through Marshmallow or Pydantic, and the flask [cli_prefix] command group exposes operational tasks like [cli_commands].
When to use it
- Starting a new Flask project you expect to grow past a single file
- You need several feature areas (auth, billing, users) cleanly separated as Blueprints
- You want one codebase to run identically across dev, test, and prod via config classes
- You need a testing setup with per-test transaction rollback and authenticated client fixtures
- You're standardizing model mixins like UUID primary keys and timestamp columns across a team
- You want a
flask [cli_prefix]command group for operational tasks like seeding or admin creation - You're handing the project to other engineers and want a structure they can navigate without a tour
Example output
The AI returns a layered project blueprint: a create_app factory accepting a config class name, a [package_name] directory tree with one sub-package per blueprint (routes.py, models.py, schemas.py, services.py), four config classes inheriting from a base Config, model mixins for timestamps and UUID keys, an auth module scoped to your roles, and a pytest fixture set with a test client, an authenticated client, and rolled-back transactions. Expect annotated code blocks for each numbered section rather than a single monolithic file, so you can adopt the pieces incrementally.
Pro tips
- Set
[module_count]and[blueprint_list]to match — if you list six blueprints, say six modules so the factory registration is consistent - Make
[log_destination]explicit (for example, stdout in JSON) when targeting containers so log aggregation works without extra wiring - Use
[sensitive_configs]to enumerate every secret (DATABASE_URL, SECRET_KEY, API keys) so none get baked intoConfig - Pin
[auth_strategy]precisely — JWT with refresh tokens versus session auth changes the whole login module and the role checks for[user_roles] - Keep
[cli_commands]focused on operational chores; bloating the CLI group with business logic makes it harder to test - Confirm the generated extension initialization matches what you actually install, since an unused extension in the factory will fail at startup
- If the first pass feels thin on testing, re-prompt asking specifically for the pytest fixtures with rolled-back transactions per test
