spec-constellation-to-prompt-suite

name	spec-constellation-to-prompt-suite
model	sonnet
description	Produces a suite of coordinated, self-contained implementation prompts and a master integration contract table from a set of interconnected specs. Use when 'convert specs to prompts', 'ready to commission these specs', or 'coordinate these parallel tracks into executable prompts'.
category	specification-driven-development
triggers	["convert specs to prompts","ready to commission these specs","coordinate these parallel tracks into executable prompts"]
tier	1
agents	["primary"]
tool_dependencies	["file_system"]
inputs	[{"name":"spec_files","type":"string[]","description":"Paths to interconnected specification files to convert into prompts","required":true}]
outputs	[{"name":"prompt_suite","type":"ref","format":"cas-ref","description":"Suite of coordinated, self-contained implementation prompts and master integration contract table"}]

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

• You have 2+ interconnected specifications covering different aspects of a release
• Prompts for different tracks must agree on APIs, types, exports, or design tokens
• You're moving from "specs documented" to "ready to commission parallel work"
• One track's output becomes another track's input (explicit handoff required)
• You need a master plan that ties implementation work together
• Risk: Tracks ship independently without realizing their contracts don't align

III. Prerequisites

• A master plan or release plan defining the release scope
• 2+ specifications covering different aspects of the release
• A parallel tracks decomposition (or the intent to create one)
• Codebase patterns extracted for grounding (handler patterns, response formats, type definitions)
• At least one existing codebase to extract patterns from

IV. The Workflow

Step 1: Map the Spec Constellation

List all specs that contribute to this release. For each spec, identify:

• Which aspects map to which track(s)
• Which other specs it depends on or feeds
• What decisions or scouts inform it

Create a matrix:

Spec	Contributes To	Dependencies	Key Decision
Entity Data Model	Track B, C, D	—