agentsclimarketplace

Litestar di

Skill litestar-org/litestar-skills/skills/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.

Install
npx -y skills add litestar-org/litestar-skills --skill litestar-di

Assembled 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]. Use NamedDependency[SkipValidation[T]] only for trusted provider output that must bypass validation.
  • Wrap providers in Provide. For synchronous providers, set sync_to_thread=True for blocking work or False for 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

<workflow>

Workflow

  1. Identify whether the dependency is app, request, transaction, or function scoped.
  2. Choose built-in dependency maps or the existing DI framework.
  3. Register providers at the narrowest useful scope.
  4. Inject dependencies by name or type according to the chosen stack.
</workflow> <guardrails>

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.
</guardrails> <validation>

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.
</validation> <example>

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

Shared Styleguide Baseline

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.