Build oxpecker web app

Skill gaelic-ghost/socket/skills/build-oxpecker-web-app

The Source for macOS Agent Workflows

Install

npx -y skills add gaelic-ghost/socket --skill build-oxpecker-web-app

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

Build or modify an Oxpecker web application in idiomatic F#, using endpoint routing, functional EndpointHandler and EndpointMiddleware composition, ASP.NET Core metadata, and focused endpoint tests.

SKILL.md

2.2 KB, as published. Nobody here has run it

Build Oxpecker Web App

Use Oxpecker's endpoint-routing model deliberately. Its F# DSL sits on ASP.NET Core Endpoint Routing, so native endpoint metadata and middleware behavior remain part of the application contract.

Source Check

Inspect the existing host, endpoints, middleware, project references, tests, and configuration. Use the Oxpecker documentation and ASP.NET Core routing documentation when local evidence does not answer the question.

Workflow

Confirm Oxpecker is selected through dotnet:choose-fsharp-web-framework.
Model one endpoint as an EndpointHandler: validate or bind input, invoke a focused domain operation, and produce the response.
Use EndpointMiddleware for a reusable pipeline concern with an explicit before/after or short-circuit behavior. Do not use it as a generic service locator or business-rule container.
Keep route patterns, HTTP methods, authorization requirements, tags, and other endpoint metadata co-located enough to review as one API contract.
Continue using ASP.NET Core for host configuration, authentication, authorization, logging, and cross-cutting middleware. Preserve its pipeline ordering when introducing Oxpecker endpoints.
Test domain behavior independently and endpoint behavior for routing, binding, status, metadata, authorization, and serialized response contracts.

Validation

Use the smallest project-level validation available, normally:

dotnet build <web-project.fsproj>
dotnet test <test-project.fsproj>

Boundaries

Keep .fsproj file ordering explicit and preserve Task boundaries at the HttpContext edge.
Do not assume Giraffe handlers or middleware map mechanically to Oxpecker; migrate only with an explicit route and test-contract review.
Use the official Azure Skills plugin for Azure architecture, provisioning, diagnostics, and deployment decisions.