Is there file(s) to ignore to commit in .specify and specs directories ?

[antoineb-primeum]

Hi,

Is there file(s) to ignore to commit in .specify and specs directories ?

It seems that .specify/feature.json is modified between the implementation of different specs and seems focus the latest spec in usage.

I'm a bit too new to know that kind of subtilities but i would share only needed files to my team via git.
Thank you for sharing your experiences on this subject with me.

[mnriem]

What you commit is up to you. Or you can quickly install whatever you need.

[antoineb-primeum]

Thank you for your response, it is still a bit vague. I would really like to know the best practice for sharing files with my team and possibly those that can be ignored.

To tease you, your answer reminds me a bit of '42,' the answer to "The great question of life and everything else".

[mnriem]

It depends. Do you want to retain everything. Then commit it all. Do you want to retain the specs? Keep them. Reinstalling the Specify CLI is quick and easy so is the .specify directory needed in Git? Not really. But again depends on what you want!

[antoineb-primeum]

Thanks for your answers, I'll share you my observations for now, I investigated three files in .specify:

• .specify/feature.json: this one seems working as a "current session/workspace" file, and could be ignore in repository
• .specify/memory/constitution.md: this one seems to be dedicated to the projet and is versioned (SEMVER in file), sound like an importante file to push and share with the team. To upgrade it, run /speckit.constitution <with fresh information about project>.
• .specify/extensions.yml: this one refere about practices allowed to the team (ex: use or not git extension) about enabled (or not) extensions, sound like an importante file too to push and share with the team.

I'm curious to know if the community have more files to commit or not with remarks,
Thank you all

[jarodsmk]

Good morning all - stumbled across this discussion when searching for an answer to this myself 😄 and while typing out my questions I kind of answered them.

Initially I was asking - should these be shared across the team? Because I can imagine running into conflicts on these would be troublesome.
Looking at the various sub folders that we have so far, and contextualizing this to a team:

• /integrations: you'll likely want these shared across your team to standardize your tooling
• /memory: if you'd like the team/project to have a centralized memory, keep this committed
• /scripts: If you'd like your team to utilize the same scripts, keep this committed
• /templates: If you'd like your team use the same templates, ...
• /workflows: ...

There's a pattern for each answer here - so ultimately if you want your team to have a consistent experience, keep them committed :)

[mnriem]

Great investigation, and @jarodsmk's framing is spot on: if you want a consistent team experience, commit it. Here's the concrete breakdown based on how the files actually behave.

Commit and share (project-level, meant to be versioned):

• specs/ — the specs, plans, tasks, and research. This is the whole point of SDD; share it all.
• .specify/memory/constitution.md — project-wide, SemVer-tracked. Definitely commit.
• .specify/extensions.yml — the list of enabled extensions; commit it so everyone runs the same tooling.
• .specify/extensions/<ext-id>/<ext-id>-config.yml — project-level extension config; commit it.
• .specify/scripts/, .specify/templates/ — committing pins everyone to the same version instead of relying on each person re-installing the CLI.

Machine/session-local state (don't share):

• .specify/feature.json — you nailed it. It's just a local pointer to the current feature directory, rewritten every time you switch features. Sharing it only causes churn/merge noise.
• .specify/extensions/<ext-id>/local-config.yml — per-machine extension overrides.

Good news: you shouldn't have to manage this by hand. I've opened a PR (#4000) so specify init scaffolds a managed .specify/.gitignore that ignores exactly those two things:

feature.json
extensions/*/local-config.yml

It's tracked by the CLI's shared-infrastructure manifest, so your edits are preserved on re-init and specify init --here --force restores it. Everything else under .specify/ stays shareable by default.

One caveat regardless of gitignore: if you already committed feature.json before this, gitignore won't untrack it — run git rm --cached .specify/feature.json once.

TL;DR: commit specs/, constitution.md, and your extension setup so the team is aligned; the local "current feature" pointer and per-machine configs are now gitignored for you out of the box.

---

_{Posted on behalf of @mnriem by GitHub Copilot (model: Claude Opus 4.8). The linked PR was authored by the same agent.}