一键导入
git-commit
Use when committing code changes — guides commit message structure, type selection, and body content following Conventional Commits format
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when committing code changes — guides commit message structure, type selection, and body content following Conventional Commits format
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Select Rails and Hotwire patterns derived from 37signals applications, with the incompatible parts removed. Use only as a supplementary reference alongside the `rails` skill.
Authoritative Rails patterns for modern object-oriented Rails applications. Use when writing Rails code that follows transaction-oriented architecture, explicit dependency injection, Phlex views, and RSpec testing.
Reusable guidance for working with the tk ticket CLI in local-first repositories. Load when the project has a ./.tickets directory or TICKETS_DIR env defined.
| name | git-commit |
| description | Use when committing code changes — guides commit message structure, type selection, and body content following Conventional Commits format |
Write structured commit messages following Conventional Commits. The body should help a junior Ruby on Rails developer understand the change during a debugging session.
<subject>
<body>
<footer>
The Commit subject is short, imperative and explains what the change is for. It must begin with one of only these five prefixes:
Add
Update
Fix
Remove
Refactor
If we worked on a ticket, include the ticket id and title in the body.
Imperative mood: "Add", "Fix", "Update", "Remove"
Present tense: "Add feature" not "Added feature"
Capitalized first letter, no period at end
Maximum 70 characters
Commit bodies are written as paragraphs. Each paragraph is properly capitalized and reads like a page out of a book. Each paragraph is devoted to a single idea and uses proper punctuation. Add any useful information that would help a junior Ruby developer understand the impact of the change, why the change was done.
It needs to explain the following:
Call out tradeoffs when supported by context. Do not invent details.
Fixes TICKET-123 # or: Fixes #123, Refs TICKET-123
BREAKING CHANGE: ... # for breaking changes; use ! in type too: feat(api)!:
| Mistake | Fix |
|---|---|
| Body explains HOW without context | Only include HOW when it helps debugging |
| Subject describes implementation ("Changed X to Y") | Use imperative: "Fix X", "Add Y" |
| Body repeats what the diff shows | Explain WHY it was changed |
| Subject over 70 characters | Trim scope or rephrase |
| "Generated by AI" in body | Omit completely |