civitai system prompt

--- name: ux-design description: UX design methodology and external consultation. Use when creating user flows, wireframes, interaction patterns, or getting UX feedback. Provides structured frameworks for user-centered design. --- # UX Design Skill A comprehensive UX design methodology for creating user-centered products. Use this skill when designing user experiences, creating flows, evaluating usability, or getting external UX feedback. ## Core UX Principles ### 1. Jobs-to-be-Done (JTBD) Focus on what users are trying to accomplish, not features. ``` Template: When [situation], I want to [motivation], so I can [expected outcome]. Example: When I have a character I love, I want to generate comic panels with them, so I can tell stories without learning to draw. ``` ### 2. Progressive Disclosure Show only what's needed at each step. Complexity emerges as users need it. ``` Level 1: Core action (upload, generate) Level 2: Basic options (style, description) Level 3: Advanced controls (parameters, fine-tuning) Level 4: Expert features (custom LoRAs, composition) ``` ### 3. Recognition Over Recall Users should recognize options, not remember commands. ``` Bad: "Enter LoRA weight (0.0-1.0)" Good: [Slider with preview] "Style strength: Subtle ←→ Strong" ``` ### 4. Error Prevention > Error Recovery Design to prevent errors, not just handle them gracefully. ``` Example: Disable "Generate" until character is locked, not "Error: No character" ``` ### 5. Immediate Feedback Every action should have visible response within 100ms. ``` - Button press → visual state change - Upload → progress indicator - Generation → status updates ("Analyzing face...", "Applying style...") ``` ## UX Design Process ### Phase 1: Research & Discovery ``` 1. User Interviews - Who are the target users? - What are they trying to accomplish? - What do they currently use? What's frustrating? - What would "magic" look like? 2. Competitive Analysis - What do competitors do well? - Where do they fail? - What's the table stakes? - What's the differentiation opportunity? 3. Jobs-to-be-Done Mapping - List all user jobs - Prioritize by frequency × importance - Identify underserved jobs 4. User Personas - 2-3 primary personas - Goals, frustrations, context - Technical proficiency level ``` ### Phase 2: Information Architecture ``` 1. Content Inventory - What content/features exist? - How do they relate? 2. Site/App Map - Hierarchy of screens/pages - Navigation structure 3. User Flows - Primary task flows (happy path) - Error/edge case flows - Entry and exit points ``` ### Phase 3: Interaction Design ``` 1. Wireframes - Low-fidelity layouts - Component placement - Information hierarchy 2. Interaction Patterns - How does each element behave? - State transitions - Micro-interactions 3. Responsive Considerations - Desktop, tablet, mobile breakpoints - Touch vs mouse interactions ``` ### Phase 4: Visual Design ``` 1. Design System - Typography - Color palette - Spacing/grid - Component library 2. High-Fidelity Mockups - Pixel-perfect designs - All states (empty, loading, error, success) - Dark/light mode if applicable 3. Prototypes - Interactive clickable prototypes - Animation/transition specs ``` ### Phase 5: Validation ``` 1. Usability Testing - Task completion rates - Time on task - Error rates - User satisfaction 2. A/B Testing - Hypothesis-driven experiments - Statistical significance 3. Analytics - Funnel analysis - Drop-off points - Feature usage ``` ## UX Deliverables ### User Flow Diagram Format ``` [Entry Point] → (Decision) → [Screen/State] → [Exit/Success] ↓ [Alternative Path] Legend: [ ] = Screen or state ( ) = Decision point → = Flow direction --- = Optional path ``` ### Wireframe Annotation Format ``` ┌─────────────────────────────────────────┐ │ [Component Name] │ │ ┌─────────────────────────────────────┐│ │ │ ││ │ │ ① Element description ││ │ │ ② Interaction behavior ││ │ │ ││ │ └─────────────────────────────────────┘│ │ │ │ Notes: │ │ - Accessibility considerations │ │ - Edge cases │ │ - Mobile behavior │ └─────────────────────────────────────────┘ ① Numbered annotations reference specific elements ② Describe behavior, not just appearance ``` ### State Diagram Format ``` State Machine: [Component Name] States: - idle: Default state - loading: Async operation in progress - success: Operation completed - error: Operation failed Transitions: idle → loading: [trigger: user action] loading → success: [trigger: operation complete] loading → error: [trigger: operation failed] error → idle: [trigger: dismiss/retry] ``` ## Running UX Reviews Use the agent-review skill with UX-focused prompts: ```bash # Get UX feedback on a flow node .claude/skills/agent-review/query.mjs -m opus \ -s "You are a senior UX designer with 15 years of experience in consumer products. Focus on usability, accessibility, and emotional design." \ -f docs/ux-flow.md \ "Review this user flow for usability issues and opportunities" # Evaluate information architecture node .claude/skills/agent-review/query.mjs -m opus \ -s "You are an information architect specializing in complex creative tools. Prioritize discoverability and progressive complexity." \ -f docs/site-map.md \ "Evaluate this information architecture for a comic creation tool" # Get feedback on wireframes node .claude/skills/agent-review/query.mjs -m opus \ -s "You are a UX designer who specializes in creative tools like Figma, Canva, and Adobe products. Focus on efficiency for power users while maintaining approachability." \ -f docs/wireframes.md \ "Critique these wireframes for a comic panel generator" ``` ## UX Heuristics Checklist Use this checklist to evaluate designs: ### Nielsen's 10 Usability Heuristics - [ ] **Visibility of system status**: User always knows what's happening - [ ] **Match with real world**: Uses familiar language and concepts - [ ] **User control and freedom**: Easy to undo, escape, go back - [ ] **Consistency and standards**: Same actions work the same way - [ ] **Error prevention**: Design prevents errors before they occur - [ ] **Recognition over recall**: Options visible, not memorized - [ ] **Flexibility and efficiency**: Shortcuts for experts, simplicity for novices - [ ] **Aesthetic and minimal**: No irrelevant information - [ ] **Help users with errors**: Clear error messages with solutions - [ ] **Help and documentation**: Available when needed ### Accessibility (WCAG) - [ ] **Perceivable**: Content available to all senses - [ ] **Operable**: All functionality via keyboard - [ ] **Understandable**: Clear language, predictable behavior - [ ] **Robust**: Works with assistive technologies ### Emotional Design - [ ] **Visceral**: First impression is positive - [ ] **Behavioral**: Feels good to use, efficient - [ ] **Reflective**: Users feel proud/satisfied after use ## UX Writing Guidelines ### Microcopy Principles ``` 1. Be concise: "Upload" not "Click here to upload your files" 2. Be specific: "3 images required" not "Upload images" 3. Be helpful: "Try a front-facing photo" not "Invalid image" 4. Be human: "Almost there!" not "Processing: 80%" ``` ### Button Labels ``` Good: [Create Comic] [Save Draft] [Generate Panel] Bad: [Submit] [OK] [Go] Action verbs that describe what happens ``` ### Error Messages ``` Format: What happened + Why + How to fix Example: "Character not recognized. We couldn't detect a face in your images. Try uploading photos with a clear, front-facing view." ``` ### Loading States ``` Informative progress, not just spinners: "Analyzing your character..." (0-30%) "Learning facial features..." (30-50%) "Creating style profile..." (50-70%) "Almost ready..." (70-100%) ``` ## Output Templates When creating UX documentation, use these templates: ### User Story Template ```markdown ## User Story: [Title] **As a** [user type] **I want to** [action] **So that** [benefit] ### Acceptance Criteria - [ ] Criterion 1 - [ ] Criterion 2 ### UX Notes - Key interaction details - Edge cases to handle - Accessibility considerations ``` ### Screen Specification Template ```markdown ## Screen: [Name] **Purpose:** What this screen accomplishes **Entry Points:** How users arrive here **Exit Points:** Where users can go from here ### Layout [ASCII wireframe or description] ### Components | Component | Behavior | States | |-----------|----------|--------| | Component 1 | Description | idle, hover, active, disabled | ### Interactions 1. When user does X, Y happens 2. ... ### Edge Cases - Empty state: What shows when no data? - Error state: What shows on failure? - Loading state: What shows during async? ### Accessibility - Keyboard navigation - Screen reader considerations - Color contrast ``` ### User Flow Template ```markdown ## Flow: [Name] **Goal:** What the user accomplishes **Trigger:** What initiates this flow **Actors:** Who is involved ### Happy Path 1. Step 1 → [Screen/State] 2. Step 2 → [Screen/State] 3. Success! ### Alternative Paths - If [condition], then [alternative flow] ### Error Paths - If [error], show [error state], user can [recovery action] ### Flow Diagram [ASCII or mermaid diagram] ``` ## When to Use This Skill - **New Feature Design**: Before writing code, design the experience - **UX Review**: Evaluate existing designs for usability issues - **User Flow Mapping**: Document how users accomplish tasks - **Wireframing**: Create low-fidelity layouts - **Interaction Design**: Define how elements behave - **Usability Evaluation**: Heuristic analysis of designs - **UX Writing**: Craft microcopy, error messages, onboarding text

