Support numbered change names (NNNNN-slug) for sequencing

[pankajudhas81]

Problem

When creating many change proposals over time, there is no way to tell which came first and which came later. The directory listing is alphabetical (add-auth, fix-bug, refactor-db) with no chronological ordering.

validateChangeName() in change-utils.js currently enforces strict kebab-case starting with a lowercase letter:

const kebabCasePattern = /^[a-z][a-z0-9]*(-[a-z0-9]+)*$/;

This rejects any digit-prefixed name like 00001-add-auth, making it impossible for wrapper tools (like pi-openspec) to add sequential numbering.

Proposal

Relax validateChangeName() to allow digit-prefixed names so that tooling can prepend a sequence number for chronological ordering. Something like:

00001-add-auth
00002-fix-bug
00003-refactor-db

Or ideally, openspec new change could support a --number / --auto-number flag that scans existing changes and auto-assigns the next sequence number.

Suggested format

NNNNN-slug (e.g., 00001-add-auth) — zero-padded 5-digit prefix + kebab-case slug. This:

• Sorts naturally in directory listings (ls, find, file explorers)
• Makes it immediately obvious which proposals are older/newer
• Scales to 99,999 changes per project (more than enough)
• Does not break any existing plain kebab-case names (backward compatible)

Minimal fix

Change the validation regex to also accept digit-prefixed names:

// Current: must start with letter
const kebabCasePattern = /^[a-z][a-z0-9]*(-[a-z0-9]+)*$/;

// Proposed: allow digit prefix (e.g., 00001-add-auth)
const kebabCasePattern = /^[a-z0-9][a-z0-9]*(-[a-z0-9]+)*$/;

This is backward compatible — all existing valid names remain valid.

Context

I am using OpenSpec with the pi coding agent (pi-openspec extension). The extension wraps /openspec new and tries to auto-number changes, but the CLI rejects the numbered names. Currently I have 3+ changes in a project and cannot tell their order without checking filesystem timestamps.

Environment

• @fission-ai/openspec@1.4.1
• macOS

[TabishB]

This ends up breaking for anyone using it in a team or even when creating changes in parallel in worktree. I agree some form of roadmapping / dependency management is needed though.

[pankajudhas81]

This ends up breaking for anyone using it in a team or even when creating changes in parallel in worktree. I agree some form of roadmapping / dependency management is needed though.

maybe with NNNNN-<Timestamp readable>-<name>/