Spec Generator Skill

Turn a vague product idea — possibly supported by sketches, screenshots, notes, or other documents — into a clear, well-structured product specification document that a development team can act on.

This always produces a product spec. That covers customer-facing products, internal tools, and staff-facing systems — they're all products. Never produce a feature spec, API spec, or integration spec.

What "good" looks like

A good output spec should:

• Be concise but complete — no padding, no gaps
• Use plain language, not corporate jargon
• Be opinionated where needed (e.g. suggest a sensible default stack or behaviour) while flagging where the team still needs to decide
• Surface implicit assumptions and make them explicit
• Feel like it was written by a thoughtful senior PM or tech lead who has thought through the edges

Process