# General Image Creation Pipeline — Improvement Plan

**Purpose:** A project-agnostic framework for generating high-quality AI illustrations through a coordinated team. Applies to any visual creation work regardless of style, subject, or output format.

---

## 1. Team Roles & Pipeline Structure

### The Pipeline (Non-Negotiable Order)

```
Assaf (brief) → Kitt (frame & delegate) → Erica (coordinate) → Tatiana (create) + Anton (critique) → Erica (collect) → Kitt (final check) → Assaf (approve)
```

### Role Definitions

**Kitt — Strategic Framer**
- Translates Assaf's request into a structured creative brief
- Delegates to Erica. Never generates, prompts, or reviews style directly
- Final check: does the output serve the business goal?
- Owns the "what" and "why." Never the "how."

**Erica — Pipeline Coordinator**
- Routes briefs to Tatiana, results to Anton, revisions back to Tatiana
- Executes image generation commands on Tatiana's behalf (tool access)
- Manages Discord threads, version tracking, approval flow
- Never makes creative decisions. Facilitates and tracks.

**Tatiana — Creative Director**
- Analyzes reference material and style requirements
- Writes all prompts. Owns prompt engineering and iteration.
- Defines the visual direction for each piece
- Revises based on Anton's critique. Owns creative quality.

**Anton — Art Critic**
- Reviews every generated image against the project rubric (see §3)
- Scores on standardized criteria. Provides specific, actionable fixes.
- Binary verdict: APPROVED or REVISION NEEDED
- Never generates. Only critiques.

### Enforcement Rules
- Kitt cannot run `generate_image.py` or write image generation prompts
- Erica cannot generate without a Tatiana-authored prompt
- Nothing reaches Assaf without Anton's APPROVED verdict
- Pipeline violations get logged and reviewed

---

## 2. Creative Brief Template

Every image creation task starts with a brief. Kitt fills this out from Assaf's request:

```
PROJECT:        [project name]
DELIVERABLE:    [what's being created — slide illustration, social post, etc.]
QUANTITY:       [how many images]
DIMENSIONS:     [aspect ratio, resolution]
STYLE:          [reference artist/brand/mood — link to project style guide]
SUBJECT:        [what the image shows]
CONTEXT:        [where it will be used, what message it supports]
CONSTRAINTS:    [must-haves and must-avoids]
REFERENCES:     [paths to reference images]
DEADLINE:       [when it's needed]
```

---

## 3. Standardized Critique Rubric

Anton uses this for every review. Criteria adapt per project (see Per-Project Workflow), but the structure is constant.

```
CRITIQUE RUBRIC (1-10 each)

UNIVERSAL CRITERIA:
□ Composition & Layout     — visual hierarchy, balance, readability at target size
□ Color & Palette          — harmony, contrast, mood alignment
□ Subject Accuracy         — does it match the brief description?
□ Technical Quality        — artifacts, resolution, rendering quality
□ Style Consistency        — matches reference material and project style guide

PROJECT-SPECIFIC CRITERIA (defined per project):
□ [Criteria 1]             — [description]
□ [Criteria 2]             — [description]
□ [Criteria 3]             — [description]

OVERALL SCORE:    /80 (or /50 if no project-specific criteria)
VERDICT:          APPROVED (≥70%) / REVISION NEEDED (<70%)
SPECIFIC FIXES:   [numbered actionable list]
```

**Scoring thresholds:**
- ≥70% → APPROVED
- 50-69% → REVISION NEEDED (minor fixes, keep composition)
- <50% → REGENERATE (fundamental issues, start fresh)

---

## 4. Prompt Engineering Framework

### Prompt Structure (Universal)
Every prompt follows this skeleton, adapted per style:

```
[Medium/Format] + [Style Reference] + [Subject Description] + [Composition] + [Materials/Texture] + [Lighting] + [Background] + [Negative Constraints]
```

### Prompt Library Management
- Store proven prompt patterns in `skills/deck-illustrations/references/prompt-patterns.md`
- Organize by style category (not by project)
- Track what works AND what fails — both are valuable
- Tag patterns with the model/tool they were tested on (Gemini, DALL-E, Midjourney, etc.)

### Iteration Protocol
1. **First generation:** Full prompt from Tatiana's analysis
2. **Revision round:** Tatiana adjusts based on Anton's specific feedback
3. **Fine-tuning:** Minor prompt modifications for polish
4. **Max 5 iterations** before reassessing the approach entirely
5. If stuck after 5: Tatiana proposes a fundamentally different angle

---

## 5. Reference Image Management

### Structure (Per-Project — see Per-Project Workflow)
Each project gets its own reference library. The general system defines the structure:

```
projects/<project>/references/
├── style-guide.md          — written analysis of target style
├── reference-images/       — curated source images
│   ├── primary/            — the 2-3 key references that define the style
│   └── supplementary/      — additional context images
├── approved-outputs/       — images that passed Anton's review (become future refs)
└── prompt-log.md           — what prompts produced what results
```

### Reference Image Selection Criteria
- **Primary refs (2-3 max):** The closest examples to what we want. Used in every prompt.
- **Supplementary refs:** Show specific elements (color palette, texture, composition patterns)
- **Approved outputs:** Our own successful generations become references for consistency
- After the first 2-3 approved images, include the best one as a reference input alongside the original style refs

---

## 6. Thread & Version Discipline

### Discord Thread Protocol
- Every discrete task (one illustration, one slide) gets its own thread
- Thread naming: `🎨 [Project] — [Task Name]`
- All pipeline activity happens inside the thread — briefs, generations, critiques, approvals
- Never post Task A work in Task B's thread
- Thread status updates via thread name or pinned message

### Version Tracking
- Filenames: `YYYY-MM-DD-<project>-<task>-v<N>.png`
- Every generation gets posted to the thread with version number
- Anton's verdict tagged to specific version
- Approved version pinned or clearly marked

### Batch Processing Rules
- **Sequential first:** Approve 2-3 pieces to lock style baseline
- **Parallel after lock:** Once style is consistent, batch remaining tasks
- **Each batch task still gets its own thread**
- Erica manages concurrent threads, routes between Tatiana and Anton

---

## 7. Post-Processing Pipeline

For fixes that don't require full regeneration:

### Available Post-Processing
- **Background flattening** — remove gradients, clean to solid color
- **Color correction** — adjust palette to match reference
- **Upscaling** — enhance resolution for final delivery
- **Format conversion** — PNG, JPEG, WebP as needed
- **Compositing** — combine elements from multiple generations

### When to Post-Process vs. Regenerate
- **Post-process:** Background issues, color tweaks, minor cleanup
- **Regenerate:** Wrong subject, wrong composition, wrong style, anatomical problems

### Tools
- Pillow/numpy for background work (script at `/tmp/flatten_bg.py`)
- nano-banana-pro for regeneration
- Future: dedicated post-processing skill

---

## 8. Delivery & Integration

### For Pitch Decks (Google Slides)
- Upload approved images to Google Drive
- Place via Slides API with proper sizing
- Maintain slide-to-image mapping in project docs

### For Other Outputs
- Deliver to specified channel/location
- Include brief context: what it is, which brief it fulfills
- Archive approved finals in `projects/<project>/finals/`

---

## 9. Quality Metrics (Track Per Project)

| Metric | Target | How to Measure |
|--------|--------|----------------|
| First-pass approval rate | >40% | Approved on v1 / total tasks |
| Average iterations to approval | <3 | Total versions / total tasks |
| Pipeline violations | 0 | Logged bypasses |
| Style consistency score | >8/10 | Anton's average style score |
| Time per approved image | <20 min | Clock time from brief to approval |
| Client satisfaction | Approved without revision | Assaf accepts on first delivery |

---

## 10. Implementation Tasks

### Phase 1 — Immediate (This Week)
| # | Task | Owner | Priority |
|---|------|-------|----------|
| 1 | Update Erica's agent config to enforce "no generation without Tatiana prompt" | Kitt | P0 |
| 2 | Update Anton's agent config with standardized rubric template | Kitt | P0 |
| 3 | Update Tatiana's agent config to own prompt engineering explicitly | Kitt | P0 |
| 4 | Create prompt-patterns.md as a general (not Ozawa-specific) reference | Tatiana | P1 |
| 5 | Build post-processing script toolkit (background flatten, color correct) | Kitt | P1 |

### Phase 2 — Next Project
| # | Task | Owner | Priority |
|---|------|-------|----------|
| 6 | Test parallel batch processing with locked style baseline | Erica | P1 |
| 7 | Automate Discord thread creation and naming | Kitt | P2 |
| 8 | Build deck integration automation (Slides API image placement) | Kitt | P2 |

### Phase 3 — Ongoing
| # | Task | Owner | Priority |
|---|------|-------|----------|
| 9 | Collect metrics after each project, refine targets | Kitt | P2 |
| 10 | Evaluate animation capabilities (Luma, Runway, Kling) | Tatiana | P3 |

---

*This plan is project-agnostic. For project-specific style rules, reference libraries, and custom critique criteria, see the Per-Project Workflow Template.*