Litestar di
Opinionated first-party agent skills, plugins, subagents, slash commands, and MCP servers for the Litestar framework ecosystem — publishable to Claude Code, Gemini CLI, Codex CLI, Cursor, OpenCode, and VS Code/Copilot from a single repo.
npx -y skills add litestar-org/litestar-skills --skill litestar-diAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Auto-activate for Provide, NamedDependency, SkipValidation, Dependency(skip_validation=True), dependencies=, litestar.di, Dishka FromDishka, Inject, or providers. Not for plain parameters.
SKILL.md
3.1 KB, as published. Nobody here has run it
Litestar Dependency Injection
Use this skill for Provide, NamedDependency / SkipValidation, dependency
maps, provider factories, request-scoped resources, and Dishka integration.
Code Style Rules
- Mark every name-based injected parameter with
NamedDependency[T]. UseNamedDependency[SkipValidation[T]]only for trusted provider output that must bypass validation. - Wrap providers in
Provide. For synchronous providers, setsync_to_thread=Truefor blocking work orFalsefor trivial non-blocking work; leaving it unspecified emits a warning. - Use Litestar dependency maps for simple and medium apps.
- Use Dishka when the project needs explicit scopes and provider modules.
- Keep provider names stable and descriptive.
- Do not open request-scoped resources at import time.
Quick Reference
- DI patterns: di.md
- Pair with litestar-data-services for service providers.
- Pair with litestar-settings for settings injection.
- Pair with litestar-autowire when discovered controllers need the optional Dishka router integration.
Workflow
- Identify whether the dependency is app, request, transaction, or function scoped.
- Choose built-in dependency maps or the existing DI framework.
- Register providers at the narrowest useful scope.
- Inject dependencies by name or type according to the chosen stack.
Guardrails
- Do not introduce Dishka for one or two simple providers.
- Do not mix dependency naming conventions in one app.
- Do not keep database sessions or clients as global mutable state.
- Do not hide business logic inside providers.
- Do not mutate dependencies on a constructed app in tests. Build a fresh app or test client with the replacement dependency map.
Validation Checkpoint
- Dependency scope is explicit.
- Providers are async when they manage async resources.
- Tests can override providers cleanly.
- Provider wiring matches the app's existing DI style.
Example
from litestar.di import NamedDependency, Provide
async def provide_user_service(db_session: NamedDependency[AsyncSession]) -> UserService:
return UserService(session=db_session)
dependencies = {"users_service": Provide(provide_user_service)}
</example>
References Index
Official References
- https://docs.litestar.dev/ - Litestar documentation
- https://docs.litestar.dev/latest/reference/ - Litestar API reference
- https://github.com/litestar-org/litestar/tree/v2.24.0 - Audited Litestar 2.24.0 source