[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79TCJMWPPFNMS9BY9VSP2NW":3,"skill-same:01M79TCJMWPPFNMS9BY9VSP2NW":53},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":14,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M79TCJMWPPFNMS9BY9VSP2NW","flask-architect",null,"Architect-level Flask guidance — app factory and blueprint boundaries, WSGI and sync concurrency model, extension configuration, request\u002Fapplication context discipline, error handlers, and when Flask is the right choice over FastAPI or Django. Use when designing or reviewing a Flask service.","SriAkhilSJ\u002FPulseAIRepo","SriAkhilSJ","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206201543?v=4","01M79RWFD1Q09B89SXTTKKJY6Z","Sri Akhil SJ","01M79RWFE26NPG0BZ1FRNX376H",0,"MIT","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fbackend-development-architect\u002Fpython-architect\u002Fflask-architect\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: flask-architect\ndescription: Architect-level Flask guidance — app factory and blueprint boundaries, WSGI and sync concurrency model, extension configuration, request\u002Fapplication context discipline, error handlers, and when Flask is the right choice over FastAPI or Django. Use when designing or reviewing a Flask service.\nlicense: MIT\ncompatibility: Flask 3.x, WSGI (gunicorn\u002FuWSGI)\nmetadata:\n  crusor-domain: website-architect\n  crusor-path: website-architect\u002Fbackend-development-architect\u002Fpython-architect\u002Fflask-architect\n  crusor-origin: original\n  crusor-sources: \"flask.palletsprojects.com; wsgi.readthedocs.io\"\n  crusor-triggers: \"flask, wsgi, blueprints, app factory, jinja, gunicorn\"\n  crusor-verified-on: \"2026-10-30\"\n---\n\n# Flask Architect\n\nFlask is a **library, not a platform**: it gives you routing and a request cycle,\nand you decide everything else. Architecture here is mostly about what you refuse\nto put in the app.\n\n## When to use\n\n- Small\u002Fmedium service or internal API with explicit control over the stack.\n- Server-rendered pages with Jinja and light interactivity.\n- A WSGI deployment that must stay simple (no async requirement).\n- Prototypes that will grow — provided the factory\u002Fblueprint discipline below is\n  in place from day one.\n\n## When NOT to use\n\n- Many concurrent I\u002FO waits (see `fastapi-architect`; Flask's sync model bounds\n  you to worker processes).\n- A product with admin, auth, and a large ORM surface (see `django-architect`).\n- OpenAPI-first contract delivery — FastAPI makes that native.\n\n## Decision 1 — App factory + blueprints\n\n```python\ndef create_app(config: Config) -> Flask:\n    app = Flask(__name__)\n    app.config.from_object(config)\n    app.register_blueprint(api_v1, url_prefix=\"\u002Fv1\")\n    return app\n```\n\n- **No module-level `app`.** The factory is what makes tests, workers and\n  multiple configs possible.\n- One blueprint per bounded context (`auth`, `orders`, `billing`), not per file.\n- Extensions initialised in the factory, bound to `app.extensions`, never as\n  import-time singletons.\n- Config is an object with typed fields; secrets come from the environment.\n\n## Decision 2 — Layering inside a WSGI app\n\n```\nwsgi.py            create_app()\n  blueprints\u002F      routes: parse, validate, status codes\n    services\u002F      use-cases (no flask imports)\n      repositories\u002F DB access\n        models\u002F    SQLAlchemy or plain dataclasses\n```\n\n- A service function never imports `request`, `g`, or `current_app`.\n- Validation happens at the blueprint edge; services take typed arguments.\n- `g` is per-request scratch space, not a container for business objects.\n\n## Decision 3 — Contexts and error handling\n\n- Application context for startup resources; request context for request data.\n  Do not stash request state on the app object.\n- One `register_error_handler` per error class; return the same envelope shape\n  everywhere.\n- 404\u002F405\u002F500 handled explicitly — a default HTML traceback is a security leak.\n- Teardown hooks close sessions\u002Fconnections deterministically.\n\n## Decision 4 — Concurrency and deployment\n\n- WSGI = one request per worker at a time. Scale with worker **processes**.\n- Blocking external calls need timeouts; without them a slow upstream consumes\n  the worker.\n- Shared state (rate limits, caches) belongs outside the process; memory dies\n  with the worker and is not shared.\n- Behind a proxy: trust exactly one hop of `X-Forwarded-*`\n  (`ProxyFix`), and set secure cookie flags.\n\n## Failure modes at scale\n\n- Module-level `app` + import-time extension init → can't test, can't scale.\n- Business logic inside view functions → duplicated across blueprints.\n- `app.config` used as a global registry for runtime state.\n- One worker configuration for CPU-bound and I\u002FO-bound paths.\n- Sessions\u002Fcookies used as a data store.\n\n## Verification receipts\n\n1. App created twice in one process (tests) without shared state.\n2. Error handlers verified for 400\u002F404\u002F405\u002F500 with a consistent envelope.\n3. Load test at expected concurrency: worker saturation and queue time visible.\n4. Teardown test: connections closed, no leaked sessions.\n5. Config audit: no secret in code, debug off in production.\n","# Flask Architect\n\nFlask is a **library, not a platform**: it gives you routing and a request cycle,\nand you decide everything else. Architecture here is mostly about what you refuse\nto put in the app.\n\n## When to use\n\n- Small\u002Fmedium service or internal API with explicit control over the stack.\n- Server-rendered pages with Jinja and light interactivity.\n- A WSGI deployment that must stay simple (no async requirement).\n- Prototypes that will grow — provided the factory\u002Fblueprint discipline below is\n  in place from day one.\n\n## When NOT to use\n\n- Many concurrent I\u002FO waits (see `fastapi-architect`; Flask's sync model bounds\n  you to worker processes).\n- A product with admin, auth, and a large ORM surface (see `django-architect`).\n- OpenAPI-first contract delivery — FastAPI makes that native.\n\n## Decision 1 — App factory + blueprints\n\n```python\ndef create_app(config: Config) -> Flask:\n    app = Flask(__name__)\n    app.config.from_object(config)\n    app.register_blueprint(api_v1, url_prefix=\"\u002Fv1\")\n    return app\n```\n\n- **No module-level `app`.** The factory is what makes tests, workers and\n  multiple configs possible.\n- One blueprint per bounded context (`auth`, `orders`, `billing`), not per file.\n- Extensions initialised in the factory, bound to `app.extensions`, never as\n  import-time singletons.\n- Config is an object with typed fields; secrets come from the environment.\n\n## Decision 2 — Layering inside a WSGI app\n\n```\nwsgi.py            create_app()\n  blueprints\u002F      routes: parse, validate, status codes\n    services\u002F      use-cases (no flask imports)\n      repositories\u002F DB access\n        models\u002F    SQLAlchemy or plain dataclasses\n```\n\n- A service function never imports `request`, `g`, or `current_app`.\n- Validation happens at the blueprint edge; services take typed arguments.\n- `g` is per-request scratch space, not a container for business objects.\n\n## Decision 3 — Contexts and error handling\n\n- Application context for startup resources; request context for request data.\n  Do not stash request state on the app object.\n- One `register_error_handler` per error class; return the same envelope shape\n  everywhere.\n- 404\u002F405\u002F500 handled explicitly — a default HTML traceback is a security leak.\n- Teardown hooks close sessions\u002Fconnections deterministically.\n\n## Decision 4 — Concurrency and deployment\n\n- WSGI = one request per worker at a time. Scale with worker **processes**.\n- Blocking external calls need timeouts; without them a slow upstream consumes\n  the worker.\n- Shared state (rate limits, caches) belongs outside the process; memory dies\n  with the worker and is not shared.\n- Behind a proxy: trust exactly one hop of `X-Forwarded-*`\n  (`ProxyFix`), and set secure cookie flags.\n\n## Failure modes at scale\n\n- Module-level `app` + import-time extension init → can't test, can't scale.\n- Business logic inside view functions → duplicated across blueprints.\n- `app.config` used as a global registry for runtime state.\n- One worker configuration for CPU-bound and I\u002FO-bound paths.\n- Sessions\u002Fcookies used as a data store.\n\n## Verification receipts\n\n1. App created twice in one process (tests) without shared state.\n2. Error handlers verified for 400\u002F404\u002F405\u002F500 with a consistent envelope.\n3. Load test at expected concurrency: worker saturation and queue time visible.\n4. Teardown test: connections closed, no leaked sessions.\n5. Config audit: no secret in code, debug off in production.\n",{"name":5,"license":15,"metadata":24,"description":7,"compatibility":31},{"crusor-path":25,"crusor-domain":26,"crusor-origin":27,"crusor-sources":28,"crusor-triggers":29,"crusor-verified-on":30},"website-architect\u002Fbackend-development-architect\u002Fpython-architect\u002Fflask-architect","website-architect","original","flask.palletsprojects.com; wsgi.readthedocs.io","flask, wsgi, blueprints, app factory, jinja, gunicorn","2026-10-30","Flask 3.x, WSGI (gunicorn\u002FuWSGI)","main","8fa4e240be65b98472c9b2d3a505ade2aea1a5c6","skills\u002Fwebsite-architect\u002Fbackend-development-architect\u002Fpython-architect\u002Fflask-architect","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ","Studying in CMR institute of Technology\r\n2024 - 2028","2026-11-13 21:02:23",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add SriAkhilSJ\u002FPulseAIRepo --skill flask-architect",{"tool":45,"command":46},"bunx","bunx skills add SriAkhilSJ\u002FPulseAIRepo --skill flask-architect",{"tool":48,"command":49},"pnpm","pnpm dlx skills add SriAkhilSJ\u002FPulseAIRepo --skill flask-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fbackend-development-architect\u002Fpython-architect\u002Fflask-architect\u002FSKILL.md",true,[],[54,61,68,75,82,89],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M79TTAJNACCNXCEN3649CMMD","interaction-patterns-architect","Architect-level interaction design in code — choosing established patterns over invented ones, feedback and latency behaviour, destructive-action safeguards, navigation and overlay conventions, and the state model behind every interactive surface. Use when a screen has to behave, not just look.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Finteraction-patterns-architect\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M79TT2ESKB1TKZBYY9KYJHV9","design-system-ops-architect","Architect-level operation of a design system in code — token pipelines and versioning, component API and variant policy, the catalogue as the contract, adoption metrics, and the governance that stops a system from forking into three. Use when a component library must survive several teams.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fdesign-system-ops-architect\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M79TSV0PWGNK3PRX9P4JDR9N","design-handoff-architect","Architect-level design handoff — what must be specified before implementation starts, tokens over raw values, responsive and content-limit contracts, state matrices, and the review loop that catches drift between design and code. Use when a design is about to become code.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fdesign-handoff-architect\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M79TSJS9BFXNP696FMJ9GKDA","content-microcopy-architect","Architect-level UI content — where strings live, voice and terminology consistency, error and empty-state copy as part of the interface, translation-ready authoring, and the content model a product needs before it multiplies screens. Use when the words in the interface matter as much as the pixels.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fcontent-microcopy-architect\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M79TSCNBST3N1M68V1KPH9HQ","ui-ux-implementation-architect","Architect-level direction for turning a design into working UI — the handoff contract, component ownership versus screen-level layout, interaction and state conventions, design QA gates, and the review habits that keep an implementation faithful without frozen pixels. Use before any specific UI implementation skill.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M79TS4N6A4D2QQ433VXS5D0R","test-strategy-architect","Architect-level test strategy — allocating assertions across unit, integration, contract and end-to-end layers, designing for testability through dependency boundaries, fixture and data strategy, and the flake and coverage policies that keep a suite trustworthy. Use when defining how a codebase is tested.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Ftesting-and-deployment-architect\u002Ftest-strategy-architect\u002FSKILL.md",[],[]]