What this prompt does
This prompt casts the model as a senior Python engineer and asks it to design a scalable Flask app using the application-factory and blueprint patterns -- with working code where the tree runs and the tests pass, not pseudocode. You supply [domain], [database], [auth], and [deploy_target], and it returns the factory, blueprints, per-environment config, SQLAlchemy plus Flask-Migrate, JWT auth, CLI commands, and tests.
The structure works because it rebuilds the classic one-giant-app.py problem into isolated pieces. [domain] decides how blueprints are split by feature area. [database] and [auth] wire the models and the login flow concretely (Flask-JWT-Extended, for instance, gives you a real protected route). [deploy_target] shapes the Dockerfile. The deliverables specifically demand that migrations work under the factory, which is the pairing that trips up most setups, so the prompt addresses it head-on instead of leaving you to debug the Flask-Migrate wiring later.
When to use it
- You're scaffolding a new Flask service and want a clean factory-plus-blueprints layout.
- You inherited a giant
app.pythat's become impossible to test or extend. - You need config to stop leaking secrets and load per environment from env vars.
- You want Flask-Migrate working correctly under the application factory.
- You need JWT auth with a login flow and a protected-route example.
- You want custom CLI commands (seed, create-admin) and a pytest setup with fixtures.
- You want central error handling and request logging shared across every blueprint.
Example output
You get the full file tree, then the key files: the __init__ factory, one example blueprint, the config classes, and a sample test. Around them sit the SQLAlchemy models with Flask-Migrate, the JWT login flow and protected route, central error handling and request logging, the CLI commands, and a Dockerfile. It's structured so the tree runs and the sample test passes once filled in, giving you a working skeleton rather than disconnected snippets.
Pro tips
- Describe
[domain]by its feature areas (blog with posts, authors, comments) so blueprints split along real boundaries. - Set
[auth]to a concrete library (Flask-JWT-Extended) so the login flow and protected route are real, not abstract. - Match
[database]to your engine so the SQLAlchemy models and migration config fit. - Get the factory and Flask-Migrate playing together early -- that pairing trips up most setups, and the prompt targets it directly.
- Make
[deploy_target]specific so the Dockerfile and process model match where it runs. - Ask for the test fixtures to spin up a clean app instance per test; that's the payoff of the factory pattern.
- Add central error handling and request logging early so blueprints share one consistent failure response shape.
