ワンクリックで
draft-commit
Analyze staged git changes and draft a commit with a structured message following project conventions
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Analyze staged git changes and draft a commit with a structured message following project conventions
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Write and improve Rust documentation comments following Rust's std-dev-guide. Use this skill whenever documenting Rust code, adding doc comments, writing crate-level docs, creating doctests, or when the user asks to document a module/struct/enum/trait/function. Also trigger when the user mentions rustdoc, API guidelines, doc comments, doctests, or asks to check documentation quality. This skill covers both writing new documentation and auditing existing docs for completeness and API guideline compliance.
This skill should be used when the user provides one or more POH/AFM chart or table images and asks to transcribe them into libefb performance-type Rust literals (climb, cruise, descent, takeoff, or landing). It converts chart curves or tabular rows into `ClimbDescentBand`, `CumulativeClimbDescentEntry`, `PerformanceTableRow`, or `TakeoffLandingPerformance` table data using the correct measurement constructors.
Design Rust public APIs that are idiomatic, self-explanatory, and follow the official API guidelines. Use this skill when creating new public types, traits, functions, or modules in Rust — or when reviewing existing APIs for naming clarity, type safety, trait implementations, and ergonomics. Also trigger when the user asks about Rust naming conventions, newtype patterns, builder patterns, conversion traits, or asks to review/improve a Rust API surface. This skill covers API shape and naming; for documentation comments and doctests, defer to the rustdoc skill.
| name | draft-commit |
| description | Analyze staged git changes and draft a commit with a structured message following project conventions |
| disable-model-invocation | true |
| allowed-tools | Bash(git *) |
Analyze the staged git changes or those of a commit if specified by the use. Draft a commit message following the project's conventions, and draft the commit message.
Run these commands in parallel:
git status to see staged and unstaged files (never use -uall)git diff --cached to see the staged diffgit diff --cached --stat for a file summarygit log --oneline -10 for recent commit style referenceIf nothing is staged, tell the user and stop. Do not stage files automatically — ask the user which files to stage if there are unstaged changes.
Infer the tag from the changed file paths using this mapping:
| Path prefix | Tag |
|---|---|
efb/src/route/ | route |
efb/src/fp/ | fp |
efb/src/measurements/ | measurements |
efb/src/nd/ | nd |
efb/src/fms/ | fms |
efb/src/core/ | core |
efb/src/aircraft/ | aircraft |
efb/src/geom/ | geom |
efb/src/fc/ | fc |
arinc424/ | arinc424 |
aixm/ | aixm |
handbook/ | handbook |
bindings/c/ | c |
bindings/wasm/ | wasm |
bindings/python/ | python |
bindings/swift/ | swift |
Rules:
CLAUDE.md, CONTRIBUTING.md, .github/, Cargo.toml
are not module-specific — ignore them when determining the tag unless
they are the only changes (then omit the tag).Follow these formatting rules:
tag: Imperative summary (or just Imperative summary if
no tag)BREAKING CHANGE: followed by a
descriptiontag: Title here
Body here.