conventional-commits
Generate and validate commit messages following the Conventional Commits specification. Use when creating git commits, writing commit messages, reviewing commit history, generating changelogs, or when the user mentions commits, commit messages, semantic versioning, or changelog generation.
What this skill does
# Conventional Commits ## Overview Conventional Commits is a specification for commit messages that provides an explicit structure for creating a clear commit history. It enables automated tools for generating changelogs, determining semantic version bumps, and communicating changes effectively. **Core Principle**: Every commit message follows a structured format that clearly communicates the type and scope of changes. ## Commit Message Structure ``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` ## Quick Reference | Element | Required | Format | Purpose | | --------------- | ----------- | ------------------------ | ----------------------------------- | | **Type** | ✅ Yes | `feat`, `fix`, or custom | Indicates the nature of the change | | **Scope** | ❌ Optional | Parentheses: `(parser)` | Provides additional context | | **Breaking** | ❌ Optional | `!` after type/scope | Indicates breaking changes | | **Description** | ✅ Yes | Short summary | Brief description of the change | | **Body** | ❌ Optional | Free-form paragraphs | Detailed explanation | | **Footer** | ❌ Optional | `Token: value` format | Metadata (e.g., `BREAKING CHANGE:`) | ## Commit Types ### Standard Types - **`feat`**: A new feature (correlates with MINOR in SemVer) - **`fix`**: A bug fix (correlates with PATCH in SemVer) ### Additional Types (Common) - **`build`**: Changes to build system or dependencies - **`chore`**: Maintenance tasks, no production code change - **`ci`**: Changes to CI configuration - **`docs`**: Documentation only changes - **`hotfix`**: Emergency bug fix applied directly to production, bypassing normal development workflow (correlates with PATCH in SemVer) - **`perf`**: Performance improvements - **`refactor`**: Code refactoring without behavior change - **`style`**: Code style changes (formatting, missing semicolons, etc.) - **`test`**: Adding or updating tests ## Breaking Changes Breaking changes can be indicated in two ways: 1. **In the type/scope prefix**: Append `!` before the colon ``` feat!: remove deprecated API feat(api)!: change authentication method ``` 2. **In the footer**: Use `BREAKING CHANGE:` token ``` feat: add new authentication system BREAKING CHANGE: Old authentication tokens are no longer valid ``` ## Examples ### Basic Feature Commit ``` feat: add user authentication endpoint Implement JWT-based authentication with login and token validation ``` ### Feature with Scope ``` feat(auth): implement password reset flow Add forgot password endpoint and email notification system ``` ### Bug Fix ``` fix(parser): correct array parsing with multiple spaces Handle edge case where strings contained multiple consecutive spaces ``` ### Breaking Change (Prefix) ``` feat(api)!: remove deprecated v1 endpoints BREAKING CHANGE: All v1 API endpoints have been removed. Migrate to v2. ``` ### Breaking Change (Footer) ``` feat: update database schema BREAKING CHANGE: Environment variables now take precedence over config files ``` ### Documentation ``` docs: update API reference for authentication endpoints ``` ### Refactoring ``` refactor(auth): extract token validation to separate module Improve code organization and testability ``` ### Performance ``` perf(queries): optimize database query for user lookup Reduce query time from 500ms to 50ms by adding index ``` ### Hotfix #### Security Hotfix ``` hotfix(auth): fix critical security vulnerability in token validation Immediate fix for CVE-2024-XXXX. Patch token validation to prevent unauthorized access. ``` #### Database Hotfix ``` hotfix(db): fix connection pool exhaustion causing service outage Emergency patch to increase pool size and add connection timeout. Applied directly to production to restore service. ``` #### Payment Hotfix ``` hotfix(payment): fix incorrect currency conversion in checkout Critical bug causing incorrect charges. Immediate fix applied to prevent financial impact. ``` #### API Hotfix ``` hotfix(api): fix null pointer exception in user endpoint Emergency fix for production crash. Bypassed normal deployment process. ``` #### Performance Hotfix ``` hotfix(cache): fix memory leak causing server crashes Immediate fix for production instability. Applied hotfix to prevent service degradation. ``` #### Data Integrity Hotfix ``` hotfix(data): fix corrupted data migration affecting user accounts Emergency fix applied directly to production database to prevent data loss. ``` ## Common Mistakes ### ❌ Missing Colon and Space ``` feat add authentication ``` ✅ **Correct:** ``` feat: add authentication ``` ### ❌ Uppercase Type ``` FEAT: add authentication ``` ✅ **Correct:** ``` feat: add authentication ``` ### ❌ Description Too Long ``` feat: add user authentication with JWT tokens, password hashing, session management, and email verification ``` ✅ **Correct:** ``` feat(auth): implement JWT-based authentication Add login endpoint, password hashing, session management, and email verification ``` ### ❌ Using Wrong Type ``` fix: add new feature for user dashboard ``` ✅ **Correct:** ``` feat: add user dashboard ``` ### ❌ Breaking Change Not Indicated ``` feat(api): remove deprecated endpoints ``` ✅ **Correct:** ``` feat(api)!: remove deprecated endpoints BREAKING CHANGE: All v1 endpoints have been removed ``` ### ❌ Scope Without Parentheses ``` feat auth: implement login ``` ✅ **Correct:** ``` feat(auth): implement login ``` ## Workflow Guidelines ### When Creating Commits 1. **Determine the type**: Is this a feature, fix, or other type? - Use `hotfix` for emergency fixes applied directly to production, bypassing normal development workflow - Use `fix` for regular bug fixes in normal development workflow 2. **Identify scope** (optional): Which part of the codebase is affected? 3. **Check for breaking changes**: Does this change break existing functionality? 4. **Write concise description**: Keep under 72 characters when possible 5. **Add body if needed**: Provide context, motivation, or details 6. **Include footer if applicable**: Add breaking changes, references, etc. ### Description Best Practices - Use imperative mood: "add feature" not "added feature" or "adds feature" - Don't end with a period - Keep it concise (50-72 characters ideal) - Focus on what changed, not why (why goes in body) ### Body Best Practices - Separate from description with blank line - Explain the "why" behind the change - Provide context or background - Reference related issues or PRs ## Semantic Versioning Correlation | Commit Type | SemVer Impact | | ----------------- | ------------------------- | | `fix` | PATCH (1.0.0 → 1.0.1) | | `hotfix` | PATCH (1.0.0 → 1.0.1) | | `feat` | MINOR (1.0.0 → 1.1.0) | | `BREAKING CHANGE` | MAJOR (1.0.0 → 2.0.0) | | Other types | No automatic version bump | ## Validation Checklist Before finalizing a commit message, verify: - [ ] Type is lowercase and valid - [ ] Colon and space follow type/scope - [ ] Description is concise and imperative - [ ] Breaking changes are properly indicated - [ ] Body is separated by blank line (if present) - [ ] Footer tokens use hyphens (e.g., `BREAKING CHANGE`, not `BREAKING_CHANGE`) - [ ] Message doesn't exceed 120 characters in title (if team standard) ## Special Cases ### Revert Commits ``` revert: let us never again speak of the noodle incident Refs: 676104e, a215868 ``` ### Multiple Commits for One Feature If a commit conforms to multiple types, split into separate commits when possible: ``` feat(auth): add login endpoint test(auth): add login endpoint tests docs(auth): update API documentation for login ``` ## Integration with Tools Conventional Commits enables: - **A
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.