
Ai Chat
- 6 installs
- 228 repo stars
- Updated June 30, 2026
- thedaviddias/ux-patterns-for-developers
Helps with ai & agent building tasks.
About
ai-chat is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.
- ai-chat
- AI & Agent Building
- AI-coding skill
Ai Chat by the numbers
- 6 all-time installs (skills.sh)
- +1 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #12,825 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/thedaviddias/ux-patterns-for-developers --skill ai-chatAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 6 |
|---|---|
| repo stars | ★ 228 |
| Last updated | June 30, 2026 |
| Repository | thedaviddias/ux-patterns-for-developers ↗ |
What it does
Helps with ai & agent building tasks.
Files
AI Chat Interface
Conversational AI chat interfaces
What it solves
A AI Chat Interface pattern helps teams create a reliable way to combine prompt entry, streaming output, history, and follow-up actions inside a conversational workflow. It is most useful when teams need assistant sidebars and copilots. Compared with adjacent patterns, this pattern should reduce friction without hiding the state, rules, or recovery paths people need to keep moving.
When to use
- Assistant sidebars and copilots
- Support and help experiences
- Conversation-first AI products
When to avoid
- Avoid adding AI-specific UI when a standard non-AI workflow would be clearer and more reliable.
- Do not expose advanced controls unless users can actually benefit from them.
- Do not hide model uncertainty behind polished visuals alone.
Implementation workflow
1. Confirm the pattern matches the problem and constraints before copying the example. 2. Start from the anatomy and examples in references/pattern.md, then choose the smallest viable variation. 3. Apply accessibility, performance, and interaction guardrails before layering visual polish. 4. Use the testing guidance to verify behavior across keyboard, screen reader, responsive, and failure scenarios.
Accessibility guardrails
Keyboard Interaction
- [ ] Verify that ai chat interface can be completed using keyboard alone.
- [ ] Keep focus order logical when the pattern opens, updates, or reveals additional UI.
- [ ] Preserve a visible focus state that is still readable at high zoom.
Screen Reader Support
- [ ] Use semantic elements first, then add ARIA only where semantics alone are not enough.
- [ ] Announce state changes such as errors, loading, or completion in the right place and with the right politeness.
- [ ] Connect labels, hints, and status text with
aria-describedbyor structural headings when useful.
Visual Accessibility
- [ ] Do not rely on color alone to convey severity, completion, or selection state.
Performance guardrails
- Budget for network latency, token usage, and client-side rendering of long responses together, not as separate concerns.
- Stream or chunk content when it improves time-to-first-value, but stabilize layout so reading does not become jittery.
- Track expensive states such as long prompts, model changes, and retries so you can tune the experience with evidence.
Common mistakes
Hiding the system state
The Problem: Users cannot tell whether the model is waiting, streaming, retrying, or done.
How to Fix It? Expose clear request lifecycle states and keep them visible near the content they affect.
Treating failures like standard form errors
The Problem: AI failures include safety blocks, context limits, model availability, and partial output, not just a failed request.
How to Fix It? Differentiate failure modes and give recovery actions that match each one.
Ignoring token and latency budgets
The Problem: The experience feels unpredictable when responses get slower, shorter, or more expensive without explanation.
How to Fix It? Design token, latency, and provider constraints into the interface from the beginning.
Related patterns
- https://uxpatterns.dev/patterns/ai-intelligence/prompt-input
- https://uxpatterns.dev/patterns/ai-intelligence/response-feedback
- https://uxpatterns.dev/patterns/ai-intelligence/streaming-response
---
For full implementation detail, examples, and testing notes, see references/pattern.md.
Pattern page: https://uxpatterns.dev/patterns/ai-intelligence/ai-chat
AI Chat Interface
Learn how to implement AI chat interfaces. Discover best practices for message threading, context management, and conversational UX.
URL: https://uxpatterns.dev/patterns/ai-intelligence/ai-chat Source: apps/web/content/patterns/ai-intelligence/ai-chat.mdx
---
Overview
A AI Chat Interface pattern helps teams create a reliable way to combine prompt entry, streaming output, history, and follow-up actions inside a conversational workflow. It is most useful when teams need assistant sidebars and copilots.
Compared with adjacent patterns, this pattern should reduce friction without hiding the state, rules, or recovery paths people need to keep moving.
Use Cases
When to use:
- Assistant sidebars and copilots
- Support and help experiences
- Conversation-first AI products
When not to use:
- Avoid adding AI-specific UI when a standard non-AI workflow would be clearer and more reliable.
- Do not expose advanced controls unless users can actually benefit from them.
- Do not hide model uncertainty behind polished visuals alone.
Common scenarios and examples
- Assistant sidebars and copilots where users need a clear, repeatable interface model.
- Support and help experiences where users need a clear, repeatable interface model.
- Conversation-first AI products where users need a clear, repeatable interface model.
Benefits
- Clarifies how ai chat interface should behave before implementation details begin to sprawl.
- Creates a reusable interaction model for teams who need to combine prompt entry, streaming output, history, and follow-up actions inside a conversational workflow.
- Makes accessibility, edge cases, and recovery paths part of the design instead of post-launch cleanup.
- Gives product, design, and engineering a shared language for evaluating trade-offs.
Drawbacks
- It depends on variable model latency, output quality, and provider behavior.
- Trust drops quickly when limits, confidence, or recovery paths are hidden.
- State transitions are harder to design because the system can stream, retry, or partially fail.
- Cost and token usage become a real product constraint, not just an implementation detail.
Anatomy
flowchart TB
Root[AI Chat Interface] --> A[Message history]
Root --> B[Prompt composer]
Root --> C[Assistant response]
Root --> D[Follow-up actions]
Root --> E[Conversation controls]Component Structure
1. Message history
- Preserves enough context for users to understand the conversation.
2. Prompt composer
- Collects the current request and attachments.
3. Assistant response
- Shows streamed or completed model output in readable chunks.
4. Follow-up actions
- Support copy, regenerate, edit, or branch actions.
5. Conversation controls
- Manage history, context, or model settings.
Summary of Components
| Component | Required? | Purpose |
|---|---|---|
| Message history | ✅ Yes | Preserves enough context for users to understand the conversation. |
| Prompt composer | ✅ Yes | Collects the current request and attachments. |
| Assistant response | ✅ Yes | Shows streamed or completed model output in readable chunks. |
| Follow-up actions | ✅ Yes | Support copy, regenerate, edit, or branch actions. |
| Conversation controls | ❌ No | Manage history, context, or model settings. |
Variations
Support-style chat
Optimizes for clarification, troubleshooting, and citations.
When to use: Use for help desks and guidance surfaces.
Workbench chat
Pairs responses with tools, files, or structured actions.
When to use: Use for product workflows where AI is embedded in a task.
Companion chat
Prioritizes continuity, memory, and lightweight follow-up.
When to use: Use when the conversation itself is the main product.
Best Practices
Content
Do's ✅
- Explain what the AI is doing and what users can still control.
- Use plain-language labels for models, actions, and limits.
- Show enough provenance, status, or history for the AI output to feel reviewable.
Don'ts ❌
- Do not present speculative output as guaranteed fact.
- Do not hide model changes, truncation, or tool usage when they change the result.
- Do not collapse all failures into a single generic error message.
Accessibility
Do's ✅
- Verify that ai chat interface can be completed using keyboard alone.
- Keep focus order logical when the pattern opens, updates, or reveals additional UI.
- Preserve a visible focus state that is still readable at high zoom.
- Use semantic elements first, then add ARIA only where semantics alone are not enough.
- Announce state changes such as errors, loading, or completion in the right place and with the right politeness.
Don'ts ❌
- Do not remove focus styles without a visible replacement.
- Do not depend on placeholder or helper text that disappears before the user can act on it.
- Do not assume pointer, touch, and assistive technologies will all interact with the pattern the same way.
Visual Design
Do's ✅
- Separate system status from generated content visually.
- Keep request, streaming, and completion states recognizable at a glance.
- Use subtle motion to show progress without distracting from reading.
Don'ts ❌
- Do not animate every token or status chip if it harms readability.
- Do not make AI controls compete with the response itself.
- Do not overload the first screen with advanced options users rarely need.
Layout & Positioning
Do's ✅
- Keep prompt entry, result review, and follow-up actions logically grouped.
- Preserve enough history for people to understand why the current state exists.
- Make retries and alternate paths easy to find.
Don'ts ❌
- Do not let key controls move around as streaming content grows.
- Do not push critical notices below a long AI response.
- Do not assume a single-column desktop layout will translate to mobile unmodified.
State Management
- Model the request lifecycle explicitly: idle, validating, sending, streaming, complete, interrupted, and failed.
- Preserve the prompt, settings, and visible system state when users retry or branch from the current result.
- If the interface supports multiple turns or tools, decide which state is local to the current turn and which belongs to the broader conversation.
Error Handling
- Differentiate provider errors, policy blocks, context limits, and user-correctable input issues.
- Preserve enough context after a failure that users can retry without losing work.
- Offer a next best action such as retry, shorten input, switch model, or continue manually.
API Integration
- Treat model responses as asynchronous and occasionally partial; the UI should remain coherent if chunks arrive late or out of order.
- Debounce or batch requests when the pattern updates live from typing or repeated toggles.
- Keep provider-specific identifiers and jargon out of the primary user-facing copy unless they materially change behavior.
Performance
- Budget for network latency, token usage, and client-side rendering of long responses together, not as separate concerns.
- Stream or chunk content when it improves time-to-first-value, but stabilize layout so reading does not become jittery.
- Track expensive states such as long prompts, model changes, and retries so you can tune the experience with evidence.
Common Mistakes & Anti-Patterns 🚫
Hiding the system state
The Problem: Users cannot tell whether the model is waiting, streaming, retrying, or done.
How to Fix It? Expose clear request lifecycle states and keep them visible near the content they affect.
---
Treating failures like standard form errors
The Problem: AI failures include safety blocks, context limits, model availability, and partial output, not just a failed request.
How to Fix It? Differentiate failure modes and give recovery actions that match each one.
---
Ignoring token and latency budgets
The Problem: The experience feels unpredictable when responses get slower, shorter, or more expensive without explanation.
How to Fix It? Design token, latency, and provider constraints into the interface from the beginning.
Examples
Basic Implementation
<div class="demo-shell card generic-card"><h2>AI Chat Interface</h2><p class="muted">Basic demo placeholder for conversational ai chat interfaces.</p></div>What this example demonstrates
- A clear baseline implementation of ai chat interface that can be reviewed without framework-specific noise.
- Visible state, spacing, and content hierarchy that mirror the implementation guidance above.
- A small enough surface to copy into a design review or prototype before scaling the pattern up.
Implementation Notes
- Start with semantic HTML and only add JavaScript where the interaction truly requires it.
- Keep styling tokens and spacing consistent with adjacent controls or layouts.
- If the live implementation introduces async behavior, mirror those states in the code example rather than documenting them only in prose.
Accessibility
Keyboard Interaction
- [ ] Verify that ai chat interface can be completed using keyboard alone.
- [ ] Keep focus order logical when the pattern opens, updates, or reveals additional UI.
- [ ] Preserve a visible focus state that is still readable at high zoom.
Screen Reader Support
- [ ] Use semantic elements first, then add ARIA only where semantics alone are not enough.
- [ ] Announce state changes such as errors, loading, or completion in the right place and with the right politeness.
- [ ] Connect labels, hints, and status text with
aria-describedbyor structural headings when useful.
Visual Accessibility
- [ ] Do not rely on color alone to convey severity, completion, or selection state.
- [ ] Test the pattern at 200% zoom and with reduced motion enabled.
- [ ] Ensure touch targets remain comfortable on mobile and coarse pointers.
Testing Guidelines
Functional Testing
- [ ] Verify the default, loading, error, and success states for ai chat interface.
- [ ] Test the primary action and the obvious recovery action in the same run.
- [ ] Confirm that state survives refresh, navigation, or retry in the way users would expect.
Accessibility Testing
- [ ] Run keyboard-only checks and at least one screen reader pass on the final implementation.
- [ ] Validate headings, labels, and announcement behavior with real content rather than lorem ipsum.
- [ ] Check color contrast and focus visibility in both default and stressed states.
Edge Cases
- [ ] Test empty, long, duplicated, and unexpectedly formatted content.
- [ ] Check behavior on narrow screens, zoomed layouts, and slower networks.
- [ ] Verify that optimistic or asynchronous states reconcile correctly after a failure.
Frequently Asked Questions
Related Patterns
Resources
References
- WCAG 2.2 - Accessibility baseline for keyboard support, focus management, and readable state changes.
- MDN ARIA live regions - How to announce streaming text, status updates, and non-modal feedback to screen readers.
Guides
- People + AI Guidebook - A practical framework for building AI-assisted interfaces with transparency and user control.
Articles
- Microsoft Human-AI Interaction Guidelines - Research-backed recommendations for AI feedback, confidence, intervention, and recovery.
NPM Packages
- `ai` - Vercel AI SDK primitives for chat, streaming UI, tools, and model integrations.
- `assistant-ui` - Composable chat UI primitives for production-grade AI assistants.
- `react-markdown` - Render markdown-rich responses, citations, and structured assistant output.