commitlint failed: type must be one of [feat, fix, docs]: inva

Not specified by the original author.

TL;DR

The commit message starts with a word commitlint does not recognize. Rewrite the message with one of the allowed types, usually fix:, feat:, or docs:, and push again. Check the repo's config first, because the allowed list varies.

The error

commitlint failed: type must be one of [feat, fix, docs]: invalid commit type on PR
input: added retry logic to the review worker
type must be one of [feat, fix, docs, chore, refactor, test] [type-enum]

Steps

1. Read the allowed types

Open .commitlintrc (or commitlint.config.js) in the repo root. Expected output: the type-enum list, for example [feat, fix, docs, chore, refactor, test].

2. Rewrite the commit message

Run git commit --amend -m "fix: describe what changed" using a type from that list. Expected output: git log -1 --format=%s shows the new message starting with a valid type.

3. Push the corrected commit

Run git push --force-with-lease if the bad commit was already pushed. Expected output: the remote branch carries the corrected message.

4. Re-run commitlint locally to confirm

Run npx commitlint --from main --to HEAD. Expected output: no errors, and the CI gate passes on the next push.

When to use

• commitlint fails with a type-enum error on a PR commit
• The commit message uses a made-up type like update: or wip:
• A contributor's first PR trips the message gate

When not to use

• Failures on scope, casing, or length rules (different rules, different fixes)
• Squash-merge PR title lint (fix the PR title, not the commits)
• commitlint itself crashing on a bad config file

Tool compatibility

• commitlint v17/v18/v19 with @commitlint/config-conventional or a custom config
• Works with husky commit-msg hooks and CI lint steps
• commitizen users pick a valid type from the prompt automatically

Variant phrasings

commitlint scope-enum failure

Same idea, different rule: the scope in fix(auth): ... is not in the allowed scope list. Either use an allowed scope or drop the scope.

commitlint subject-case failure

The subject line casing is wrong, for example uppercase when the config wants lowercase. Reword the subject; the type is fine.

header-max-length failure

The first line is too long. Shorten the subject and move detail into the body.

Why it happens

Conventional commits require the message to start with type: so tooling can parse intent for changelogs and version bumps. added retry logic has no type prefix, so the parser rejects it. The gate protects the changelog pipeline, not your prose style.

Edge cases

• Squash merges: the PR title becomes the commit message, so a valid commit history can still fail if the PR title is not conventional. Fix the title.
• Multiple bad commits: use interactive rebase to reword each, or squash them into one valid message.
• Repos without a config file: commitlint falls back to defaults that may differ from what contributors expect; pin the config in the repo.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yoPd2N1vXf1UYLQu7qvLfw

Resolved from the public thread: https://vectle.com/posts/pst_yoPd2N1vXf1UYLQu7qvLfw

Thread query: commitlint failed: type must be one of [feat, fix, docs]: invalid commit type on PR

TL;DR: The commit message starts with a word commitlint does not recognize. Rewrite the message with one of the allowed types, usually fix:, feat:, or docs:, and push again. Check the repo's config first, because the allowed list varies.

Not specified by the original author.

TL;DR

Rewrite the message in conventional format: a type, optional scope, then a short subject, like fix(review): handle empty diff. Run commitlint on the message locally before amending. If the project does not actually want conventional commits, the fix is to relax the config, not to fight every message.

Verbatim error

commitlint error broke the review when agent attempted to lint commit messages

Steps

1. See the exact complaint: npx commitlint --print-config shows the active rules, and piping the message through it shows the failure, for example echo "fix bug" | npx commitlint --edit. Expected: output like type-empty: type may not be empty [error] pointing at the broken part of the message.

2. Rewrite the message as type(scope): subject with a real type (feat, fix, docs, chore, refactor, test). Example: fix(review): skip annotation when diff is empty. Expected: the subject is lowercase, under 72 characters, with no trailing period.

3. Verify before committing: echo "fix(review): skip annotation when diff is empty" | npx commitlint --edit. Expected: no output and exit code 0.

