Change commands for more order

[stefanofalasca]

Improved Speckit Workflow

I've been using Speckit over the last few weeks, but I immediately noticed that the workflow wasn't optimized for my daily routine or the way I'm used to working with Claude Code.

I've made some modifications to the commands, and I can now say the experience is much better. I'd like to share these changes with you because I believe this workflow reflects how many other developers work, not just me.

Issues with the Original Workflow

When I started using Speckit, there were three things I didn't like:

1. Automatic Branching: It takes the initiative to create a branch based on its own rules.
2. Counter Reliability: The counter used to create branches and folders didn't always work correctly; several times I ended up with duplicate counters.
3. Folder Consistency: Occasionally, I noticed the specs folder being created in inconsistent locations.

Despite this, I think Speckit is an excellent tool, so I adapted it to a more standard developer approach.

---

The New Workflow

1. Branch Naming & Ownership

In my company, we use Azure DevOps. We link our working branches to specific Work Items and follow a strict naming convention.

• The Change: I now create the branch manually before starting. The tool must respect this branch and remain unchanged, whether you use Jira, Azure DevOps, or any other PM tool.

2. Categorization (Feature vs. Bug)

Inside the specs folder, a subfolder is now created to categorize the type of work. The structure follows this logic:

specs/
├── feature/
│   └── [branch-name]/
└── bugs/
    └── [branch-name]/

3. Iterative Session Management

Large tasks are difficult to complete in a single session. I break them down into multiple sessions, where each session becomes a new specification.

• Smart Incrementing: Every time I run speckit.specify, it finds the highest counter in the directory and increments it by one.
• AI-Suggested Naming: The subfolder name is suggested by the AI based on my input (e.g., speckit.specify @xxxx.md) and awaits my confirmation.

Example Structure:

specs/
└── feature/
    └── f-xxx-newfeature/
        ├── 001-getextradll-api-migration/
        ├── 002-validation-installation-code/
        └── 003-update-banks-database/

4. Monorepo & Multi-App Support

My repository contains several projects using different technologies.

• The Change: Instead of a single global folder, the specs folder is now created within the specific project folder I am working in. If an implementation requires changes across multiple projects, I simply move up a level in the directory tree, and it creates the folder in my current location.

5. Language Preservation

When running speckit.specify @xxx.md, all generated documentation now respects the original language of the input file.

• The Change: The tool automatically detects the language used in your input document and ensures that all generated specifications, comments, and documentation are written in the same language. This is particularly useful for international teams or projects where documentation needs to be maintained in a specific language.

---

Conclusion

Everything is much better organized now. Should we open a discussion to evaluate a PR? I've modified several commands to fit this workflow and I'd love to share them as I think they might benefit the wider community.