agentleFS
TheAngryByrdTheAngryByrd/fsharp-skills/skills/fsharp-verify-api/SKILL.md

fsharp-verify-api

Skill23 starsChanged 32 days agoMITView on GitHub

Check the real signature of a .NET or F# API before F# code uses it, so the build does not loop on FS0039, FS0001, FS0074, or FS0078. Use when writing F# against a NuGet package, a package version that changed its API, an unfamiliar type, or an .fsx script with #r lines, and before adding a helper that the codebase can already have.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 5 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before you call a member that you have not seen in this codebase or in this version, list its signature.

    line 18
  2. Very specific:

    Use scripts/show-api.ps1. It prints the public constructors, methods, properties, and extension methods of a type, with inherited members …

    line 19
  3. Very specific:

    Do not probe an API with a build or with speculative dotnet fsi code.

    line 21
  4. Very specific:

    When a type is not defined (FS0039), check the open first: find the namespace of the type in the listing (TYPE line) and add that open.

    line 22
  5. Distinctive:

    When the compiler reports FS0074, the type comes from an assembly that the project does not reference.

    line 23
  6. Very specific:

    Before you write a helper, search the codebase for one that does the same work.

    line 24
  7. Very specific:

    Read references/LOOKUP.md for each lookup method, the XML docs in the NuGet cache, and the .fsx rules.

    line 28
  8. Very specific:

    Use -Member '' to list all members, -Member ctor for constructors, and -Assembly when the assembly name differs from the package ID.

    line 40
  9. Distinctive:

    When the signature is not what you remember, find the replacement member in the same listing or in the XML docs.

    line 41
  10. Distinctive:

    Write the code with the listed signatures, then build once.

    line 42
  11. Distinctive:

    When the build fails, read the first error only.

    line 43
  12. Distinctive:

    Run the proof script from the skill root:

    line 47

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Verify an F# API before you use it

Agents write the API that they remember. Packages move, rename, and remove members between versions. The compiler then reports FS0039 (not defined), and each guess costs one more failed build. Session evidence ranks FS0039 as the top compiler error. 177 Codex sessions had 4 or more failed builds or test runs.

The fix is to read the signature first. One listing is cheaper than three failed builds.

Rules

  • Find the package version that the project uses. Read the .fsproj, Directory.Packages.props, or paket.lock. Do not assume the latest version.
  • Before you call a member that you have not seen in this codebase or in this version, list its signature. Use scripts/show-api.ps1. It prints the public constructors, methods, properties, and extension methods of a type, with inherited members and F# source names. The script exits 0 when the type or member does not exist. A missing member is information, not a failed build.
  • Do not probe an API with a build or with speculative dotnet fsi code. Each failed probe is a failed build.
  • When a type is not defined (FS0039), check the open first: find the namespace of the type in the listing (TYPE line) and add that open.
  • When the compiler reports FS0074, the type comes from an assembly that the project does not reference. Add the package that holds that assembly. Do not add an unrelated package.
  • Before you write a helper, search the codebase for one that does the same work. Use rg for the result type or for a verb in the name.
  • In an .fsx script, a relative #r path resolves from the script's directory, not from the current directory. FS0078 means the path is wrong. Pin each #r "nuget: Package, Version" to the project's version. Without a version, FSI loads the latest stable version.

Read references/LOOKUP.md for each lookup method, the XML docs in the NuGet cache, and the .fsx rules.

Steps

  1. List each external type and member that the change uses and that the codebase does not use already. Done when each item has a package and a version.
  2. For each item, run the listing script and read the real signature:

    pwsh <skill-root>/scripts/show-api.ps1 -Package FsToolkit.ErrorHandling -Version 5.2.0 -Type FsToolkit.ErrorHandling.Result -Member require

    Use -Member '' to list all members, -Member ctor for constructors, and -Assembly when the assembly name differs from the package ID.

  3. When the signature is not what you remember, find the replacement member in the same listing or in the XML docs. Do not guess a second name.
  4. Write the code with the listed signatures, then build once.
  5. When the build fails, read the first error only. Later errors are often cascades of the first. Fix it with step 2, not with a guess.

Verify

Run the proof script from the skill root:

pwsh ./scripts/run.ps1

The script lists members of two versions of a package that moved its API between versions. It fails when an expected member is missing or a removed member is present.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.