From sc-skills
Reframe code designs with functional programming principles for agent-assisted development, separating pure functions from effects to boost agent effectiveness and human reviewability. Use for module planning and agent-friendly structures.
npx claudepluginhub kylesnowschwartz/simpleclaude --plugin sc-skillsThis skill uses the workspace's default tool permissions.
FP discipline for agent-assisted development. Not about switching languages — about structuring code so agents write it well and humans review it fast.
Applies Acme Corporation brand guidelines including colors, fonts, layouts, and messaging to generated PowerPoint, Excel, and PDF documents.
Builds DCF models with sensitivity analysis, Monte Carlo simulations, and scenario planning for investment valuation and risk assessment.
Calculates profitability (ROE, margins), liquidity (current ratio), leverage, efficiency, and valuation (P/E, EV/EBITDA) ratios from financial statements in CSV, JSON, text, or Excel for investment analysis.
FP discipline for agent-assisted development. Not about switching languages — about structuring code so agents write it well and humans review it fast.
Agents are pattern matchers. They compress training data into a world model, then map between representations: f(pattern_in, context, constraints) => pattern_out. FP makes the patterns explicit.
| FP Property | Agent Benefit | Human Benefit |
|---|---|---|
| Type signatures encode intent | One line = full context. Input, output, effects. No retrieval needed. | Skim signatures, skip bodies |
| Pure functions are self-contained | Entire function is contiguous text. No hidden state to chase. | Trust pure code, scrutinize edges |
| Composition is the architecture | Agents pattern-match the wiring, generate the parts | Review wiring, ignore parts |
| Constraints prevent laziness | Can't introduce side effects where the type system forbids them | Structural enforcement, not convention |
When approaching any design decision:
Instead of: "What object/class should own this behavior?" Ask: "What's the pure transform, and where does the effect happen?"
Every function is one of three things:
| Type | What It Does | Who Reviews | Agent Writes Well? |
|---|---|---|---|
| Pure transform | Data in, data out. No effects. | Skim or skip | Yes — self-contained, testable |
| Effect at the edge | IO, network, DOM, persistence | Read every line | Needs guidance — effects are contextual |
| Composition | Wires pure + edge together | This IS the architecture | No — human decides the wiring |
Apply these operations to any code design problem:
Ask: "If I deleted every side effect from this function, what computation remains?"
That computation is your pure core. Extract it. The side effects become a thin shell that calls the pure function and does IO with the result.
BEFORE: fetchUser(id) { data = await fetch(url); return validate(data); }
AFTER: validateUser(data) { ... } // pure
fetchUser(id) { data = await fetch(url); return validateUser(data); } // edge
Ask: "Can the caller handle this effect instead of the callee?"
Effects belong at the outermost layer possible. A function that reads localStorage is harder to test than one that receives the data as an argument. Push effects toward main(), toward the composition root, toward the entry point.
Ask: "Can the type system prevent this bug, or does it rely on runtime discipline?"
Branded types prevent coordinate confusion. Discriminated unions with exhaustive matching prevent missed cases. Result<T, E> makes failure explicit in the return type instead of hidden in exceptions.
Ask: "If an agent ignores my instructions, does the code still work correctly?"
Agents are lazy. They'll take shortcuts if shortcuts compile. Convention says "don't put side effects here." Structure says "this module physically cannot import the side-effect library." Prefer structure.
Examples:
*.pure.ts filesAsk: "What's the minimum this function needs to know?"
A function that takes AgentState when it only needs { hex: HexCoordinate } carries unnecessary context. Narrow the input type. This reduces the context an agent needs to understand the function, and makes the function reusable across more call sites.
State management is where FP discipline pays off most in frontend code:
| Rule | Why |
|---|---|
| No side effects in actions | Actions become pure state transitions. Testable without mocking. |
| No cross-store calls in actions | Wire cross-cutting concerns at the composition root. Stores stay independent. |
| No persistence in store files | Extract to subscription files. Store logic is pure; persistence is an edge effect. |
| No logging in actions | Event stores or subscriptions handle observability. Actions compute new state, period. |
Store action template:
1. Read current state
2. Compute new state (call pure functions)
3. Single set() call
4. Return value for caller — no side effects
Handlers dispatch on message type and perform effects. Use dependency injection to keep them testable:
interface HandlerDeps {
getAgent: (id: string) => Agent | undefined;
// inject only what's needed
}
function createHandler(deps: HandlerDeps): (msg: Message) => void
The handler factory is pure (given deps, returns a function). The deps are wired at the composition root. Testing injects mock deps without touching real stores.
Make purity visible in the filesystem:
feature/
types.ts # Pure types, no runtime
foo.pure.ts # Pure transforms — agents write these freely
fooStore.ts # State transitions — review action shapes
fooPersistence.ts # Edge effects — review carefully
Foo.tsx # UI — inherently impure, review interaction logic
The .pure.ts suffix signals to both agents and reviewers: this file has no side effects, is enforced by linting, and can be trusted if the types check.
When reviewing agent-written code through an FP lens:
Time allocation: 60% on composition + edges, 30% on tests, 10% on pure function bodies.
| Anti-Pattern | Symptom | Fix |
|---|---|---|
| Purity theater | .pure.ts file that secretly mutates a closure | Enforce with linting, not just naming |
| Effect sandwich | Pure-impure-pure in one function body | Split into three functions, compose at call site |
| Overly narrow types | 15 tiny interfaces when 3 would do | Group by usage pattern, not by minimal surface |
| Monadic overengineering | Result<Option<Either<T, E>>> | Use discriminated unions. if (result.ok) is readable. |
| Convention cop | Writing comments like "DO NOT add side effects here" | Add a lint rule instead. Agents don't read comments. |
For your current design problem:
The best code for agent-assisted development is code where the types tell the whole story.