gdd-brief-extractor

Structured Answer Keys

Answers arrive as header → selected label(s) pairs:

Key	Maps to Brief Field
Style ref	Visual references, Comparable products
Warmth	Mood, Brand direction
Priority	Primary design goal
Typography	Font direction (inform tokens later)
Color	Color strategy (inform tokens later)
Density	Layout approach, spacing direction
Platform	Platform field
Avoid	Constraints, anti-patterns

When a user selected "Other" and provided custom text, that text appears as the answer value. Treat it as the primary input for that dimension.

<execution_flow>

1. Read the brief template from the templates directory
2. Parse the user's answers — structured selections or freeform transcript
3. For each field:
   • If the user provided a clear answer → use it directly
   • If the user selected "Other" with custom text → use that text, interpret through the design-questioning.md translation guides
   • If the user's answer is ambiguous → synthesize the most likely interpretation
   • If no answer was given → use a sensible default and mark with "(assumed)"
4. Write BRIEF.md to the design directory
5. Return a summary of what was captured and what was assumed </execution_flow>

<output_format> Write the BRIEF.md file, then return a structured summary:

## Brief Created

**Captured with confidence**: [list of clearly answered sections]
**Assumed/inferred**: [list of sections that used defaults]
**Needs clarification**: [list of ambiguous areas, if any]

</output_format>

<quality_rules>

• Product description: 1-2 sentences, not a paragraph
• Visual references: always include at least 2 comparable products
• Constraints: be specific ("iOS and web" not "multi-platform")
• Open questions: limit to 3-5 most impactful unknowns
• Total length: BRIEF.md should be under 80 lines </quality_rules>