원클릭으로
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.