You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a state-driven commit flow API for non-interactive commit clients #2011
cz commit currently assumes an interactive terminal flow: it asks all questions through questionary, renders the commit message, and immediately runs git commit.
This works well for humans in a TTY, but it is hard to integrate with LLM-based tools, editor integrations, or other non-interactive clients that need to:
answer one question at a time
inspect validation errors
revise earlier answers
finalize the real commit only after the full flow is accepted
I would like Commitizen to expose a state-driven commit flow API that separates question flow from the final commit execution.
Possible Solution
Add an optional session-based flow interface for commit adapters.
Example shape:
session = cz.start_commit_flow()
question = session.next_question()
result = session.submit_answer(question.name, answer)
This would allow a client to drive the commit flow step by step without relying on an interactive TTY.
The existing cz commit command could continue to work as it does today by driving this API internally.
A narrow first implementation for cz_conventional_commits would probably be enough to validate the design before extending it to cz_customize or third-party plugins.
Additional context
Today, commitizen/commands/commit.py gets a flat list from self.cz.questions(), passes it directly to questionary.prompt(...), then calls self.cz.message(answers) and performs the commit.
The built-in flows are mostly linear already, so this proposal is less about adding complex branching and more about exposing the commit flow as a session/state protocol for external clients.
Main tradeoff: this would add API surface and require a compatibility story for existing adapters and plugins.
I'm not a fan and will not be a user of it 🤔 If we're to go with full LLM, we probably would just skip commitizen commit? or what would be the benefit to mix use them
That is also my concern. The main benefit is the commit message generated by cz commit is guaranteed to be valid. However, following patterns should not be a problem for LLMs now?
We don't even know whether this new feature will save tokens.
Wouldn't validation be possible already with cz check?
Yes, exactly. The original proposal is way too complicated.
What I'm doing for now is that:
Create a skill with all commit types baked in so the LLM already knows the valid formats (cz schema + cz example + cz info)
Add valid step to call cz check -m "<message>" in the skill
LLM generates the commit message from the staged diff by the skill
So I can use Commitizen purely as a schema and validation layer. The value is that cz check enforces the
project-specific rules (especially for cz_customize configs), which the LLM may not know without it.
Activity
bearomorphism commentedon Jun 2, 2026
I remember @ongchi and I had an offline discussion on this in the scisprint Taiwan in-person event. @woile @Lee-W mind taking a look on this issue?
(forgive me if I remembered incorrectly)
woile commentedon Jun 2, 2026
what would the API entail?
Lee-W commentedon Jun 3, 2026
I'm not a fan and will not be a user of it 🤔 If we're to go with full LLM, we probably would just skip commitizen commit? or what would be the benefit to mix use them
bearomorphism commentedon Jun 3, 2026
That is also my concern. The main benefit is the commit message generated by cz commit is guaranteed to be valid. However, following patterns should not be a problem for LLMs now?
We don't even know whether this new feature will save tokens.
woile commentedon Jun 3, 2026
Wouldn't validation be possible already with
cz check?ongchi commentedon Jun 7, 2026
Yes, exactly. The original proposal is way too complicated.
What I'm doing for now is that:
So I can use Commitizen purely as a schema and validation layer. The value is that cz check enforces the
project-specific rules (especially for cz_customize configs), which the LLM may not know without it.
Thanks for the nudge.