diff --git a/.agents/skills/commit/SKILL.md b/.agents/skills/commit/SKILL.md index ae78203c5..d83625a3e 100644 --- a/.agents/skills/commit/SKILL.md +++ b/.agents/skills/commit/SKILL.md @@ -1,89 +1,38 @@ - --- name: commit -description: Use when you need to create git commits or pull requests. -allowed-tools: Bash(git:*), Bash(gh:*) +description: Use when preparing, reviewing, or suggesting git commit messages or pull request titles, or before creating a commit. --- -# Commit & PR Conventions +# Commit and PR title conventions -Use this skill whenever the user asks to commit current worktree changes, or to create / edit a pull request. Commits and PR titles share the same emoji convention; PR descriptions follow the structure documented below. - -## Commit Workflow - -1. Inspect the worktree before committing: - - `git status --short` - - `git diff --staged` - - `git diff` - - `git log --oneline -5` -2. Review all staged and unstaged changes that will be part of the commit. -3. Stage the relevant files, but never include likely secrets such as `.env` files or credential dumps. -4. Write a concise commit message in the repository's usual style. -5. Prefix the message with the single emoji that best matches the dominant change (see Emoji Mapping). -6. Create the commit and confirm success with `git status --short`. - -If there is nothing to commit, say so instead of creating an empty commit. - -## Emoji Mapping - -Commit messages **and PR titles** must be prefixed with exactly one of: - -- `πŸ›` Fix a bug -- `✨` New user-facing feature. Use this only for a meaningful feature users would actively want to try. Use it sparingly. If the change is incremental rather than substantial, prefer `πŸ‘Œ`. **Only when there is a frontend change.** -- `πŸ‘Œ` New user-facing addition to an existing feature, such as a new option or small capability. **Only when there is a frontend change.** -- `πŸ”§` New internal implementation. When the change is mostly internal and not directly noticeable by end users. -- `♻️` Refactoring. When behavior stays effectively the same and the main goal is code cleanup or restructuring. -- `πŸ’…` UI or UX update. When the main value is visual polish, interaction quality, or layout improvements. -- `πŸ“` Blog or documentation update. +Commit messages and PR titles must be prefixed with exactly one emoji that describes the primary intent of the change. Prefer the most user-visible category when a commit spans multiple areas. -## Commit Message Format +## Emoji prefixes + +- `πŸ›` Fix a bug. +- `✨` New user-facing feature. Use this only for a meaningful feature users would actively want to try. Use it sparingly. If the change is incremental rather than substantial, prefer `πŸ‘Œ`. Use only when there is a frontend change. +- `πŸ‘Œ` New user-facing addition to an existing feature, such as a new option or small capability. Use only when there is a frontend change. +- `πŸ”§` New internal implementation. Use when the change is mostly internal and not directly noticeable by end users. +- `♻️` Refactoring. Use when behavior stays effectively the same and the main goal is code cleanup or restructuring. +- `πŸ’…` UI or UX update. Use when the main value is visual polish, interaction quality, or layout improvements. +- `πŸ“` Blog or documentation update. + +## Before committing + +Always check the diff and remove debug logs, temporary files, commented-out experiments, and other temporary artifacts before creating a commit. + +## After opening a PR + +Never amend commits that are already part of an opened PR. Push follow-up fixes as new commits so review history and existing comments remain stable. + +## Format + +Use a concise imperative or descriptive title after the emoji: ```text - +πŸ› Fix workspace invite redirect +πŸ”§ Add billing sync worker +♻️ Simplify block schema helpers ``` - -Keep it short, specific, and focused on why the change matters. - -Examples: - -- `πŸ”§ Add logs to debug WA status forward` -- `πŸ’… Make group title hitbox fit text` -- `✨ Add prompt and new models to OpenAI transcription` -- `πŸ› Fix webhook listening not working` -- `♻️ Migrate builder from tRPC to oRPC` - -## Pull Request Titles - -PR titles follow the **exact same rules** as commit messages: one leading emoji from the mapping above, then a short imperative summary. Reuse the title of the dominant commit when the branch has one main commit; otherwise pick the emoji that matches the most user-visible change across the branch. - -Do **not** add issue numbers or `(#1234)` suffixes manually β€” GitHub appends the PR number on its own. - -## Pull Request Descriptions - -Keep PR bodies short and useful. Default structure: - -```markdown -## Summary - -<1–3 bullets describing what changed and why, in plain English.> - -## Test plan - -- [ ] -- [ ] -``` - -Guidelines: - -- The summary is for humans skimming the merge queue β€” lead with the user-facing impact, not the implementation detail. -- The test plan lists how the change was (or should be) validated: commands run, manual flows exercised, edge cases checked. Skip it only for pure docs / blog PRs. -- Omit boilerplate sections (Screenshots, Risks, Rollback…) unless they add information. No empty headings. -- Do not include AI assistant footers, "Generated with …" lines, or `Co-Authored-By` trailers on PR descriptions. - -## When NOT to Use This Skill - -- Cosmetic git operations that don't create a commit (e.g. `git status`, `git stash`). -- Amending an existing commit's metadata only. -- Operations on remotes (push, fetch) outside of the commit / PR creation flow.