Configuration file needed

[airtonix]

It's become clear that your idea of where spec files go and how branches are created won't match everyone elses needs.

1. configuration file
2. support decentralised specfile location (monorepos)
3. allow specdir naming pattern configuration
4. allow git branch creation to be avoided, ie don't use git branch to indicate current spec.

---

1. So I suggest that you first look for a config file speckit.json or if you don't want to rely on jq then speckit.env

SPECKIT_DIR=./specs
SPECKIT_IDPATTERN="ABC-1234"
SPECKIT_INCREMENTID=false
SPECKIT_CREATEBRANCHES=false

2. instead of finding the git root, walk the fs tree until you find speckit.env this is the local root for working on specs. if this dir doesn't contain a .specify directory then keep walking until you find one. this is the project root.

3. i personally don't like the naming pattern you're using. and our team would want them to be jira ticket codes instead.

4. store active spec in .speckit/memory/active-specs :

# .speckit/memory/active-specs

<project-root>/pkgs/somelib = ABC-1234-somethingsomethingsomething-darkside
...etc

---

In fact it might be better if you just get rid of the idea of git branches all together, because :

• planning might happen on an epic ticket, implementation happens on other tickets. or
• planning might happen on a ticket linked to the epic ticket, and implementation happens on other tickets linked to the epic.

[airtonix]

I've actually made this conversion in my own project twice now, basically I ask opencode

[PLAN] Hey, I just installed speckit, I love it. But I don't love the git branch behaviour. Remove it. instead let's store the current feature in a file within the .specify/memory/current file.
Remove all mention of branches and creating branches from everything spec-kit introduced: .specify/* and .opencode/command/*

Then proceed to review what it changes.

Overall though, I'm not even convinced that there's any value in knowing the current feature.

If you look at how scopecraft approaches this, it has backlog/<epicid>/<taskid>.md, active/<epicid>/<taskid>.md and archived/<epicid>/<taskid>.

Even that seems to be pointless, since your bash files that list tasks/features can just allow for filtering on the frontmatter status field.

I personally much prefer how scope craft structures the tasks in relation to a parent task, but I also love the preparation workflow that SpecKit takes you through.

just don't agree with the idea that git should be involved at all.

It's a detail that gets in the way of the real value of SpecKit.