Token导航 LogoToken导航

Agent Skill · 研究检索

ffi-code-review(FI 代码审查)

ffi-code-review 用于查找、检索和筛选相关信息,适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

ffi-code-review 是研究检索类 Agent Skill,可用宿主为 OpenClaw,通过ClawHub获取,权限为需要联网;许可证为 MIT-0,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 28,398。

总安装 3,224周安装 133GitHub Stars 公开资料未说明下载 1,053核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT-0
版本
1.0.1

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:ffi-code-review(FI 代码审查)
来源仓库:https://github.com/anderskev/ffi-code-review
安装命令:
openclaw skills install ffi-code-review
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install ffi-code-review

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

ffi-code-review 检查 Rust FFI 代码的类型安全与内存兼容性。适合分析字符串处理、回调模式与不安全边界,提升跨语言调用可靠性。通过 clawhub 安装,使用 openclaw skills install ffi-code-review 命令集成。需结合具体代码上下文使用,避免误报或不完整审查。

适用宿主包括 OpenClaw,接入前应确认版本、权限和运行环境要求。

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 OpenClaw;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 openclaw skills install ffi-code-review;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

ffi-code-review 怎么安装?

在终端执行 openclaw skills install ffi-code-review。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

ffi-code-review 支持哪些 AI 工具?

公开资料标注支持 OpenClaw。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

ffi-code-review 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

ffi-code-review 是免费的吗?

来源标注的许可证是 MIT-0。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

ffi-code-review 用的人多吗?

公开数据是累计安装 3,224 次,近一周安装 133 次,下载 1,053 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

ffi-code-review 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 专注 OpenClaw 一种宿主,触发方式和使用习惯不用来回切换。
  • 许可证明确为 MIT-0,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 OpenClaw,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
ffi-code-review

FI 代码审查 · 本页

3,224—需要联网MIT-0通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

name
ffi-code-review
description
Reviews Rust FFI code for type safety, memory layout compatibility, string handling, callback patterns, and unsafe boundary correctness. Use when reviewing extern blocks, #[repr(C)] types, bindgen output, or code calling C/C++ libraries.

FFI Code Review

Review Workflow

  1. Check Cargo.toml -- Note Rust edition (2024 has breaking changes to extern blocks and unsafe attributes), build-dependencies (bindgen, cc, pkg-config), crate-type (cdylib, staticlib), and links key
  2. Check build.rs -- Verify link directives (cargo:rustc-link-lib, cargo:rustc-link-search), bindgen configuration, and C source compilation
  3. Check extern blocks -- Verify calling conventions, symbol declarations, and safety annotations
  4. Check type layout -- Every type crossing FFI must be #[repr(C)] or a primitive FFI type
  5. Check string and pointer handling -- CStr/CString usage, null checks, ownership transfers
  6. Check callbacks -- extern "C" fn pointers, panic safety across FFI boundary
  7. Gates -- Complete Gates below before reporting; do not skip ahead on “internal verification”

Gates

Complete in order. Do not emit findings until Gate 4 passes for each issue.

