{"owner":"conventional-changelog","repo":"commitlint","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":1296,"categories":["root-instruction","anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","skills/committing-with-commitlint/SKILL.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nContributor rules live in [.github/CONTRIBUTING.md](.github/CONTRIBUTING.md). Read it before committing or opening a pull request.\n\n## Commit type\n\ncommitlint lints commit messages, so its own history is held to that standard. Settle the type before the first commit, by what the change means for someone using the published packages:\n\n- `fix`: behaviour was wrong and is now right.\n- `feat`: a new capability.\n- `perf`: same behaviour, faster or smaller. Install size counts.\n- `refactor`: code changed, nothing a user can observe did.\n- `docs`, `test`, `ci`, `build`, `chore`: the change stays within that area. Dependency updates are `chore`.\n\nChoose by what the change is, whatever release it produces.\n\nThe merge queue squashes, so the pull request title becomes the commit on master. Give the title, every commit and the \"Types of changes\" boxes the same type, and update all three together if the type changes.\n\nWhen two types fit, name both in the pull request description and say which you chose.\n","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":{"AGENTS.md":"# AGENTS.md\n\nContributor rules live in [.github/CONTRIBUTING.md](.github/CONTRIBUTING.md). Read it before committing or opening a pull request.\n\n## Commit type\n\ncommitlint lints commit messages, so its own history is held to that standard. Settle the type before the first commit, by what the change means for someone using the published packages:\n\n- `fix`: behaviour was wrong and is now right.\n- `feat`: a new capability.\n- `perf`: same behaviour, faster or smaller. Install size counts.\n- `refactor`: code changed, nothing a user can observe did.\n- `docs`, `test`, `ci`, `build`, `chore`: the change stays within that area. Dependency updates are `chore`.\n\nChoose by what the change is, whatever release it produces.\n\nThe merge queue squashes, so the pull request title becomes the commit on master. Give the title, every commit and the \"Types of changes\" boxes the same type, and update all three together if the type changes.\n\nWhen two types fit, name both in the pull request description and say which you chose.\n","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":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/conventional-changelog/commitlint/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nContributor rules live in [.github/CONTRIBUTING.md](.github/CONTRIBUTING.md). Read it before committing or opening a pull request.\n\n## Commit type\n\ncommitlint lints commit messages, so its own history is held to that standard. Settle the type before the first commit, by what the change means for someone using the published packages:\n\n- `fix`: behaviour was wrong and is now right.\n- `feat`: a new capability.\n- `perf`: same behaviour, faster or smaller. Install size counts.\n- `refactor`: code changed, nothing a user can observe did.\n- `docs`, `test`, `ci`, `build`, `chore`: the change stays within that area. Dependency updates are `chore`.\n\nChoose by what the change is, whatever release it produces.\n\nThe merge queue squashes, so the pull request title becomes the commit on master. Give the title, every commit and the \"Types of changes\" boxes the same type, and update all three together if the type changes.\n\nWhen two types fit, name both in the pull request description and say which you chose.\n","isInternal":false,"tokens":236,"sizeBytes":1019},{"name":"SKILL.md","path":"skills/committing-with-commitlint/SKILL.md","rawUrl":"https://raw.githubusercontent.com/conventional-changelog/commitlint/HEAD/skills/committing-with-commitlint/SKILL.md","title":"committing-with-commitlint","category":"anthropic-skill","format":"markdown","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","frontmatter":{"name":"committing-with-commitlint","description":"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"},"isInternal":false,"tokens":1060,"sizeBytes":4571}],"systemPromptSnippet":"<yakaai_skills repo=\"conventional-changelog/commitlint\">\n<!-- File: AGENTS.md (Tokens: ~236 | Category: root-instruction) -->\n# AGENTS.md\n\nContributor rules live in [.github/CONTRIBUTING.md](.github/CONTRIBUTING.md). Read it before committing or opening a pull request.\n\n## Commit type\n\ncommitlint lints commit messages, so its own history is held to that standard. Settle the type before the first commit, by what the change means for someone using the published packages:\n\n- `fix`: behaviour was wrong and is now right.\n- `feat`: a new capability.\n- `perf`: same behaviour, faster or smaller. Install size counts.\n- `refactor`: code changed, nothing a user can observe did.\n- `docs`, `test`, `ci`, `build`, `chore`: the change stays within that area. Dependency updates are `chore`.\n\nChoose by what the change is, whatever release it produces.\n\nThe merge queue squashes, so the pull request title becomes the commit on master. Give the title, every commit and the \"Types of changes\" boxes the same type, and update all three together if the type changes.\n\nWhen two types fit, name both in the pull request description and say which you chose.\n\n<!-- File: skills/committing-with-commitlint/SKILL.md (Tokens: ~1060 | Category: anthropic-skill) -->\n---\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</yakaai_skills>"}