Before submitting
Area
Not sure
Problem or use case
t3code automatically generates human-readable branch names after the first turn, but there is currently no way to configure the naming convention used for those branches.
Teams or users following Conventional Branch therefore need to manually rename generated branches or accept branch names that don't follow their usual Git workflow.
Since t3code already supports Conventional Commits, having the option to use the corresponding convention for branch names would also make generated Git state more consistent.
Proposed solution
Add a branch naming setting that allows users to opt into Conventional Branch naming.
When enabled, generated human-readable branches would follow the specification, for example:
feature/add-worktree-support
fix/worktree-branch-naming
refactor/git-branch-utilities
The branch type could be inferred from the task similarly to how t3code already determines Conventional Commit types.
The existing naming strategy could remain the default, making this entirely opt-in.
Why this matters
This would allow repositories already using Conventional Branch to keep consistent branch naming without requiring manual renames.
It would also complement t3code's existing Conventional Commits support, providing a consistent convention across automatically generated commits and branches
Smallest useful scope
Add a single setting to enable Conventional Branch naming for the human-readable branch generated after the first turn.
The existing naming behavior can remain the default, and temporary worktree branch naming does not need to change as part of the first implementation.
Alternatives considered
A more flexible alternative would be to allow users to provide custom branch naming instructions through a prompt, for example:
Follow the Conventional Branch specification and use one of:
feature/, fix/, refactor/, docs/, test/, build/, ci/, chore/, or perf/.
This would support Conventional Branch as well as repository-specific conventions without requiring t3code to implement each convention explicitly.
However, a dedicated Conventional Branch option would provide a simpler experience for a common standardized convention, while custom prompt-based naming rules could be added separately for users who need more control.
Risks or tradeoffs
Inferring the correct branch type from a prompt may occasionally produce an imperfect type.
Keeping the feature opt-in avoids changing existing workflows, and the generated type could use a reasonable fallback such as chore when the intent is unclear
Examples or references
Conventional Branch specification:
https://conventionalbranch.org/
This is conceptually similar to the Conventional Commits support already available in t3code.
Contribution
Before submitting
Area
Not sure
Problem or use case
t3code automatically generates human-readable branch names after the first turn, but there is currently no way to configure the naming convention used for those branches.
Teams or users following Conventional Branch therefore need to manually rename generated branches or accept branch names that don't follow their usual Git workflow.
Since t3code already supports Conventional Commits, having the option to use the corresponding convention for branch names would also make generated Git state more consistent.
Proposed solution
Add a branch naming setting that allows users to opt into Conventional Branch naming.
When enabled, generated human-readable branches would follow the specification, for example:
The branch type could be inferred from the task similarly to how t3code already determines Conventional Commit types.
The existing naming strategy could remain the default, making this entirely opt-in.
Why this matters
This would allow repositories already using Conventional Branch to keep consistent branch naming without requiring manual renames.
It would also complement t3code's existing Conventional Commits support, providing a consistent convention across automatically generated commits and branches
Smallest useful scope
Add a single setting to enable Conventional Branch naming for the human-readable branch generated after the first turn.
The existing naming behavior can remain the default, and temporary worktree branch naming does not need to change as part of the first implementation.
Alternatives considered
A more flexible alternative would be to allow users to provide custom branch naming instructions through a prompt, for example:
This would support Conventional Branch as well as repository-specific conventions without requiring t3code to implement each convention explicitly.
However, a dedicated Conventional Branch option would provide a simpler experience for a common standardized convention, while custom prompt-based naming rules could be added separately for users who need more control.
Risks or tradeoffs
Inferring the correct branch type from a prompt may occasionally produce an imperfect type.
Keeping the feature opt-in avoids changing existing workflows, and the generated type could use a reasonable fallback such as chore when the intent is unclear
Examples or references
Conventional Branch specification:
https://conventionalbranch.org/
This is conceptually similar to the Conventional Commits support already available in t3code.
Contribution