/fsi
Use F# Interactive (`dotnet fsi`) for .NET exploration, scriptable experiments, package-backed .fsx workflows, quick data transforms, and reproducible command-line probes. USE FOR: .fsx scripts, F# REPL work, #r nuget references, #load composition, interactive type exploration,
$ npx -y skills add managedcode/dotnet-skills --skill fsi --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/fsi
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use F# Interactive (`dotnet fsi`) for .NET exploration, scriptable experiments, package-backed .fsx workflows, quick data transforms, and reproducible command-line probes. USE FOR: .fsx scripts, F# REPL work, #r nuget references, #load composition, interactive type exploration,
SKILL.md
fsi.SKILL.mdname: fsi
description: "Use F# Interactive (`dotnet fsi`) for .NET exploration, scriptable experiments, package-backed .fsx workflows, quick data transforms, and reproducible command-line probes. USE FOR: .fsx scripts, F# REPL work, #r nuget references, #load composition, interactive type exploration, and small strongly typed experiments before moving code into a project. DO NOT USE FOR: production application code that needs compiled project structure; C# scripting; long-lived automation better expressed as a normal CLI, test, or build target. INVOKES: run dotnet fsi, edit .fsx scripts, load project or source files, and validate snippets against the target SDK."
compatibility: "Requires a .NET SDK with `dotnet fsi`; NuGet-backed scripts may need package restore and trusted package sources."
F# Interactive
Trigger On
- the task asks for F# Interactive, FSI, `.fsx`, or `dotnet fsi`
- a quick typed experiment is needed before changing compiled project code
- a script should reference NuGet packages directly with `#r "nuget: ..."`
- an investigation needs quick access to F# type inference, pattern matching, or pipelines
- a repeatable one-file probe is better than a temporary project
Do Not Use For
- long-lived application code that needs a compiled `.fsproj`
- production automation that should be versioned as a CLI, test project, or build target
- C# script work
- package restore from untrusted sources
Quick Start
Run an interactive REPL:
dotnet fsi
Run a script:
dotnet fsi scripts/check.fsx
Create a Unix executable script when that fits the repo:
#!/usr/bin/env -S dotnet fsi
printfn "Hello from FSI"
chmod +x scripts/check.fsx
./scripts/check.fsx
On Windows, run scripts with `dotnet fsi scripts/check.fsx`.
Workflow
1. Decide whether the request is a disposable REPL probe, a repeatable `.fsx` script, or code that should be promoted to a compiled F# project. 2. Put repeatable work in an `.fsx` file immediately. Add all required `#r`, `#load`, `open`, input path, and package source directives to the script instead of relying on hidden REPL state. 3. Keep package references pinned when the script should be reproducible, and use only trusted NuGet feeds or local feeds derived from `__SOURCE_DIRECTORY__`. 4. Run the script with `dotnet fsi` from a clean shell, passing the same arguments the user or CI will use. 5. Promote the script to an `.fsproj` when it needs tests, distribution, project references, or long-term CI coverage.
Current Upstream Notes
- The July 2026 F# Interactive reference keeps `dotnet fsi` as the supported command-line entry point for interactive sessions and `.fsx` scripts; it does not turn hidden REPL state into a reproducible workflow.
- Use repeatable `.fsx` files with explicit `#r "nuget: ..."` and `#load` directives once an experiment affects a repository task; do not rely on hidden REPL state.
Interactive Session Rules
- End REPL submissions with `;;`.
- Multi-line input is allowed; FSI evaluates when it receives `;;`.
- Previously evaluated values stay in the session, so do not rely on hidden session state in scripts.
- Use `.fsx` files for repeatability once an experiment matters.
let square x = x * x;;
[ 1 .. 5 ] |> List.map square;;
Script Patterns
Read And Summarize Text
Use ordinary .NET APIs directly from F# scripts.
open System
open System.IO
let summarize path =
File.ReadLines path
|> Seq.filter (String.IsNullOrWhiteSpace >> not)
|> Seq.countBy (fun line -> line.Split(' ')[0])
|> Seq.sortByDescending snd
|> Seq.truncate 10
|> Seq.toList
for key, count in summarize "input.log" do
printfn $"{key}: {count}"Write A Checked Output File
Keep script outputs deterministic and fail early when required inputs are missing.
open System
open System.IO
let input = "data/items.txt"
let output = "artifacts/items.normalized.txt"
if not (File.Exists input) then
failwith $"Missing input file: {input}"
Directory.CreateDirectory(Path.GetDirectoryName output) |> ignore
File.ReadLines input
|> Seq.map (fun line -> line.Trim())
|> Seq.filter (String.IsNullOrWhiteSpace >> not)
|> Seq.distinct
|> Seq.sort
|> fun lines -> File.WriteAllLines(output, lines)Reference NuGet Packages
Pin package versions for repeatable scripts. Only use package sources the repo trusts.
#r "nuget: Newtonsoft.Json, 13.0.3"
open Newtonsoft.Json
let payload = {| Name = "Ada"; Kind = "sample" |}
let json = JsonConvert.SerializeObject(payload)
printfn $"{json}"Use `#i` only when an additional feed is required. Local feed paths must be absolute; construct them from `__SOURCE_DIRECTORY__` instead of committing personal paths.
let localFeed =
System.IO.Path.Combine(__SOURCE_DIRECTORY__, "../artifacts/packages")
|> System.IO.Path.GetFullPath
#i $"nuget: {localFeed}"Split Scripts With Load
`#load` evaluates another script and exposes it through the generated module name.
// MathHelpers.fsx
let square x = x * x
// Check.fsx
#load "MathHelpers.fsx"
open MathHelpers
printfn $"%d{square 12}"Promote To A Project
Move from FSI to a compiled project when:
- the script has multiple dependencies, tests, or distribution needs
- startup time or restore behavior matters
- C# or other .NET callers need a stable assembly
- the code needs CI coverage beyond a smoke run
Start with:
dotnet new console -lang "F#" -o tools/Probe
dotnet build tools/Probe/Probe.fsproj
Validate
Use the simplest command that proves the script still runs:
dotnet fsi scripts/check.fsx
dotnet fsi scripts/check.fsx -- arg1 arg2
For scripts that reference packages, run from a clean shell at least once so hidden REPL state cannot mask missing `#r`, `#load`, or `open` directives.
Sources
- https://learn.microsoft.com/dotnet/fsharp/tools/
Read more
name: fsi description: "Use F# Interactive (`dotnet fsi`) for .NET exploration, scriptable experiments, package-backed .fsx workflows, quick data transforms, and reproducible command-line probes. USE FOR: .fsx scripts, F# REPL work, #r nuget references, #load composition, interactive type exploration, and small strongly typed experiments before moving code into a project. DO NOT USE FOR: production application code that needs compiled project structure; C# scripting; long-lived automation better expressed as a normal CLI, test, or build target. INVOKES: run dotnet fsi, edit .fsx scripts, load project or source files, and validate snippets against the target SDK." compatibility: "Requires a .NET SDK with `dotnet fsi`; NuGet-backed scripts may need package restore and trusted package sources."
F# Interactive
Trigger On
- the task asks for F# Interactive, FSI, `.fsx`, or `dotnet fsi`
- a quick typed experiment is needed before changing compiled project code
- a script should reference NuGet packages directly with `#r "nuget: ..."`
- an investigation needs quick access to F# type inference, pattern matching, or pipelines
- a repeatable one-file probe is better than a temporary project
Do Not Use For
- long-lived application code that needs a compiled `.fsproj`
- production automation that should be versioned as a CLI, test project, or build target
- C# script work
- package restore from untrusted sources
Quick Start
Run an interactive REPL:
dotnet fsi
Run a script:
dotnet fsi scripts/check.fsx
Create a Unix executable script when that fits the repo:
#!/usr/bin/env -S dotnet fsi printfn "Hello from FSI"
chmod +x scripts/check.fsx ./scripts/check.fsx
On Windows, run scripts with `dotnet fsi scripts/check.fsx`.
Workflow
1. Decide whether the request is a disposable REPL probe, a repeatable `.fsx` script, or code that should be promoted to a compiled F# project. 2. Put repeatable work in an `.fsx` file immediately. Add all required `#r`, `#load`, `open`, input path, and package source directives to the script instead of relying on hidden REPL state. 3. Keep package references pinned when the script should be reproducible, and use only trusted NuGet feeds or local feeds derived from `__SOURCE_DIRECTORY__`. 4. Run the script with `dotnet fsi` from a clean shell, passing the same arguments the user or CI will use. 5. Promote the script to an `.fsproj` when it needs tests, distribution, project references, or long-term CI coverage.
Current Upstream Notes
- The July 2026 F# Interactive reference keeps `dotnet fsi` as the supported command-line entry point for interactive sessions and `.fsx` scripts; it does not turn hidden REPL state into a reproducible workflow.
- Use repeatable `.fsx` files with explicit `#r "nuget: ..."` and `#load` directives once an experiment affects a repository task; do not rely on hidden REPL state.
Interactive Session Rules
- End REPL submissions with `;;`.
- Multi-line input is allowed; FSI evaluates when it receives `;;`.
- Previously evaluated values stay in the session, so do not rely on hidden session state in scripts.
- Use `.fsx` files for repeatability once an experiment matters.
let square x = x * x;; [ 1 .. 5 ] |> List.map square;;
Script Patterns
Read And Summarize Text
Use ordinary .NET APIs directly from F# scripts.
open System
open System.IO
let summarize path =
File.ReadLines path
|> Seq.filter (String.IsNullOrWhiteSpace >> not)
|> Seq.countBy (fun line -> line.Split(' ')[0])
|> Seq.sortByDescending snd
|> Seq.truncate 10
|> Seq.toList
for key, count in summarize "input.log" do
printfn $"{key}: {count}"Write A Checked Output File
Keep script outputs deterministic and fail early when required inputs are missing.
open System
open System.IO
let input = "data/items.txt"
let output = "artifacts/items.normalized.txt"
if not (File.Exists input) then
failwith $"Missing input file: {input}"
Directory.CreateDirectory(Path.GetDirectoryName output) |> ignore
File.ReadLines input
|> Seq.map (fun line -> line.Trim())
|> Seq.filter (String.IsNullOrWhiteSpace >> not)
|> Seq.distinct
|> Seq.sort
|> fun lines -> File.WriteAllLines(output, lines)Reference NuGet Packages
Pin package versions for repeatable scripts. Only use package sources the repo trusts.
#r "nuget: Newtonsoft.Json, 13.0.3"
open Newtonsoft.Json
let payload = {| Name = "Ada"; Kind = "sample" |}
let json = JsonConvert.SerializeObject(payload)
printfn $"{json}"Use `#i` only when an additional feed is required. Local feed paths must be absolute; construct them from `__SOURCE_DIRECTORY__` instead of committing personal paths.
let localFeed =
System.IO.Path.Combine(__SOURCE_DIRECTORY__, "../artifacts/packages")
|> System.IO.Path.GetFullPath
#i $"nuget: {localFeed}"Split Scripts With Load
`#load` evaluates another script and exposes it through the generated module name.
// MathHelpers.fsx let square x = x * x
// Check.fsx
#load "MathHelpers.fsx"
open MathHelpers
printfn $"%d{square 12}"Promote To A Project
Move from FSI to a compiled project when:
- the script has multiple dependencies, tests, or distribution needs
- startup time or restore behavior matters
- C# or other .NET callers need a stable assembly
- the code needs CI coverage beyond a smoke run
Start with:
dotnet new console -lang "F#" -o tools/Probe dotnet build tools/Probe/Probe.fsproj
Validate
Use the simplest command that proves the script still runs:
dotnet fsi scripts/check.fsx dotnet fsi scripts/check.fsx -- arg1 arg2
For scripts that reference packages, run from a clean shell at least once so hidden REPL state cannot mask missing `#r`, `#load`, or `open` directives.
Sources
- https://learn.microsoft.com/dotnet/fsharp/tools/
Stop explaining .NET to your AI. Start building. We've all been there: asking Claude to use Entity Framework, only to get EF6 patterns in a .NET 8 project. Explaining to Copilot that Blazor Server and Blazor WebAssembly aren't the same thing.
Repo: managedcode/dotnet-skills
Other skills on dotnet-skills.
- /aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET. USE FOR: working on ASP.NET Core apps, services, or middleware; changing auth, routing, configuration,
Open skill - /aspire
Build, upgrade, and operate Aspire 13.4.x C# or TypeScript application hosts with the current CLI, AppHost, ServiceDefaults, integrations, dashboard, testing, MCP, and deployment patterns for distributed apps. USE FOR: Aspire.AppHost.Sdk, Aspire.Hosting.*,
Open skill - /azure-functions
Build, review, or migrate Azure Functions in .NET with correct execution model, isolated worker setup, bindings, DI, and Durable Functions patterns. USE FOR: working on Azure Functions in .NET; migrating from the in-process model to the isolated worker model; adding Durable
Open skill - /blazor
Build and review Blazor applications across server, WebAssembly, web app, and hybrid scenarios with correct component design, state flow, rendering, and hosting choices. USE FOR: building interactive web UIs with C# instead of JavaScript; choosing between Server, WebAssembly, or
Open skill - /entity-framework6
Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access
Open skill - /entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications. USE FOR: DbContext, migrations, model configuration, EF queries, tracking, loading, performance, transactions, and
Open skill

