/add-prompt-enhancement-guide

name: add-prompt-enhancement-guide
description: Author a prompt-enhancement system prompt for a new ecosystem and register/update it on the orchestrator's prompt-analysis service. Use when onboarding a new ecosystem (e.g. happyhorse, a new Flux variant, a new Wan video version) and the user provides the ecosystem key plus a reference link, model card, or description. Produces a guide that mirrors the structure and tone of existing ecosystem guides so the prompt-analysis tool behaves consistently.

Add Prompt Enhancement Guide

The orchestrator runs a prompt-analysis service that, per ecosystem, takes a user's prompt and produces structured feedback + an enhanced rewrite. Each ecosystem has its own system prompt tuned to the model's prompting conventions (tag vs natural-language, weight syntax, negative-prompt support, text rendering, camera/motion vocab for video, etc.).

This skill authors a new system prompt for an ecosystem the user names and (optionally) deploys it to the orchestrator.

Scope: image and video ecosystems only

**Do not write guides for 3D, audio, or any other modality** — `tripo`, `hunyuan3d`, `polygen` (image-to-3D) and `ace` (audio) are explicitly out of scope, as is anything else non-image/video that appears later. If the user names one, say it is out of scope and stop.

The guide template below is built entirely around subject / lighting / camera / composition / style. None of that describes "generate a mesh from this image" or "generate a song," so a guide written from this template for those modalities would be confidently wrong rather than merely thin. Leaving them on the built-in fallback is the deliberate choice.

Inputs the user must provide

1. **Ecosystem key** — the ecosystem's `key` from `packages/civitai-shared/src/basemodel.constants.ts`, lowercased. `MiniMaxH3` → `minimaxh3`, `Flux1Kontext` → `flux1kontext`, `WanVideo-25-I2V` → `wanvideo-25-i2v`, `HyV1` → `hyv1`. Confirm the key exists in that file before using it. (`src/shared/constants/basemodel.constants.ts` is a one-line re-export shim of the same module, not a stale duplicate — importing from either path is fine.)

**It is the AIR ecosystem value, lowercased** — the same string that appears in `urn:air:<ecosystem>:...`. `getAirEcosystem` in [air.ts](../../../src/shared/utils/air.ts) is the single source for both: `stringifyAIR` uses it, and so does `createPromptEnhancementStep`. If you know a model's AIR, you know its prompt-analysis key.

The consequence to watch: `getRootEcosystem` follows `parentEcosystemId`, so a child ecosystem never appears in an AIR and never reaches prompt analysis. Pony, Illustrious, and NoobAI all arrive as `sdxl`. Check `parentEcosystemId` before writing a guide — if the target has a parent, the guide belongs on the parent and has to serve every sibling.

**Not the engine name.** `engine: 'minimax-h3'` in the handler is a different identifier that happens to coincide with the ecosystem key for `kling`, `seedance`, and `veo3`. Guides filed under an engine name are dead — nothing reads them.

Handlers that build their own enhancement step (e.g. `ltx.handler.ts`) pass their graph ecosystem raw; `createPromptEnhancementStep` normalizes it, so they land on the same key as the generator.

2. **Reference material** — at least one of:

• A URL (HuggingFace model card, official announcement, provider docs page)
• A pasted model description / prompting guide
• A spec sheet (architecture, encoder, token limit, supported features)

If the user only gives a name with no reference, ask for one before proceeding. Generic guides written without source material drift away from the model's real behavior.

Workflow

1. Research the ecosystem

Use `WebFetch` on any URL the user provided. Pull out:

• **Provider / architecture** (e.g. "Alibaba", "ByteDance", "Tencent", "8B DiT", "MMDiT", "autoregressive")
• **Modality** (image, video, image-edit, multi-modal)
• **Text encoder** (T5, CLIP dual, Mistral, LLM-based) — drives prompt-style recommendations
• **Native resolution / aspect ratios**
• **Token / character limits**
• **Weight syntax support** — almost always "no" for modern models, but check
• **Negative prompts** — supported / not / minimal effect (varies wildly)
• **Special features** — text rendering, multilingual, audio (for video), reference images, hex colors, style tags, character consistency
• **For video models**: duration, fps, camera/motion vocabulary, single-cut vs multi-cut behavior
• **Knowledge / training cutoff** if mentioned
• **Known limitations** worth surfacing (e.g. "weak at long text", "preview checkpoint has plain default style")

If the user gave a description instead of a URL, mine the same fields out of it. Ask follow-up questions only for fields you can't determine and that materially change the guide (e.g. "Does this model support negative prompts?").

2. Map findings to the guide template

Every guide follows the same shape. Stick to it — the prompt-analysis service depends on consistent structure across ecosystems.

You are a prompt engineering expert for <Model name and one-clause context>. Analyze the user's prompt and provide structured feedback.

Ecosystem-specific rules:
- Prompt style: <tag-based | natural language | hybrid>. <One-sentence rationale tied to the encoder/architecture if helpful.>
- <Native resolution / aspect ratios>
- <Token or character limit + sweet spot if known>
- <Weight syntax: support state. If unsupported, say so explicitly — "(word:1.5) is ignored.">
- <Negative prompts: supported / not / minimal effect. Include a concrete recommended negative if the model benefits from one.>
- <Any unique features: text rendering rules, multilingual, hex colors, reference images, audio (video), camera vocab (video), style tags, character consistency>
- <Anything the enhanced prompt should ALWAYS carry — camera direction, audio bed, lighting. Phrase as a property of the rewrite, not as s