Choose fsharp web framework

Skill gaelic-ghost/socket/skills/choose-fsharp-web-framework

The Source for macOS Agent Workflows

Install

npx -y skills add gaelic-ghost/socket --skill choose-fsharp-web-framework

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

6 stars6 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

Choose an F# web application framework before implementation, comparing ASP.NET Core Minimal APIs, Giraffe, Falco, Oxpecker, and Saturn by application shape, composition model, dependencies, testing, and deployment boundaries.

SKILL.md

3.4 KB, as published. Nobody here has run it

Choose F# Web Framework

Choose the web surface before scaffolding. Keep the application's F# domain model, HTTP host, persistence, and deployment decision explicit instead of treating a framework DSL as the whole architecture.

Source Check

Inspect the repository and its locked packages first. When a current framework behavior matters, use its official documentation before generating code:

Selection

Need	Default fit	Why
Small service using standard ASP.NET endpoint conventions	Minimal APIs	Least extra framework surface; keep idiomatic F# modules around the host.
Composable middleware-style functional handlers	Giraffe	`HttpHandler` composition over the ASP.NET Core pipeline.
Lightweight functional API or full-stack server toolkit	Falco	Direct routing and response helpers with ordinary ASP.NET Core integration.
Endpoint-routing / Minimal-API-shaped F# DSL	Oxpecker	F# endpoint handlers and middleware on ASP.NET Core Endpoint Routing.
Established convention-heavy F# MVC application	Saturn	Use only when its MVC/scaffolding shape is desired by the project.

Do not select from popularity alone. Check existing package choices, team experience, endpoint style, HTML/view needs, authentication, hosting, and how much framework-specific API the project is willing to own.

Workflow

Classify the application: API, HTML server app, webhook, internal tool, background worker with health endpoints, or full-stack application.
Inspect its existing ASP.NET Core host, package versions, test harness, configuration, and deployment files.
State the chosen framework and why the alternatives do not fit this project.
Keep domain operations in F# modules independent of HTTP handlers.
Use the matching framework skill for Giraffe, Falco, or Oxpecker. For Minimal APIs use dotnet:aspnet-core-service-workflow; for Saturn, inspect its local conventions and official documentation before making framework-specific edits.
Select the smallest useful test level and run dotnet build plus the relevant dotnet test command.

Boundaries

SAFE Stack, Fable, Bolero, WebSharper, and browser-client architecture are separate decisions; do not imply that a server framework selects a client.
Keep F# compile order deliberate in .fsproj files.
Do not introduce a repository, service, or view-model layer merely to mirror a framework's API. Name the concrete external dependency or reuse boundary first.
For Azure architecture, provisioning, diagnostics, or deployment, hand off to the official Microsoft Azure Skills plugin through the cloud deployment routing workflow; do not duplicate its MCP or infrastructure guidance here.

Output

Return the application shape, selected framework, rejected alternatives, host and domain ownership, test approach, Azure handoff if applicable, and exact validation commands.