How do I install the Fn Args Deps skill?

Run npx skillmds@latest add jagreehal/fn-args-deps in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Fn Args Deps safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Fn Args Deps?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Fn Args Deps free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Fn Args Deps?

jagreehal (@jagreehal) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Fn Args Deps by jagreehal — Agent Skill

Name: Fn Args Deps
Rating: 4.5 (4 reviews)
Author: jagreehal

Fn Args Deps

Enforces the fn(args, deps) pattern: business logic as functions with explicit dependency injection instead of service classes. Use this skill when writing or refactoring TypeScript business logic, replacing classes, structuring deps, or setting up a composition root. Do not use when/for React component structure (use react-development) or Result/error modeling alone (use result-types).

jagreehal Updated Sep 10, 2026

File contents

Functions Over Classes: fn(args, deps)

Critical rules

Business logic is fn(args, deps) — never service classes. args are per-call; deps are long-lived collaborators.
Declare a per-function deps type. No god AllServiceDeps objects.
Wire deps once at a composition root. Handlers call factories, not constructors mid-request.
Inject only network/disk/clock collaborators. Import pure utilities directly.
Use import type for infra interfaces; instances arrive via deps.
Before writing examples or grouping choices, read references/examples.md and references/patterns.md.

Workflow

Identify business logic that should be a function (or extract it from a class).
Split per-call data into args and collaborators into a named XDeps type.
Before choosing individual vs grouped injection, read references/patterns.md.
Implement fn(args, deps). Keep classes only as thin framework wrappers or stateful resources.
Add a factory / composition-root wire-up so call sites never construct deps.
Test with mock<XDeps>() — no class instantiation. See references/examples.md.

Resources

references/examples.md — WRONG vs CORRECT signatures, composition root, NestJS wrapper, tests. Read when implementing or reviewing.
references/patterns.md — grouping, migration, when classes are OK, enforcement, rationalizations. Read before structuring modules.

Validation

Every business function is fn(args, deps) with a per-function deps type
No unused deps fields; no god deps bag
Deps wired once at composition root
Infra via import type only; instances via deps
Pure utilities imported, not injected
Remaining classes are wrappers, stateful resources, or builders
Tests use mock<XDeps>() without instantiating a class

Constraints

Framework-mandated classes, connection pools, caches, and fluent builders may stay as thin wrappers over pure functions.
Related: result-types, validation-boundary, testing-strategy, writing-tests, observability, strict-typescript, pattern-enforcement.

---name: fn-args-depsdescription: >- Enforces the fn(args, deps) pattern: business logic as functions with explicit dependency injection instead of service classes. Use this skill when writing or refactoring TypeScript business logic, replacing classes, structuring deps, or setting up a composition root. Do not use when/for React component structure (use react-development) or Result/error modeling alone (use result-types).version: 1.2.0libraries: ["vitest-mock-extended"]---# Functions Over Classes: fn(args, deps)## Critical rules- Business logic is `fn(args, deps)` — never service classes. `args` are per-call; `deps` are long-lived collaborators.- Declare a per-function deps type. No god `AllServiceDeps` objects.- Wire deps once at a composition root. Handlers call factories, not constructors mid-request.- Inject only network/disk/clock collaborators. Import pure utilities directly.- Use `import type` for infra interfaces; instances arrive via `deps`.- Before writing examples or grouping choices, read [references/examples.md](references/examples.md) and [references/patterns.md](references/patterns.md).## Workflow1. Identify business logic that should be a function (or extract it from a class).2. Split per-call data into `args` and collaborators into a named `XDeps` type.3. Before choosing individual vs grouped injection, read [references/patterns.md](references/patterns.md).4. Implement `fn(args, deps)`. Keep classes only as thin framework wrappers or stateful resources.5. Add a factory / composition-root wire-up so call sites never construct deps.6. Test with `mock<XDeps>()` — no class instantiation. See [references/examples.md](references/examples.md).## Resources- [references/examples.md](references/examples.md) — WRONG vs CORRECT signatures, composition root, NestJS wrapper, tests. Read when implementing or reviewing.- [references/patterns.md](references/patterns.md) — grouping, migration, when classes are OK, enforcement, rationalizations. Read before structuring modules.## Validation- [ ] Every business function is `fn(args, deps)` with a per-function deps type- [ ] No unused `deps` fields; no god deps bag- [ ] Deps wired once at composition root- [ ] Infra via `import type` only; instances via `deps`- [ ] Pure utilities imported, not injected- [ ] Remaining classes are wrappers, stateful resources, or builders- [ ] Tests use `mock<XDeps>()` without instantiating a class## Constraints- Framework-mandated classes, connection pools, caches, and fluent builders may stay as thin wrappers over pure functions.- Related: `result-types`, `validation-boundary`, `testing-strategy`, `writing-tests`, `observability`, `strict-typescript`, `pattern-enforcement`.

Frequently asked questions