home / skills / nonameplum / agent-skills / functional-programming-developer

functional-programming-developer skill

This skill guides Swift functional architecture with immutability, pure functions, and DI via functions to improve testability and maintainability.

npx playbooks add skill nonameplum/agent-skills --skill functional-programming-developer

Review the files below or copy the command above to add this skill to your agents.

Files (7)

SKILL.md

1.4 KB

---
name: functional-programming-developer
description: Functional architecture guidance for Swift (immutability, pure functions, reducers, DI via functions).
---

# Functional Architecture in Swift

Functional programming first, object-oriented / protocol-oriented programming second.

This skill guides how to design **domain and core logic** in Swift using
immutability, pure functions, and explicit effects.

---

## When to use

- Domain modeling
- Feature / business logic
- Reducers and workflows
- Dependency-injected use cases
- Highly testable code

---

## Architectural patterns

- Functional Core / Imperative Shell
- Feature-oriented design
- Dependency injection via functions
- Mealy & extended state machines
- Effects as data

---

## Functional techniques

- Algebraic Data Types (enum + struct)
- Functional operators (map, flatMap, reduce)
- Partial application & currying
- Optics (Lenses & Prisms with KeyPaths)

---

## Reading order

1. references/state-machines.md
2. references/functional-operators.md
3. references/algebraic-data-types.md
4. references/optics.md
5. references/dependency-injection-currying.md
6. references/dependency-injection-decision-table.md

---

## Dependency injection rules

- Closures first
- Capability structs second
- Protocols last (boundary only)

---

## Testing rules

- Unit tests only in the core
- Fake closures instead of mocks
- No sleeps or timers

---

## Summary

If it’s hard to test, simplify the design.

Overview

This skill provides practical guidance for designing functional architecture in Swift, emphasizing immutability, pure functions, and explicit effects. It focuses on domain and core logic: reducers, workflows, and dependency-injected use cases that are highly testable. The guidance favors functional techniques first and OO/protocol approaches only where they serve boundaries.

How this skill works

The skill inspects common domain design choices and recommends a functional core with an imperative shell. It explains how to model state and events with algebraic data types, implement reducers and Mealy-style state machines, and represent effects as data. It also prescribes dependency injection via closures or capability structs and testing with fake closures rather than mocks.

When to use it

Modeling domain and business logic separate from UI
Designing reducers, workflows, and state machines
Writing dependency-injected use cases that must be testable
Refactoring code that is hard to unit test
Building features that need composable, predictable behavior

Best practices

Prefer immutability and pure functions in the core domain
Use closures for DI first, capability structs second, protocols only at boundaries
Represent effects as data and handle them in an imperative shell
Keep unit tests focused on the core; avoid timers and sleeps
Use enums and structs for algebraic data types and strong state modeling
Fake closures in tests instead of creating heavy mocks

Example use cases

Implementing a reducer-driven feature where state transitions are pure and side effects are described as data
Defining a Mealy or extended state machine for complex workflows
Creating a set of use cases injected via curried functions for easy testing
Refactoring a view model to a functional core + small imperative shell to simplify tests
Composing domain logic with optics (lenses/prisms) to work with nested immutable state

FAQ

When should I use protocols instead of closures for DI?

Use protocols only at module boundaries or when you need multiple implementations that must be swapped at runtime. Prefer closures for simple, testable injection inside the core.

How do I test effects described as data?

Keep the core pure and return an effects description. In tests, assert the effects produced. Execute effects in an outer integration layer or test harness when necessary.