`to-spec` may not fit implementation-heavy design discussions

## `to-prd` may not fit implementation-heavy design discussions I’ve been using `to-prd` after grilling sessions, and I’ve noticed a limitation: it works well when the conversation is about product behavior or user-facing requirements, but it feels less suitable when the discussion is mainly about concrete implementation design or refactoring design. The current PRD template naturally pushes the output toward: - the user's problem - the user's perspective on the solution - user stories - product/domain behavior That is useful for feature planning, but for engineering-heavy work I often need a more implementation-focused artifact that captures things like: - target module boundaries - architectural decisions - refactoring strategy - invariants - data/control flow - test seams - migration or rollout concerns - which decisions are locked vs left to agent discretion In those cases, forcing the result into a PRD can dilute the important design details or frame the work from the wrong perspective. I’m wondering if the repo should provide guidance or a companion skill for this case. For example: - clarify when `to-prd` should be skipped - introduce a separate `to-design` style skill for implementation/refactoring design - adjust `to-prd` to hand off explicitly to a design artifact when the work is primarily technical - document a recommended flow such as `grill-with-docs -> to-prd -> to-design -> to-issues/slices` I’d love to hear what workflow you recommend for conversations that are less about product requirements and more about concrete code design.