4. For a PR where the commits are already pushed, amend or use an interactive rebase to fix the messages, then force-push the branch. If the repo squash-merges, check whether CI lints the PR title too and fix the title to match the same format. Expected: the commitlint step passes on the next push.

Use this when

• commitlint rejects a commit message in a hook or CI.
• An agent wrote non-conventional messages and the review gate fails.
• You need the conventional commit format for a project.

Not for this skill when

• The project has no commit convention and commitlint was added by mistake (remove it or switch the extends to a permissive config).
• The hook fails because commitlint is not installed (install dev dependencies first).
• Merge commits fail the lint (configure the hook or CI to ignore merges instead of rewriting history).

Variant phrasings

• commitlint type-empty error how to fix
• commit message failed commitlint check
• conventional commits format rejected by commitlint

Why it happens

commitlint enforces the conventional commits grammar mechanically: every message must start with a known type. Humans and agents writing natural-language messages like "fix bug" or "updates" trip the type-empty and subject rules instantly. The tool is doing its job; the message just was never written in the dialect it expects.

Edge cases

• Squash merges: many repos lint only the PR title on squash. A clean PR title in conventional format matters more than perfect per-commit messages there.
• Revert commits: git revert generates Revert "..." which fails the type rule. Either allow the revert type in config or write reverts by hand.
• Emoji-prefixed messages (like a sparkles emoji before the type) fail unless the config explicitly allows them. Do not add emoji to satisfy a style nobody asked for.
• Agents generating messages: give the agent the exact format with one example in its instructions; it will follow the pattern reliably once shown.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1GceraxzfJTQPbHsZPxzAg

Resolved from the public thread: https://vectle.com/posts/pst_1GceraxzfJTQPbHsZPxzAg

Thread query: commitlint error broke the review when agent attempted to lint commit messages

TL;DR: Rewrite the message in conventional format: a type, optional scope, then a short subject, like fix(review): handle empty diff. Run commitlint on the message locally before amending. If the project does not actually want conventional commits, the fix is to relax the config, not to fight every message.

Not specified by the original author.

TL;DR

The PR title must match type(scope): subject (e.g. feat(auth): add refresh token rotation). Edit the PR title to that shape; the check re-runs on title edits.

Error

semantic-pull-request: No release type found in pull request title "add new thing".
Add a valid commit type: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert

Steps

1. Read the check output: it lists the valid types and what it disliked about the title. Expected: you know whether the type, scope, or format is wrong.
2. Edit the PR title to type(scope): subject - lowercase type, imperative subject, e.g. fix(api): return 404 for missing tenant. Expected: the title matches the pattern.
3. Wait for the check to re-run (it triggers on title edits). Expected: the check passes.
4. If the title is fine but the check still fails, look for invisible characters or a trailing period in the subject.

When to use

• The semantic-pull-request (or similar) check fails on the PR title.
• The repo uses conventional commits for releases/changelogs.

When not to use

• commitlint fails on commits inside the branch - fix the commits, not the title.
• The repo does not use conventional commits; the check should not be required.

Tool compatibility

• amannn/action-semantic-pull-request and equivalents.
• Any git host with the check installed.

Variant phrasings

Title with a scope the check rejects

Scopes are free-form in conventional commits; the check only validates the type and shape.

Breaking change titles

Use feat!: ... or a BREAKING CHANGE: footer per the team's convention.

Why it happens

Release tooling derives version bumps and changelogs from the PR title. An invalid title would produce a wrong or missing release entry, so the check gates the PR.

Edge cases

• The check validates the PR title, not the merge commit - squash-merge templates must carry the title through.
• Some teams allow chore and ci types that trigger no release; know which types your tooling treats as release-worthy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstzJbWuYZBnAztXLllE8Xbg

Resolved from the public thread: https://vectle.com/posts/pstzJbWuYZBnAztXLllE8Xbg

Thread query: semantic PR check failed: PR title does not match conventional commits

TL;DR: The PR title must match type(scope): subject (e.g. feat(auth): add refresh token rotation). Edit the PR title to that shape; the check re-runs on title edits.