Skills are organized by function — users navigate by workflow position

I'm a non-technical founder using gstack to build a legal tech product. I want to share an observation that I think limits the tool's reach beyond developers who already have strong software workflow intuition.

The skills list is organized by what each skill does. /qa tests a web app. /ship creates a PR. /plan-eng-review reviews architecture. That makes sense from a tooling perspective.

**The problem**: if you don't already have a mental model of the software development lifecycle, the list is noise. You don't know that /office-hours comes before /plan-eng-review, which comes before /ship, which comes before /qa. You don't know what stage you're in, so you don't know which tool to reach for. You either under-use gstack or misuse it by reaching for the wrong skill at the wrong moment.

I ran into this directly. I've been building with gstack for several weeks and still don't have confident intuition about the sequence. I use the skills I happened to discover. I probably miss the ones that would actually help at a given moment.

I noticed the same structural problem in the legal tech product I'm building. Attorneys don't think in terms of tools — they think in terms of workflow stages. "I'm in discovery, specifically deposition preparation. What do I do next?" The skill is something you reach for within a stage you already understand. Organizing by skill name first, stage second, is an engineer's taxonomy. Attorneys don't navigate that way and neither do most non-technical users.

**The gap**: there's no "you are here" orientation layer. /autoplan sequences some reviews, but it assumes you're already at the right starting point. There's nothing that asks "what are you trying to accomplish?" and answers with a sequence: you're in the design phase, here's what to run first and why.

**A possible direction**: a /workflow or /where-am-i skill that orients the user to their current development stage and presents the applicable skills in sequence rather than as a flat menu. Stage-first, skill-second. The same way a good attorney tool should present "you are in discovery → depositions → preparation, here are the three things you do now" rather than a list of 40 skill names.

The insight isn't original to me — it's just visible from outside the developer mental model. Someone who has built software for 20 years can't see this gap because they can't remember not having the workflow intuition. I can see it because I don't have it yet.

Happy to elaborate if useful.

Start by reviewing the existing skill entry points named in the issue: /office-hours, /plan-eng-review, /ship, /qa, and /autoplan, and map their intended workflow stages. Define a stage-first orientation flow that tells users where they are, which skills apply next, and why; done means the sequence is understandable without prior software-workflow intuition.

Written by the indexing model from the issue text.