Prompt Anatomy

# Prompt Anatomy

Mandatory component checklist and fallback patterns for every generated prompt. Read this file during Phase 3B to ensure no critical component is missing.

---

## Component Checklist

Every generated prompt must include these components. Check each off before delivery. If the user opted out of a component in Phase 2, skip it — but note the omission in the Creation Report.

| # | Component | Required For | Purpose | Skip When |
|---|-----------|-------------|---------|-----------|
| 1 | **Role / Persona** | All except image-gen | Establishes expertise level, tone, and perspective | Image-gen prompts (no persona) |
| 2 | **Task Description** | All | What the model should produce — the core instruction | Never skip |
| 3 | **Constraints** | All | Boundaries, rules, what NOT to do | User explicitly says "no constraints" |
| 4 | **Output Format** | All except creative-writing | Shape of the response (JSON, Markdown, sections, etc.) | Creative writing where over-constraining hurts |
| 5 | **Fallback Instructions** | All except image-gen | What to do when input is ambiguous, data is missing, or task cannot be completed | Image-gen (single-shot, no error path) |
| 6 | **Expected Output** | Complex tasks, data extraction, coding | A sample or description of what correct output looks like | Simple tasks where format is obvious |
| 7 | **Task Roadmap** | Moderate and complex tasks | Numbered steps or phases the model should follow | Simple single-step tasks |
| 8 | **Success Criteria** | All except creative-writing, image-gen | How to know the output is done and correct | Tasks with subjective quality |

### How to apply each component

**Role / Persona:**
- Be specific: "Senior backend engineer with 10 years of Go experience" beats "helpful assistant"
- Match the domain: financial analyst for stock research, security researcher for pen testing
- For Claude: place in `<role>` tags or system prompt. For GPT: use `# Role` header

**Task Description:**
- Lead with the deliverable: "Produce a report", "Generate a function", "Extract fields"
- State scope explicitly: what's in, what's out
- For complex tasks: summarize the task in 1-2 sentences, then detail in the roadmap

**Constraints:**
- Format as a bulleted list for scannability
- Include both positive constraints ("always use TypeScript") and negative ("do not use deprecated APIs")
- Be specific: "under 500 words" beats "be concise"

**Output Format:**
- For structured data: provide the exact schema with field names, types, and descriptions
- For prose: specify section headers, tone, and length targets
- For code: specify language, style, whether to include comments/tests

**Fallback Instructions:**
- See the Fallback Patterns section below for domain-specific templates
- Always address: missing input, ambiguous requirements, conflicting instructions, knowledge gaps

**Expected Output:**
- Even a partial example anchors the model's format, depth, and style
- For data extraction: show one complete input→output pair
- For analysis: show a sample section with the expected depth and format
- For code: show the function signature and a usage example

**Task Roadmap:**
- Number the steps: "Step 1: Gather data. Step 2: Analyze. Step 3: Synthesize."
- For each step: state the input, action, and expected output
- Include decision points: "If X, proceed to Step 3a. Otherwise, Step 3b."
- For very complex tasks: group steps into phases

**Success Criteria:**
- Define "done": "The report is complete when all 8 sections are filled"
- Define "correct": "All JSON must validate against the provided schema"
- Define "quality floor": "Each section should be at least 200 words"

---

## Fallback Patterns by Domain

Use these templates when generating fallback instructions. Adapt the wording to fit the prompt's tone and the target model's style.

### Coding