New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Rigor Ffi Plugin Author

by rigortype in rigortype/rigor

Assess and, when necessary, author a Rigor sub-plugin for an FFI-binding gem.

MPL-2.0Auto-check passedDevelopment

Install Rigor Ffi Plugin Author

skills CLI
$ npx skills add rigortype/rigor --skill rigor-ffi-plugin-author -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rigortype/rigor rigor-ffi-plugin-author --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rigortype/rigor.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/rigor-ffi-plugin-author .claude/skills/rigor-ffi-plugin-author && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
rigor-ffi-plugin-author
GitHub stars
106
Token cost
~3.9k tokens
SKILL.md length
1,792 words
Files
1
Skills in repo
36
Repo updated
First seen
Licence
MPL-2.0

At a glance

Assess and, when necessary, author a Rigor sub-plugin for an FFI-binding gem.

  • Works in 7 steps: When to trigger this SKILL → Coverage assessment (decide if a plugin… → Where this plugin will live (per ADR-31) → …
  • FFI wrappers remain Dynamic beyond core rigor-ffi
  • SKILL.md covers Phase 0 — When to trigger this…, Phase 1 — Coverage assessment…, Phase 2 — Where this plugin… and Phase 3 — Scaffold, plus 5 more sections
  • Calls gem and git

What it does

Rigor Ffi Plugin Author is an agent skill from rigortype/rigor. Assess and, when necessary, author a Rigor sub-plugin for an FFI-binding gem. Use when FFI wrappers remain Dynamic beyond core rigor-ffi; not for bundled FFI plugin edits, which use rigor-plugin-author.

Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development. The repository describes itself as: Inference-first static analysis for Ruby. The licence is MPL-2.0.

When your agent uses it

  • FFI wrappers remain Dynamic beyond core rigor-ffi
  • Not for bundled FFI plugin edits
  • Which use rigor-plugin-author

Example prompts

  • “/rigor-ffi-plugin-author”

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. When to trigger this SKILL
  2. Coverage assessment (decide if a plugin is even needed)
  3. Where this plugin will live (per ADR-31)
  4. Scaffold
  5. FFI-specific extension points
  6. Test
  7. Ship

What it can do on your machine

Read from SKILL.md and the folder at commit 57a67cf. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gem
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Rigor Ffi Plugin Author loads about 3.9k tokens when it runs. Until then it costs about 58 tokens; SKILL.md has 1,792 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~58
When it runs · the whole SKILL.md, loaded when a task matches
~3.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rigortype/rigor at commit 57a67cf, republished under its MPL-2.0 licence (© rigortype). 1,792 words, ~3,889 tokens.

Download SKILL.mdSave it as .claude/skills/rigor-ffi-plugin-author/SKILL.md (or your agent's skills folder).
name
rigor-ffi-plugin-author
description
Assess and, when necessary, author a Rigor sub-plugin for an FFI-binding gem. Use when FFI wrappers remain `Dynamic` beyond core `rigor-ffi`; not for bundled FFI plugin edits, which use `rigor-plugin-author`.
license
MPL-2.0
metadata.internal
true
metadata.version
0.1.0
metadata.homepage
https://github.com/rigortype/rigor

Rigor FFI Plugin Author

Sub-plugin for FFI-binding gems. Starts with an assessment phase that will talk you out of authoring a plugin if core rigor-ffi already covers the gem — that's the point. Plugins only exist where the four binding-recovery hazards documented in ADR-30 appear.

Phase 0 — When to trigger this SKILL

Trigger when the user wants to type FFI bindings on a gem that isn't already one of the four bundled consumers (rigor-rbnacl, rigor-ethon, rigor-ffi-rzmq, rigor-sassc). Typical asks:

  • "Our internal libacme Ruby gem wraps libacme via FFI; the wrapper class methods all type as Dynamic[Top]."
  • "Add a Rigor plugin for OSS gem X that uses the ffi gem."
  • "The ffx translator complains about our binding file — can Rigor catch this statically?"

Do NOT trigger for:

  • Edits to an existing bundled rigor-rbnacl / rigor-ethon / rigor-ffi-rzmq / rigor-sassc — use the general rigor-plugin-author SKILL or treat as ordinary edit work.
  • Core rigor-ffi engine changes (the BindingRecognizer extension point, the typedef-nominal heuristic, the ffx.unsupported-* diagnostic family) — those are core development under lib/rigor/, not plugin authoring.
  • Hand-written C extensions (rb_define_method in ext/*.c) — no Ruby-side static handle; out of scope per ADR-30 WD8.
  • Fiddle-based bindings — separate rigor-fiddle SKILL / plugin family (sibling, not in scope here).

Phase 1 — Coverage assessment (decide if a plugin is even needed)

Check the gem against this table. If every row is "core suffices", the SKILL terminates with "declare the dependency and stop — no plugin needed." This is the most common outcome; resist the pull to author a plugin pre-emptively.

Question about the wrapped gem's sourceAnswerVerdict
Does the binding file use literal attach_function :name, [args], ret calls (no wrapping DSL like sodium_function)?yescore suffices
no (custom DSL)needs plugin — BindingRecognizer registration (ADR-30 WD2)
Are the bindings in this gem's lib/, or in a sibling gem (like ffi-rzmq-core for ffi-rzmq)?this gemcore suffices
sibling gemneeds plugin — either ADR-25 bundled RBS or wait on ADR-10 progress
Are method names generated dynamically from an option catalog (define_method over iterate option_table)?nocore suffices
yes (ethon-style)needs plugin — ADR-16 Tier B/C
Does the high-level wrapper class layer add semantics richer than what the FFI primitive return type captures (e.g. "this :pointer is always a 32-byte signing-key buffer")?no — wrapper is a thin pass-throughcore suffices
yes — wrapper carries domain invariants the FFI types don'tplugin recommended for RBS refinement (the wrapper still types correctly without the plugin, just less precisely)
Does the gem use typedef :pointer, :handle_name aliases for opaque pointers?yes — names follow _ptr / _handle / Ptr / Handlecore suffices (heuristic per ADR-30 WD4)
yes — a name matches the pattern but should stay a plain :pointercore suffices; add the alias to the rigor-ffi plugin's exceptions: config in .rigor.yml

Vanilla case (most common). The gem just declares attach_function :acme_open, [:string], :pointer plus a thin MyCorp::Acme#initialize(path) that stores the result. The user- facing class methods type correctly via ordinary inference. No plugin needed — just list the gem under dependencies: in .rigor.yml so the binding file is in ADR-10 scope.

Stop here if Phase 1 says core suffices. Don't author.

Phase 2 — Where this plugin will live (per ADR-31)

Per ADR-31 (project-wide plugin contribution policy), the default for all new plugins — private, public, anyone — is the same: author the plugin as a third-party rigor-<gem> gem in your own repo, depending on gem "rigortype" (ADR-31 WD4). There is no path to land a new plugin via a pull request to this monorepo.

Layout

Three options depending on your context:

  • Standalone gem rigor-<gem> in its own repo. The clean choice for OSS gems and for internal gems consumed by multiple projects.
  • Sibling gem in a private gem server (gem "rigor-<acme>" from your company's internal gem index). Same shape as standalone but not published to rubygems.org.
  • Inline inside the consuming project's lib/rigor/plugins/rigor-<gem>/. Simplest for single-project use; no separate gem to maintain.

This SKILL is procedural — it doesn't care which of the three you pick. Continue to Phase 3+ inside whichever tree you chose.

Optional: propose for official bundling

If the wrapped gem reaches significant community adoption (ADR-31 WD3), you can file an issue at rigortype/rigor proposing the plugin for bundling. The issue should include:

  • The wrapped gem's identity, homepage, license.
  • Evidence of community adoption (named in major projects' dependencies, cited in widely-read write-ups, multiple unrelated requesters, etc. — see ADR-31 WD3 for the intentionally-vague criterion).
  • A pointer to your working third-party plugin (the implementation the maintainers will use as reference).
  • Confirmation that the wrapped gem's upstream maintainers are not authoring a parallel rigor plugin in their own repo.

If accepted, the Rigor team re-implements the plugin in plugins/rigor-<gem>/ from scratch (ADR-31 WD2). Your contribution is credited via Co-authored-by: in the implementation commit(s) (GitHub renders the co-author on the commit and counts it toward your profile). The supply-chain rationale — maintainers must author every line of code that ships in the rigortype gem — is the reason this isn't a PR-merge.

In rare cases where re-implementation would be strictly redundant with a well-shaped third-party plugin (significant adoption, maintenance-transfer willingness, code-style match, MPL-2.0 license or relicensable), git subtree merge is available as an option (ADR-31 WD5) to absorb your plugin while preserving its git history. This is not a path to plan around — default expectation is "your plugin stays in your repo, indefinitely."

Phase 3 — Scaffold

The procedural shape is gem-type-agnostic. Use the existing rigor-plugin-author SKILL for:

  • Directory layout (lib/ / demo/ / README.md / CHANGELOG.md).
  • Gemspec, Plugin::Base subclass skeleton.
  • Spec layout — under spec/integration/ for an in-repo plugin or under your gem's own spec/ tree for the standalone case.
  • IoBoundary + cache-producer pattern (read inputs inside the producer block; declare watch: for directory globs).
  • Demo directory with tmp/-anchored cache + per-demo .gitignore.
  • Local-gate and CI expectations + commit subject convention.

Gemspec note — wrapped-gem version pinning. Pin the wrapped FFI gem's version range in your plugin's gemspec:

ruby
spec.add_dependency "acme", "~> 1.4"   # match the version your bindings target

When the wrapped gem releases a new version that changes its attach_function declarations, RBS surface, or DSL shape, the plugin author tracks the change by updating the plugin in their own repo (ADR-31 WD4). Orphan-plugin risk (the wrapped gem evolves, the plugin doesn't) is the plugin author's responsibility, not Rigor's. The version pin makes the supported-wrapped-version boundary explicit so downstream users get a clean resolution failure rather than a silently wrong recognition.

The FFI-specific divergences are documented in Phase 4 below.

Phase 4 — FFI-specific extension points

The extension points live in plugins/rigor-ffi/lib/rigor/plugin/ffi/; plugins/rigor-rbnacl is the reference DSL recognizer. Read them for current signatures before relying on the sketches below.

Show full SKILL.md (726 more words)Show less
4a — DSL recognizer (only if your gem has a custom DSL wrapping attach_function)

If Phase 1 row 1 said "needs plugin — custom DSL", register a Plugin::FFI::BindingRecognizer. The recognizer takes an AST node (Prism::CallNode-shaped) and returns zero or more synthesized attach_function facts:

ruby
class Rigor::Plugin::Acme < Rigor::Plugin::Base
  ffi_binding_recognizer :acme_function do |node, module_name|
    # node: Prism::CallNode for `acme_function :foo, :c_foo, [:int]`
    # module_name: the enclosing module's name, or nil
    # Return Array<AttachFunctionFact> or [] if not a match.
    next [] unless node.name == :acme_function
    args = node.arguments&.arguments || []
    next [] if args.size != 3
    Rigor::Plugin::FFI::AttachFunctionFact.new(
      ruby_name: args[0].unescaped.to_sym,
      c_name: args[1].unescaped.to_sym,
      arg_types: args[2].elements.map(&:unescaped).map(&:to_sym),
      return_type: :int,
    )
  end
end

The core processes the synthesized facts through the same pipeline as literal attach_function calls.

4b — High-level wrapper RBS refinement (only if Phase 1 row 4 said "yes")

For domain-invariant returns the FFI primitive type can't express, ship hand-authored RBS via signature_paths: (ADR-25):

ruby
class Rigor::Plugin::Acme < Rigor::Plugin::Base
  manifest(id: "acme", version: "0.1.0", description: "Rigor support for acme",
           signature_paths: ["sig"])
end

The RBS lives at sig/rigor-acme.rbs inside the plugin and refines the wrapper class:

rbs
module MyCorp
  class Acme
    def initialize: (String path) -> void
    def signing_key: () -> String  # always 32-byte binary
  end
end
4c — ffx target awareness (optional)

If the wrapped gem is authored for ffx (or dual-target), Phase 1's assessment is identical — ffx is a strict subset of the ffi gem (ADR-30 addendum). The plugin doesn't need ffx-specific logic; the core's ffx.unsupported-* diagnostic family handles ffx-incompatible declarations automatically when an extconf.rb / Gemfile.lock signal is detected (WD5+WD6).

4d — Demo fixture

The demo project should:

  • require the wrapped FFI gem.
  • Include a lib/ example exercising every binding shape the recognizer matches.
  • Have a .rigor.yml activating the plugin.
  • Produce diagnostic output verifying the plugin's typing wins (e.g. a deliberately wrong-arity call surfaces as call.wrong-arity instead of Dynamic[Top]-silenced).

Phase 5 — Test

Integration spec covers:

  • Every binding shape the recognizer handles (positive and negative cases).
  • The recognizer's output passing the same engine pipeline as a literal attach_function (i.e. a synthesised binding and a literal binding produce identical downstream behaviour).
  • Wrapper class typing improves measurably with the plugin active.

Mirror the bundled-four spec patterns as a reference — copy the structure from whichever of rigor-rbnacl (DSL recognizer) / rigor-ethon (option catalog) / rigor-sassc (literal + nominal typedef) is closest to your gem's shape.

Phase 6 — Ship

The plugin lives in your repo (per Phase 2). Verify via rigor check against real code that depends on the wrapped gem — the success criterion is "wrapper class methods that previously typed Dynamic[Top] now type concretely."

For a published standalone gem: cut a release per your own release process. For an inline (lib/rigor/plugins/) layout: no release process — the plugin is consumed in-tree.

Optional: propose for official bundling

If the wrapped gem reaches significant community adoption later (ADR-31 WD3), file an issue per Phase 2's "propose for bundling" template. The Rigor team evaluates the request; if accepted, they re-implement the plugin from scratch in plugins/rigor-<gem>/, crediting your work via Co-authored-by: in the implementation commit(s) (ADR-31 WD2).

You don't open a PR for a new bundled plugin — new bundled plugins are classified as sweeping changes under ADR-31 WD1 and go through the issue-first route. The re-implementation is by Rigor team only; the rationale is the supply-chain + review- capacity argument in ADR-31 WD1. (Bug fixes to your own third-party plugin land in your own repo; bug fixes to existing bundled plugins/rigor-* from the rigor monorepo are welcome as minor direct PRs per ADR-31's direct-PR path.)

What "done" looks like

  • Phase 1 said core suffices — no files changed; user instructed to add the gem under dependencies: in .rigor.yml. Done.
  • Phase 1 said plugin needed — plugin gem (or inline plugin) exists in your repo, spec passes against real code that depends on the wrapped gem, rigor check shows concrete types where it previously showed Dynamic[Top], wrapped-gem version pin in place. Done.
  • Promotion-for-bundling proposal filed — issue opened with the Phase 2 fields (wrapped gem identity, adoption evidence, pointer to your working plugin, upstream-effort confirmation). Rigor team takes it from there; your role becomes "answer clarifying questions, test the official version once it lands". The Co-authored-by: attribution lands in the implementation commit(s).

Common pitfalls

  • Authoring a plugin for a vanilla gem. Phase 1 exists to prevent this. If every row of the table says "core suffices", the plugin adds noise and maintenance burden for zero precision gain. Stop.
  • Attempting to open a PR to this repo for a new bundled plugin. New bundled plugins are sweeping changes under ADR-31 WD1 and take the issue-first path. File an issue with the Phase 2 fields instead. (Bug fixes to existing bundled plugins are minor PRs and welcome directly.)
  • Skipping the upstream-effort check. Duplicating a plugin the wrapped gem's maintainers are authoring wastes both efforts. Search the wrapped gem's repo before authoring.
  • Forgetting the wrapped-gem version pin. Without a version pin in the gemspec, your plugin silently misbehaves when the wrapped gem releases an API-changing version. Pin and follow semver-aware update patterns in your own repo.

© rigortype, MPL-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/rigor-ffi-plugin-author of rigortype/rigor.

Open the folder on GitHubat commit 57a67cf

Compare with similar skills

Rigor Ffi Plugin Author next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Rigor Ffi Plugin Author compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Rigor Ffi Plugin Author this skillrigortype/rigor106—~3.9kAutomated safety check: PassMPL-2.0
Vercel Composition Patternssupabase/supabase111k59 repos~726Automated safety check: PassMIT
Finishing a Development Branchobra/superpowers296k5 repos~1.9kAutomated safety check: PassMIT
Typescript Advanced Typesrolling-scopes/rsschool-app10k25 repos~4.2kAutomated safety check: PassMPL-2.0
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Code Review ChecklistshareAI-lab/learn-claude-code78k5 repos~1.1kAutomated safety check: PassMIT

Similar skills

  • Vercel Composition Patterns

    supabase/supabase

    Official

    React composition patterns that scale. An agent skill from supabase/supabase.

    111k GitHub starsUsed in 59 repos~726 tokens
    DevelopmentAuto-check passed

  • Finishing a Development Branch

    obra/superpowers

    Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    296k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed

  • Typescript Advanced Types

    rolling-scopes/rsschool-app

    Master TypeScript's advanced type system including generics, conditional types, mapped types, template literals, and utility types for building type-safe applications.

    10k GitHub starsUsed in 25 repos~4.2k tokens
    DevelopmentAuto-check passed

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Code Review Checklist

    shareAI-lab/learn-claude-code

    Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.

    78k GitHub starsUsed in 5 repos~1.1k tokens
    DevelopmentAuto-check passed

  • Greploop

    onyx-dot-app/onyx

    Iteratively improves a PR (GitHub), MR (GitLab), or shelved changelist (Perforce) until Greptile gives it a 5/5 confidence score with zero unresolved comments.

    32k GitHub starsUsed in 4 repos~3.3k tokens
    DevelopmentAuto-check passed

More from rigortype/rigor

All 36 skills in this repo

  • Rigor Regression Sweep

    rigortype/rigor

    Measure Rigor's baseline drift across the tagged history of a real OSS Ruby project.

    106 GitHub stars~2.9k tokensUpdated today
    Auto-check passed

  • Rigor Unused Adjudicate

    rigortype/rigor

    Adjudicate a rigor unused report safely before proposing dead-code removal.

    106 GitHub stars~1.1k tokensUpdated today
    Auto-check passed

  • Rigor Baseline Reduce

    rigortype/rigor

    Reduce an existing .rigor-baseline.yml rule by rule by triaging sites, fixing or intentionally suppressing them, and regenerating the baseline.

    106 GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • Rigor Doctor

    rigortype/rigor

    Validate that a project's Rigor configuration, plugins, paths, and baseline are actually healthy.

    106 GitHub stars~767 tokensUpdated today
    Auto-check passed

  • Rigor Plugin Author

    rigortype/rigor

    Author a new Rigor plugin, choosing plugins/ for production support or examples/ for a contract walkthrough.

    106 GitHub stars~3.3k tokensUpdated today
    Auto-check: notes

  • Rigor Plugin Author

    rigortype/rigor

    Author a Rigor plugin in an adopting project or standalone rigor- gem for a DSL, framework, or metaprogramming pattern.

    106 GitHub stars~1.9k tokensUpdated today
    Auto-check passed

Categories

Questions about Rigor Ffi Plugin Author

What does Rigor Ffi Plugin Author do?

Assess and, when necessary, author a Rigor sub-plugin for an FFI-binding gem. Rigor Ffi Plugin Author is an agent skill from rigortype/rigor. Assess and, when necessary, author a Rigor sub-plugin for an FFI-binding gem.

When should I use Rigor Ffi Plugin Author?

Rigor Ffi Plugin Author fits situations like: FFI wrappers remain Dynamic beyond core rigor-ffi; not for bundled FFI plugin edits; which use rigor-plugin-author.

How do I install Rigor Ffi Plugin Author in Claude Code?

Run `npx skills add rigortype/rigor --skill rigor-ffi-plugin-author -a claude-code`. Or copy the skill folder (.claude/skills/rigor-ffi-plugin-author in rigortype/rigor) into .claude/skills/rigor-ffi-plugin-author in your project. Claude Code loads it when a task matches its description.

How do I install Rigor Ffi Plugin Author in Codex?

Run `npx skills add rigortype/rigor --skill rigor-ffi-plugin-author -a codex`. Or copy the skill folder (.claude/skills/rigor-ffi-plugin-author in rigortype/rigor) into .agents/skills/rigor-ffi-plugin-author in your project. Codex loads it when a task matches its description.

Can I use Rigor Ffi Plugin Author in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rigortype/rigor --skill rigor-ffi-plugin-author -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/rigor-ffi-plugin-author, .gemini/skills/rigor-ffi-plugin-author, .github/skills/rigor-ffi-plugin-author and .opencode/skills/rigor-ffi-plugin-author in your project.

What does Rigor Ffi Plugin Author need to run?

Going by SKILL.md and its folder, Rigor Ffi Plugin Author needs the command-line tools its instructions call (gem and git).

Does Rigor Ffi Plugin Author access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Rigor Ffi Plugin Author safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Rigor Ffi Plugin Author use?

Rigor Ffi Plugin Author is published under the MPL-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Rigor Ffi Plugin Author use?

About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Rigor Ffi Plugin Author?

Skills that share tags, products or a category with Rigor Ffi Plugin Author: Vercel Composition Patterns (supabase/supabase, 111k stars), Finishing a Development Branch (obra/superpowers, 296k stars), Typescript Advanced Types (rolling-scopes/rsschool-app, 10k stars) and PR Babysitter (openinterpreter/openinterpreter, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Rigor Ffi Plugin Author?

rigortype (a GitHub organization) maintains it in rigortype/rigor, which has 106 GitHub stars. The repository holds 36 skills in this directory. The repository was last updated on October 8, 2026.

Source: rigortype/rigor on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.