メニュー
Review your own changes before creating a pull request. Use this before running create-pr, or whenever you want to check that your changes are clean, correct, and well-tested. Trigger when: about to create a PR, finished a chunk of work, or asked to review changes.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
How to add hegel-rust support for a third-party Rust crate. Use when the user asks to 'add support for <crate>', 'add a <crate> integration', 'add generators for <crate>', or similar. Orchestrates implementing a generator and DefaultGenerator impl for every public type the crate exposes.
How to add a new generator to hegel-rust. Use when the user asks to implement, add, or write a generator for a type — e.g. 'add a generator for Url', 'implement a UUID generator', 'write a generator for jiff::civil::Date'. Covers the generator struct, builder methods, Generator trait impl, argument validation, mod.rs wiring, rustdoc, and the required test set. Pair with the new-default-generator skill to also wire up gs::default::<T>().
Changelog style guide for writing RELEASE.md files. Use when creating or reviewing RELEASE.md, writing changelog entries, or preparing a PR that needs release notes.
How to add a DefaultGenerator impl for a type so gs::default::<T>() works. Use when the user asks to wire up default() for a type, add a default generator, or make a type usable with #[derive(DefaultGenerator)]. Pair after the new-generator skill when adding a fresh generator, or use standalone when the underlying generator already exists or can be composed from existing generators.
How to approach code coverage in this project. Use when coverage CI fails, when writing tests for new code, when deciding whether to add // nocov, or when you need to make untestable code testable. Also use proactively when writing new code to ensure it will be coverable.
| name | self-review |
| description | Review your own changes before creating a pull request. Use this before running create-pr, or whenever you want to check that your changes are clean, correct, and well-tested. Trigger when: about to create a PR, finished a chunk of work, or asked to review changes. |
Run through these checks before creating a PR or declaring work complete. The goal is to catch the things a human reviewer would flag, before they have to.
Run all of these — they're fast and catch the most common issues:
just check # formatting, lint, tests, docs
Fix any failures before proceeding. Don't skip checks because they passed locally last time — the code may have changed.
Run git diff origin/main...HEAD and read through it. Look for:
file:// URLs or local fixtures instead? Keep at most one integration test that verifies the real network path works./tmp/foo in tests should be tempfile::tempdir() for isolation and cleanup.// nocov annotations: each one needs explicit human permission. Your first instinct should be to write a test or refactor for testability instead.If cargo-llvm-cov is available, run just check-coverage and review the output. If new code is uncovered, address it before the PR — don't rely on CI to catch it. See the coverage skill for how to approach coverage gaps.
Ask yourself: if someone else wrote this diff, what would I flag in code review? Common things to catch: