Problem
When consuming cz in CI pipelines, it's common to need the parsed scope from a commit message for secondary processing — for example, counting how many service scopes a PR title declares, or routing logic based on type/scope.
Currently the only way to extract these fields is to replicate cz's internal regex (^([a-z]+)(\(([a-zA-Z0-9_@/,*-]+)\))?(!)?: (.+)$) with a grep in the calling script. This is fragile: if the regex in cz ever changes, consumers silently diverge.
Proposed solution
Add a subcommand (e.g. cz extract or extend cz lint) that reads a commit message from stdin and outputs the parsed fields in a machine-readable format (e.g. newline-separated key=value or JSON):
type=feat
scope=teams-mcp,mcp-server-module
breaking=false
description=add cross-service feature
Or as a flag on cz lint:
echo "feat(teams-mcp): add feature" | cz lint --output fields
Use case example
In our gatekeeper CI we need to count how many service scopes a PR title declares and emit a warning when more than one is present:
SCOPE=$(printenv PR_TITLE | grep -oP '^[a-z]+\(\K[^)]+' || true)
This works today but duplicates internal parsing logic. A first-class extraction command would make this more robust and keep consumers in sync with cz's own parser.
Problem
When consuming
czin CI pipelines, it's common to need the parsed scope from a commit message for secondary processing — for example, counting how many service scopes a PR title declares, or routing logic based on type/scope.Currently the only way to extract these fields is to replicate
cz's internal regex (^([a-z]+)(\(([a-zA-Z0-9_@/,*-]+)\))?(!)?: (.+)$) with agrepin the calling script. This is fragile: if the regex inczever changes, consumers silently diverge.Proposed solution
Add a subcommand (e.g.
cz extractor extendcz lint) that reads a commit message from stdin and outputs the parsed fields in a machine-readable format (e.g. newline-separatedkey=valueor JSON):Or as a flag on
cz lint:Use case example
In our gatekeeper CI we need to count how many service scopes a PR title declares and emit a warning when more than one is present:
SCOPE=$(printenv PR_TITLE | grep -oP '^[a-z]+\(\K[^)]+' || true)This works today but duplicates internal parsing logic. A first-class extraction command would make this more robust and keep consumers in sync with
cz's own parser.