• Add opt-in useExclamationMark setting for breaking change notation
• Appends ! after type/scope in commit header per Conventional Commits spec
• Includes comprehensive test coverage for all scenarios
• Updates type definitions and documentation

Implement exclamation mark logic in message builder

• Extract isBreaking from answers parameter
• Add logic to conditionally append ! based on useExclamationMark setting
• Include breaking mark in prefix construction

@commitlint/cz-commitlint/src/SectionHeader.ts

Add comprehensive test coverage for exclamation mark feature

• Add 5 new test cases covering breaking change scenarios
• Test ! placement after type and scope
• Verify default disabled behavior
• Test edge cases with empty subject

@commitlint/cz-commitlint/src/SectionHeader.test.ts

Add default configuration for exclamation mark setting

• Add useExclamationMark setting with default value of false
• Maintain backward compatibility with opt-in approach

@commitlint/cz-commitlint/src/store/defaultPromptConfigs.ts

Description

HeaderQuestion.beforeQuestionStart() computes remaining header length using
combineCommitMessage(answers) before isBreaking is asked, so it may allow a subject that fits
without ! but produces a final header exceeding header-max-length once isBreaking becomes
true. This can lead to generated commit messages that violate commitlint header length rules despite
the prompt’s length validation.

Code

@commitlint/cz-commitlint/src/SectionHeader.ts[R30-33]

+	const { type = "", scope = "", subject = "", isBreaking } = answers;
+	const breakingMark =
+		isBreaking && getPromptSettings()["useExclamationMark"] ? "!" : "";
+	const prefix = `${type}${scope ? `(${scope})` : ""}${breakingMark}`;

Evidence

The header prompt enforces input lengths using HeaderQuestion.beforeQuestionStart() and
Question.validate(). The new combineCommitMessage() adds a ! only when answers.isBreaking is
true, but isBreaking is collected later because the prompt question order is header -> body ->
footer; therefore, during header prompting answers.isBreaking is still unset and the computed
remaining length does not reserve space for a later !.

@commitlint/cz-commitlint/src/SectionHeader.ts[21-39]
@commitlint/cz-commitlint/src/Process.ts[26-38]
@commitlint/cz-commitlint/src/SectionFooter.ts[41-83]
@commitlint/cz-commitlint/src/Question.ts[137-156]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`combineCommitMessage()` now adds an exclamation mark based on `answers.isBreaking`, but `isBreaking` is answered in the footer section after header questions. Header input max-length is computed during header prompting via `HeaderQuestion.beforeQuestionStart()`, so it can’t account for the later `!`, allowing a subject that later produces an over-long header.

## Issue Context
The prompt pipeline in `Process.ts` asks header questions before footer questions, and `Question.validate()` enforces max length based on the per-question `maxLength` computed in `beforeQuestionStart()`.

## Fix Focus Areas
- @commitlint/cz-commitlint/src/SectionHeader.ts[21-39]
- @commitlint/cz-commitlint/src/Process.ts[26-38]
- @commitlint/cz-commitlint/src/SectionFooter.ts[41-83]

## Suggested direction
Implement one of:
1) Conservative reservation: when `getPromptSettings().useExclamationMark` is true and the `isBreaking` question exists but `answers.isBreaking` is still `undefined`, reserve 1 char in header remaining length computations.
2) Reorder questions so `isBreaking` is asked before validating the `subject` question’s max length (e.g., insert `isBreaking` immediately after `type/scope` and before `subject`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

@commitlint/types adds useExclamationMark as a required property on the exported
PromptConfig.settings type, which can break TypeScript consumers that construct PromptConfig
objects without this field. Runtime behavior is safe due to defaults, but downstream compilation can
fail without an update or a major version bump.

Code

@commitlint/types/src/prompt.ts[R19-23]

	settings: {
		scopeEnumSeparator: string;
		enableMultipleScopes: boolean;
+		useExclamationMark: boolean;
	};

Evidence

PromptConfig is exported from @commitlint/types and its settings object now requires
useExclamationMark. Although cz-commitlint provides a default value in defaultPromptConfigs,
TypeScript consumers who type objects as PromptConfig (not UserPromptConfig) must now add this
new field to compile.

@commitlint/types/src/prompt.ts[18-25]
@commitlint/cz-commitlint/src/store/defaultPromptConfigs.ts[1-7]
@commitlint/types/src/prompt.ts[54-60]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new required field `useExclamationMark` was added to the exported `PromptConfig.settings` type. This can break TypeScript consumers that construct `PromptConfig` literals without this field.

## Issue Context
Runtime defaults in `cz-commitlint` set `useExclamationMark: false`, so behavior is fine; the risk is compile-time compatibility for external TS users.

## Fix Focus Areas
- @commitlint/types/src/prompt.ts[18-24]
- @commitlint/cz-commitlint/src/store/defaultPromptConfigs.ts[1-7]

## Suggested direction
- Consider changing `useExclamationMark: boolean;` to `useExclamationMark?: boolean;` in `PromptConfig.settings`, keeping defaults so internal code still sees a boolean at runtime; OR
- If `PromptConfig` is intentionally strict, document and ship under a major version bump.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools