spec-constellation-to-prompt-suite

I. The Philosophy

When you move from one specification to one implementation prompt, you're writing a focused brief. But when you move from four interconnected specifications to four parallel implementation prompts, you're solving a coordination problem.

The danger: each prompt looks coherent in isolation, but the tracks execute independently. Track B (Go backend) produces the API that Track C (frontend) consumes—but if the two prompts define the contract differently, integration fails. Track A (scaffold) defines design tokens that Track D (dock + home) must use—but inconsistent naming breaks everything. Type definitions (DojoEntity, PipelineContent) must be identical across tracks, not compatible or "close enough."

This skill exists because:

• Writing N prompts from N specs is not N repetitions of "write one prompt"
• The coordination happens at the integration boundaries, not within prompts
• Shared types and contracts must be defined BEFORE prompts are written
• Cross-validation is the difference between "tracks that exist" and "tracks that integrate"

II. When to Use This Skill