andr-caandr-ca/agentharness/.claude/skills/dependency-injection/SKILL.md

dependency-injection

Skill1 starsChanged 2 months agoMITView on GitHub

Use when writing or reviewing code with object graphs, service dependencies, or testability concerns. Covers constructor injection, DI containers, lifetimes, and anti-patterns (service locator, ambient context, over-injection).

We split this skill into the rules it gives an agent

2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.

0
Common
Most of the 10 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Use a container (FastAPI's Depends, tsyringe, Wire for Go) when:
line 60
Distinctive:
Don't use a container for:
line 65

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Dependency Injection

One rule: depend on abstractions, receive them via constructor, never create them internally.

The Pattern

# BAD — hard to test, tightly coupled
class OrderService:
    def __init__(self):
        self.db = Database()          # creates its own dependency
        self.email = EmailClient()    # can't inject fakes in tests

# GOOD — testable, decoupled
class OrderService:
    def __init__(self, db: Database, email: EmailClient) -> None:
        self.db = db
        self.email = email

// BAD
class OrderService {
    private db = new Database();   // hidden dependency
}

// GOOD
class OrderService {
    constructor(private db: Database, private email: EmailClient) {}
}

Rules

Do	Don't
Inject dependencies via constructor	Create dependencies with `new` inside a class
Depend on interfaces/protocols	Depend on concrete types when an abstraction exists
Make dependencies explicit	Use service locators (`Container.get(...)`) inside business logic
Keep constructors simple — no logic	Do work in `__init__`/constructors
Use fakes/stubs in tests	Patch global singletons in tests

When to Use a DI Container

Use a container (FastAPI's Depends, tsyringe, Wire for Go) when:

The object graph has 3+ levels of nesting
You need lifetime management (singleton vs. transient vs. scoped)
You need request-scoped dependencies (e.g., database sessions per HTTP request)

Don't use a container for:

Small scripts or utilities (manual wiring is simpler and clearer)
Value objects (DTOs, records) — they carry data, not behavior
Stateless pure functions

Lifetimes

Lifetime	When to use	Example
Singleton	Shared state across the app; expensive to create	`DatabasePool`, `ConfigLoader`
Scoped	One instance per request/unit of work	`DbSession`, `UserContext`
Transient	Stateless; cheap to create	`EmailFormatter`, `Validator`

Anti-Patterns

Service Locator — business logic calls Container.get(Service) directly. Makes dependencies invisible.

Ambient Context / Thread-local — global mutable state accessed via static accessors. Breaks testability.

Constructor over-injection (> 4 params) — sign the class violates SRP; split responsibilities.

Circular dependency — A depends on B which depends on A. Refactor to break the cycle, often by extracting a shared interface.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free