メニュー
Use when committing code changes — guides commit message structure, type selection, and body content following Conventional Commits format
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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 |