F# for .NET

Trigger On

• the task touches .fs, .fsx, .fsi, or .fsproj files
• domain logic benefits from records, discriminated unions, options, results, or exhaustive pattern matching
• generated code needs a strongly typed functional model instead of nullable primitive state
• F# code must interoperate with C# or other .NET libraries
• the repository needs project setup, source ordering, or validation for F# code

Workflow

1. Inspect the existing .fsproj, .fs, .fsi, and .fsx files to determine compile order, public boundaries, and whether the code is F#-first or C#-facing.
2. Choose the smallest F# model that represents the invariant: records for named product data, discriminated unions for closed state, option for absence, and Result for expected failures.
3. Add or edit source files in dependency order, then update the .fsproj compile list before consumers reference the new code.
4. Review public API shape for .NET interop. Translate F#-specific internal models to DTOs, methods, or Try* patterns when C# callers need a stable surface.
5. Run dotnet build, targeted tests, and any relevant dotnet fsi probes before returning the final result.

Validate

Run the narrowest relevant checks after changes:

dotnet build
dotnet test
dotnet fsi scripts/check.fsx

If adding a new F# file, also inspect the project file diff to confirm the compile order is deliberate.

Related skills