[Feature]: Support for multi-developer work on a shared speckit project

[harishiyer007]

Problem Statement

I have a project where multiple developers are working on specifying and implementing various features. Current speckit /specify command generates a sequential nnn numbered spec series. If different developers checkout a project along with the specs and run this command, they may both get the same number.
I suggest that we can have a developer initial prefixed to the spec number so that we can uniquely track all the specs.
I have implemented a version of this locally by making changes in the speckit commands and markdowns.
If relevant, I can provide this change.

Proposed Solution

I would like the specs defined by different developers in the same project to be prefixed with the developer's initials. For e.g. developer John Doe's specs could be jd-001, jd-002 etc. And developer Tom Hardy's specs could be th-001, th-002 etc.

Alternatives Considered

No response

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

None

Use Cases

No response

Acceptance Criteria

No response

Additional Context

No response

[github-actions]

Feature assessment — shared-spec-project · Stage 1/5: Intake

Idea Intake: Multi-developer shared Spec Kit project

• Slug: shared-spec-project
• Created: 2026-09-03T11:37:40Z
• Source: GitHub issue [Feature]: Support for multi-developer work on a shared speckit project #4418 (read via GitHub issue tool)
• Type: new-capability

Idea (as captured)

Problem Statement

I have a project where multiple developers are working on specifying and implementing various features. Current speckit /specify command generates a sequential nnn numbered spec series. If different developers checkout a project along with the specs and run this command, they may both get the same number.
I suggest that we can have a developer initial prefixed to the spec number so that we can uniquely track all the specs.
I have implemented a version of this locally by making changes in the speckit commands and markdowns.
If relevant, I can provide this change.

Proposed Solution

I would like the specs defined by different developers in the same project to be prefixed with the developer's initials. For e.g. developer John Doe's specs could be jd-001, jd-002 etc. And developer Tom Hardy's specs could be th-001, th-002 etc.

Alternatives Considered

No response

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

None

Use Cases

No response

Acceptance Criteria

No response

Additional Context

No response

Restated

The request proposes changing Spec Kit's feature/spec identifier generation so that identifiers include a developer-specific initials prefix as well as a sequential number. This is intended to avoid duplicate identifiers when multiple developers work from the same project and independently run /specify.

Origin & Context

• Raised by: GitHub user harishiyer007
• Trigger: A reported collision risk when multiple developers check out a shared project and independently create specs; the issue author reports having a local implementation.

First-Glance Unknowns

