{"owner":"conventional-changelog","repo":"commitlint","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["skills/committing-with-commitlint/SKILL.md"],"skills":{"skills/committing-with-commitlint/SKILL.md":"---\nname: committing-with-commitlint\ndescription: Use when writing a git commit message in a repository that uses commitlint — read the enforced convention first, write a compliant message, and self-correct from hook rejections instead of bypassing them\n---\n\n# Committing in a repository that uses commitlint\n\ncommitlint validates commit messages against the repository's configured convention\n(usually [Conventional Commits](https://www.conventionalcommits.org)). The configuration\nis the contract: read it before writing a commit message, and trust the error output\nwhen a commit is rejected.\n\n## 1. Detect whether the repository uses commitlint\n\nAny of these means commitlint is in play:\n\n- A config file in the repository root:\n  `.commitlintrc`, `.commitlintrc.{json,yaml,yml,js,cjs,mjs,ts,cts,mts}`,\n  or `commitlint.config.{js,cjs,mjs,ts,cts,mts}`\n- A `\"commitlint\"` field in `package.json`\n- A commit-msg hook that runs commitlint (check `.husky/commit-msg`, `lefthook.yml`,\n  or `.git/hooks/commit-msg`)\n\n## 2. Read the enforced rules\n\n```bash\nnpx commitlint --print-config json\n```\n\nIf this exits non-zero, the configuration itself is broken (for example an\nunresolvable `extends`) — read the error on stderr instead of guessing.\n\nLook at the `rules` object. Each rule is `[severity, applicability, value]`:\n\n- **severity** — `0` = disabled, `1` = warning, `2` = error (only errors block commits)\n- **applicability** — `\"always\"` = the condition must hold, `\"never\"` = it must not\n- **value** — the rule's parameter (list, number, or string)\n\nThe rules that matter most when writing a message:\n\n| Rule                   | What it controls                                                         |\n| ---------------------- | ------------------------------------------------------------------------ |\n| `type-enum`            | Allowed types (e.g. `feat`, `fix`, `chore`, ...)                         |\n| `scope-enum`           | Allowed scopes (empty list = any scope allowed)                          |\n| `scope-empty`          | `[2, \"never\"]` = scope is required; `[2, \"always\"]` = scope is forbidden |\n| `subject-case`         | With `\"never\"`: cases the subject must NOT use                           |\n| `subject-full-stop`    | With `\"never\"` and `\".\"`: subject must not end with a period             |\n| `header-max-length`    | Maximum length of the first line                                         |\n| `body-leading-blank`   | Blank line required between subject and body                             |\n| `body-max-line-length` | Maximum length of each body line                                         |\n\nA rule that is absent or disabled (severity 0) is simply not enforced. When unsure, use\na conservative baseline that passes the common presets: lower-case type, no trailing\nperiod, header under 72 characters (config-conventional allows up to 100). Note that\nrunning commitlint with no config at all fails with an `empty-rules` error rather than\nfalling back to any default convention.\n\n## 3. Write the message\n\nFormat: `type(scope): subject` — the scope is optional unless `scope-empty` is `[2, \"never\"]`.\n\nAn example that satisfies `@commitlint/config-conventional`:\n\n```\nfeat(parser): add support for inline issue references\n\nExplain what changed and why. Separate the body from the subject with a blank\nline (body-leading-blank) and keep lines within body-max-line-length.\n\nCloses #123\n```\n\n## 4. Validate before committing\n\n```bash\nprintf '%s' \"feat(parser): add support for inline issue references\n\nExplain what changed and why.\n\nCloses #123\" | npx commitlint\n```\n\nExit code 0 with no output means the message passes. Validate the complete\nmessage (header and body), not just the first line — body rules are checked\ntoo. Doing this before committing is cheaper than a failed commit.\n\n## 5. Self-correct when the commit-msg hook rejects\n\nRejection output names each violated rule in brackets:\n\n```\n⧗   --- input ---\nFeat: Added new parser.\n✖   subject must not be sentence-case, start-case, pascal-case, upper-case [subject-case]\n✖   subject may not end with full stop [subject-full-stop]\n✖   type must be lower-case [type-case]\n✖   type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]\n\n✖   found 4 problems, 0 warnings\n```\n\n- Fix ONLY the rules named in brackets; keep everything else identical.\n- Re-validate via stdin (step 4), then retry the commit.\n- NEVER bypass the hook with `git commit --no-verify` — fixing the message is\n  always the correct action.\n"},"files":{"skills/committing-with-commitlint/SKILL.md":"---\nname: committing-with-commitlint\ndescription: Use when writing a git commit message in a repository that uses commitlint — read the enforced convention first, write a compliant message, and self-correct from hook rejections instead of bypassing them\n---\n\n# Committing in a repository that uses commitlint\n\ncommitlint validates commit messages against the repository's configured convention\n(usually [Conventional Commits](https://www.conventionalcommits.org)). The configuration\nis the contract: read it before writing a commit message, and trust the error output\nwhen a commit is rejected.\n\n## 1. Detect whether the repository uses commitlint\n\nAny of these means commitlint is in play:\n\n- A config file in the repository root:\n  `.commitlintrc`, `.commitlintrc.{json,yaml,yml,js,cjs,mjs,ts,cts,mts}`,\n  or `commitlint.config.{js,cjs,mjs,ts,cts,mts}`\n- A `\"commitlint\"` field in `package.json`\n- A commit-msg hook that runs commitlint (check `.husky/commit-msg`, `lefthook.yml`,\n  or `.git/hooks/commit-msg`)\n\n## 2. Read the enforced rules\n\n```bash\nnpx commitlint --print-config json\n```\n\nIf this exits non-zero, the configuration itself is broken (for example an\nunresolvable `extends`) — read the error on stderr instead of guessing.\n\nLook at the `rules` object. Each rule is `[severity, applicability, value]`:\n\n- **severity** — `0` = disabled, `1` = warning, `2` = error (only errors block commits)\n- **applicability** — `\"always\"` = the condition must hold, `\"never\"` = it must not\n- **value** — the rule's parameter (list, number, or string)\n\nThe rules that matter most when writing a message:\n\n| Rule                   | What it controls                                                         |\n| ---------------------- | ------------------------------------------------------------------------ |\n| `type-enum`            | Allowed types (e.g. `feat`, `fix`, `chore`, ...)                         |\n| `scope-enum`           | Allowed scopes (empty list = any scope allowed)                          |\n| `scope-empty`          | `[2, \"never\"]` = scope is required; `[2, \"always\"]` = scope is forbidden |\n| `subject-case`         | With `\"never\"`: cases the subject must NOT use                           |\n| `subject-full-stop`    | With `\"never\"` and `\".\"`: subject must not end with a period             |\n| `header-max-length`    | Maximum length of the first line                                         |\n| `body-leading-blank`   | Blank line required between subject and body                             |\n| `body-max-line-length` | Maximum length of each body line                                         |\n\nA rule that is absent or disabled (severity 0) is simply not enforced. When unsure, use\na conservative baseline that passes the common presets: lower-case type, no trailing\nperiod, header under 72 characters (config-conventional allows up to 100). Note that\nrunning commitlint with no config at all fails with an `empty-rules` error rather than\nfalling back to any default convention.\n\n## 3. Write the message\n\nFormat: `type(scope): subject` — the scope is optional unless `scope-empty` is `[2, \"never\"]`.\n\nAn example that satisfies `@commitlint/config-conventional`:\n\n```\nfeat(parser): add support for inline issue references\n\nExplain what changed and why. Separate the body from the subject with a blank\nline (body-leading-blank) and keep lines within body-max-line-length.\n\nCloses #123\n```\n\n## 4. Validate before committing\n\n```bash\nprintf '%s' \"feat(parser): add support for inline issue references\n\nExplain what changed and why.\n\nCloses #123\" | npx commitlint\n```\n\nExit code 0 with no output means the message passes. Validate the complete\nmessage (header and body), not just the first line — body rules are checked\ntoo. Doing this before committing is cheaper than a failed commit.\n\n## 5. Self-correct when the commit-msg hook rejects\n\nRejection output names each violated rule in brackets:\n\n```\n⧗   --- input ---\nFeat: Added new parser.\n✖   subject must not be sentence-case, start-case, pascal-case, upper-case [subject-case]\n✖   subject may not end with full stop [subject-full-stop]\n✖   type must be lower-case [type-case]\n✖   type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]\n\n✖   found 4 problems, 0 warnings\n```\n\n- Fix ONLY the rules named in brackets; keep everything else identical.\n- Re-validate via stdin (step 4), then retry the commit.\n- NEVER bypass the hook with `git commit --no-verify` — fixing the message is\n  always the correct action.\n"},"items":[{"name":"SKILL.md","path":"skills/committing-with-commitlint/SKILL.md","title":"committing-with-commitlint Skill","content":"---\nname: committing-with-commitlint\ndescription: Use when writing a git commit message in a repository that uses commitlint — read the enforced convention first, write a compliant message, and self-correct from hook rejections instead of bypassing them\n---\n\n# Committing in a repository that uses commitlint\n\ncommitlint validates commit messages against the repository's configured convention\n(usually [Conventional Commits](https://www.conventionalcommits.org)). The configuration\nis the contract: read it before writing a commit message, and trust the error output\nwhen a commit is rejected.\n\n## 1. Detect whether the repository uses commitlint\n\nAny of these means commitlint is in play:\n\n- A config file in the repository root:\n  `.commitlintrc`, `.commitlintrc.{json,yaml,yml,js,cjs,mjs,ts,cts,mts}`,\n  or `commitlint.config.{js,cjs,mjs,ts,cts,mts}`\n- A `\"commitlint\"` field in `package.json`\n- A commit-msg hook that runs commitlint (check `.husky/commit-msg`, `lefthook.yml`,\n  or `.git/hooks/commit-msg`)\n\n## 2. Read the enforced rules\n\n```bash\nnpx commitlint --print-config json\n```\n\nIf this exits non-zero, the configuration itself is broken (for example an\nunresolvable `extends`) — read the error on stderr instead of guessing.\n\nLook at the `rules` object. Each rule is `[severity, applicability, value]`:\n\n- **severity** — `0` = disabled, `1` = warning, `2` = error (only errors block commits)\n- **applicability** — `\"always\"` = the condition must hold, `\"never\"` = it must not\n- **value** — the rule's parameter (list, number, or string)\n\nThe rules that matter most when writing a message:\n\n| Rule                   | What it controls                                                         |\n| ---------------------- | ------------------------------------------------------------------------ |\n| `type-enum`            | Allowed types (e.g. `feat`, `fix`, `chore`, ...)                         |\n| `scope-enum`           | Allowed scopes (empty list = any scope allowed)                          |\n| `scope-empty`          | `[2, \"never\"]` = scope is required; `[2, \"always\"]` = scope is forbidden |\n| `subject-case`         | With `\"never\"`: cases the subject must NOT use                           |\n| `subject-full-stop`    | With `\"never\"` and `\".\"`: subject must not end with a period             |\n| `header-max-length`    | Maximum length of the first line                                         |\n| `body-leading-blank`   | Blank line required between subject and body                             |\n| `body-max-line-length` | Maximum length of each body line                                         |\n\nA rule that is absent or disabled (severity 0) is simply not enforced. When unsure, use\na conservative baseline that passes the common presets: lower-case type, no trailing\nperiod, header under 72 characters (config-conventional allows up to 100). Note that\nrunning commitlint with no config at all fails with an `empty-rules` error rather than\nfalling back to any default convention.\n\n## 3. Write the message\n\nFormat: `type(scope): subject` — the scope is optional unless `scope-empty` is `[2, \"never\"]`.\n\nAn example that satisfies `@commitlint/config-conventional`:\n\n```\nfeat(parser): add support for inline issue references\n\nExplain what changed and why. Separate the body from the subject with a blank\nline (body-leading-blank) and keep lines within body-max-line-length.\n\nCloses #123\n```\n\n## 4. Validate before committing\n\n```bash\nprintf '%s' \"feat(parser): add support for inline issue references\n\nExplain what changed and why.\n\nCloses #123\" | npx commitlint\n```\n\nExit code 0 with no output means the message passes. Validate the complete\nmessage (header and body), not just the first line — body rules are checked\ntoo. Doing this before committing is cheaper than a failed commit.\n\n## 5. Self-correct when the commit-msg hook rejects\n\nRejection output names each violated rule in brackets:\n\n```\n⧗   --- input ---\nFeat: Added new parser.\n✖   subject must not be sentence-case, start-case, pascal-case, upper-case [subject-case]\n✖   subject may not end with full stop [subject-full-stop]\n✖   type must be lower-case [type-case]\n✖   type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]\n\n✖   found 4 problems, 0 warnings\n```\n\n- Fix ONLY the rules named in brackets; keep everything else identical.\n- Re-validate via stdin (step 4), then retry the commit.\n- NEVER bypass the hook with `git commit --no-verify` — fixing the message is\n  always the correct action.\n","category":"skills","tokens":1136}]}