Gate 1 — Crate context (on disk) PASS when: You opened the reviewed crate’s Cargo.toml (workspace member path if applicable) and recorded edition =, plus any of links, crate-type, or build-dependencies that matter for this FFI. Blocks rationalization: Edition-specific findings (unsafe extern "C" {}, #[unsafe(no_mangle)], etc.) require this — if edition is not 2024, do not flag 2024-only requirements.

Gate 2 — Linkage and binding sources PASS when: If the crate links native code or uses bindgen/pkg-config, you opened build.rs (or the checked-in bindings entry point). If there is no build.rs, you stated that bindings are hand-written and reviewed those extern / include! sites. Artifact: At least one path you opened (e.g. build.rs, src/ffi.rs, or OUT_DIR bindings via include!).

Gate 3 — Code evidence PASS when: Every planned finding has a target [FILE:LINE] from a full function/block you read, not only diff hunks or partial snippets.

Gate 4 — Pre-report protocol PASS when: You loaded and applied beagle-rust:review-verification-protocol, including FFI-Specific Verification for repr(C), safety comments, ownership/callbacks, or bindgen-heavy code.

Output Format

Report findings as:

[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.

Quick Reference

Issue TypeReference
C-to-Rust type mapping, repr(C) layout, enums, opaque typesreferences/type-mapping.md
Safe wrappers, ownership transfer, callbacks, build.rs, testingreferences/safety-patterns.md

Review Checklist

extern Blocks and Calling Conventions

  • [ ] Foreign function declarations use extern "C" (explicit, not bare extern)
  • [ ] Edition 2024: extern "C" {} blocks written as unsafe extern "C" {}
  • [ ] Functions exposed to C use extern "C" fn (not default Rust calling convention)
  • [ ] Calling convention matches the foreign library ("C", "system" for Win32 API)
  • [ ] #[link(name = "...")] specifies the correct library name
  • [ ] #[link(name = "...", kind = "static")] used when statically linking

Symbol Management

  • [ ] Exported functions use #[no_mangle] to preserve symbol names
  • [ ] Edition 2024: #[no_mangle] written as #[unsafe(no_mangle)]
  • [ ] Edition 2024: #[export_name = "..."] written as #[unsafe(export_name = "...")]
  • [ ] #[link_name = "..."] used when Rust name differs from C symbol
  • [ ] Exported items are pub (only public #[no_mangle] symbols appear in library output)

Type Layout

  • [ ] Every struct/union crossing FFI has #[repr(C)] -- Rust's default layout is undefined
  • [ ] Primitive types use std::ffi / std::os::raw equivalents (c_int, c_char, c_void)
  • [ ] No bare i32 where C uses int -- use c_int (width varies by platform)
  • [ ] Quirky C types like __be32 use byte arrays ([u8; 4]), not Rust integers
  • [ ] Enums crossing FFI use #[repr(C)] or #[repr(u8)]/#[repr(u32)] with explicit discriminants
  • [ ] C-style bitflag enums use a newtype around an integer (or bitflags crate), not a Rust enum
  • [ ] #[non_exhaustive] on enums representing C enumerations that may gain new values

String Handling

  • [ ] C strings use CStr (borrowed) or CString (owned), never &str or String
  • [ ] CString::new() result is checked for interior null bytes (returns Err on \0)
  • [ ] CString outlives any *const c_char pointer derived from it via .as_ptr()
  • [ ] Incoming *const c_char validated with CStr::from_ptr() inside unsafe
  • [ ] No assumption that C strings are valid UTF-8 -- use to_str() which returns Result
  • [ ] OS paths use OsStr/OsString and CStr, not &str

Ownership and Allocation

  • [ ] Clear ownership contract: who allocates, who frees
  • [ ] Rust-allocated memory freed by Rust (Box::from_raw), C-allocated freed by C
  • [ ] Box::into_raw / Box::from_raw paired correctly for heap transfers
  • [ ] Vec::into_raw_parts used when passing arrays to C (pointer + length + capacity)
  • [ ] Destructor functions exposed for every opaque Rust type given to C
  • [ ] No Drop running on C-allocated memory (and vice versa)

Callbacks

  • [ ] Callback types are extern "C" fn(...), not closures or fn(...)
  • [ ] Callbacks use std::panic::catch_unwind to prevent panics from unwinding across FFI
  • [ ] Callback context passed as *mut c_void with safe reconstruction at call site
  • [ ] Option<extern "C" fn(...)> used for nullable function pointers (niche optimization)

Bindgen and Build Scripts

  • [ ] Bindgen output reviewed for correctness (auto-generated types may need adjustment)
  • [ ] -sys crate pattern used for raw bindings, separate crate for safe wrappers
  • [ ] build.rs uses cargo:rustc-link-lib and cargo:rustc-link-search correctly
  • [ ] links key in Cargo.toml prevents duplicate linking of the same native library
  • [ ] Platform-specific bindings generated per-build (not checked in for a single platform)

Safety Documentation

  • [ ] Every unsafe block has a // SAFETY: comment explaining invariants
  • [ ] Every public FFI wrapper function documents safety requirements
  • [ ] Edition 2024: unsafe fn bodies use explicit unsafe {} blocks around unsafe ops

Severity Calibration

Critical (Block Merge)

  • Missing #[repr(C)] on types crossing FFI boundary (undefined memory layout)
  • Wrong string handling: &str/String where CStr/CString required
  • Ownership confusion: freeing C-allocated memory with Rust's allocator (or vice versa)
  • Panic unwinding across FFI boundary without catch_unwind
  • Using Rust enum for C bitflags (invalid discriminant = undefined behavior)
  • Passing closure where extern "C" fn pointer required

Major (Should Fix)

  • Missing safety documentation on unsafe blocks or public FFI functions
  • No null pointer check on incoming *const T / *mut T before dereferencing
  • CString dropped before its pointer is used by C (dangling pointer)
  • Missing #[link(name = "...")] causing link failures on some platforms
  • Edition 2024: extern block not marked unsafe extern
  • Edition 2024: #[no_mangle] not wrapped in #[unsafe(...)]

Minor (Consider Fixing)

  • Using i32 instead of c_int for C int (correct on most platforms but not portable)
  • Missing #[non_exhaustive] on enums mapping to extensible C enumerations
  • Verbose manual bindings where bindgen would be more maintainable
  • Checked-in bindings without platform guards

Informational

  • Suggestions to split raw bindings into a -sys crate
  • Suggestions to add opaque wrapper types for distinct *mut c_void pointers
  • Suggestions to use Option<NonNull<T>> for nullable pointers

Valid Patterns (Do NOT Flag)

  • unsafe extern "C" {} in edition 2024 -- correct form for foreign declarations
  • #[unsafe(no_mangle)] in edition 2024 -- correct form for symbol export
  • Option<extern "C" fn(...)> for nullable callbacks -- niche optimization guaranteed
  • Option<NonNull<T>> for nullable pointers -- zero-cost nullable pointer pattern
  • ***mut c_void for opaque C types** -- standard when internal layout is irrelevant
  • Distinct empty structs wrapping c_void for type-safe opaque pointers -- prevents pointer confusion
  • CStr::from_bytes_with_nul_unchecked with compile-time literal -- safe when literal is known null-terminated
  • extern "C-unwind" for controlled unwinding -- valid per RFC 2945
  • include!(concat!(env!("OUT_DIR"), "/bindings.rs")) in bindgen crates -- standard pattern
  • Box::into_raw / Box::from_raw pairs for ownership transfer -- correct pattern when paired

Before Submitting Findings

Complete Gates 1-4 in order before reporting any issue; Gate 4 incorporates beagle-rust:review-verification-protocol.

平台分布

OpenClaw

87.48%
按下载量换算921

安全审计

VirusTotal

未展示

ClawScan

通过

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills