Google Rust Skills
Скилл Google для Rust: пишет и проверяет раздел Safety и комментарии к unsafe-коду как доказательство с опорой на Rust Reference
- 71 ★ репозитория
- Последний коммит
Минимальный доступ
Почему такой уровень
- Инструкции и справочные правила: скилл ничего не запускает и не обращается к сети
Установка
- Работает в
Ручная установка
Поставь скилл: клонируй https://github.com/google/rust-skills, скопируй папку unsafe_rust_review в .claude/skills/ этого проекта и проверь, что SKILL.md читается. Экспериментальный вариант копируй, только если я попрошу.
Доступ и проверки
Как мы проверяемМинимальный доступИнструмент ничего не запускает и не ходит в сеть.
- Инструкции и справочные правила: скилл ничего не запускает и не обращается к сети
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Репозиторий Rust Skills содержит два скилла для работы с `unsafe` Rust. Основной, unsafe_rust_review, велит агенту работать как предельно строгий автор и ревьюер: каждый раздел # Safety трактуется как теорема, а каждый комментарий safety как ее доказательство. Скилл требует задать утверждение, перечислить все допущения, указать источник каждого допущения, показать, что из них следует контракт unsafe-операции, и описать постусловия. Скилл включается при любой работе с unsafe-поверхностью: `unsafe fn`, `unsafe trait`, `unsafe impl`, блоки `unsafe extern` и подобное. Внутри лежат иерархия источников истины, обязательная классификация фактов, правила для документации и для комментариев, список обязательных тем доказательства, шаблоны отказа, правила для зависимостей и чек-листы опасных мест вроде создания ссылок. Разделы имеют стабильные идентификаторы вида `[doc]` и `[rej]`, на них ссылаются вместо номеров. Второй скилл, unsafe_rust_review_experimental, короче и шире по задачам: он покрывает проектирование и аудит unsafe-кода, сырые указатели, FFI, встроенный ассемблер, атомики, SIMD, аллокаторы и разбор доверенной вычислительной базы.
Для кого. Rust-разработчикам, которые пишут или проверяют unsafe-код, и командам, где комментарии safety должны выдерживать строгое ревью.
Подходит, если
- К публичной `unsafe fn` нужно написать раздел # Safety, который читается как набор проверяемых условий
- Блок `unsafe` в обертке над FFI сопровождают комментарием safety с перечнем допущений и их источников
- В ревью попадает `pull request` с `unsafe impl`, и нужно найти слабые, круговые или непроверяемые предпосылки
- Код, сгенерированный агентом, содержит `unsafe`, и его проверяют по чек-листам опасных мест
- Меняется контракт модуля, а инвариант хранится в полях структуры: нужен аудит доказательства
Не подходит, если
- Код полностью безопасный: скилл включается только там, где есть unsafe-поверхность
- Нужна общая стилистика Rust или оптимизация: у скилла другая цель, доказательства для `unsafe`
- Нужен быстрый беглый просмотр: основной скилл на 2141 строку требует строгих рассуждений и работает неспешно
- Нужны правила для другого языка: набор рассчитан только на Rust
Пример запроса к агенту
Напиши раздел # Safety для функции read_unaligned_u32 и безопасностные комментарии к ее unsafe-блокам, а затем проверь их как строгий ревьюерОграничения
- Скилл заточен под `unsafe` Rust: на безопасный код он не рассчитан.
- Скилл большой, SKILL.md основного варианта занимает 2141 строку, а экспериментального 364, поэтому они расходуют заметную часть контекста.
- Требуется строгое следование источникам: Rust Reference, документации стандартной библиотеки и контрактам доверенных зависимостей, домыслы скилл отвергает.
- Вариант unsafe_rust_review_experimental помечен автором экспериментальным.
- Установочных команд в README нет: папку скилла копируют в каталог скиллов агента вручную.
- Лицензия Apache-2.0, последний коммит в октябре 2026 года.
Как отключить. Скилл удаляется вместе с папкой unsafe_rust_review или unsafe_rust_review_experimental из каталога скиллов агента, например из .claude/skills/. Других следов он не оставляет.
Частые вопросы
Что делает скилл unsafe_rust_review?
Он учит агента писать и проверять разделы # Safety и комментарии safety к unsafe-коду как формальные доказательства: утверждение, допущения с источниками, вывод контракта и постусловия.
Когда скилл включается?
При любой работе с unsafe-поверхностью: `unsafe fn`, `unsafe trait`, `unsafe impl`, `unsafe extern`, атрибуты `unsafe` и код, который зависит от такого кода.
Чем отличается экспериментальный вариант?
Он короче, 364 строки против 2141, и шире по темам: проектирование, аудит, FFI, атомики, SIMD, аллокаторы и разбор доверенной вычислительной базы.
Какие источники скилл считает авторитетными?
Rust Reference, документацию стандартной библиотеки, явно разрешенные документированные зависимости, факты системы типов и локальные инварианты проекта. Фольклорные и круговые предпосылки он отвергает.
Как установить скилл в Claude Code?
Скопируйте папку unsafe_rust_review в .claude/skills/ проекта или в ~/.claude/skills/ для всех проектов. Отдельной команды установки в README нет.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
Скиллы265 коротких правил по Rust для ИИ-агента: заимствование, ошибки, async, unsafe и производительность, с примерами плохого и хорошего кода
Три скилла и конфиг clippy: агент пишет, проверяет и переносит код на идиоматичный Rust, а правила проходят в CI
Скилл для ревью кода по многим языкам и фреймворкам: архитектура, производительность, безопасность, антипаттерны и типичные ошибки
Больше 200 скиллов по стекам и практикам: React, Next.js, Rails, Rust, Python, отладка, TDD и ревью интерфейсов
kyy-logs code-review-skill
code-review-skill
Скилл ревью кода: четыре независимых прохода, замечания с доказательствами и допуск к слиянию из JSON
Скиллы-контроли для кодовых агентов: второй проход по диффу, который ловит типичные ошибки в коде, тестах и документации от ИИ
Сравнение с похожими
Карточки с тем же главным запросом: чем они отличаются.
| Инструмент | Официальный | Авторизация | Звезды репозитория | Главное отличие |
|---|---|---|---|---|
| Google Rust Skills (эта карточка) | да | 71 | ||
| Beautiful Rust | нет | 1 798 | справочник по оформлению и идиомам Rust, доказательств безопасности unsafe в нем нет | |
| rust-docs-mcp | нет | не нужна | 142 | MCP-сервер документации по крейтам Rust, ревью unsafe не ведет |
Коротко о README
README совсем короткий: он называет репозиторий набором скиллов для работы с Rust-кодом, включая скилл для ревью `unsafe`. Всю нагрузку несут два файла SKILL.md в папках unsafe_rust_review и unsafe_rust_review_experimental. Помимо них в репозитории лежат CONTRIBUTING.md и LICENSE.md.
Бейдж для README
Исходный SKILL.md
---
name: unsafe-rust-review
description: Write and review unsafe Rust `# Safety` documentation and safety comments (e.g., `// safety:` or `/// safety:` in any capitalization) as proof obligations grounded in the Rust Reference, standard library documentation, trusted opted-in dependency contracts, and explicit project invariants.
---
# Unsafe Rust Safety Documentation and Commenting Skill
## Mission
Act as an extremely strict unsafe Rust author and reviewer. Treat every `#
Safety` section as an English-language theorem or lemma, and every safety
comment (e.g., `// safety:` or `/// safety:` in any capitalization) as an
English-language proof.
The goal is not reassuring prose. The goal is logic bulletproof-ness. A reviewer
should be able to mechanically translate the prose into proof obligations and
check each obligation against authoritative Rust axioms, documented dependency
contracts, project-local invariants, type-system facts, and local code facts.
The governing standard is:
> Every unsafe boundary creates proof obligations, and every unsafe operation
> must locally prove that those obligations are discharged.
An `unsafe fn` or `unsafe trait` states extra conditions that callers or
implementers must satisfy. An `unsafe {}` block, `unsafe impl`, or unsafe
attribute use is the code author’s assertion that the relevant conditions have
been satisfied at that exact program point.
Unsafe documentation and comments must therefore be written in the style of
formal proof:
- Define the proposition being proved.
- Enumerate all required assumptions.
- Classify each assumption by source.
- Show that the assumptions imply the required unsafe contract.
- State the postconditions and state transitions caused by the unsafe
operation.
- Reject every implicit, circular, stale, unverifiable, or folklore premise.
## Conventions
Every section carries a stable `` `[area.slug]` `` ID after its heading. Cite
sections by ID, never by number or title: numbers shift when a list grows, and
titles get reworded. Areas: `model`, `evidence`, `fact`, `conv`