What's the best way to use spec-kit in a team?

[dkoenawan]

When we run the /specify command, it creates a new specs folder that is numerically incremented (001, 002, 003...).

This works well when you're developing a project by yourself. However, when you are working in a team and everyone branches off a common branch to develop different features, their number will naturally conflict. Is this the intended way that spec-kit is designed to work?

[LeiYanAdmin]

How about this solution:
-------------------------+
| 0. Ideation Phase |
+----------------------------+
↓
+----------------------------+ Led by Architecture/Product
| 1. /constitution | ──────────────────────────────┐
+----------------------------+ │
↓ │
+----------------------------+ │
| 2. /specify | ←→ Tech feasibility, feature breakdown
+----------------------------+ │
↓ │
+----------------------------+ │
| 3. Specification Finalized | (Committed to main SPEC repo)│
+----------------------------+ │
↓ ▼
+----------------------------------------------+
| 4. Team-Specific Branches from SPEC |
| (Frontend / Backend / QA / DevOps) |
+----------------------------------------------+
↓
+----------------------------------------------+
| 5. /plan → /task → /implement |
+----------------------------------------------+
↓
+----------------------------+
| 6. Pull Request & Review |
+----------------------------+
↓
+----------------------------+
| 7. Automated Test & Deploy |
+----------------------------+

[wilsonneto-swe]

There is a feature for the feature and branch names here:
#935

Regarding the question, I think that we should not try to resolve all the company problems with Spec-Kit, it won't be the only tool in a scaled company. One good flow would be: The Product team already created the PRD/Requirements Doc and the feasibility was already discussed with technical people, the company already has a architectural guidance doc in a the shared wiki, your TDD/Solution

Design can use spec kit, but probably it will be better stored in another shared doc than centralized in the repo. I see spec-kit as one tool for the teams, the squad, the squad always has its own nuances and approaches based on their system, so one shared constitution, based on the PRD and approved TDD you slice it to avoid context rot and start using spec kit in slices of it to plan the stages of the development within the squad.

At least this is the way I feel it fits better.

[airtonix]

You won't be able to use spec kit in a team:

• won't work with git worktrees
• won't work in a monorepo where there's multiple different speckits
• wont' work in a repo where multiple different people work on different tasks in a feature.

You have to understand that speckit is hypegrift growth hacking for github, they're only focusing on converting all the new comers who are solo vibe "coders" into github customers.

If it was a serious team SDD framework it wouldn't be so heavily dependant on git.