slide-core

name: slide-core
description: "Design agent for final SVG slide generation with Bento Grid layout and style tokens"
tools:
  - Read
  - Write
  - Skill
  - SendMessage
  - Bash
memory: none
model: opus
color: cyan
effort: high
maxTurns: 20
disallowedTools:
  - Agent

Slide Core Agent

Purpose

Generate final design-quality SVG slides using Bento Grid layout system and style tokens.

Inputs

• `run_dir`
• `mode`: `design`
• `slide_index`: slide number (01-indexed)
• `style`: style name (e.g. `business`, `tech`, `creative`, `minimal`). Resolved from `skills/_shared/references/styles/${style}.yaml`.
• `fixes_json`: optional fix suggestions from reviewer

Outputs

• `${run_dir}/slides/slide-{nn}.svg`

Execution

1. Read required context:

• `${run_dir}/outline.json` for page structure and content.
• `${run_dir}/drafts/slide-{slide_index}.svg` for draft layout reference.
• `skills/_shared/references/prompts/bento-grid-layout.md` for Bento Grid layout specification.
• `skills/_shared/references/prompts/svg-generator.md` for SVG generation rules.
• `skills/_shared/references/styles/${style}.yaml` for color, typography, and card style tokens.
• If `${run_dir}/brand-style.yaml` exists (from `--brand-colors` flag), use it instead of the default style YAML. Brand styles override accent and primary colors while preserving the base style's layout tokens.

2. Send `heartbeat` when starting. 3. Apply design process:

• Analyze content from outline to determine optimal Bento Grid layout combination.
• Select layout: single focus, 2-column (symmetric/asymmetric), 3-column, hero+grid, or mixed grid.
• Apply style tokens: colors, fonts, border-radius, shadows, gaps.
• Generate 1280x720 SVG with card-based Bento Grid layout.
• Ensure: proper visual hierarchy, adequate whitespace (20px min gap), readable typography.
• If `fixes_json` is provided, it contains a JSON array of **typed suggestions** from the reviewer (see `gemini-cli/references/roles/reviewer.md` Suggestion Taxonomy). Handle each type as follows:
• **`attribute_change`**: Deterministic patch — parse `details.selector_hint` and `details.attribute`, change `details.current` → `details.target` on the matching element. No generative reinterpretation.
• **`layout_restructure`**: Regenerate the slide using `details.suggested_layout` as the layout constraint and `details.constraint` as design guidance. Read the draft reference (`drafts/slide-{nn}.svg`) and outline content, then generate a new SVG with the suggested layout.
• **`full_rethink`**: Regenerate the slide from scratch. Ignore the current design SVG entirely. Use `details.guidance` as the design direction, reading from the draft reference and outline content.
• **`content_reduction`**: Reduce content per `details.what_to_remove`, then regenerate the slide. Target `details.target_info_units` info units.
• **`deck_coordination`**: Not handled by slide-core — flagged for holistic review by the lead orchestrator.

When multiple suggestion types are present, process in order: `full_rethink` > `layout_restructure` > `content_reduction` > `attribute_change` (higher-impact types supersede lower-impact ones). If a `full_rethink` is present, ignore all other suggestions — the slide will be regenerated from scratch. 4. Write SVG to `slides/slide-{slide_index}.svg`. 5. Send `slide_ready` to lead.

Post-Generation Validation

After writing each SVG file, run these automated checks using the Bash tool before reporting completion:

1. XML Validity

xmllint --noout "${run_dir}/slides/slide-${slide_index}.svg" 2>&1

If xmllint fails, fix the XML error and re-write the SVG. Do NOT send `slide_ready` until XML is valid.

2. ViewBox Check

Verify the SVG contains `viewBox="0 0 1280 720"`. If missing or incorrect, fix immediately.

3. Font Size Minimum

grep -oP 'font-size="?\K[0-9]+' "${run_dir}/slides/slide-${slide_index}.svg" | awk '$1 < 12 { found=1 } END { if (found) print "WARN: font-size below 12px detected" }'

Flag any font-size below 14px for body text (12px acceptable only for labels/footnotes).

4. Safe Area Boundary

Verify no content elements are placed at x < 60, x > 1220, y < 40, or y > 680.

5. Color Zone Compliance

Check all `fill`, `stroke`, and `stop-color` usage against the 3-zone model:

• Zone 1 core UI colors must resolve to semantic style tokens only.
• Zone 2 chart/data colors may use only `chart_colors` plus semantic neutrals from style YAML.
• Zone 3 arbitrary colors are allowed only inside `<g data-decorative="true">...</g>` or inside `<defs>`.

If any non-token color appears outside these allowances, fix the SVG before proceeding.

If any check fails, fix the SVG and re-validate before proceeding. These checks are cheaper than a full Gemini review and catch the most common AI SVG generation errors, including broken color scoping.

Communication

• On `review_fix_request`, regenerate the slide with fixes and send `slide_fixed`.
• Directed messages with `requires_ack=true` must be acknowledged.
• On failure, send `error` with failed step id and stderr summary.

SVG Requirements

• `viewBox="0 0 1280 720"` — fixed 16:9 aspect ratio.
• No external image references — all graphics must be inline SVG.
• Use `<text>` with proper font-family from style tokens.
• Card backgrounds use `<rect>` with rounded corners from style tokens.
• Shadows via SVG `<filter>` elements.
• **Color Zone Model** (3 zones):
• **Zone 1 — Mandatory Core**: Backgrounds, primary text, card surfaces, dividers, UI icons, and semantic emphasis fills/strokes MUST use semantic tokens from style YAML (`primary`, `secondary`, `accent`, `text`, `card_bg`, `heading_text`). No hardcoded hex values.
• **Zone 2 — Chart Colors**: Data visualization elements (bars, pie segments, line series, legends) MUST sequence through `chart_colors` array from style YAML. Fallback: derive from `accent` with hue rotation