Menu
Use Conventional Commits when creating reviewing or fixing commit messages.
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
Debug and repair code using minimal, reviewable patches instead of full-file rewrites. Use this whenever the user is fixing a bug, iterating on failing tests, asks for a surgical code change, wants a minimal diff, or is in a tight debug loop where output size and token cost matter. Prefer this even if the user does not explicitly say "patch."
Build or use a tight automated test-fix loop that repairs one failing test at a time with minimal patches and narrow context. Use whenever the user wants a repair harness, constrained bug-fixing loop, failing-test repair workflow, or a prompt that turns the model into a surgical fix engine instead of a general coding assistant.
Interact with local Chrome browser session (only on explicit user approval after being asked to inspect, debug, or interact with a page open in Chrome)
Reduce cognitive load when implementing or refactoring code for readability.
Audit and refactor React UI components to match DataConnect UI implementation rules (Text component, tokens, Tailwind, naming) and Vercel React/composition guidance. Use when the user asks for a UI audit, React audit, composition review, or to fix UI implementation issues in components.
Standardize DataConnect route/page layout, logic/JSX separation, tests, and README expectations. Use when organizing pages/routes, refactoring page structure, or discussing file structure conventions.
| name | conventional-commits |
| description | Use Conventional Commits when creating reviewing or fixing commit messages. |
Reference: https://www.conventionalcommits.org/en/v1.0.0/
Use this format exactly:
<type>[optional scope][optional !]: <description>
[optional body]
[optional footer(s)]
type, then : , then a short description.! before : for breaking changes, for example feat(api)!: drop v1 endpoint.BREAKING CHANGE: ... in a footer when details are needed.fix: bug fixfeat: new featuredocs: documentation-only changesrefactor: code change without behavior changeperf: performance improvementtest: add/update testsbuild: build system or dependency changesci: CI/CD changeschore: maintenance work that is not user-facingrevert: revert a previous commitPrefer fix or feat when either is accurate.
fix(connect): ....add, fix, remove, refactor, rename.Good:
fix(connect): preserve return path after loginfeat(auth)!: require signed nonce for session creationBad:
fixed the login bugchangesfeat: stuffAdd a body only when needed. Use it for:
Do not repeat obvious diffs from the subject.
Use footers for machine/human metadata:
BREAKING CHANGE: <details>Refs: #123Reviewed-by: NameBREAKING CHANGE must be uppercase when used as a footer token.
For breaking changes, do one of:
! in header: feat(core)!: remove legacy grant formatBREAKING CHANGE: legacy grant format is removedfix, feat, etc.).When asked to produce a commit message: