メニュー
Use when creating git commits - ensures messages follow Conventional Commits, explain motivation over implementation, and help future maintainers
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when implementing any task end-to-end without user intervention - ensures continuous forward progress by always having a next tool call until the task is fully complete
Use when a task should be parallelized across multiple agents — decomposes work into Linear issues, then drains the queue by spawning worktree agents for unblocked tickets using drive-to-completion
Use when creating a Linear issue from a feature, bug, or task description — gathers required fields then calls the Linear MCP tool directly
Use to critically review a plan before approval - invokes a senior engineering review for readability, maintainability, operability, and testability
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
Use when creating or improving agent skills - ensures efficient context usage, clear activation conditions, and proper structure for different skill types
| name | Write Commit Message |
| description | Use when creating git commits - ensures messages follow Conventional Commits, explain motivation over implementation, and help future maintainers |
<type>[optional scope]: <description under 72 chars, prefer <50>
[optional body with 72-char line limit]
[optional footer(s)]
feat: - New feature (MINOR version bump)fix: - Bug fix (PATCH version bump)perf: - Performance improvement (PATCH version bump)chore: - Maintenance (deps, config, no code change)docs: - Documentation onlyrefactor: - Code restructure without behavior changetest: - Add or fix testsbuild:, ci:, style: - As appropriateAdd ! after type or BREAKING CHANGE: footer:
feat!: remove legacy API endpoints
BREAKING CHANGE: Clients must migrate to v2 API by 2026-03-01.
See migration guide at docs/v2-migration.md
Describe the effect (what changed), not implementation (how).
``` fix: add mutex to guard database handle ``` Implementation detail, doesn't explain impact ``` fix: prevent database corruption during simultaneous sign-ups ``` Clear effect on usersExplain why this change exists.
``` style: change background from blue to pinkUpdates CSS for pink background instead of blue.
States the obvious
</bad-example>
<good-example>
style: change background from blue to pink
Blue background made links illegible. Pink improves contrast while matching app personality.
Explains reasoning and constraints
</good-example>
### Context
- What problem does this solve?
- What alternatives did you consider?
- What did you learn?
- External references that guided decisions
### Cross-References
Closes Ticket: AI-1234
Auto-closes Jira ticket when merged.
Ticket: AI-1234
References without closing.
Summarize relevant bug details - don't force readers to dig through tickets.
# What To Exclude
- File lists (visible in diff)
- API names you called (visible in code)
- Obvious implementation details
- Critical code maintenance info (belongs in code comments with automated checks)
- Adjectives, adverbs, flowery language
- Time-limited preview URLs
# Length Constraints
- Title: 72 chars max, prefer <50
- Body: 72 chars per line
- Use headings (`**Background**`, `**Motivation**`) to structure long messages
# Style
- Present tense ("fix" not "fixed")
- Active voice ("prevents corruption" not "corruption is prevented")
- Inverted pyramid - most important info first
- Succinct - remove unnecessary words
- Liberally use footnotes to permalinks from GitHub and external sources (APIs, documentation, etc)