Question about GSD-2 commit message conventions

[kaichenzhu]

Hi, I noticed an inconsistency in commit message style and wanted to understand the intended convention.

In the repository history, many commits follow a standard Conventional Commits style such as:

• feat: xxx
• fix: xxx

However, when using the GSD-2 workflow/tools, the generated commits seem to follow a different format, for example:

• feat(S01/T02): Add xxx
• test(S03/T01): Verified xxxx

I am curious about the reasoning behind this difference.

From my perspective, the tool-generated format seems to encode milestone/task traceability directly into the commit scope, which is useful for mapping implementation back to structured work units. At the same time, it also introduces a project-specific convention on top of standard Conventional Commits.

I would love to understand:

1. Is the Sxx/Txx scope format the recommended long-term commit convention when developing with GSD-2?

2. Is the intention that human-authored commits and tool-generated commits may follow different styles, or should they eventually converge?

3. How should users think about this tradeoff between:

• standard ecosystem compatibility (feat:, fix: etc.),
• and stronger task-level traceability (feat(S01/T02): ...)?

4. For release tooling, changelog generation, and semantic versioning, is the scoped Sxx/Txx style considered the preferred path?
5. Would it make sense to document this explicitly as a recommended pattern, so users know whether this is just a tool artifact or an intentional workflow design?

I am asking mainly because I am evaluating how to structure commit history in a repo that uses GSD-2 heavily, and I want to understand whether I should align human commits with the tool-generated style.

Thanks — I think the traceability aspect is interesting, and I’d like to understand the design choice more clearly.

[ayushcmd]

Good catch, I think this difference comes from the tool focusing more on traceability.

The feat(S01/T02) style seems to include task or milestone info directly in the commit, which helps link changes to specific work items. That’s useful for tracking, but it also adds a custom layer on top of standard Conventional Commits.

In practice, it’s probably best to stay consistent. Either follow the tool’s format across all commits, or stick to standard feat/fix if you rely heavily on ecosystem tools like changelog generators.

So it looks more like a design choice for better internal tracking, but it would definitely help if it’s clearly documented for contributors.

[trek-e]

Correct — when GSD-2 drives a commit during auto-mode execution, it tags the slice/task context in the scope for traceability. When you're committing manually or contributing to the repo itself, standard Conventional Commits without the slice tag is right. The two styles coexist intentionally: auto-generated commits carry the GSD task context, human commits don't.