Enforce the fn(args, deps) pattern: functions over classes with explicit dependency injection
Enforces the fn(args, deps) pattern for business logic: functions with explicit dependency injection instead of classes. Claude will use this when creating new business logic functions or refactoring existing classes, ensuring dependencies are typed per-function and injected at composition roots rather than imported directly.
/plugin marketplace add jagreehal/jagreehal-claude-skills/plugin install jagreehal-claude-skills@jagreehal-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
All business logic functions MUST follow this signature:
fn(args, deps)
args and deps have different lifetimes:
args are per-call datadeps are long-lived collaboratorsKeeping them separate makes dependency bloat visible and composition easier.
ALWAYS declare explicit deps types for each function:
// CORRECT
type GetUserDeps = {
db: Database;
logger: Logger;
};
async function getUser(
args: { userId: string },
deps: GetUserDeps
): Promise<User | null> {
deps.logger.info(`Getting user ${args.userId}`);
return deps.db.findUser(args.userId);
}
// WRONG - God object with all deps
async function getUser(
args: { userId: string },
deps: AllServiceDeps // Contains mailer, cache, metrics that getUser doesn't use
): Promise<User | null>
Classes become problematic when:
this// WRONG
class UserService {
constructor(
private db: Database,
private logger: Logger,
private mailer: Mailer, // only createUser needs this
private cache: Cache, // only someOtherMethod needs this
) {}
}
// CORRECT
type GetUserDeps = { db: Database; logger: Logger };
type CreateUserDeps = { db: Database; logger: Logger; mailer: Mailer };
Wire deps ONCE at the boundary, not at every call site:
// user-service/index.ts
export function createUserService({ deps }: { deps: UserServiceDeps }) {
return {
getUser: ({ userId }: { userId: string }) =>
getUser({ userId }, deps),
createUser: ({ name, email }: { name: string; email: string }) =>
createUser({ name, email }, deps),
};
}
// main.ts (Composition Root)
const deps = { db, logger, mailer };
const userService = createUserService({ deps });
// Handlers stay clean
await userService.getUser({ userId: '123' });
Only inject things that hit network, disk, or clock. Import pure utilities directly:
// WRONG - Over-injecting
function createUser(args, deps: { db, logger, slugify, randomUUID }) { }
// CORRECT - Only inject what you'll mock
import { slugify } from 'slugify';
import { randomUUID } from 'crypto';
function createUser(args, deps: { db, logger }) { }
Use import type to prevent runtime coupling:
// CORRECT
import type { Mailer } from '../infra/mailer';
// WRONG - Runtime import creates coupling
import { mailer } from '../infra/mailer';
import { describe, it, expect } from 'vitest';
import { mock } from 'vitest-mock-extended';
import { getUser, type GetUserDeps } from './get-user';
it('returns user when found', async () => {
const mockUser = { id: '123', name: 'Alice', email: 'alice@test.com' };
const deps = mock<GetUserDeps>();
deps.db.findUser.mockResolvedValue(mockUser);
const result = await getUser({ userId: '123' }, deps);
expect(result).toEqual(mockUser);
});
import { mailer as _mailer, type Mailer } from '../infra/mailer';
const defaultDeps: SendEmailDeps = { mailer: _mailer };
export async function sendEmail(
recipient: User,
sender: User,
deps: SendEmailDeps = defaultDeps // Default for existing callers
) { ... }
import type { Mailer } from '../infra/mailer';
export async function sendEmail(
recipient: User,
sender: User,
deps: SendEmailDeps // No default - must inject
) { ... }
export async function sendEmail(
args: { recipient: User; sender: User },
deps: SendEmailDeps
) { ... }
Classes are fine for:
| Use Case | Why It's OK |
|---|---|
| Framework integration | NestJS, Express middleware require class syntax |
| Stateful resources | Connection pools, caches with lifecycle |
| Builder patterns | Fluent APIs where method chaining adds clarity |
| Thin wrappers | Delegating to pure functions (see below) |
Classes are NOT OK for:
Use classes as thin wrappers, keep logic in pure functions:
// Pure function - your actual logic
async function createUser(
args: CreateUserInput,
deps: { db: Database; logger: Logger }
): Promise<Result<User, 'EMAIL_EXISTS' | 'DB_ERROR'>> {
// Business logic here
}
// NestJS wrapper - thin delegation layer
@Injectable()
export class UserService {
constructor(private db: Database, private logger: Logger) {}
async createUser(args: CreateUserInput) {
return createUser(args, { db: this.db, logger: this.logger });
}
}
Critics sometimes worry that creating many small objects (args objects, deps bags, factory functions) increases garbage collection pressure.
The reality: Modern V8 engines (Orinoco) use generational garbage collection. Objects that die young—like the temporary objects created during request handling—are reclaimed almost instantly. V8 is extremely efficient at this.
For I/O-bound web applications:
| Operation | Typical Latency |
|---|---|
| Database query | 1-50ms |
| HTTP request | 10-500ms |
| Object allocation | 0.0001ms |
The database query is 10,000-500,000x slower than object allocation. The architectural clarity and type safety of the fn(args, deps) pattern far outweigh any micro-overhead.
When to worry about allocation:
For typical web services, don't optimize for GC. Optimize for correctness, testability, and maintainability.
Enable in tsconfig.json:
{
"compilerOptions": {
"verbatimModuleSyntax": true
}
}
ESLint rule to prevent infra imports:
"no-restricted-imports": ["error", {
patterns: [{
group: ["**/infra/**"],
message: "Domain code must not import from infra. Inject dependencies instead."
}]
}]
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.