菜单
Use when an AI answer surface needs structure, citations, grounding, editable refinement, or a chat-versus-canvas decision. Do not use for agent autonomy, approvals, or execution status; route those interaction controls to ai-agent-ux.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a game for children or learners needs age-appropriate comprehension, scaffolding, learning-feedback separation, privacy/safety, stopping cues, guardian/teacher needs, accessible play, or non-exploitative engagement. Use onboarding-and-first-run-design for ordinary apps.
Use when a game needs visual pillars, shape language, colour scripting, character/world readability, cultural motif governance, 2D/3D cohesion, VFX hierarchy, an asset bible, style scalability, performance-aware art, or engine handoff. Use illustration-style-and-systems for non-game illustration sets.
Use when tuning a game action through anticipation, response, impact, timing, animation, VFX, audio-visual coordination, camera, hit-stop, particles, haptics, reduced-motion, sensory alternatives, or intensity settings. Use micro-interactions-and-feedback for ordinary UI controls.
Use when designing game HUDs, menus, maps, inventory, dialogue, tutorials, pause/settings, save/load, failure/success, controller focus, touch, couch-distance, or diegetic interfaces. Use ordinary app UI skills for non-game task flows.
Use when a game needs its player fantasy and interaction loop routed into HUD, art direction, feedback, camera, input, accessibility, testing, and engine handoff. Use ordinary app UI skills for non-game software and the four game specialists for focused craft.
Use when designing or auditing an interactive UI for WCAG 2.2 AA, keyboard and focus behaviour, accessible names, screen readers, target size, reflow, authentication, or reduced motion. Use inclusive-and-assistive-design for needs beyond the compliance floor.
| name | ai-output-design |
| description | Use when an AI answer surface needs structure, citations, grounding, editable refinement, or a chat-versus-canvas decision. Do not use for agent autonomy, approvals, or execution status; route those interaction controls to ai-agent-ux. |
| metadata | {"portable":true,"category":"04-web-and-ui-design","compatible_with":["claude-code","codex"]} |
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
ai-agent-ux (its ai-ux-patterns reference module).ai-agent-ux (its ai-agentic-ui reference module).| Input | Source | Evidence |
|---|---|---|
| User task and output decisions | Product brief or observed workflow | Ranked decisions and follow-up actions |
| Source/grounding payload | Retrieval or model contract | Citation identifiers and unavailable-evidence states |
| Output variability and error modes | Evaluation results or engineering | Representative good, weak, partial, and failed outputs |
SKILL.md first, then load referenced deep-dives as needed.| Condition | Choice | Wrong-choice failure |
|---|---|---|
| Output supports ongoing editing | Persistent canvas with inline controls | Chat-only regeneration loses context and user changes |
| Claim can be sourced | Citation adjacent to the claim | Detached source lists make verification costly |
| Evidence is absent or conflicting | State the gap and verification action | Confidence percentages manufacture trust without proof |
| Output | Consumer | Evidence and acceptance |
|---|---|---|
| AI output template and state matrix | Design and engineering | Clear, verifiable, grounded, actionable, adjustable states are mapped |
| Output quality review | Product and QA | Representative outputs show source proximity, failure handling, and forward actions |
doctrine/design-doctrine.md — the anti-slop charter; ungrounded, unverifiable, dead-end AI output is product slop.doctrine/references/ai-slop-taxonomy.md — the product/interface slop tells (output surfaced without verifiability, grounding, or an undo/adjust affordance) the five principles fix.references/five-output-principles.md — expanded treatment with UI mechanics.references/verifiability-patterns.md — why confidence % is wrong; inline-source patterns.references/canvas-vs-chat.md — decision matrix, versioning, collaboration.references/inline-refinement.md — on-select UI, buttons, knobs, version selectors.Most AI output surfaces fail for one of five reasons:
The five principles below map to fixes for each.
Every output has a structure template in the system prompt. Enforce structure but use the leanest template that works; over-styling suppresses flexibility.
Baseline template:
Title -> Intro (1-2 sentences) -> Key Concepts -> Steps (if procedural) -> Notes (caveats) -> Sources
UI side: render the template as collapsible sections when long; preserve the sections on copy/export.
REJECT confidence-percentage UI for LLMs. LLMs are bad at self-confidence; internal token probabilities do not map to truth. A "87% confident" badge on a hallucinated answer is worse than no badge — it confers false authority.
Instead: inline sources per claim. Perplexity superscript pattern. Each claim links to a specific passage in a source. Multiple claims without sources is a structural smell.
Exceptions where a confidence number IS OK:
See references/verifiability-patterns.md.
Users trust an output when they know the lens the model used. Surface:
Implement as a "Why we suggested this" affordance — one click expands the grounding metadata.
The output is not the goal; the action after the output is. Design the onward journey. Every output surface should expose obvious forward affordances:
Rule: a response that ends "…and that's it" without an action button is a design failure. Default to 2–4 forward affordances even for pure Q&A (copy, save, share, refine).
See references/inline-refinement.md.
Two distinct output paradigms.
| Paradigm | When to use | Prescriptions |
|---|---|---|
| Chat | Ephemeral Q&A, conversational iteration, short outputs | Linear transcript, streaming tokens, recent history visible |
| Canvas | Output is durable artifact (doc, plan, image, code) — shareable, storable, returnable | Editable workspace, version history (Codex Artifacts), undo/redo, node-based iteration for generative media (Runway) |
Rule: move output to canvas the moment it becomes shareable. A 3-page policy draft in chat is friction; the same draft in canvas is a deliverable.
See references/canvas-vs-chat.md.
Starter prompts are not examples — they are product positioning. Generic starters ("Write a poem about autumn") are lazy. Good starters reflect the product's specific integrations, tone, and differentiators. Make them context-aware: Monday-morning vs Friday-afternoon, document-type-open-in-editor, user-plan-tier.
Structure every response as:
1. One-sentence title
2. 1-2 sentence introduction
3. Key concepts as a bulleted list if appropriate
4. Step-by-step instructions if procedural
5. Notes section for caveats, limits, or edge cases
6. Sources section with inline citations
If a section has no content, omit it.
See also:
ai-agent-ux — sibling skill covering streaming/loading/feedback patterns (ai-ux-patterns module), long-running agent surfaces (ai-agentic-ui module), and AI trust/transparency principles.doctrine/references/ai-slop-taxonomy.md — product/interface slop tells for AI surfaces.