--- 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. ## Inputs the user must provide 1. **Ecosystem key** — the lowercase identifier matching what the orchestrator returns and what the codebase uses for that ecosystem (e.g. `happyhorse`, `flux2`, `wanvideo-25-i2v`). If unsure, ask the user; do not guess. 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> - <For video: duration, fps, single-take guidance> - <Known limitations worth steering the user away from> - Prompt template: [Section 1] [Section 2] [Section 3] ... Guidelines: - Identify vague or overly generic descriptions - Flag <syntax that is incompatible with this model — e.g. weight syntax on Flux, brackets on HiDream> - Flag <negative prompt attempts when unsupported, OR suggest negatives when this model benefits from them> - <Model-specific flags: photorealism cues on anime models, multi-character without descriptions, scene-cut descriptions on short video clips, etc.> - <Suggestions tied to unique features: quote-wrap text, add safety tags, add audio descriptions, add camera direction> - Limit recommendations to the 3 most impactful improvements - The enhanced prompt should be a single, ready-to-use prompt that stays faithful to the user's original intent ``` The last two bullets in **Guidelines** are required and identical across every guide — keep them verbatim. ### 3. Tone and content rules - **Be concrete.** "No weight syntax — `(word:1.5)` is ignored" beats "weight syntax not recommended." - **Tie suggestions to the model's strengths.** If a model excels at text rendering, the guide must instruct the analyzer to flag missing quote-marks for in-image text. If a model has strong camera vocabulary, the guide must teach the analyzer to flag missing camera direction. - **Call out incompatibility loudly.** If the model ignores negative prompts or weight syntax, the Guidelines section MUST tell the analyzer to flag attempts at them. This is the most common and most useful correction. - **Mention the encoder when it explains a rule.** "T5 understands grammar, so write sentences" gives the downstream model leverage. - **Don't pad.** If the model has no special audio/text/multilingual features, don't invent bullets to fill the section. The SD1 guide is short on purpose. - **Match precedent for similar models.** A new Wan variant should look like the existing Wan guides; a new Flux variant should look like the existing Flux guides. Consistency across siblings matters more than novelty. ### 4. Confirm with the user Before deploying, paste the drafted guide back to the user and ask for sign-off. Highlight any field where research was thin or you had to make a judgment call (e.g. "I assumed negative prompts are unsupported because the model card doesn't mention them — confirm?"). Accept edits. Re-paste the final version after any changes. ### 5. Deploy to the orchestrator (optional) If the user wants the guide pushed live, use the orchestrator manager API. Two env vars are required: - `ORCHESTRATOR_ENDPOINT` — base URL of the orchestrator manager - `ORCHESTRATOR_ACCESS_TOKEN` — bearer token with manager scope Endpoints: - `GET /v1/manager/prompt-analysis/{ecosystem}` — check whether the ecosystem is already registered. 404 means it isn't. - `POST /v1/manager/prompt-analysis` with body `{ "ecosystem": "<key>" }` — register a new ecosystem. Expect 204. - `PUT /v1/manager/prompt-analysis/{ecosystem}` with body `{ "systemPrompt": "<full guide>", "modelId": "<analysis-model-id>", "samples": [] }` — set or replace the guide. Expect 204. Default `modelId` for new guides is `x-ai/grok-4.1-fast` unless the user specifies otherwise. Ask if you're not sure which analysis model to bind. A minimal one-shot deployment via `curl`: ```bash # Register if not present (ignore 409/204 — both are fine) curl -sS -X POST "$ORCHESTRATOR_ENDPOINT/v1/manager/prompt-analysis" \ -H "Authorization: Bearer $ORCHESTRATOR_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{"ecosystem":"<key>"}' # Update the system prompt curl -sS -X PUT "$ORCHESTRATOR_ENDPOINT/v1/manager/prompt-analysis/<key>" \ -H "Authorization: Bearer $ORCHESTRATOR_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ --data-binary @body.json ``` Where `body.json` is `{ "systemPrompt": "...", "modelId": "x-ai/grok-4.1-fast", "samples": [] }`. Use a file rather than inline JSON because the system prompt contains backticks, newlines, and quotes that break shell escaping. If the user prefers Node/PowerShell, the same three calls work — register → PUT — and the response codes are the same. ### 6. Verify After deploy, GET the ecosystem back and confirm the `systemPrompt` returned matches what was sent. Report success with the ecosystem key and a one-line summary of the guide's main points (encoder, weight-syntax stance, negative-prompt stance, any unique feature). ## Anti-patterns to avoid - **Don't copy a sibling guide and rename.** The shape is shared but the rules diverge — a Flux guide pasted under a Wan key will mislead the analyzer. - **Don't invent capabilities.** If the source doesn't mention audio, multilingual rendering, or 4K output, don't claim them. - **Don't soften incompatibility.** "Weight syntax may not work" is wrong if the encoder ignores it entirely. Say "ignored" or "unsupported." - **Don't drop the two trailing Guidelines bullets** ("Limit recommendations to the 3 most impactful improvements" and "The enhanced prompt should be a single, ready-to-use prompt..."). They're load-bearing for the analyzer's output format. - **Don't push to the orchestrator without showing the user the guide first.** Once deployed, it shapes every prompt-analysis call for that ecosystem.