メニュー
Git commit conventions with enforced scopes, conventional commits, and meaningful commit messages. Use when creating git commits, writing commit messages, staging changes, or any git workflow in this project. Always follow these conventions for every commit.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Rust testing coverage analysis, edge case discovery, and test writing with cargo-tarpaulin. Use when the user asks about test coverage, wants to find testing gaps, add tests for a module, write integration tests, check edge cases, or run coverage reports in any Rust project. Trigger on: "add tests", "test coverage", "coverage gaps", "edge cases", "what's untested", "integration tests for X", "run coverage", "find testing gaps", "corner cases", "write tests for", "what should I test", "improve test coverage", "have we considered all edge cases". Also trigger when the user finishes implementing a feature and tests should be verified/expanded.
Explore a codebase to find opportunities for architectural improvement, focusing on making the codebase more testable by deepening shallow modules. Rust-first but applicable to any language. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, reduce coupling, simplify module boundaries, or make a codebase more testable and AI-navigable. Also use when the user mentions "shallow modules", "module deepening", "trait boundary design", or "architectural friction".
Rust coding standards with ownership patterns, type safety, clean code, and performance-conscious design. Use when creating or editing Rust files (*.rs), reviewing Rust code, or making any decisions in Rust projects. This skill applies to ALL Rust development — new files, modifications, refactoring, debugging, or code review.
| name | git-conventions |
| description | Git commit conventions with enforced scopes, conventional commits, and meaningful commit messages. Use when creating git commits, writing commit messages, staging changes, or any git workflow in this project. Always follow these conventions for every commit. |
Format: Conventional Commits | Scopes: Required | Breaking changes:
!suffix + footer
Every commit message follows this structure:
<type>(<scope>): <subject>
<body>
<footer>
All three parts matter. The subject line gets people's attention, the body tells the story, the footer records breaking changes and references.
feat(editor): add multi-cursor support for batch edits
git log --oneline and GitHub UI otherwiseUse exactly these types — no others:
| Type | When to use |
|---|---|
feat | New feature or capability for the user |
fix | Bug fix — something was broken, now it works |
refactor | Code restructuring with no behavior change |
perf | Performance improvement with no behavior change |
docs | Documentation only — README, doc comments, specs, plans |
test | Adding or updating tests with no production code change |
build | Build system, dependencies, Cargo.toml changes |
ci | CI/CD pipeline configuration |
chore | Maintenance that doesn't fit above — formatting, linting, tooling config |
Choosing the right type:
feat or fixrefactorperftestdocsEvery commit must include a scope that identifies the area of the codebase affected. Scopes should be short, lowercase, and consistent.
Application scopes:
| Scope | Area |
|---|---|
app | Application state, event loop, top-level orchestration |
db | Database connection, query execution, channels |
schema | Schema tree panel, table/column/index loading |
editor | SQL editor panel, syntax highlighting, buffer management |
results | Results panel, table rendering, column sizing |
detail | Record detail panel, row inspection |
explain | Query explain/analysis panel |
er | ER diagram panel |
pragmas | Pragma viewer/editor panel |
dbinfo | Database info panel |
data-editor | Inline data editing, DML generation, staged changes |
history | Query history storage and search |
theme | Theming, colors, styling |
config | Configuration loading, defaults, file I/O |
cli | CLI argument parsing, entry point |
nav | Navigation, focus management, keybindings |
clipboard | Clipboard integration |
ui | Shared UI components, layout, widgets |
Infrastructure scopes:
| Scope | Area |
|---|---|
deps | Dependency additions, removals, or upgrades |
ci | CI/CD pipeline |
release | Version bumps, changelogs, release prep |
tooling | Dev tooling, linting config, formatters |
When a change spans multiple areas, use the scope of the primary change. If genuinely
cross-cutting, use app.
Scopes will evolve as the project grows — add new ones when a new module or area emerges that doesn't fit existing scopes. Keep them short and descriptive.
The body explains why this change exists, not what it does (the diff shows that).
feat(results): add horizontal scrolling for wide result sets
Tables with many columns were clipped at the terminal edge, making it
impossible to inspect columns beyond the visible width. Users had to
resize their terminal or reduce font size as a workaround.
Track a horizontal scroll offset per result set and shift the visible
column window with left/right arrow keys. Column headers scroll in
sync with data rows.
Body guidelines:
git log formatting in terminalsFor changes that break the public API or change user-facing behavior in incompatible ways:
! after the scope in the subject lineBREAKING CHANGE: footer explaining what broke and how to migratefeat(config)!: change config file format from JSON to TOML
The configuration file format has changed to TOML for better readability
and comment support.
BREAKING CHANGE: config.json is no longer read. Rename to config.toml
and convert the syntax. See docs/migration.md for a conversion guide.
Both the ! marker and the footer are required — the ! for quick scanning in git log,
the footer for migration details.
Each commit should be a single logical change that compiles and passes tests on its own. If you're writing "and" in your subject line, consider splitting.
Good — one concern per commit:
refactor(db): extract connection pool into dedicated module
feat(db): add connection retry with exponential backoff
test(db): add connection pool timeout tests
Bad — multiple concerns bundled:
feat(db): refactor connection pool and add retry logic and tests
The diff shows exactly what changed. The commit message should answer: "Six months from
now, when someone reads git blame on this line, what context will they need?"
Refs: #42Footers go after the body, separated by a blank line. Use them for:
BREAKING CHANGE: description of what broke and migration path
Refs: #123, #456
Closes: #789
Only include footers when they carry information. Don't add empty footers.
When creating a commit: