agentleFS
jabbott-iiijabbott-iii/Tidepool/.claude/skills/add-ffi-binding/SKILL.md

add-ffi-binding

Skill1 starsChanged 12 days agoApache-2.0View on GitHub

Use whenever adding or changing OS bindings (libc, X11, Objective-C/AppKit/CoreGraphics, Win32, ConPTY). Declares items in tidepool-sys with layout assertions and source citations, then wraps them safely in tidepool-platform.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the header isn't available in this session, use the official documentation and mark the values "verify on <OS>".

    line 24
  2. Very specific:

    Document ownership (who frees what, with which call) and main-thread-only requirements.

    line 55
  3. Very specific:

    Ask security-reviewer to review.

    line 68

≈ “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

Add an FFI binding

Request: $ARGUMENTS

We use no binding crates (ADR-0001), so correctness depends on following this procedure exactly. Nadir (same owner) uses the same procedure; check whether it already declares what you need and port it with a note.

1. Scope it

  • List the exact functions, types, constants or selectors the feature calls. Declare nothing else.
  • For each item, find the authoritative source:
    • Linux: glibc headers (/usr/include/*.h, sys/*.h), X11 headers (/usr/include/X11/*.h), kernel uapi headers (linux/inotify.h)
    • macOS: SDK framework headers or Apple's developer documentation
    • Windows: Windows SDK headers (um/*.h) or Microsoft Learn
  • If the header isn't available in this session, use the official documentation and mark the values "verify on <OS>".

2. Declare in tidepool-sys

  • File: crates/sys/src/<os>/<module>.rs. Every item carries a doc comment or a // source: comment naming the header and declaration.
  • Functions: unsafe extern "system" { ... } for Win32, unsafe extern "C" { ... } elsewhere. Libraries we dlopen (libX11) use the dynlib! macro, which reports every missing symbol by name.
  • Types: #[repr(C)], fields in header order with exact widths (long is i64 on LP64 Linux and macOS, i32 on Windows; objc BOOL is bool on arm64, i8 on x86_64).
  • Layout assertions for every struct, with numbers from the header or docs (never from the Rust struct you just wrote):
    const _: () = assert!(core::mem::size_of::<XEvent>() == 192);
    const _: () = assert!(core::mem::align_of::<XEvent>() == 8);
    const _: () = assert!(core::mem::offset_of!(XKeyEvent, keycode) == 84);
    Gate per target with #[cfg(...)] when values differ.
  • Constants: the header's type and spelling (hex stays hex).
  • Objective-C: cache selectors once; every msg_send! spells the full signature; _stret for big struct returns on x86_64; runtime-created classes list ivars and methods with type encodings in one place.

3. Wrap safely in tidepool-platform

  • Safe API: owned RAII types for handles, &str/&Path instead of raw strings, our error enums instead of codes.
  • One unsafe operation per block, each preceded by // SAFETY:.
  • Document ownership (who frees what, with which call) and main-thread-only requirements; make main-thread types !Send.
  • Convert every failure path into an error with context.

4. Test

  • Layout assertions compile on the OS they target: say which OS builds you actually ran.
  • Unit tests for wrapper logic that doesn't need the OS (key mapping tables, string conversion).
  • Behavior tests under Xvfb on Linux where a display is needed.
  • Run cargo xtask unsafe-audit and cargo clippy -p <crate> --all-targets -- -D warnings.
  • Ask security-reviewer to review.

5. Report

  • Each declared item and its source.
  • Which layout assertions compiled on which OS in this session.
  • Which items still need verification on another OS (also add a ⏳ note to the roadmap task).

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.