/specify-fasttrack or /specify-lite a new command targets spec and implementation specify->plan->implement.

[dhilipkumars]

For small features that don't require the full specify → plan → tasks → implement cycle.

Sometimes we want to add something tiny that doesn't warrant a full SDLC cycle, task tracking, or being broken into multiple phases.

This command/skill will first triage whether the feature qualifies for fast-tracking. The AI is encouraged to reason with the user if it believes the feature is too complex for fast-track.

• If the user confirms yes (fast-track): generates a spec with a fast-track annotation at the top. The user can then follow with /plan and /implement, bypassing /tasks. Other commands like /analyze or /tasks should ignore specs and plans annotated with fast-track.
• If the user confirms no (not fast-track): proceeds with the regular flow without any annotation.
  This avoids having people vibe-code small features directly, since vibe-coded features leave no spec as a record — which breaks the spec-DD style.

What are your thoughts?

Sample fast-track annotation that will go on top of spec and plan documents.

<!-- fast-track -->
# Spec: Add helper function for X
...

[dhilipkumars]

@mnriem @mbachorik would love to get your thoughts on this.

This could be a new command or we can think of improving existing specify MD to triage if a given spec can fit into fast track or regular track.

why can't this be an extension?

My Rational, This touches the core flow, and the automation will skip /Tasks or /Analyze command.

[mnriem]

Still would prefer it as an extension. Note that some agents will honor the automation while others will not. And because it short circuits the process how do you capture what it does? Does it have a spec? For Git users, is it on a branch?

[dhilipkumars]

yes it will have the same flow as in will create git branch and so on so that PRs / commits are made on a branch, it will produce a spec and tech plan. the main optimization here is by-passing Tasks and moves to implementation directly.

[mnriem]

Just want to call out that once presets lands you can override the default commands / templates without the need to introduce a new command (unless of course you want the /fast-track command to just take the spec, auto plan and immediately implement) Thoughts?

[dhilipkumars]

yes yes thats the idea spec->plan->implement. You are right Override template/command will be useful for this too.

[mbachorik]

I'll need to think about it - quick read lets me think it might be approached differently. based on this "This command/skill will first triage whether the feature qualifies for fast-tracking", I'm inclined to agree with @mnriem and have this as extension (I am working now on extension from the other end of SDLC - reverse engineering - and have a few 'triage' steps there too, which is more exploratory work than core specification flow)

[dhilipkumars]

okay perfect thanks @mnriem and @mbachorik for your input with this and this inflight i think i can think of having before-hooks to bypass commands based on special annotations and shape this as an extension. May be a good idea to get community feedback to begin with.

having to go through full set of steps for small features is often called out as a paint point from folks who have tried spec-kit in the past.

any other ideas you folks have to bring fast-track like approach as a core feature in the long-term? Do you think that's a problem to solve for speck-kit?

here are the non-negotiables in my mind for such a fast-track/quick-track flow.

1. It has to go through git branch (i should have called this out in the beginning)
2. It needs to produce a spec of record
3. It certainly needs to add a tech plan before execution.

[mbachorik]

"having to go through full set of steps for small features is often called out as a paint point from folks who have tried spec-kit in the past."

yeah, i got the same from my staff too. they way how i approach this is - use spec-kit to get to specification that i am satisfied with (±80%) and use spec-kit to implement it. then tune it to w/o spec-kit by adding/modifying smaller features. then re-sync specification (incl. tasks) and often, run verify. i use my prompt to sync the spec to code, but i believe we have extension for it now (have not had chance to try it yet - i am not a core developer for many years ..).

the sync of code to spec (and using spec-kit as the standard for spec-driven development) led me to idea to create reverse-engineering extension (similar problem as above, but much bigger scope) and given my early results, i think it might be viable approach. the goal is to 'reverse engineer to spec-kit and automatically re-implement in target tech stack' ...

coming back to your question - code will always diverge from spec, regardless it's written by humans or AI. the good thing is that spec-kit can provide way to sync it back to specification in structured way.