Flask patterns -- application factory, blueprints, error handlers, extensions, request lifecycle, configuration, logging, CLI commands
98
98%
Does it follow best practices?
Impact
98%
1.28xAverage score across 5 eval scenarios
Passed
No known issues
{
"instruction": "Use application factory pattern with create_app(), not module-level app",
"relevant_when": "Agent builds or scaffolds a Flask application",
"context": "Flask apps must use a create_app() factory function in app/__init__.py. The factory imports blueprints and extensions inside the function body to avoid circular imports, accepts a config parameter for testing/dev/prod, and never calls app.run() inside itself.",
"sources": [
{
"type": "file",
"filename": "skills/flask-best-practices/SKILL.md",
"tile": "tessl-labs/flask-best-practices@0.2.0"
}
],
"checklist": [
{
"name": "create-app-factory",
"rule": "Agent defines a create_app() function that creates and returns a Flask app instance -- not a module-level `app = Flask(__name__)` with routes defined on it",
"relevant_when": "Agent sets up a Flask application"
},
{
"name": "factory-in-init",
"rule": "The create_app() function lives in app/__init__.py (not in run.py or a random module)",
"relevant_when": "Agent creates the Flask application entry point"
},
{
"name": "imports-inside-factory",
"rule": "Blueprints and extensions are imported inside create_app(), not at the top of the module",
"relevant_when": "Agent registers blueprints or extensions in the factory"
},
{
"name": "config-parameter",
"rule": "create_app() accepts a configuration parameter (config name, dict, or object) to support different environments (testing, development, production)",
"relevant_when": "Agent defines the create_app() function signature"
},
{
"name": "no-app-run-in-factory",
"rule": "create_app() does NOT call app.run() -- the caller (run.py, WSGI server, or test fixture) decides how to run",
"relevant_when": "Agent implements the create_app() function"
}
]
}