Givon AI

View saved version →

---
name: audio-prompt-craft
description: "For a generation-ready music, sound-design or speech prompt, turn the audio goal and selected model contract into creative direction and separate literal lyrics or spoken text. Not needed for a question about audio models or for editing a script's words without preparing a generation."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Preparing an audio prompt professionally

First define the meaning of the result: music, a jingle, a sound bed, sound design or a
voiceover. These tasks use different fields and must not collapse into one universal prompt.

## General order

1. Pin down the purpose: an ad, background for a clip, an intro, a podcast, a character's voice.
2. Take into account the confirmed inputs and settings of the chosen model.
3. Keep the explicit genre, mood, instruments, voice, language, text and exclusions.
4. Decide minor details yourself — tempo, dynamics, structure, density of the arrangement,
   character of the performance — when they follow from the task.
5. Do not ask a question about every parameter, and do not invent lyrics, lines, brand claims
   or the voice of a specific person.

Pass duration, variant, language or voice id and other execution controls in the typed settings
or provider options. The prompt contains only the creative brief, and the literal content goes
in the field meant for it.

## Music and jingles

A full brief contains the relevant elements:

- the function of the track and its place in the content;
- genre and era, without unlawfully copying a specific composition;
- mood and emotional arc;
- tempo, rhythm and energy;
- lead and supporting instruments;
- structure over time: intro, build, peak, outro;
- density, space and production character;
- vocals and lyrics only if requested and supported;
- what must not be heard, when the exclusion really matters.

Example:

```text
A 15-second energetic electronic jingle for a short ad for a sports app. A fast, bouncy beat,
a short three-note synth hook, a tight bass pulse and one bright hit on the final logo.
Structure: an instant hook, a build toward the 10th second, a clean final accent with a short
tail. Modern polished production, no vocals, no long intro and no aggressive distortion.
```

Do not add generic `cinematic`, `epic` or a list of genres unless they serve the task.

## Voiceover

The text to be spoken is a separate literal input. It is kept word for word, including names,
numbers and punctuation. Tone, pace, emotion, pauses and pronunciation belong to the delivery
controls or to a separate instruction field, if the schema supports one.

