infographic

What this skill does

# Infographic Prompt Writer And Generator

Create a structured image-generation prompt from repo documentation or inline
context. Return the prompt for handoff by default. If the user explicitly asks
for an actual generated image and an image generation tool is available, call
that tool with the structured prompt after building it.

## Inputs

- `context` (required): A repo Markdown path/link, `@file:` reference, or inline
  text block. If it is a path or link, read the source before writing the prompt.
  If it is missing or unreadable, ask for it.
- `orientation` (optional): `landscape` by default. Also accept `portrait` or
  `square`.
- `level` (optional): `lite` by default. Also accept `medium` or `heavy`.
- `format` (optional): `markdown` by default. Also accept `json`.
- `mode` (optional): infer from the request. Use `prompt` by default. Use
  `generate` only when the user explicitly asks for an image to be generated,
  rendered, created, or made.
- `style_reference` (optional): a design system, brand guide, style guide,
  product screenshot, prior visual, or other repo artifact that should influence
  the visual treatment.
- `reference_images` (optional): one or more prior explainers, screenshots,
  mockups, or style references to preserve, remix, or edit. If provided,
  identify each image by index and role in the prompt.

Normalize common aliases:

- `wide`, `16:9`, `deck`, `slide` -> `landscape`
- `vertical`, `9:16`, `poster`, `mobile` -> `portrait`
- `1:1` -> `square`
- `md`, `sections`, `structured` -> `markdown`
- `object`, `schema`, `strict-json` -> `json`
- `render`, `make image`, `create image`, `actual image`, `generate image` ->
  `generate`
- `prompt only`, `handoff`, `copy-paste`, `do not generate` -> `prompt`

## Mode Selection

Default to prompt handoff. This keeps the skill useful in environments without
image tools and avoids surprising generation when the user only asked for a
brief.

Use `mode=generate` only when all of these are true:

1. The user asks for an actual generated image, not just an image prompt.
2. An image generation tool is available in the current tool set.
3. The tool can accept a text prompt, or a text prompt plus the provided
   reference images.

When `mode=generate`:

1. Build the same structured prompt that would be returned in prompt mode.
2. Include the selected `model`, `quality`, and `size` inside the prompt or tool
   call when the tool supports those parameters.
3. Pass the prompt to the image generation tool.
4. After tool completion, return a short note identifying the generated image
   result and the key parameters used. Do not include a long duplicate prompt
   unless the user asked to see it.

When `mode=prompt`, no image tool is called. Return the prompt and parameter
summary exactly as a handoff artifact.

If the user asks to generate an image but no image generation tool is available,
return the handoff prompt and say that generation requires an attached image
generation tool.

If the user explicitly asks not to generate, do not call an image generation
tool even if one is available.

## Style Handling

Use explicit style references when provided. If none are provided, inspect only
nearby, obvious repo artifacts when available, such as:

- `DESIGN.md`
- `STYLEGUIDE.md`
- `BRAND.md`
- `docs/design/`
- `docs/brand/`
- screenshots, mockups, or prior explainers mentioned by the user

If no style reference exists, use a neutral technical-documentation style:

- clean structured surfaces
- legible sans-serif typography
- restrained accent color chosen from the repo or source material when possible
- compact panels with crisp borders
- clear hierarchy and high contrast for labels
- no decorative clutter, generic stock-photo treatment, or unsupported logos

Treat style references as visual guidance only. Do not use them as evidence for
product behavior, architecture, maturity, security, privacy, timelines, or
implementation details.

## Source Handling

When `context` points to repo documentation:

1. Read the source and use its front matter status when present.
2. Treat `accepted`, `approved`, or equivalent final-status docs as
   authoritative for their stated scope.
3. Preserve `proposed`, `draft`, `experimental`, and `research` uncertainty. Do
   not make unresolved design choices look settled.
4. If the source is under `research/`, frame it as exploratory unless the prompt
   context explicitly asks for a research infographic.
5. Use canonical project terms from the source. If a glossary exists, check it
   when labels or component names are ambiguous.
6. Do not invent implementation details, production readiness, security or
   privacy guarantees, timelines, metrics, owners, or dependencies.

When `context` is inline text:

1. Use only the supplied claims unless the user explicitly asks you to inspect
   repo files.
2. Keep unknowns out of the image or label them as open questions.

## Density Levels

Use the `level` parameter to choose how much information the image should carry.

| Level | Use For | Content Budget | Layout Guidance | Quality Guidance |
| --- | --- | --- | --- | --- |
| `lite` | quick explainers, meeting recaps, social/deck visuals | 1 headline, 3-5 key points, 3-6 labels | one dominant flow or hub-and-spoke, generous spacing | `quality=medium` by default; use `high` when text accuracy matters |
| `medium` | architecture explainers, decision summaries, runbook overviews | 1 headline, 5-8 key points, 6-10 labels | 2-4 sections, clear arrows, compact callouts | `quality=high` for diagrams, slides, small labels, or stakeholder-facing output |
| `heavy` | dense technical posters, review artifacts, system maps | 1 headline, 8-12 key points, 10-18 labels | multi-panel poster, swimlanes, layered system map, or timeline | `quality=high` because dense labels and layout precision need maximum fidelity |

For `heavy`, explicitly request high quality or maximum fidelity from the image
model because small labels and dense layouts need more precision.

## Model Parameters

When returning a prompt handoff or preparing a tool call, include suggested
generation parameters unless the caller requested prompt text only:

- `model`: default to `gpt-image-2` for new image-generation workflows unless
  the caller specifies another model.
- `quality`: choose from the density table. Prefer `high` whenever the image has
  dense labels, legends, axes, footnotes, small text, or stakeholder-facing
  diagrams.
- `size`: choose for the final display canvas rather than relying on later
  cropping:
  - `landscape`: `1536x864` for deck slides, or `1680x944` for a slightly
    roomier 16:9 explainer canvas.
  - `portrait`: `1056x1488` for poster/deep-dive explainers.
  - `square`: `1024x1024` for compact concept maps.
  - `overview`: `1536x1024` when the user asks for an architecture overview or
    a wider-than-slide reasoning board.

## Prompting Rules

Write the image prompt like an artifact spec, not a vague illustration request.
For examples of good patterns, failure modes, and repairs, read
`references/prompt-patterns.md` only when the request asks for examples, the
source is dense, or the first prompt draft feels underspecified.

Include these parts in a stable order:

1. Deliverable and canvas: infographic, orientation, aspect ratio, intended
   audience.
2. Style reference: explicit source if provided; otherwise a short neutral style
   summary.
3. Main message: the one idea the viewer should understand first.
4. Required content: exact labels, components, relationships, and callouts.
5. Layout: panel structure, flow direction, placement, hierarchy, and spacing.
6. Reference image handling: name each input image by index and role when
   references are provided.
7. Text rules: quote exact in-image text, keep labels short, require verbatim,
   legible typography.
8. Constraints: no invented facts, unsupported arrows, generic stock-photo
   treatment, decorative clutter, illegible tiny text, or lo