Repository navigation
Feature request: option to auto-create feature branch for new proposals #332
Description
Summary
It would be useful if OpenSpec could optionally create a new feature branch in the git repository whenever a new proposal is started through the /openspec-proposal slash command or equivalent. This behaviour is inspired by SpecKit’s branch workflow: each new change begins on its own branch with a numeric prefix and an AI-generated slug.
Motivation
Today, when starting a new proposal with OpenSpec, all changes are made in the current branch unless the user manually creates a feature branch. Creating a dedicated branch per feature makes it easier to manage work in progress, track history, and review pull requests. SpecKit implements this pattern by generating branch names like 001-add-profile-filters, 002-update-auth, etc. Bringing a similar capability to OpenSpec would improve developer ergonomics.
Proposal
- Add a configuration option (e.g. in
openspec/project.mdor a CLI flag) that enables automatic branch creation when starting a new proposal. - When enabled, OpenSpec should:
- Determine the next sequence number (e.g. based on existing feature branches in the repo).
- Generate a human-readable branch name based on the proposal title (using AI to slugify).
- Create and check out the new branch before scaffolding the
openspec/changes/<change>/directory.
- The user should still have the ability to disable this feature if they prefer to manage branches manually.
Benefits
- Each feature or change lives in its own branch, making it easier to see the history of development.
- Aligns with existing workflows in tools like SpecKit, making migration smoother.
- Reduces manual steps and potential mistakes when starting a new feature.
Please consider adding this optional branch creation mechanism to OpenSpec to streamline the workflow.
Activity
TabishB commentedon Nov 24, 2025
We're experimenting with reworking a lot of the core internals and how this project works. This will come alongside that soon.
BretJohnson commentedon Feb 4, 2026
Weighing in here, I could see it working like this:
config.yamlto enable it, maybe starting with it off by default until early users are happy with it then enable by default. (I assume config.yaml is the right place for a setting like this these days - maybe project.md went away?)askpatrickw commentedon Feb 5, 2026
I would definitely not prefer branches. As there is more and more desire to work simultaneously, on several features, git worktrees are starting to be more popular.
BretJohnson commentedon Feb 5, 2026
Don't worktrees and branches normally go hand in hand, where a particular worktree is tied to a particular branch? Branches seem like essentially a requirement to use worktrees.
Given that I could see config settings something like this:
c4jquick commentedon Mar 21, 2026
have also been comparing ralph for sdd which implements a simple git branching strategy (no worktrees) based on spec changes. the git commits are super helpful for tracking and undoing if things go wrong.
https://github.com/snarktank/ralph
it will create a feature branch named after the change during plan stage. when doing task implementation it will commit changes on each iteration (think openspec tasks) with helpful git comment about what it actually did. ie
snarktank/ralph@800c221
ralph will never merge it back into main (leaves it to humans)
do you think something like this would be possible w/ openspec if i were to editing the current skills it installs?
harveyhq commentedon Sep 17, 2026
Any news?