to-design — PRD to Design Document

Turn a PRD (or a rough idea) into a design document written in the style of Go's official design proposals: plain language, concrete examples, and—above all—an honest account of why this approach and not the alternatives.

This is not the same as prd-to-spec. A SPEC is an implementation contract (tables, endpoints, schemas) for an engineer to build against. A design document is a decision artifact: it argues for an approach, surfaces the tradeoffs, and lets a team agree on the same facts before anyone writes code. When the question is "how should we build this and why", produce a design doc; when the question is "give me the exact contract to implement", produce a SPEC.

设计哲学源自对 5 篇 Go 官方 proposal（泛型 / 错误包装 / loopvar / slog / try）的分析。核心信念：文档的价值不取决于方案是否通过，而取决于它是否让讨论建立在同一套事实和取舍之上。

When to Use

• A PRD exists and you need to decide how to build it before committing to implementation
• The approach has real tradeoffs and you want them documented and debated
• The change is risky, breaking, or hard to reverse (a design doc forces the compatibility conversation early)
• Multiple people need to agree on a direction before work fans out
• You want a durable record of "why we chose X and rejected Y" — even if the proposal is later rejected

If the team just needs the concrete contract to code against, use /prd-to-spec instead (or run to-design first, then prd-to-spec).