agentsclimarketplace

Litestar di

Skill litestar-org/litestar-skills/plugins/litestar/skills/litestar-di

Auto-activate for Provide, NamedDependency, SkipValidation, Dependency(skip_validation=True), dependencies=, litestar.di, Dishka FromDishka, Inject, or providers. Not for plain parameters.From its SKILL.md

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.

SKILL.md

3.1 KB, 665 tokens by cl100k_base, 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

What ships with it: 1 file

7.4 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 325,949. 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.