Never put service phrases into the literal spoken-text field, such as «[говорит энергично]»
("speaks energetically"), «мужской голос» ("male voice") or «пауза 2 секунды» ("2-second
pause"): many models will say them out loud.

Before you prepare the generation, check that:

- all of the user's text is kept word for word;
- the language and voice are compatible with the model;
- difficult names have confirmed pronunciation guidance, if it is needed;
- the delivery does not change the meaning of the text;
- the length of the text is realistic for the chosen duration;
- no instructions will end up in the speech as words.

## Sound design for video

Tie each sound to its source and moment: a footstep, the click of a lid, rustling fabric, city
ambience, a transition or a final sonic logo. Do not list abstract "high-quality sounds". If the
native audio of the chosen video model is not enough, prepare a separate sound layer instead of
a video prompt that asks the model for audio it cannot produce.

View saved version →

---
name: campaign-concepts-and-tests
description: "For alternative campaign directions, turn the brief, audience and available evidence into distinct creative concepts with examples and a practical hypothesis to compare. Not needed for a single finished text."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Campaign concepts and hypotheses

Turn the brief into distinct creative directions. A concept sets the idea mechanism and the
system of variants; finished copy, a script and a media plan remain separate results, produced
on request.

## Direction card

For each requested direction, fill in the useful fields:

- audience or situation;
- an observation, or a clearly marked hypothesis;
- the key promise;
- the creative mechanism or repeatable idea;
- examples of storylines, images or hooks;
- suitable formats and channels, if they are given;
- what must stay constant across variants;
- what exactly is being compared and which observable signal to look for;
- which facts or materials are still needed.

Make directions differ by strategy, audience or idea mechanism. Use past results, trends,
competitor data and forecasts only from the available materials. When there is no measurable
baseline, propose a testable hypothesis, an observable signal and a way to compare.

When one request asks for the whole package, add copy, story and visual details to the extent
needed to apply the concept. The main result remains the strategic direction and the test plan.

View saved version →

---
name: card-text-in-image
description: "For text inside a generated image beyond one short headline: several lines, bullets, property labels or badges with icons; covers splitting the supplied wording into exact lines, spelling, placement and label style. Not needed for one short headline."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Russian text in the frame

The text on a card is drawn by the generative model. Clear wording, short lines and a set
position improve the legibility and accuracy of the lettering.

## Legibility

Generative models reproduce short lettering with a clear hierarchy more reliably than dense
paragraphs and small text. Choose the amount of text and how to split it to suit the task, the
frame size and the capabilities of the chosen model.

## How to put lettering into the prompt

- State explicitly in the prompt which text to render and where it sits in the composition
  ("a large offer at the top", "a bullet near the bottom edge"). Do not count on the model to
  come up with the text itself.
- Write the in-frame text in exactly the words that must appear on the slide, in its own
  language, in quotes or as an explicit list of lines, so that the model does not rephrase it.
- Describe only the visible result: the content of the lettering, its role, its position and its
  visual character.

## Spelling

- Check the spelling and the keyboard layout of the Russian text you ask to render (no words typed
  in the wrong layout, no Latin letters that only look Cyrillic): a mistake on a card is visible
  to every buyer.

## Labels and markers

- Express a property marker in words: describe the label and a simple, clear icon ("a label with
  text and a minimalist water-drop icon for water resistance").
- Keep markers simple and unambiguous, because the model draws a complex pictogram unreliably.
- Describe the labels of one set uniformly (shape, position, style): a consistent rhythm is held
  through identical wording on every slide.

## Check before assembly

- The text is short and fits the frame without small type.
- The spelling is checked.
- The label style matches the rest of the set.

*For the chosen model, keep the intent and the exact in-frame text, and take the model's limits
and capabilities from the current catalog. The chosen model's current prompting guidance owns model-specific syntax;
its live contract owns available fields.*

View saved version →

---
name: character-legend-design
description: "Legend or canon for a fictional persona or series hero in the fall-and-rebuild format: identity, trigger, loss, turn, path and lived-in details, preserving established facts when revising. Not needed for a character's look alone."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Character legend and canon

Create or edit a fictional character in exactly the form the user asked for: a short card, a
full legend in the first or third person, a canon for the team, a season arc or an edit of an
existing version. When there is enough to build on, give the result right away. Ask only about
what would substantially change the hero, the goal or the format.

## The meaning framework

Tie these required elements into one causal system:

- who the hero was and what made up their identity;
- the core of the conflict and a concrete trigger;
- the low point: an observable loss of money, status, work, support, relationships or
  self-respect;
- an inner shame, fear or contradiction;
- the turn: the hero's decision and action now;
- the promise of a path that viewers can follow in the next episodes.

Don't replace causality with a list of traits. Events must explain the hero's rules, and the
hero's decision must launch the future story.

## Canon and lived-in truth

Separate given facts from new creative decisions. When refining, preserve names, age,
relationships, chronology and other anchor facts. Add at least 3–5 functional details from
different categories to every full legend: a place, an object, a document or interface, a
habit, a number, a deadline, a specific line of speech, an everyday procedure or a trace of a
relationship.

Read the full set of [reference legends](references/character-legends.md): it is the required
bar for depth, logic, voice and everyday truth. Don't copy Mila, Sergey, Angelina, Ksyusha or
Sasha with a changed name: create a new causal combination of biography, environment,
trigger, details and path.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: creative-brief
description: "When a broad request or scattered materials need a usable brief, synthesize the goal and available project context into a concise direction, assumptions and critical gaps. A complete brief is not a prerequisite. Not needed when the request is already clear enough to act on."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Creative brief

Put together the shortest brief that is enough for the next decision or for handing the work
to production. Rely on the user's materials and the available project knowledge. Mark every
guess as a working assumption or a hypothesis.

## Structure

Choose the fields you need from this set:

- the task and the change it should bring about;
- the audience and the situation in which the task arises;
- the problem, tension or opportunity;
- the offer, brand or creative subject;
- the key communication task;
- required facts, materials and constraints;
- a useful format for the result;
- an observable signal by which the team will judge the hypothesis.

Keep these apart:

- **given** — confirmed by the brief, the materials or project knowledge;
- **working assumption** — the interpretation chosen in order to continue;
- **hypothesis** — an idea that needs to be tested;
- **gap** — information without which the decision really changes.

A working brief separates critical gaps from assumptions and stays usable for the next decision
even when the source data is incomplete.

View saved version →

---
name: footage-transformation-vfx
description: "For editing existing footage or adding VFX to it, use the source video, the requested change and the chosen model's contract to define what stays, what changes and how the effect blends in over time, including the frame-first path for an exact subject from a photo. Not needed for a new scene generated from text or an image."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# VFX transformation of existing footage

This skill applies when the starting point is an existing clip rather than a new scene built
from scratch. Its job is to hold the stated properties of the source and carry out the changes
the user named. It complements `video-prompt-craft`: the general video skill covers motion and
camera, this one covers the footage transformation contract.

## Identify the real input mode

Check the chosen model and its input schema against the current catalog:

- `video_edit` / source-video slot: the model receives the footage as an editable base;
- `video_reference` / video-reference slot: the clip sets motion, composition or the scene, but
  does not promise frame-by-frame preservation of the whole source;
- when preservation accuracy matters more than a particular model, choose a model with
  `video_edit`;
- describe a reference input as control of motion, composition or scene; promise frame-by-frame
  preservation only when the matching capability exists.

Use confirmed facts from the attachment or the asset summary: duration, transcript, whether
there is sound, the described subject and scene. State the FPS, the timecode of a line, the lens
or the light direction only when there is a measurement or an explicit source.

## An exact subject from a photo in existing footage

A video model redraws a subject from its reference, so a pet, a product or a person from a photo
comes out similar, not the same. When the user needs that exact subject in their footage, offer
the frame-first path instead of one edit:

Explain the frame-first trade-off before starting: image editing can preserve the reference
subject more closely, but regenerating motion from that frame does not preserve the original
footage frame by frame. Do not promise exact identity throughout the resulting video.

1. Obtain a suitable frame of the footage. Use host-local frame extraction only when an actual
   available capability can read that footage and the user has authorized the local operation.
   Otherwise ask for a supplied frame or an accessible frame image; do not invent a public frame
   extraction tool, a local path readable by MCP, or an attachment URL.
2. Use `givon_list_models` and `givon_get_model_schema` to select a supported image-edit model
   that accepts both the frame and the subject photo. Upload/import them through the available
   public asset route, bind each returned `assetUri` to its supported input role, and author an
   image-edit prompt preserving the source scene while placing the subject. If the required
   combination is unsupported, explain the gap and agree the alternative before proceeding.
3. Quote the exact image request with `givon_quote_generation`, obtain approval under
   `givon-ai-create`, generate through `givon_generate_content` with quoted `maxTokens` and a
   stable `idempotencyKey`, then check `givon_get_generation_status` and show the resulting frame.
   Obtain the user's approval of that frame before moving to the video stage.
4. Select an active image-to-video model and inspect its live schema. Bind the approved image
   only to the declared start-image field and describe motion, preserving the agreed trade-off.
   Quote and obtain approval for this separate video request, then generate and check status
   through the same public lifecycle. Return the finished clip or its truthful running/failed
   state. Reuse each stage's idempotency key after uncertain acceptance; never launch a duplicate.

Use the CLI equivalents in `givon-ai-create` when shell access is the chosen route. Each stage
has its own supported input, quote and job. Do not replace a requested direct footage edit
with regeneration from a frame without agreeing that loss of source continuity with the user.

## Contract: PRESERVE → CHANGE → INTEGRATE

### 1. PRESERVE

Name only the source invariants that apply:

- character: identity, face, body proportions, wardrobe, expression, performance;
- product: exact geometry, color, material, label and logo shape;
- frame: framing, angle, headroom, horizon, lens character, camera motion;
- scene: objects and parts of the surroundings the user did not ask to change;
- sound: source dialogue and lip-sync, when they need to be kept.

### 2. CHANGE

List the requested changes and how they relate in time or space. Do not merge independent
changes into an invented causal chain. Use the wording `change only`, `replace only`,
`transform only` and `add only` only when the user really limited the change to one element.

### 3. INTEGRATE

The integration approach follows the user's artistic direction. For a realistic or physically
embedded effect, take only the relevant traits:

- matching direction, softness and temperature of the key light;
- contact shadow, environmental bounce, reflections and light cast by the effect;
- parallax and the speed of the world relative to the source camera motion;
- matching depth of field, focus falloff, lens character, grain and atmospheric haze;
- no stray halos or cut-out edges, and consistent depth where objects touch.

For a hand-drawn, graphic, surreal, glitch or otherwise stylized effect, keep exactly the
requested visual logic instead of substituting photorealism.

Describe behaviour over time: where the effect starts, how it spreads, and what it lights,
deforms or refracts. For large creatures and objects, state the scale explicitly relative to a
specific element of the scene.

## References

Use the chosen live schema and `promptAuthoring` / `x-promptAuthoring` reference semantics to
bind every uploaded/imported asset to its role. Use only the aliases the selected model supports:

- numbered tags such as `@Video1`, `@Image1` or `@Audio1` require declared inline-reference
  support and must match the order of the corresponding schema-backed reference collection;
- a dedicated source/start/end slot has its own semantic role; describe "the source video" or
  "the opening frame" instead of inventing a numbered alias;
- never invent a slot, alias, media URL or file-selection status. If a required asset has no
  supported input field, explain the mismatch and agree the alternative with the user.

If a photo is needed only as a texture reference, pin down its role: take the look, fur or
material from it, and keep the background, composition and light of the source scene. Tie each
reference to its role directly in the scene description.

## Timing, lines and duration

For an event on a spoken line, use two anchors, and only when the facts are available:

1. semantic: the exact words of the line;
2. numeric: `at about N seconds`, from a measured or given timecode.

The numeric anchor requires a measured or given timecode. If an intro is added before the
source performance, check the arithmetic: `total runtime - intro = remaining source window`. For
a line that does not fit, increase the total length, remove the pre-roll or state the trim
explicitly.

## Prompt language

Write the prompt in the prompt language set by the chosen model's current prompt-authoring contract; usually that is English. Keep the `@ImageN` /
`@VideoN` / `@AudioN` aliases, names, numbers, brands and exact lines as written. If the user asked for several language versions, prepare a separate,
self-contained variant for each.

## Iterations

For a refinement such as «свет мягче» (softer light), «эффект начинается раньше» (the effect
starts earlier), «существо больше» (a bigger creature) or «камера остаётся исходной» (the camera
stays as in the source), change the named part and keep the rest of the contract, the aliases,
the invariants, the timing and the chosen model stable.

## Final check

- the model's input mode matches the attached video;
- every reference used is named by its alias and role;
- PRESERVE lists only the invariants that are needed;
- CHANGE contains all the requested changes and only them;
- the integration approach matches the requested realism or style;
- no timecodes are invented;
- the duration and the line physically fit;
- the prompt contains only the description of the result and the parameters that affect
  generation.

View saved version →

---
name: givon-ai-create
description: "Run the full Givon AI generation lifecycle through MCP or CLI: select an active model, build schema-valid input, upload references, launch the job and deliver the finished asset."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Givon AI Create

Create the first useful result with the smallest valid request. Keep MCP
mechanics, raw schemas, job ids and JSON internal unless the user asks for them.

## Default Route

1. Infer the modality (`image`, `video`, `music` or `voiceover`) from the user
   request. A voiceover needs a voice: list them with `givon_list_voices` (CLI:
   `givon voice list`) and pass the chosen id as `input.voice`.
2. Classify the requested result and the input media it depends on.
3. Call `givon_list_models` and choose an active model from live guidance, the
   user's priorities and the required input type.
4. Call `givon_get_model_schema` for that model before building `input`.
5. Build only schema-supported fields. Use schema defaults instead of inventing
   extra options.
6. If the request needs local/reference media, upload or import it first and
   keep the returned `assetUri`.
7. Confirm the price in the chat. Quote the exact request with
   `givon_quote_generation` (CLI: `givon generate quote`), tell the user the
   token cost and wait for their go-ahead before running. Skip the question only
   when the user said in this conversation to run without confirmations; that
   choice lasts until they take it back. Either way pass the quoted price as
   `maxTokens` (CLI: `--max-tokens`). A `price_above_limit` error means the
   price changed: re-quote and ask again. If quoting is unavailable, say the
   price is unknown and ask before running.
8. Call `givon_generate_content` with `wait: true` and a stable
   `idempotencyKey` for this exact request, then poll
   `givon_get_generation_status` until `succeeded`, `failed`, or `canceled`.
   Reuse that key after an uncertain response; do not launch a second job just
   because a wait timed out. Use a new key for a changed or intentional new request.

## CLI or MCP

Use one route for the whole task. On a computer with shell access, prefer the
`givon` CLI: if it is on PATH, run `givon whoami` once and use it when sign-in
succeeds. If the CLI is unavailable or cannot reach the service, use connected
Givon MCP tools. When neither route exists, ask the user to connect Givon MCP
through the host settings. CLI installation is a separate local setup action;
this generation skill does not download or execute an installer.

In a web chat without shell access, use MCP directly. If its tools are absent
or authentication fails, ask the user to connect or reconnect Givon through
the host's plugin/connector settings and browser sign-in. Do not ask a web user
to install a CLI or run terminal diagnostics. Both routes use the same account,
catalog, schemas, prices, assets and generation lifecycle.

## Model Selection

Live catalog guidance and schema own model availability, supported inputs,
defaults, selection guidance and cost. Match them to the user's goal and
priorities, then validate the chosen route against the live schema.

## Asset Route

- Local file with shell access: use `givon asset upload <path>
  --kind <image|video|audio>` and keep the returned `assetUri`. In ChatGPT, use
  `givon_upload_file_asset` when the host provides a native file parameter.
- Remote media: use `givon_import_asset` in MCP, or `givon asset import
<https-url|data-uri>` in CLI/API.
- Existing media: use `givon_list_assets` / `givon_get_asset`, or
  `givon asset list` / `givon asset get`.
- After upload/import, inspect the selected model schema. Pass `assetUri`,
  `https://` URL, or data URI only through fields that the schema supports
  (`sourceImage`, `referenceAssetUris`, `referenceAssets`, `assetInputs`, or
  model-specific asset slots). If the schema has no media field, the model is
  prompt-only for this request.
- Use `givon_archive_asset` or `givon asset archive` only when the user
  explicitly wants to hide an owned asset from active lists. It is a soft
  archive; audit links and existing project links remain intact.
- For image-to-video, source/start image goes into the schema-backed start image
  field; the prompt should describe motion and camera behavior.

## Prompt Craft

Preserve the user's creative facts and use the selected model's guide or the
relevant specialist skill for craft. The live schema filters fields and limits.
Keep the prompt complete, concrete and model-appropriate; never trade useful
control for brevity.

## UX Rules

- Ask only for information required to make the next action executable when it
  cannot be inferred from the current context or live schema defaults. Collect
  all such missing inputs together.
- Authentication stays in the browser or CLI credential flow; chat receives no
  API keys.
- For CLI authentication, use `givon login`; for a configured local MCP client,
  use `givon mcp doctor --client <client>`. In a web chat, reconnect through
  the host settings and browser sign-in instead.
- When using the CLI, prefer `givon generate create --wait` so the user gets
  the final asset, not only a job id.
- Prefer a host-native file parameter for chat attachments. If unavailable,
  upload actual bytes with `givon_upload_asset` only when the host can read
  them, or ask for an accessible HTTPS media link or an existing Givon asset.
  Never invent a download URL. With shell access, CLI upload is also available;
  the remote MCP server cannot read local files directly.
- Respect server polling guidance and use backoff. If the host cannot continue
  waiting, report the running job and retain its id for a status follow-up.
- Balance or entitlement failures may be explained, but do not initiate credit
  purchases, promote upgrades, or link to checkout from the plugin.

Read [references/mcp-workflow.md](references/mcp-workflow.md) when you need the
exact tool flow or error playbook.
Read [references/model-prompting.md](references/model-prompting.md) for the
universal model-guidance contract. After selecting a model, read only its family
file: [OpenAI](references/model-prompting-openai.md),
[Google](references/model-prompting-google.md),
[BytePlus](references/model-prompting-byteplus.md),
[xAI](references/model-prompting-xai.md),
[Alibaba](references/model-prompting-alibaba.md),
[Kling](references/model-prompting-kling.md),
[MiniMax](references/model-prompting-minimax.md),
[HeyGen](references/model-prompting-heygen.md), or
[Beeble](references/model-prompting-beeble.md).
Read [references/prompt-craft.md](references/prompt-craft.md) when shaping a
prompt, repairing a failed prompt, or handling image-to-video/design/brand
creative requests.

Referenced files: 13 — file references are metadata, not package contents.

View saved version →

---
name: givon-ai-job-recovery
description: "Inspect and recover a Givon AI generation by checking its status, errors, balance or quota, and MCP readiness."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Givon AI Job Recovery

Separate transport/config failures from in-band generation results. A failed job
is still a normal status response when the transport succeeded.

## Route

1. If the user has a job id, call `givon_get_generation_status`.
2. Treat `succeeded`, `failed`, and `canceled` as terminal.
3. For `queued` or `processing`, report progress briefly and keep polling only
   if the user asked you to wait.
4. For balance or quota questions, call `givon_get_balance`.
5. If tools are unavailable in a web chat, ask the user to reconnect Givon in
   the host's plugin/connector settings. With shell access, use the configured
   CLI/MCP doctor path before asking for more information.

## Playbook

- Transport/tool unavailable: reconnect through the host's browser sign-in.
  With shell access, `givon login` (no key) or
  `givon mcp doctor --client <client>` are available. A web user does not need
  to install or run a CLI.
- Auth failure: tell the user to reconnect — `givon login` (browser, no key) or
  reconnect the MCP client; for CI keys, create/rotate one in the Givon cabinet.
  Do not request the secret in chat.
- Schema/input issue: remove unsupported fields or ask for the missing required
  fields together.
- Model/job failure: explain `errorCode` and `errorMessage`; propose a narrower
  retry prompt or supported parameter change.
- Balance/quota issue: report live balance; do not guess spend or discounts.

Read [references/troubleshooting.md](references/troubleshooting.md) for concise
operator notes.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: givon-ai-marketplace-cards
description: "Create the requested marketplace listing visuals through Givon AI with clear asset roles, product references and schema-supported generation inputs."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Givon AI Marketplace Cards

Build the set the user actually requested. Asset labels organize the result; the live model
catalog and schema own generation modes, inputs and settings.

## Workflow

1. Identify the requested listing assets and the purpose of each image.
2. Use product/reference media when available and assign each reference a clear role.
3. Ask only for information required to make the requested set executable when it cannot be
   inferred from the brief, attached media, current context or live schema defaults. Collect all
   such missing inputs together.
4. Use `givon-ai-create` to select an active image model and inspect its detailed schema.
5. Build each prompt from [references/prompt-structures.md](references/prompt-structures.md),
   then apply the selected model family's guidance.
6. Run separate generations or a schema-supported batch and return labeled ready assets.

Read [references/scope-selection.md](references/scope-selection.md) for useful marketplace asset
roles and set planning; derive the final set directly from the user's request.

## Set coherence

- Give each image one clear purpose and enough product context to remain recognizable.
- For a multi-image set, assign each asset a distinct buyer question and primary message.
  Replace or merge an asset that repeats another asset's main job; a fact may recur only as
  supporting context.
- Keep a shared visual system across a requested set while varying composition and message.
- Preserve exact product facts and visible identity when they are supplied as real listing data.
- Follow a creative or hypothetical brief when the user explicitly asks for one.

Default delivery contains short asset labels and ready URLs or handles. Return a prepared prompt
instead when that is the requested artifact.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: givon-ai-model-router
description: "Inspect the live Givon AI catalog, model schemas, parameters, capabilities and costs before generation. Task-specific selection guidance lives in model-selection-guidance."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Givon AI Model Router

Recommend one practical model path by default. Keep catalog detail hidden unless
the user asks for comparison.

## Route

1. Start with `givon_list_models`; filter by modality, status, tags, or query.
2. Short-list active models only unless the user asks about coming-soon or
   deprecated models.
3. For every candidate you might recommend, call `givon_get_model_schema`.
4. Compare the user's required fields with schema-supported fields, asset slots,
   variants, and cost metadata.
5. Recommend one model and the minimum valid `input` shape.

Before live catalog/schema inspection, name only the requested result and
compatibility needs. Do not declare an executable generation/edit mode:
reference-conditioned creation may be exposed as a still-generation input or
as an edit operation, and the selected schema owns that distinction.

## CLI Flow

When working through the CLI, use `givon model list --kind <image|video>` for
live catalog discovery and `givon model get <id>` for schema inspection. Choose
the model from these instructions and the live schema; do not rely on a separate
CLI heuristic.

Selection priorities come from the user's requested result and the relevant
specialist workflow. Availability, input compatibility, quality guidance,
defaults and cost come from the live catalog and schema.

## Answer Shape

- Give one recommendation first.
- Use a table only for explicit comparisons.
- Mention costs from model metadata or live responses.
- A separate creation intent starts generation; catalog questions end with the
  recommendation and supported input shape.
- A user-named model gets a full-catalog lookup when filtered search misses it.
- Classify by the requested result, required inputs and user priorities, not by
  tags alone.
- For asset/reference workflows, treat `x-assetSlots` as capability discovery
  plus a schema checklist. Media is passed only through fields present in the
  selected model's `input` schema; a schema without media fields is prompt-only.

Read [references/model-selection.md](references/model-selection.md) for the
schema checklist.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: givon-ai-product-photoshoot
description: "Create or transform product visuals through Givon AI using a product brief, live model guidance and schema-supported inputs."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Givon AI Product Photoshoot

Turn the user's product brief into one or more schema-valid image generations. The brief
describes the desired visual; the live catalog and selected model schema own executable modes,
inputs, settings and defaults.

## Workflow

1. Capture the requested deliverable, product identity, reference roles and intended use.
2. Ask only for information required to make the next action executable when it cannot be
   inferred from the brief, attached media, current context or live schema defaults. Collect all
   such missing inputs together.
3. Use `givon-ai-create` to inspect active models and the selected model's detailed schema.
4. Build a compact prompt from the user's creative facts and the relevant structure in
   [references/prompt-structures.md](references/prompt-structures.md).
5. Pass product/reference media only through schema-supported asset fields.
6. Generate the requested number of results and return labeled ready assets.

Read [references/mode-selection.md](references/mode-selection.md) when the brief is incomplete
and you need to resolve blocking creative inputs. Apply the selected model family guidance
exposed by `givon-ai-create` after model selection.

## Product brief

Use only relevant dimensions:

- product identity and details to preserve;
- source/reference role;
- intended use and output container;
- scene, composition, crop, pose or interaction;
- light, material and visual direction;
- exact visible text;
- count and aspect when explicitly chosen or required.

For a series, keep a coherent visual system while giving each image a distinct purpose. Default
delivery contains short labels and ready asset URLs or handles; include implementation detail
when the user asks for it.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: image-prompt-craft
description: "For a generation-ready image prompt: turn the visual goal and the chosen model's contract into a standalone prompt with subject, composition and light. Not needed for video, audio or answers without a prompt."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Professional image prompt preparation

Your task is not to retell the request but to turn it into a controllable visual brief for the
exact chosen model. The finished prompt has to make sense to the generator without the chat
history and carry enough decisions to produce a coherent frame. Length by itself is neither a
virtue nor a flaw.

## 1. First establish the actual result

Determine what exactly the user wants to get:

- a new image from scratch;
- a change to an attached image;
- a new frame that keeps a character, product, logo or other object;
- a transfer of only the style, composition, background or palette from a reference;
- an advertising key visual, a product card, a poster, a portrait, an illustration, a UI or an
  infographic;
- a series of consistent images.

The user's explicit facts (subject, action, properties, relations, text, style, prohibitions)
are fixed. Do not turn everything else into a questionnaire: choose consistent non-essential
details yourself when they help the task. Ask a question only when, without the answer, the
result itself cannot be understood or a compatible input cannot be chosen.

## 2. Read images as evidence, not as decoration

Give each attached image one or more precise roles:

- `source` — the image to be changed;
- `identity / character` — the appearance and stable traits of a person or character;
- `product / object` — the product's shape, color, material, packaging and markings;
- `style` — artistic language, texture, palette, processing;
- `composition` — placement of objects, shot size, perspective;
- `background / location` — the surroundings;
- `logo / text` — exact graphics or lettering.

Look at the available pixels and use only the properties that belong to the declared role. A file
name and an earlier prompt are auxiliary metadata, not a substitute for the visual content.
If the user sent a screenshot of an interface, separate the target object from the buttons, frames
and interface text: the interface does not become part of the result unless the user asked for it.

Do not mix roles. A camera-motion reference does not set a character's appearance; a style
reference does not change the product; a source image does not mean that absolutely everything
must be kept.

## 3. Follow the chosen model's contract

Use only the confirmed inputs and capabilities of the chosen model. Do not guess them from the
brand, the name or a memory of the catalog. The chosen model's current prompting guidance owns model-specific syntax;
its live contract owns available fields.

For product references, exact lettering and local edits, read `references/product-and-text.md`
when needed. It holds general craft, checked against the official GPT Image 2 and Seedream 5 Pro
guides. Do not load it for a simple task where the current context is already enough.

Pass the aspect ratio, size, quality mode, number of results and other execution controls in the
typed settings. Repeat them in the prompt only when the value is itself part of the composition,
for example "a vertical poster with room for a headline at the top".

## 4. Build an internal visual brief

Before writing the prompt, sort the decisions into four groups in your head:

1. `keep` — all of the user's explicit facts and the invariants of the references;
2. `change / create` — the observable result;
3. `professional choices` — the angle, composition, setting, light, palette, material, texture
   and depth of field that you choose;
4. `do not add` — new characters, products, story facts, advertising promises, logos, lettering
   or decor that change the meaning of the task.

Professional choices are needed when they make the result specific. They must not contradict
explicit values. Do not add empty boosters such as `masterpiece`, `best quality`, `8K`, `HDR` or
a random lens unless they express the required look.

## 5. Architecture of a finished prompt

Do not copy this list mechanically and do not output empty sections. For an ordinary generation,
assemble a natural, coherent brief in this order:

1. **Purpose and main frame** — what is being created and for what, if that affects the
   composition.
2. **Subject** — who or what is in the frame, and its important visible traits.
3. **Action / pose / relations** — what the subject does and how the objects are placed relative
   to each other.
4. **Composition** — shot size, angle, perspective, focal point, negative space.
5. **Scene** — the environment, the background and only the details that carry meaning.
6. **Light and color** — source, direction, hardness, temperature, contrast, palette.
7. **Material and texture** — how the surfaces look and how light behaves on them.
8. **Visual language** — photography, CGI, anime, graphics, collage, and its specific traits.
9. **Text and invariants** — verbatim lettering, logo, geometry or identity, when needed.

### Creating a new image

Describe the final frame, not the agent's working process. Do not write "generate", "use the
model" or "choose the settings" inside the prompt. One paragraph is fine if it stays readable; a
complex commercial frame can be split into short blocks of meaning.

### Editing a source image

Use a clear logic:

```text
SOURCE: [which asset is being edited]
CHANGE: [one or more specific changes]
KEEP: [only the properties that truly must not change]
LOOK: [what the final visual look should be]
CONSTRAINTS: [side changes that are not allowed]
```

Do not list the whole image in `KEEP`. Pin down what the model can actually break by accident:
identity, geometry, angle, product color, logo, background or lighting.

### Person, avatar or character

If a new look is needed without an identity reference, describe the age group, visible features,
hair, clothing, expression, pose, gaze and light only as far as the task needs. If there is an
identity reference, do not replace it with a long invented description: state the reference's
role and pin down only the critical traits and the allowed change.

### Product and advertising

The product stays the visual anchor. Fix its shape, color, material, packaging and logo from the
reference, then choose a commercially meaningful composition, setting, light, contact with the
surface, shadows and room for copy. Do not invent product properties or marketing claims.

### Lettering and infographics

Pass the user's text verbatim in quotes. State the hierarchy, placement, typeface character,
color, contrast and free area. Do not correct the brand, spelling or letter case unless asked.
If the chosen model's contract does not confirm the text accuracy you need, do not promise it and
state the limitation plainly.

### Image series

First fix a shared style or identity anchor, then write a self-contained prompt for each frame.
Change only the given axes (scene, pose, angle or the product point a frame shows) and keep the
shared traits. Do not use phrases like "as in the previous frame" without an available reference
asset.

## 6. Full examples

### A bad retelling

Task from the user: «сделай белую Ferrari в мультяшном стиле (аниме)».

Not acceptable:

```text
A white Ferrari in a cartoon anime style.
```

This is a caption, not a finished prompt.

### A finished image prompt

```text
A white Ferrari is the main and only subject of the frame, seen from a low front three-quarter
angle, the whole car fitting inside the frame. A crisp, recognizable sports-car silhouette, glossy
white paint with neat cool highlights, dark wheels and clean reflections without distorted
details. The car stands on a wide city street after light rain; the background is simplified and
slightly blurred so that it does not compete with the car. The visual language of a modern
feature-length anime: expressive outlines, controlled cel shading, soft gradients in the sky,
dynamic diagonal composition, saturated but not neon accents. Evening side light brings out the
shape of the body, with a natural contact shadow under the car. No people, no text, no logos in
the surroundings and no extra cars; keep the geometry of the body and wheels correct.
```

This is one acceptable professional option. If the user set a different street, angle, time of
day or anime style, their values fully replace the ones chosen here.

### Editing a building from a source

```text
SOURCE: @Image1 — the original building and its camera angle.
CHANGE: move the surroundings into an open sandy desert; remove the neighboring buildings, roads,
cars, vegetation and urban elements.
KEEP: the building itself, its facade, proportions, the number of visible floors, the camera
position and the vertical composition.
LOOK: realistic dry daylight, pale sand to the horizon, a light atmospheric haze, natural contact
shadows at the base of the building.
CONSTRAINTS: do not change the architecture or the facade materials; do not add people, signs or
new objects around the building.
```

## 7. Final self-check

Before delivering the result, check that:

- every explicit fact from the user is kept;
- the prompt cannot be mistaken for a caption or a retelling;
- the attached images have explicit roles;
- missing non-essential decisions are made, not turned into questions;
- there is no new meaning-carrying object, text or claim;
- typed settings are not duplicated as filler prose;
- the structure fits the exact chosen model;
- the prompt is ready to use on its own, without the chat history.

Reference aliases apply only when the chosen model declares inline-reference support.
Bind them to actual reference order and roles; for dedicated source/start/end fields,
use the slot role instead of inventing an alias.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: jingle-and-sound-logo
description: "For a short brand jingle or sonic signature, use the brand mood and intended placement to produce a memorable motif brief with form, instruments and timing. Not needed for a voiceover alone or for sound effects tied to on-screen action."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Jingles and sound logos

A jingle or a sound logo is a short, recognisable form. Its structure, density and duration
follow its role in the clip, the music brief and the contract of the chosen model.

## Choosing the form

Pick the form to fit the brand's task. Several approaches are valid; choose by context:

- **Cold hook** — a musical hook at the very start, when the result must grab attention
  immediately.
- **Mnemonic (sound logo)** — a short recognisable motif that works as a sonic signature.
- **Tagline sting** — a musical sting under a spoken slogan. If a voice is needed, this links
  to the voiceover (see the voiceover-for-video skill).

If the brief does not make clear what is needed, propose a form yourself and name your choice.

## Duration

Take the duration from the request, from the jingle's place in the clip and from the values the
model supports. If the jingle falls into a known edit interval, fit the form to that interval
without silently shortening or stretching the user's material.

## Tie to the brand mood

Put together a short mood brief before you assemble the prompt:

1. **Brand character** — energetic, premium, warm, technological or playful.
2. **Tempo and energy** — fast and upbeat, or calm and confident.
3. **Instrument palette** — what sets the character (for example, synths for a tech brand,
   acoustic instruments for a warm one). Propose it yourself if the user has not set it.

## Restraint

The density of the arrangement follows the brief. Bring out a recognisable hook and describe
only the instruments, changes and sound qualities that the requested result needs. Do not add
limits on the number of elements without a reason in the request or in the model's contract.

## Final brief

The final brief pins down the form, the memorable hook, the mood, the instrument palette and the
duration.

View saved version →

---
name: marketplace-card-assets
description: "Start here for any marketplace card or slide (Wildberries, Ozon and similar), one slide or a set: plan each image's purpose, content and reference roles; alone it covers a simple slide with a short headline. Load selling-slide-composition only for a set of two or more slides, card-text-in-image only for in-frame text beyond one short headline. Not needed for listing text outside the image."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Planning marketplace card images

Determine the set from the request, the placement goal and the available materials. The result is
a list of specific images to prepare, each with a clear purpose. A single slide is a set of one.

## Possible image roles

- a cover or main frame;
- an additional angle or a close-up detail;
- the product in use or in a setting;
- the package contents;
- an infographic with the content the user specified;
- a rich/A+ module or another page block.

This is professional vocabulary for describing the result. The current task decides the set;
name the chosen roles in words the user understands.

## Planning result

For each image, record its purpose, its content, the references it uses and the marketplace
requirements that matter. For a series, add a shared visual direction only as far as coherence
needs it. Choose the model, format and parameters by the current catalog and schema.

## One slide with this method alone

For one slide with a short headline or offer, this method is enough:

- Decide what the buyer should notice first and scale the product, the text and the free space
  around that priority.
- Put the lettering on a clean, calm field: text on a busy or occupied part of the photo gets
  lost.
- Place the text and labels around the product, not over its key details (logo, shape, texture).
- Keep a safe margin from the frame edges, because the marketplace may crop the image or overlay
  its own UI.
- Put the in-frame text in quotes exactly as it should appear and check its spelling.
- For text in the frame, choose the model by the current catalog and its confirmed ability to
  reproduce lettering.
- When micro-parameters are missing, choose a consistent style from the product, the niche and
  the brand, and state the decisions you made.

## When to load another method

- `selling-slide-composition` — only for a set of two or more slides that must share a palette,
  lettering character, label rhythm and grid.
- `card-text-in-image` — only for in-frame text beyond one short headline: several lines,
  bullets, property labels or badges with icons.

Otherwise do not load them. Apply `image-prompt-craft` for the chosen image model.

View saved version →

---
name: model-selection-guidance
description: "Compare generation models when the user asks for a comparison or the trade-offs. Not needed when a valid model choice and current guidance are already in context."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Comparing models

Compare only compatible options from the current catalog. The catalog owns availability,
inputs, parameters, limits and price; this skill owns the criteria for a recommendation.

## Pick the right action

Use `givon_list_models` (CLI: `givon model list`) for browsing and comparison. Choose from
current active models by the requested result, reference media and priorities. Read the exact
chosen model with `givon_get_model_schema` (CLI: `givon model get <id>`) before authoring
its input. Use the catalog's `promptAuthoring` and schema `x-promptAuthoring` metadata for
language and reference semantics, together with the relevant craft and model-family guide.
If a current choice and guidance already cover the same inputs and constraints, reuse them.
The caller writes the final prompt; there is no separate selection-advisor or prompt-preparation
tool on this surface. Finish through `givon-ai-create` when the user asked to generate; a
comparison or prompt-only request does not authorize a paid job. Treat an unknown capability
as unknown and a lack of a compatible model as a constraint, not a service outage.

For a model the user named, check its contract; do not start a new contest between models.
If a current choice and the skills you need are already in context, use them while the
requirements stay the same. A change of inputs, operation or significant constraints
requires rechecking the affected facts; editing the text alone does not require reading the
same catalog or skill again.

Tell a request to choose apart from a request to make. For «сгенерируй фотореалистичного
человека», choose a compatible model yourself and continue preparing the generation. Do not
add a separate reply that explains the choice or asks «какую модель предпочитаете?» when you
have enough data. Explain the choice when the user asks, or when a significant limit or
trade-off needs their decision. Preparation does not replace the price check or the user's
permission to launch.

## Comparison method

1. Define the required result and the required inputs: text, a start frame, a reference,
   a source video, text to be spoken or other material.
2. Pick out the criteria that matter to the user: quality, speed, cost, editing, exact text,
   identity, sound or another explicit priority.
3. Compare the candidates by purpose, inputs, limits, defaults and price.
4. Choose one exact id. In a consultation, name the significant trade-off; in a request to
   generate, continue the action if no further decision is needed.

## When there is no exact match

A required condition does not become a preference just because the catalog does not support
it. Offer one useful conditional option: what the user asked for, what a specific model
supports and which requirements would have to change. Name every significant concession, not
only the first conflict you found. A second option is needed only when it offers a different
useful trade-off given the user's priorities.

Use the fields of the current contract, not a closed list of parameters in this skill. Check
the combination of mode, inputs and settings: separate maximums do not prove that they are
available together. Limits on source material and limits on the result are different.
Missing information means the capability is unknown, not that it is proven absent.

Before preparing or proposing a generation, agree with the user on any change to required
conditions, a replacement of a model they explicitly chose, or dropping materials or required
content. Permission already given for such a trade-off still holds; do not ask again. Combine
related concessions into one concrete question. If the user has not settled a choice between
conflicting priorities, do not make it for them silently.

For a chain of steps, check the capabilities of each step and whether their inputs and outputs
are compatible. Separate the native result from post-processing; report losses, and do not
promise exact preservation of identity or continuity across a splice. If there is no confirmed
useful alternative, explain the obstacle and the smallest change that would let the work
continue. Do not reduce the answer to the word "impossible", and do not invent a workaround.

If the current context is enough, do not reread the catalog or a skill just to explain a
trade-off. You need new information only for facts that are missing or have changed.

If the current catalog names Givon's primary pick for the task, use that recommendation among
the compatible models. Do not answer with a list of equal names or with "it is impossible to
choose" when the request allows a useful primary option. When speed or price is the priority,
consider suitable low-cost models, even if they appeared less often in the user's history.
Cheaper does not mean "draft only"; do not forbid final use without a concrete limitation.

## Evidence and freshness

Distinguish technical compatibility, Givon's recommendation, a measured result, a provider's
claim and creators' practice. Comparisons, benchmarks, popularity and social media examples are
useful as dated evidence: take into account the exact version, the task and what exactly was
compared. Popularity can explain why a workflow is common, but it does not override
incompatible inputs or an important limitation.

Do not present a saved review as a continuously updated ranking or trend monitoring. An older
list of models does not override the current catalog. If the user asks for a fresh summary,
use the available verification tools and name the date; if there are none, separate saved
information from what is not verified right now. An ordinary choice does not require
researching the whole internet again: give a primary option based on the relevant evidence you
have. A reason belongs in a consultation, not in an obligatory extra reply before every
generation.

Check a model the user named against its current contract. Do not rank from memory, by provider
or by keywords, and do not invent a universal "best" option.

View saved version →

---
name: music-bed-for-clip
description: "For background music fitted to a video, use the clip or its timing and mood to produce a music brief with structure, accents and space for speech where present. Not needed for a standalone song or for sound effects without music."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Music bed for a clip

A music bed supports the mood, action and editing of a clip. How prominent it is, its dynamics
and its structure follow the user's goal and the clip itself: it can leave room for speech,
underline the action or become the leading musical layer.

## Rules for a music bed

- **Account for speech when there is any.** If a voiceover will sit on top of the bed, leave
  gaps in the midrange and keep the melody restrained, so the voice reads clearly on top
  without fighting the music.
- **Dynamics follow the role of the music.** An even bed, accents, climaxes, pauses and
  contrasts are chosen to fit the requested edit and dramatic arc.
- **Transitions are synchronised.** Smooth or sharp transitions go where they support the
  action, a cut or an effect the user asked for.

## Mood for the type of clip

Infer mood, tempo, genre and the musical role from the request, the action, the edit, the speech
and any available references. If the user left the creative decision open, choose a consistent
option from the context and name it in the result.

## Duration to match the running time

Tie the length of the bed to the length of the clip. If the clip has a known length, give the
exact duration for its running time, so the track neither cuts off nor sags at the end. If the
length cannot be derived from the clip, the current context or the available settings, ask for
it as a required input.

## Where to leave gaps for the voice

If the clip has speech, plan the stretches where it sounds and free the frequency and dynamic
range it needs. If there is no speech, do not add this structure artificially.

## Final brief

The final brief pins down the mood, the duration, the musical role, the structure of the clip
and the stretches with voice, if there are any. The music matches the requested action and the
rhythm of the edit.

View saved version →

---
name: neuro-photoshoot
description: "For a series of several photos of the same product: a separate brief per shot, with shared identity anchors and deliberate variation in angle, setting or light. Not needed for a single shot."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Neuro photoshoot: a series from a brief

The method's task is a series of shots of one product with exactly the degree of visual
connection and variation the user asked for. Consistency rests on the anchors chosen for the series and on the
reference capabilities of the chosen model.

## Stable anchors and variables

Before the series, fix only the shared anchors that must stay stable:

- the background and its character (white / neutral / a specific scene);
- the character of the light (soft studio / directional / natural) and its direction;
- the palette and the overall mood (clean e-commerce / warm lifestyle / premium);
- the product itself as a fact: its cut, color, material, logo and hardware stay as in the
  source.

Background, light, palette and mood may be shared or may change between frames; the goal of the
series decides this, not a fixed template.

## Set of angles

A series for a listing usually takes angles that complement each other rather than duplicates:

- the main frame — the product large and whole, from the front;
- a detail — a close-up of the texture, a seam, the hardware or the key feature;
- in context — the product in hands or in use;
- lifestyle or scene — the product in an interior or a setting of use.

Adapt the set to the product type and the request. Do not chase the number of frames; make sure
each frame shows something new and fits the purpose of the series.

## Keeping the series unified

1. Define the stable anchors and the variables from the user's goal.
2. Give each frame a self-contained brief with the shared anchors it needs and its own changes.
3. For the identity you need to hold, use the reference controls and limits from the chosen
   model's live contract.

## Light, background, format

Keep light, background and format shared only when this is part of the chosen consistency or the
purpose of the series; otherwise follow the requested variation. Take the marketplace's exact
size and background requirements from current verified materials when they affect the result.

View saved version →

---
name: positioning-and-message
description: "For positioning or a core value proposition, use the offer, audience and available evidence to develop a distinct promise and supporting message hierarchy."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Positioning and messages

Formulate positioning for a product, project, creator, character, series or campaign, at
exactly the scale of the request. Use the confirmed features from the materials; mark potential
insights about the audience and the market as hypotheses.

## Working system

1. Name the audience or the choice situation, if it is given.
2. State the tension or the task that the offer resolves.
3. Pick out a distinct promise and the way it is delivered.
4. Connect the promise to the available reasons to believe.
5. Build the hierarchy: the main idea, supporting messages and acceptable proof.

Match the strength of the promise to the available proof. Make options differ by strategy,
audience or the basis of value. When one result is needed, choose the strongest direction and
justify it. Include specific ads, posts and headlines to the extent needed to apply the
strategy.

View saved version →

---
name: product-on-model
description: "When a person must wear or hold the product in the frame: choose the shot size and pose so that the product stays recognizable and its cut, color, material and details survive. Not needed when no person appears, such as a packshot or a still-life scene."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Product on a person

Build a frame in which the product stays recognizable, while the person, the pose and the setting
serve the user's idea.

## Product accuracy

- Carry over the meaningful traits of the source product: cut, silhouette, color, material,
  print, logo, lettering and hardware.
- Name explicitly the detail that matters to show, and choose an angle where it reads.
- For small elements, use a separate close-up when the chosen generation model does not hold
  them in a wider shot.

## Frame and pose

Choose the shot size and the pose for the request and for the product's visibility: a wide shot
for the silhouette, a tighter frame for an accessory or for how the product is used, a close-up
for material and details. Follow the user's scene and mood; when the brief is incomplete, choose
a consistent solution from the context.

View saved version →

---
name: selling-slide-composition
description: "For a set of two or more marketplace slides that must read as one series: shared palette, lettering, label rhythm and grid, with each slide's layout following its purpose. Not needed for a single slide."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Selling slide composition

Composition follows the content of the specific slide, the marketplace's conditions and the
available visual material. Choose the structure and the number of text blocks for the current
task. In a set, the per-slide rules below apply to every slide, and the set rules keep the series
together.

## Attention hierarchy

Decide what the viewer should notice first, and build the other elements around that priority.
Choose the scale of the product, the text, the details and the free space by the slide's purpose
and the brief you were given.

## Where to put text

- Leave a clean field for the lettering: do not put text on a busy or occupied part of the photo,
  where it gets lost.
- Do not cover the product with text: lettering and labels go around the product, not over its
  key details (logo, shape, texture).
- Keep a safe margin from the edges of the frame, because the marketplace may crop the image or
  overlay its own UI.

## Text in the frame

Match the amount of text to the frame size and the confirmed capabilities of the model. Pass the
exact text and its role explicitly; if the brief is overloaded, suggest a suitable split without
changing the meaning.

## One style across the set

For a coherent series, set a shared visual direction and keep only the truly important traits:

- **palette** — consistent base and accent colors;
- **lettering character** — one tone for all the lettering (for example, a dense grotesque for
  the offer), described in words in the prompt rather than by picking a font in a builder;
- **label rhythm** — the same position and shape of the text labels from slide to slide;
- **composition grid** — the product and the text in similar zones on every slide of the set.

Vary the composition by each slide's purpose while keeping a recognizable link between the
slides.

## Adaptation

- Take the format and dimensions from the request, the marketplace's current requirements and the
  values the chosen model supports.
- When micro-parameters are missing, choose a consistent style from the product, the niche and the
  brand, and state the decisions you made.
- For text in the frame, choose the model by the current catalog and its confirmed ability to
  reproduce lettering.

View saved version →

---
name: story-conflict-design
description: "Social-drama engine for a fictional persona series in the fall-and-rebuild format: conflict core, trigger, low point, turn and path with lived-in details, from the team library. For a story in another genre, build the conflict directly."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Conflict and story engine

Find a social conflict that fits the hero's canon, the audience, the stage of the hero's path
and the user's task. The result can be one idea, a list of different angles, the core of an
episode or an arc, but every idea must already contain a working engine, not just a theme.

## Diagnosing an idea

For every new idea, check the required chain:

- core: what breaks the hero's life or what collides irreconcilably;
- trigger: which concrete event starts the fall now;
- low point: where the reset to zero, the loss or the isolation becomes visible;
- turn: what the hero decides to do differently;
- path: which observable change carries the series;
- 3–5 real details that prove the idea is true to life.

Even when the result is a single line or a hook, build this causality internally first and
then compress it. Don't hand out ten surface-level phrasings of the same pain.

## Plausibility

Ground the conflict in the canon and the materials provided. Separate given facts from
creative hypotheses. Vary the emotional angle between ideas: injustice, shame, betrayal,
powerlessness, hope, anger, envy or contrast. A detail must reveal a cost or an action: a
place, an object, a document, an interface, a habit, a line of speech, a witness, a deadline
or everyday friction.

Read the full [library of social conflicts and pains](references/story-engines.md): it is the
required working library of cores, details, turns, red lines and path promises. For sensitive
topics, keep the hero's dignity and focus on consequences, support and recovery.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: vertical-series-showrunning
description: "Episode script or mini-season for a fictional persona series on Reels, TikTok or Shorts: hook, timed beats, on-screen text, visual brief, captions and a next-episode hook. For a one-off promo or brand video, write the script directly or use video-shot-planning."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Vertical script and mini-series

The result matches exactly the scale the user asked for: from a set of hooks or one finished
episode to a connected mini-season arc. If the user asks for a script right away, don't make
them choose from a list of themes first. Use the two-stage "ideas → script" mode for a broad
request where the direction really hasn't been chosen yet.

## Building an episode

- Make the stakes or the intrigue clear in the first 1–2 seconds, unless the genre calls for
  something else.
- Every 2–3 seconds give a micro-turn: a new shot, fact, object, line or caption changes the
  understanding or the action.
- Keep the exact action the user described, the hero's canon and the important visual anchors.
- Match the number of events to the given duration and pace; fit the timing grid to the specific
  video.
- Use at least three concrete functional details in a finished script.
- For a video without speech, build the meaning only through shots, actions, ambient sound and
  captions.

Choose the pattern by the stakes and the stage of the path, not by a matching word. In a
finished script, name the pattern explicitly and explain the choice in one sentence. By
default, give the goal, a script by seconds, the on-screen text, a visual brief, three versions
of the post caption, a soft CTA and a hook into the next episode; if the user set a different
result contract, follow theirs.

Read the full [library of viral script patterns](references/vertical-story-patterns.md): it is
required for choosing the episode's engine, structure, retention and mini-season. Don't promise
virality as a fact: patterns strengthen contrast, stakes, truth, specifics and serialization,
but they don't guarantee reach.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: video-identity-consistency
description: "When a character or product must stay recognizable across shots, use its references or established visual traits and the model's reference controls to set stable identity anchors and continuity guidance. Not needed when no character or product recurs across shots or clips."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Identity across shots

First use the mechanisms the chosen model offers: references, elements, start frames or
identity controls. Text descriptions of the subject's traits supplement this contract where
they help the model hold the subject.

A reference keeps a subject recognizable, not identical. When the user needs the exact pet,
product or person from a photo, start the video from a frame that already contains the subject
and was approved as an image: the frame-first path in `footage-transformation-vfx`.

## Visual anchors

Choose a few traits that truly distinguish the subject: shape, colour, material, texture,
clothing, hardware, logo or a characteristic detail. Repeat them in the same stable wording
from shot to shot when the model's prompting guide recommends text anchoring.

For a product from a reference, take the traits from the asset and keep the user's requirements
for shape, colour, texture and markings. For a character, keep only the traits that matter for
the request and are supported by the available references.

## Series coherence

Keep the chosen style core (light, palette, lens character and camera motion) consistent
exactly as far as the series needs. Change the action, setting or angle according to the plan
while keeping the subject's recognizable anchors.

View saved version →

---
name: video-prompt-craft
description: "For a generation-ready video prompt, turn the scene or shot plan and the chosen model's contract into action, camera, timing and sound instructions. Not needed for a storyboard without final wording or for choosing a model."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Professional video prompt preparation

A video prompt directs change over time. It has to answer not only "what is in the frame" but
also "what happens, how it develops, how the camera behaves and what stays unchanged". A
retelling of the idea without staging decisions is not a finished prompt.

## 1. Define the task and the end result

Distinguish:

- `text-to-video`: the whole scene is built from text;
- `image-to-video`: the image already sets the look and the opening composition;
- `reference-to-video`: separate assets set identity, product, style, motion, camera, effect
  or sound;
- `video edit / transform`: one specific property of the source video changes;
- `extension / transition`: a continuation or a transition between states is needed;
- `single shot`: one continuous scene;
- `multi-shot`: several meaningful shots with transitions and continuity.

An explicit subject, action, order of events, lines, style and exclusions belong to the user.
Do not ask about every setting. When a decision does not change the meaning and the chosen
model supports it, make it yourself: the duration within the available range, framing, camera,
light, the character of the motion and, when the clip has sound, the character of the sound.
Ask a question only for a real blocker.

## 2. Assign a role to every media asset

For each image, video and audio file, state its exact role:

- source, start or end frame;
- character or product identity;
- style, composition or location;
- motion, camera or effect reference;
- dialogue, voice, music or ambience reference.

Use pixels, frames and confirmed metadata within that role. Do not carry appearance over from a
motion reference, motion from a style reference, or a whole interface screenshot into the final
scene. File names help you find the material, but they do not replace its content.

## 3. Follow the chosen model's contract

Use only the confirmed input modes, durations, audio capability, slots and settings. Do not
guess capabilities from the brand or the model name. A video reference does not by itself make
an edit or extension operation available. Start and end frames set the states of a transition,
while references set identity, look, motion, style or audio: do not combine the two when the
contract declares them incompatible, and do not add references to boundary frames on your own.

The chosen model's current prompting guidance owns model-specific syntax;
its live contract owns available fields.
When the task needs one of these general methods, read only the matching reference:

- Editing a source video (for example with Seedance 2.5, Gemini Omni or SwitchX):
  `references/source-video-edit.md`.
- Style transfer or fixing a specific visual defect: `references/style-and-revision.md`.

A reference does not replace the current inputs and settings from the catalog; do not load the
other file in advance.

Duration, aspect ratio, resolution, quality and the audio flag belong to typed settings. The
prompt describes the creative result. If the user asks for a clip longer than one model output,
offer a supported segment and a plan to assemble it from several pieces instead of an error or
a prompt that cannot be executed.

## 4. Build the director's brief

Before writing the final text, decide:

1. **the subject and the observable action**;
2. **starting state → development → end state**;
3. **spatial relationships** and the direction of motion;
4. **framing and camera behaviour**;
5. **setting, light, palette and atmosphere**;
6. **the physical response** of clothing, hair, liquid, smoke, surfaces and objects;
7. **continuity and invariants**;
8. **sound intent**, only when the audio setting is on: the sound the scene produces, plus
   speech or music when the user asked for them.

Make the missing non-essential decisions yourself and tie them into one direction. Do not add a
new main character, product, plot twist, line of dialogue, music, caption or advertising
promise.

## 5. Structures for different inputs

### Text-to-video, single shot

```text
[Subject and starting position]. [One clear action and how it develops].
[Setting and spatial relationships]. [Shot size/angle and one consistent camera move].
[Light, palette, atmosphere]. [Physics and important invariants]. [Sound the scene produces, only when audio is on].
```

Motion has to be observable: instead of "dynamic", describe exactly what speeds up, turns,
opens up, scatters or changes. Do not overload a short shot with several independent events and
conflicting camera moves.

### Image-to-video

The source frame already owns the appearance, the objects, the angle and the opening
composition. So the prompt is built like this:

```text
SOURCE: @Image1 — the opening frame.
MOTION: one feasible motion that fits the source's pose, framing and duration: who or what starts moving and how it develops.
CAMERA: one consistent camera behaviour.
PHYSICS: the natural response of materials and surroundings.
KEEP: identity, product shape, key background, light or composition that must not be lost.
END STATE: the observable state at the end of the shot, if it matters.
SOUND: only the sources that are needed, and only when audio is on.
```

Do not retell the whole source image, and do not invent product properties the image does not
show. Do not demand "complete stillness" from elements that need a slight physical response to
look real.

### Video edit / transform

Name the source video, the exact change, the boundaries of the change and the properties to
keep. If the background changes, do not change the motion or identity; if the clothing changes,
do not rewrite the whole story; if an effect is added, tie it to an object and a moment.

### Reference-to-video

Use the aliases exactly as the host gave them, without renumbering, and state each one's role
explicitly:

```text
@Image1 sets the character's identity.
@Video1 sets only the camera movement.
@Audio1 sets the editing rhythm, not the character's voice.
```

Then describe the new scene. Do not use an alias that does not exist, and do not silently merge
different roles.

## 6. Single-shot and multi-shot are different artifacts

Do not turn a simple scene into a storyboard. A single shot gets one whole action, one camera
move and continuity.

For a genuinely multi-beat result, build a director packet. For each shot, give:

- its purpose or beat;
- the observable action;
- shot size, angle and composition;
- the camera movement;
- light and mood;
- the starting and ending boundary state;
- dialogue, SFX or ambience, when needed and the audio setting is on.

Distribute the shots within the available duration. Hard timestamps are needed only when they
help synchronization or the target model requires them; for a simple gesture, "first… then…" is
enough. Keep identity, product shape, direction of motion, the screen axis, time of day and
colour consistent across shots. A transition has to connect the end state of one shot with the
starting state of the next. Start and end frames reduce drift at the seam between clips, but
they do not guarantee an invisible cut, the same voice or exact geometry.

## 7. Sound follows the audio setting

Whether the clip has sound is the audio setting's call, not the prompt's. Do not ask the user
a separate "with or without sound?" question when the task is clear. The prompt follows the
value the generation runs with: an untouched switch means the model's default, and a model that
generates sound but has no switch always has sound on. When the task clearly calls for silence
(a silent product animation) or for sound (an ad, an atmospheric or talking scene) and the model
has a switch, set the audio setting accordingly instead of writing the wish into the prompt.

- When sound is on, direct the sound the scene produces: ambience and the sounds of visible
  actions and materials. Choose their character yourself.
- Add speech or music only when the user asks for them. Do not invent lines, lyrics or an exact
  voiceover; a voice reference does not license a new line either.
- «Без речи» ("no speech") rules out speech, not necessarily ambience or the sounds of the
  setting.
- When sound is off, leave sound out of the prompt.

If the chosen model's contract cannot produce a sound the user asked for, do not put an
impossible demand into the prompt: plan that sound as a separate sound layer.

## 8. Full examples

### Image-to-video: a sneaker box

```text
SOURCE: @Image1 — the red Nike box and the source close-up composition.
MOTION: a woman's hands enter the frame naturally, carefully untie the gift bow and move the
ribbon aside, then take the edges of the lid and lift it smoothly. The actions follow one
another, without jumps or extra objects.
CAMERA: static vertical close-up, no zoom and no change of angle.
PHYSICS: the ribbon bends softly and settles beside the box; the fingers and hands move with
natural anatomy; the lid keeps its rigid shape and opens on its real hinge axis.
KEEP: the red colour, shape, proportions, material, logo and look of the box; the source
background and light direction.
END STATE: the lid is slightly open, the hands hold it, and the box stays in the centre of the
frame.
SOUND: a quiet rustle of ribbon and cardboard, no speech and no music.
```

When the audio setting is off, leave the last line out of the prompt.

### Text-to-video: a short ad shot

```text
White sneakers stand on a dark matte pedestal. A narrow beam of cool light slides from left to
right along the side, revealing in turn the leather texture, the stitching and the sole; at the
end a warm rim highlight appears on the heel. The camera makes a slow arc of about a quarter
turn at product level, keeping the sneakers centred, with no change of focal length. Dust in the
air reacts faintly to the motion, and the contact shadow stays stable. Minimalist premium
product-film look, a deep background with no text, people or extra objects.
```

This example assumes the audio setting is off. With audio on, end it with the sound the scene
produces.

### Multi-shot packet

```text
Shot 1 — establishing: an empty workshop at dawn, wide static shot; a closed album lies on the
table, cold light comes from the window.
Shot 2 — discovery: medium shot from above, a hand opens the album; the camera moves in
smoothly, the pages turn physically and stop at a photograph.
Shot 3 — reaction: close-up of the heroine from @Image1, her gaze softens; warm light reflected
from the page, a barely noticeable camera move forward.
Continuity: the same heroine, clothing, table, window-light direction and album position.
Audio: a quiet rustle of pages and the morning ambience of the workshop, no music and no speech.
```

When the audio setting is off, leave the Audio line out.

## 9. Final check

- the task matches the input mode;
- the action and its progression over time are visible;
- every asset has an exact role and alias;
- the event load is realistic for the duration;
- the camera does not contradict itself;
- physics and invariants protect what matters without freezing the whole frame;
- sound follows the audio setting: the scene's sound when it is on, speech or music only on
  request, no sound in the prompt when it is off;
- the prompt is not a retelling or a UI instruction;
- settings stay typed fields;
- a single shot is not inflated into a multi-shot, and a multi-shot has continuity;
- when the same defect repeats across results, a stronger lever beats new wording: a reference
  image, one simple action, a shorter clip, a first or last frame, or fewer subjects.

Reference aliases apply only when the chosen model declares inline-reference support.
Bind them to actual reference order and roles; for dedicated source/start/end fields,
use the slot role instead of inventing an alias.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: video-shot-planning
description: "For a storyboard or shot list, turn the video brief and target duration into ordered beats or shots with action, camera and transitions. Not needed for one continuous shot unless the user asks for a plan; for final model-ready wording, use video-prompt-craft."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Storyboard and video script

The structure of the clip follows the user's request: an event, a scene, a story, a
demonstration or material for an edit. A commercial hook, a product hero shot and a CTA appear
only in a commercial brief, where they serve the clip's goal.

## Choose a sufficient form

- Keep one continuous episode as one shot.
- Break a story with several states into short, causally linked beats.
- Make a storyboard when the user asks for a plan or an edit sequence, or when the chosen model
  supports multi-shot.
- Mark hero shots when the brief has visual moments that need special emphasis.

## What a shot contains

For each shot, record only the differences that matter: subject, action, setting, framing,
camera, light, sound or transition. The details that set this shot apart from its neighbours
and hold the user's intent are enough. Adapt the form and terminology to the chosen model's
current guidance.

## Continuity

- Keep the causality and the order of actions from the brief.
- Repeat important visual anchors between shots, using the references and consistency tools the
  model supports.
- Pick a small, consistent set of transitions when transitions are needed at all.
- Match the number of events and lines to the available duration.

When movement is requested, the final plan should clearly show how the subject, the scene or the
camera moves.

View saved version →

---
name: voiceover-for-video
description: "For generating narration from agreed words, use the exact spoken text and current model voice controls to separate speech content from delivery settings. Not needed for writing or editing the script itself."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Voiceover for video

Follow the confirmed contract of the chosen model. Keep the creative task separate from the
exact text to be spoken, and use only the declared delivery parameters.

## Text to be spoken

Put the exact approved spoken words into `input.prompt`. Preserve wording, numbers,
abbreviations, names and pauses. Use inline audio tags only when the model's current prompting
guidance supports them and the user included or requested that delivery.

## Delivery

Read `givon_get_model_schema` for the chosen voiceover model. List voices through
`givon_list_voices` (CLI: `givon voice list`) and pass the chosen id as `input.voice`.
Use only delivery controls exposed as flat properties in that schema, with their declared
values and defaults. Do not assume a project-default voice or copy fields from an internal
chat contract. Keep delivery instructions separate from words that should actually be spoken.
Quote this exact input and continue through `givon-ai-create` after approval.

View saved version →

---
name: writing-content-plan
description: "For a content calendar or publication series, use the goal and available channel, audience, period and cadence context to produce concrete topics, formats and a publishing sequence. Not needed for a single post (use writing-social-and-email)."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Content plan

Build the plan in the form the user asked for: a list of directions, a set of recurring sections,
a calendar, a publication series or a combination of these.

## Basis

Take into account the goal, the platform, the period, the audience, the available materials and
the realistic publishing frequency. Ask only about a decision that would noticeably change the
plan; infer the rest from context and briefly state the assumptions you made.

## Content

- Choose recurring sections that serve the goal and yield enough distinct topics.
- Alternate formats and content purposes in a proportion that suits the project.
- Formulate concrete topics, and the next step when a publication needs one.
- For a calendar, give the date or day, the topic, the format and the goal of each publication;
  add other columns only when the task needs them.

Tie numeric forecasts of results to a measurable baseline that has been provided. The plan itself
fixes topics, formats and rhythm, not a promise of metrics.

View saved version →

---
name: writing-headlines-and-hooks
description: "For finished headlines, opening hooks or concise value-proposition variants, use the topic, facts, tone and requested count to produce distinct ready-to-use lines."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Headlines, hooks and USPs

Deliver the text in the quantity and form the user asked for. Keep the given tone, platform,
audience and facts; with an open creative brief, offer genuinely different angles, not the same
words rearranged.

## What a good result looks like

- A headline quickly conveys a promise, intrigue, an event or a concrete benefit that fits the
  task.
- A hook matches the content that follows it and does not have to follow a sales formula.
- A unique selling proposition (USP) names a meaningful difference when the user has given a
  basis for that comparison.
- Add notes to the variants only when they help the user choose.

AIDA, PAS, BAB, a question, a contrast, specifics and a story can all serve as creative
supports. Choose them by the meaning of the request, and depart from them freely for the sake
of a more precise text.

Tie factual credentials, statistics, testimonials and comparisons to the user's data or the
project's materials. Keep a hypothetical or fictional context as such.

View saved version →

---
name: writing-marketplace-card
description: "For product listing text fields, use product facts and requested marketplace fields to write or edit titles, descriptions, bullets or FAQ."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Marketplace card text

Produce exactly the fields the user needs: a title, a description, bullets, search phrases, an
FAQ, rich-content text or the full set. Take the current limits and rules of the specific
marketplace from verified materials when they affect the result.

## Meaning

The order of information follows the task and the format of the field. Buyers are usually
helped by:

- a clear name of the product and what it is for;
- meaningful benefits and usage scenarios;
- concrete specifications, composition or contents of the package;
- answers to important questions and objections.

Use keywords naturally and in proportion to the text. When there is a search keyword core,
keep its priority phrases; without one, write clear human text first of all.

## Facts and creative freedom

Keep the specifications, terms, certificates, reviews and numbers you were given. When the
request implies a hypothetical example or a creative concept, follow that context. For text
meant for publication, keep a missing required fact visibly separate from the finished wording,
so the user can fill it in quickly.

Before delivering, check that the result matches the requested fields, the marketplace's
limits, the tone and the source data.

View saved version →

---
name: writing-social-and-email
description: "For ready-to-use posts, emails or messages, turn the topic, available facts and requested channel and tone into finished copy or edits, including a series when requested."
metadata:
  version: skill-render-ea6bd93365667f6d
---

# Posts and mailings

Start from the user's result: a finished post, an email, a series of messages, an edit or a
structure. Use the channel's features as context, and take the form and length from the request.

## Building the text

- Write a strong opening that fits the goal of the message.
- Develop one coherent idea, or build a sequence if the user asks for a series.
- Add a call to action where the goal needs one; an informational, fictional or conversational
  text may have none.
- Keep paragraphs, length and tone that suit the channel.

For a promotion or an offer, convey the given terms, price, deadline and guarantees exactly. For
a creative or hypothetical text, follow the world the user set, and mark assumptions only when
that helps the user use the result.