Fp refactor
Skill newmindsgroup/ai-agent-skills-library/sources/sickn33-antigravity-awesome-skills/skills/fp-refactor
Shared library of AI agent skills — works across Claude Code, Cursor, Codex, Windsurf, OpenCode, and Google Antigravity via a single universal installer.
npx -y skills add newmindsgroup/ai-agent-skills-library --skill fp-refactorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when refactoring imperative TypeScript into fp-ts patterns such as Either, TaskEither, Option, Reader, traversal, and composable pipelines.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.0 KB, as published. Nobody here has run it
Refactoring Imperative Code to fp-ts
Refactor existing imperative TypeScript toward fp-ts without turning the codebase into a puzzle. Use this entrypoint to choose the right functional pattern, then load the full guidance for detailed before-and-after examples.
When to Use
-
Converting try/catch, thrown errors, Promise chains, callbacks, null checks, loops, or service classes into fp-ts equivalents.
-
Planning a gradual fp-ts migration across module boundaries or data access layers.
-
Reviewing whether a proposed functional refactor improves type safety, composition, and testability.
When Not to Use
-
The code is trivial, stable, and clearer without fp-ts.
-
The hot path is performance-critical and allocation-heavy abstractions would hurt measurable performance.
-
The team maintaining the code does not understand fp-ts and there is no migration/training plan.
Core Workflow
-
Identify the current imperative pain: exceptions, nullable values, async composition, callbacks, loops, or dependency injection.
-
Refactor at the boundary first so types advertise failure, absence, async work, or dependency requirements explicitly.
-
Convert sync failures to Either, async failures to TaskEither, nullable values to Option, callbacks to Task, and injected services to Reader when the added structure pays for itself.
-
Use pipe, map, chain/flatMap, traverse, and sequence to compose operations without nesting.
-
Add tests around behavior before and after the refactor, especially left/error cases and None/empty paths.
-
Stop refactoring where the functional version becomes less readable than the imperative original.
Reference Map
Read references/full-guidance.md when the task needs the complete examples and edge cases. It includes:
-
try/catch to Either/TaskEither, including helper utilities and async examples.
-
null/undefined to Option and Option/Either conversion patterns.
-
callbacks to Task, class-based dependency injection to Reader, and loop refactors to map/filter/reduce/flatMap.
-
Promise chains, Promise.all/race migration, common pitfalls, gradual adoption strategy, and when not to refactor.
Safety and Quality Rules
-
Do not mix async/await and TaskEither in ways that hide errors outside the type system.
-
Do not erase useful error details when mapping thrown exceptions into typed errors.
-
Avoid broad rewrites; migrate one boundary or module at a time and keep bridge functions for callers.
Progressive Loading
Start with this entrypoint for routing and planning. Load references/full-guidance.md only after the task clearly requires deep implementation detail, code examples, validation checklists, or troubleshooting guidance.