A bit strange that the new /design-an-api doesn't slot into plan-a-feature pipeline

[taminomara]

My normal workflow almost always starts with either plan-a-feature or investigate, and design-an-api would be a good step to place somewhere after plan-implementation; in fact, I usually ask Claude to make a full API spec as a supplement to feature/implementation plan. Maybe we can add a better integration point here? This can potentially solve #107.

[mxriverlynn]

yeah, i went back and forth on where to put this. in the end, i decided it was more appropriate for the han-code plugin since it really isn't meant to be a full "plan", and more of an API design that might fit into a plan.

but i'm also not convinced that it's currently living in the right place. maybe it should be in the han-planning plugin?

i did recently add a /plan-a-change skill to the planning plugin, as part of the v5.5.0-beta branch (#205) and i've been using it a lot, for exactly what #107 was talking about. maybe the distinction between planning vs design makes more sense, with that new skill?

[taminomara]

Yes. If I had to summarize my experience with han planning so far, it's this: a wall of text, not enough visuals, examples, API structures, etc. Yes, plan-a-feature feels more like a design work, not a full feature planning: it deliberately skimps on implementation details, making it harder to conceptualize the actual diff.

So, maybe we should rename plan-a-feature -> design-a-feature, plan-a-change -> plan-a-feature?

Note, I didn't try plan-a-change yet, so not sure if it closes all my issues with plan-a-feature.