• [NEEDS CLARIFICATION: Should the identifier prefix be configured manually, inferred from the developer identity, or selected by each developer at initialization?]
• [NEEDS CLARIFICATION: Is uniqueness required only among concurrently created local specs, or must identifiers remain unique after branches are merged and across renamed or replaced developers?]
• [NEEDS CLARIFICATION: What exact identifier format and migration behavior are required for existing numeric specs?]
• [NEEDS CLARIFICATION: Which workflows, templates, scripts, integrations, and documentation consume or parse the current numeric feature directory/name format?]
• [NEEDS CLARIFICATION: What should happen when two developers have the same initials or when a developer changes identity?]
• [NEEDS CLARIFICATION: What acceptance criteria and evidence demonstrate that the collision problem is resolved without breaking existing projects?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4418 · 375 AIC · ⊞ 30.4K · ◷

[github-actions]

Feature assessment — shared-spec-project · Stage 2/5: Research

Idea Research: Multi-developer shared Spec Kit project

• Slug: shared-spec-project
• Created: 2026-09-03T11:37:40Z
• Evidence confidence (overall): low

Users & Demand

• One issue author reports a collision risk when multiple developers check out the same project and independently run /specify; the requested outcome is unique, traceable spec identifiers — [source: GitHub issue [Feature]: Support for multi-developer work on a shared speckit project #4418] (confidence: low, cited)
• The request is a single stated demand. The issue has no use cases, acceptance criteria, reactions, or comments adding corroborating stakeholder signal — [source: GitHub issue [Feature]: Support for multi-developer work on a shared speckit project #4418] (confidence: high, cited)
• The author reports having a local implementation and offers to provide it, but no patch, measurements, or reproduction are included in the issue — [source: GitHub issue [Feature]: Support for multi-developer work on a shared speckit project #4418] (confidence: high, cited)
• [NEEDS CLARIFICATION: How often does the collision occur, how many developers/projects are affected, and what damage results when duplicate spec directories are created?] (confidence: low, assumption about missing demand data)

Prior Art

• The core /specify workflow currently defaults to sequential feature numbering: it reads feature_numbering, uses the next NNN after scanning existing directories in specs/, and constructs <prefix>-<short-name> — [source: templates/commands/specify.md, lines 80-106] (confidence: high, cited)
• The bundled Bash, Python, and PowerShell create-new-feature implementations calculate the highest numeric prefix from local specs/ directories and add one. Their directory scan does not coordinate with other checkouts — [source: scripts/bash/create-new-feature.sh, lines 111-145 and 277-315; scripts/python/create_new_feature.py, lines 198-250 and 297-340; scripts/powershell/create-new-feature.ps1, lines 53-84 and 199-245] (confidence: high, cited)
• The three core script variants have parity tests for sequential numbering and conflict correction, including a test that local directories such as 001-first and 0005-fourdigit determine the next number — [source: tests/test_create_new_feature_python_parity.py, lines 151-162] (confidence: high, cited)
• The optional Git extension already supports configurable branch namespaces using {author}, {app}, {number}, and {slug}, and can inspect local/remote branch refs for branch numbering. This is branch naming behavior, not a guarantee that the independently created spec directories are unique; the Specify template explicitly keeps branch and spec-directory naming separate — [source: extensions/git/README.md, lines 48-85; extensions/git/commands/speckit.git.feature.md, lines 29-49; templates/commands/specify.md, lines 74-111] (confidence: high, cited)
• Local history records an earlier fix for conflicting feature prefixes (bfe4772b, “fix: auto-correct conflicting feature prefixes”), showing that numeric-prefix collisions are an existing concern, but the available commit history does not establish whether it addressed concurrent checkout coordination — [source: local git history, commit bfe4772b] (confidence: medium, cited)

Market & Context

• Today, a developer can avoid some collisions by using timestamp numbering, an explicit number, or a configured branch namespace; these are documented alternatives in the core and Git extension command definitions — [source: templates/commands/specify.md, lines 86-92; extensions/git/README.md, lines 50-85] (confidence: high, cited)
• Local sequential scanning is deterministic for the same checkout state. Two developers whose checkouts do not yet contain each other's new spec directories can both compute the same next number; the issue's collision scenario is consistent with that behavior — [source: scripts/bash/create-new-feature.sh, lines 116-133; scripts/python/create_new_feature.py, lines 198-213] (confidence: medium, cited)
• [NEEDS CLARIFICATION: Whether the desired organization is specifically developer-prefixed spec directories, or whether timestamp/namespace-based identifiers would adequately address the operational problem.] (confidence: low, assumption about alternatives)

Data & Constraints

• The current default identifier is a three-digit-or-greater numeric prefix, while timestamp mode uses YYYYMMDD-HHMMSS; changing the identifier shape may affect scripts, branch validation, downstream path resolution, documentation, and integrations that recognize numeric prefixes — [source: templates/commands/specify.md, lines 86-92; scripts/bash/create-new-feature.sh, lines 120-128; extensions/git/commands/speckit.git.feature.md, lines 17-22] (confidence: high, cited)
• The core scripts are maintained as Bash, Python, and PowerShell variants with explicit parity tests, so a numbering change would need equivalent behavior across all supported script types — [source: tests/test_create_new_feature_python_parity.py, lines 112-162; scripts/bash/create-new-feature.sh; scripts/python/create_new_feature.py; scripts/powershell/create-new-feature.ps1] (confidence: high, cited)
• The Git extension has a 244-byte branch-name limit and configurable templates; a developer prefix would consume identifier/branch-name space and would need defined sanitization and collision behavior — [source: extensions/git/scripts/bash/create-new-feature-branch.sh, lines 153-167; extensions/git/README.md, lines 56-85] (confidence: high, cited)
• [NEEDS CLARIFICATION: Whether identifiers must be unique after branches merge, across remote repositories, and across all Spec Kit integrations, or only need to reduce local concurrent creation collisions.] (confidence: low, assumption about missing scope)
• [NEEDS CLARIFICATION: How prefixes are chosen and validated, including duplicate initials, non-name identities, identity changes, and privacy expectations.] (confidence: low, assumption about missing policy)

Evidence Against the Idea

• The issue provides no quantified impact, acceptance criteria, use cases, or corroborating user signal beyond one report, so the value of changing a cross-cutting identifier contract cannot yet be compared with its compatibility cost — [source: GitHub issue [Feature]: Support for multi-developer work on a shared speckit project #4418] (confidence: high, cited)
• Developer initials are not inherently unique; two developers can share initials, and automatically deriving initials can be ambiguous or unstable. A prefix-only scheme may therefore reduce but not eliminate collisions — [source: GitHub issue [Feature]: Support for multi-developer work on a shared speckit project #4418; identity ambiguity is an unverified risk] (confidence: medium, cited plus risk analysis)
• The project already documents timestamp numbering and namespace templates as alternatives. If those satisfy the real need, adding a new identifier contract may duplicate existing mechanisms and create migration burden — [source: templates/commands/specify.md, lines 86-92; extensions/git/README.md, lines 50-85] (confidence: medium, cited)
• The change would cross multiple format-specific scripts and consumers. Without a defined compatibility/migration policy, existing specs and tools may become harder to locate or parse — [source: tests/test_create_new_feature_python_parity.py, lines 151-162; extensions/git/commands/speckit.git.feature.md, lines 65-83] (confidence: high, cited)

Gaps & Open Questions

• [NEEDS CLARIFICATION: Provide the author's local implementation or a minimal reproduction showing the duplicate-directory scenario.]
• [NEEDS CLARIFICATION: Quantify affected projects/developers and the cost of duplicate identifiers.]
• [NEEDS CLARIFICATION: Define whether the requirement is uniqueness, human traceability, or both.]
• [NEEDS CLARIFICATION: Decide whether existing timestamp and branch namespace options are insufficient, and why.]
• [NEEDS CLARIFICATION: Define prefix source, format, uniqueness guarantees, and behavior for duplicate initials.]
• [NEEDS CLARIFICATION: Define backward compatibility for existing numeric specs and consumers.]
• [NEEDS CLARIFICATION: Define whether all script variants and integrations must emit identical prefixed identifiers.]

Sources

• GitHub issue [Feature]: Support for multi-developer work on a shared speckit project #4418 (host: github.com, policy: allowlisted; read via GitHub issue tool)
• templates/commands/specify.md (repository source)
• scripts/bash/create-new-feature.sh (repository source)
• scripts/python/create_new_feature.py (repository source)
• scripts/powershell/create-new-feature.ps1 (repository source)
• extensions/git/README.md (repository source)
• extensions/git/commands/speckit.git.feature.md (repository source)
• tests/test_create_new_feature_python_parity.py (repository source)
• Local git commit bfe4772b (repository history)

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4418 · 375 AIC · ⊞ 30.4K · ◷

[github-actions]

Feature assessment — shared-spec-project · Stage 3/5: Problem

Problem Definition: Multi-developer shared Spec Kit project

• Slug: shared-spec-project
• Created: 2026-09-03T11:37:40Z
• Inputs used: intake.md and research.md

Problem Statement

Developers working in parallel from separate checkouts of one Spec Kit project can receive the same next sequential spec identifier because each checkout sees the same existing specs/ state. When those changes are later shared or merged, duplicate identifiers can make specifications harder to distinguish and may create ambiguity for people and tools that refer to a spec by its directory or number.

Affected Users & Stakeholders

• Users: Developers collaborating on multiple specifications in a shared project — the issue author reports that independent checkouts can select the same next number.
• Users: People reviewing, discussing, or implementing specifications — [NEEDS CLARIFICATION: confirm whether duplicate identifiers have caused concrete review, implementation, or merge confusion].
• Stakeholders: Spec Kit maintainers — [NEEDS CLARIFICATION: confirm ownership of the identifier format and compatibility expectations].
• Stakeholders: Project teams and tooling that consume spec paths or feature identifiers — [NEEDS CLARIFICATION: identify affected integrations and downstream consumers].

Goals

• Make independently created specifications distinguishable when their changes are brought together.
• Preserve reliable navigation and reference to a specification throughout the existing Spec Kit workflow.
• Keep the identifier behavior understandable and consistent for teams using supported operating systems and script variants.
• Reduce or eliminate the reported duplicate-identifier scenario without requiring manual renaming after collaboration begins.

Non-Goals

• Selecting a particular identifier format, prefix source, or identity-management policy; those are solution decisions for the shaping stage.
• Redesigning Git branch naming, branch templates, or remote synchronization behavior except where the actual problem requires a clearly defined relationship.
• Defining implementation details such as file layouts, APIs, parsing algorithms, or command internals.
• Migrating or renaming existing specifications before compatibility requirements and scope are confirmed.
• Guaranteeing uniqueness across unrelated projects or repositories unless that requirement is explicitly established.

Success Metrics

• Distinctness: In a documented multi-developer creation scenario, 100% of specifications created independently and then combined have distinguishable identifiers (baseline: unknown; current issue reports possible duplicates).
• Reference continuity: Existing specifications remain locatable and unambiguous after the new behavior is adopted (baseline: unknown; compatibility inventory not provided).
• Workflow consistency: The same supported Spec Kit workflow produces equivalent identifier semantics across supported platforms and script variants (baseline: current variants are parity-tested for sequential numbering; target behavior not yet defined).
• Reduced manual recovery: Teams report no manual identifier renaming is needed for the tested parallel-creation scenario (baseline: unknown).

Cost of Inaction

Separate developers can continue selecting the same next sequential number from equivalent checkout state. Once their work is combined, duplicate spec directories or references may require manual renaming, complicate review and implementation discussions, and make automated path-based workflows ambiguous. The frequency and severity of this cost are not quantified in the issue.

Open Questions

• [NEEDS CLARIFICATION: Is the primary success condition globally unique identifiers, human-readable ownership/traceability, or both?]
• [NEEDS CLARIFICATION: Must uniqueness hold only after branches merge, or also across remote branches, forks, and long-lived parallel work?]
• [NEEDS CLARIFICATION: What evidence or reproduction should define the baseline collision scenario?]
• [NEEDS CLARIFICATION: Which existing specs, scripts, integrations, and external tools must remain compatible with current numeric identifiers?]
• [NEEDS CLARIFICATION: Should existing timestamp numbering or branch namespace configuration be considered sufficient for the underlying problem?]
• [NEEDS CLARIFICATION: What identity and privacy rules apply if a developer-specific prefix is used?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4418 · 375 AIC · ⊞ 30.4K · ◷

[github-actions]

Feature assessment — shared-spec-project · Stage 4/5: Concept

Concept: Multi-developer shared Spec Kit project

• Slug: shared-spec-project
• Created: 2026-09-03T11:37:40Z
• Recommended option: Option A — opt-in contributor namespace

Options

Option A — Opt-in contributor namespace

• Sketch: Let a project or contributor use a stable, human-readable namespace alongside the existing per-namespace sequence, so specifications created in parallel are distinguishable while retaining a compact numeric component. Existing projects continue using their current identifiers unless they opt in.
• Appetite: medium
• Trade-offs: This is closest to the request and preserves human traceability and sequential readability. It does not guarantee uniqueness if namespaces are duplicated or changed, and it adds configuration, identity, compatibility, and cross-platform behavior that must be defined.
• Rabbit holes: Automatic identity discovery, duplicate initials, privacy-sensitive names, migration of existing directories, interactions between spec paths and Git branches, and keeping Bash/Python/PowerShell outputs and integrations aligned.

Option B — Coordination-free unique identifier

• Sketch: Replace or supplement the shared sequential component with an identifier designed to remain distinct when created independently, such as a time- or randomness-based value, while retaining an optional human-readable title for navigation.
• Appetite: medium
• Trade-offs: This addresses the concurrency failure mode without requiring shared coordination and can provide stronger uniqueness than initials. It sacrifices the simplicity and predictable ordering of 001, 002, and similar identifiers, and may make references less readable.
• Rabbit holes: Choosing a stable format, collision guarantees, clock/randomness assumptions, sorting expectations, migration, branch-name limits, and consumers that parse numeric prefixes.

Option C — Use existing alternatives; add no new identifier behavior

• Sketch: Keep the current sequential default and direct teams to the already available timestamp numbering, explicit numbering, or branch namespace configuration for parallel work where needed.
• Appetite: small
• Trade-offs: Lowest compatibility and maintenance cost, and it is immediately available. It leaves the default collision scenario unchanged and may require each team to discover and consistently configure a workaround.
• Rabbit holes: Determining whether existing options actually affect spec directory creation in the desired workflow, documenting a reliable team practice, and handling teams that do not configure the workaround.

Recommendation

Recommend Option A as the best concept to investigate because it directly addresses the reported need for human-distinguishable identifiers while preserving the current sequential model for projects that do not opt in. Its medium appetite reflects the cross-platform scripts and path consumers identified in research. This recommendation is provisional: the low evidence confidence and unresolved uniqueness requirements mean the decision stage should not treat it as ready for specification until the collision scenario, required guarantee, and identity policy are clarified.

Out of Scope (for the recommended option)

• Changing the default identifier behavior for existing projects.
• Mandating that a contributor's legal name, Git identity, or other personal information appear in a spec identifier.
• Solving global uniqueness across unrelated projects or repositories.
• Redesigning Git branch naming or remote synchronization as a separate feature.
• Renaming existing specs or defining migration mechanics before compatibility requirements are confirmed.
• Detailed configuration schema, command flags, algorithms, file formats, or implementation tasks.

Assumptions to Validate

• A stable, project-recognizable contributor namespace is more valuable to the requesting teams than an opaque globally unique identifier.
• Teams can choose or receive namespaces without creating duplicate namespaces or exposing unwanted personal information.
• Existing numeric specifications can remain valid and discoverable while the new behavior is opt-in.
• The underlying requirement applies to spec identifiers/directories, not only to Git branch names.
• All supported core script variants and relevant integrations must present equivalent identifier semantics.
• Existing timestamp and branch namespace alternatives do not sufficiently solve the reported workflow, or teams need a safer default/experience.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4418 · 375 AIC · ⊞ 30.4K · ◷

[github-actions]

Feature assessment — shared-spec-project · Stage 5/5: Decision — verdict needs-clarification

Decision: Multi-developer shared Spec Kit project

• Slug: shared-spec-project
• Decided: 2026-09-03T11:37:40Z
• Verdict: needs-clarification
• Artifacts reviewed: intake.md | research.md | problem.md | concept.md

Scorecard

Criterion	Rating	Justification
Problem validity	adequate	The issue describes a plausible collision scenario, and repository scripts confirm that sequential identifiers are derived from local checkout state; concrete downstream harm is not demonstrated.
Evidence strength	weak	Evidence consists of one issue report and repository behavior. There is no reproduction, quantified impact, acceptance criteria, or corroborating user signal.
Value vs. inaction	unknown	Duplicate identifiers could create review and path-reference ambiguity, but the frequency, severity, and cost of manual recovery are unmeasured.
Feasibility / appetite	adequate	The shaped options identify credible small-to-medium approaches, but identity handling, compatibility, and uniqueness guarantees remain unresolved.
Strategic fit	unknown	The request concerns Spec Kit's core specification workflow, but no project constitution or explicit product priority was available to assess strategic alignment.
Risk posture	weak	The major risks are visible but not mitigated: initials may collide, identity may be unstable or privacy-sensitive, and numeric-prefix consumers may require compatibility or migration handling.

Verdict & Rationale

Needs clarification. The problem is plausible and the repository confirms the reported local-sequential behavior, but the evidence-strength gate is weak and the value of changing a cross-cutting identifier contract is unquantified. The proposed contributor namespace is a reasonable concept, yet it cannot be approved for specification until the request establishes the required uniqueness guarantee, supplies a reproducible scenario and impact signal, and resolves whether existing timestamp or namespace options are sufficient. This is a parking decision, not a rejection of the underlying problem.

If needs-clarification

• Blocking questions:
  • [NEEDS CLARIFICATION: Provide a minimal reproduction or the reported local implementation showing how two independently created specs collide, and state whether the collision occurs in spec directories, Git branches, or both.]
  • [NEEDS CLARIFICATION: Quantify the affected teams/projects, frequency of the collision, and the concrete cost when duplicate identifiers are merged.]
  • [NEEDS CLARIFICATION: Define the required guarantee: human-readable contributor traceability, uniqueness after merge, uniqueness across remote branches/forks, or a combination.]
  • [NEEDS CLARIFICATION: Define how a contributor namespace is selected and kept unique when initials collide, identities change, or users do not want personal names exposed.]
  • [NEEDS CLARIFICATION: Identify existing scripts, integrations, and external consumers that must remain compatible, and explain why timestamp numbering or existing branch namespace configuration does not solve the need.]
    +- Revisit stage: research (then shape if the clarified guarantee or alternatives change the recommended concept)

If go — Handoff to __SPECKIT_COMMAND_SPECIFY__

Not applicable while the verdict is needs-clarification.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4418 · 375 AIC · ⊞ 30.4K · ◷

[mnriem]

Thanks for raising this. This workflow is already supported through the existing overrides:

export SPECIFY_FEATURE_DIRECTORY="specs/jd-001-user-auth"
export GIT_BRANCH_NAME="jd-001-user-auth"

These values are used as provided, and the feature directory is persisted for downstream commands. Since this addresses the described scenario without code changes, we’re closing this as already supported.