Menu
Use when creating git commits - ensures messages follow Conventional Commits, explain motivation over implementation, and help future maintainers
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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)