design
Design and build Glide screens, components, forms, and actions. Create screens that are intuitive, data-dense, and serve user workflows. Use when creating or designing screens, choosing components, building forms, configuring navigation, or reviewing and improving screen usability.
What this skill does
# Glide Layout & Design ## Screen Types ### Creating Screens Click the "+" button in the Navigation or Menu section of the Layout Editor. | Screen Type | Description | Use Case | |-------------|-------------|----------| | **Screen from data** | Collection screen linked to a table | Lists, directories | | **Custom screen** | Blank screen to build freely | Dashboards, custom layouts | | **Form screen** | Data entry form | Add/edit records | ### Sample Screen Templates Pre-built templates for common patterns: - **Project management** - Task tracking layout - **Dashboard** - Overview with metrics - **Company directory** - People/contacts list - **Multi-Step form** - Wizard-style data entry - **Chat** - Messaging interface ## Design Principles Keep these in mind when building and reviewing screens: - **Show don't hide** - Important data should be visible at a glance, not buried in detail views - **Reduce clicks** - Can users accomplish tasks with fewer taps? Minimize navigation - **Context matters** - Group related information together so users see what they need - **Mobile vs Desktop** - Optimize for how the app will actually be used (phone-first usually) - **Progressive disclosure** - Show overview first, details on demand ## Viewing Layouts for Design Review When reviewing or building screens in the Layout Editor, **always switch to Desktop preview** unless specifically designing a mobile-only app. ### Switch to Desktop Preview 1. Look for the **device switcher** in the Layout preview toolbar (shows phone/tablet/desktop icons) 2. Click the **Desktop** icon to see the full-width layout 3. This reveals how components fill horizontal space and how multi-column layouts render Mobile preview is narrow and hides important layout issues: - Tables truncate columns - Multi-column containers collapse - Side-by-side layouts stack vertically - Cards show fewer per row ### See Below the Fold To review full page layouts: - **Scroll the preview** - Drag or scroll within the preview pane to see content below the fold - **Zoom out browser** - Use Cmd/Ctrl + minus (-) to zoom out and see more of the page at once - **Resize browser window** - Make the browser window taller to see more content Always check: - What users see on first load (above the fold) - How the full screen flows when scrolled - Whether important actions are visible or buried ## Screen Design Workflow Each tab in a Glide app has multiple screens that need to be designed. **You must navigate to each screen in the Layout Editor to design it** - they don't appear automatically. ### Screens to Design for Each Tab 1. **The tab itself** - Set its label (1-2 words max) and icon in the Navigation section 2. **Collection screen** - The top-level screen showing the list/grid/table of items 3. **Detail screen** - Click an item in the preview to navigate to and design the detail view 4. **Edit screen** - If editing is enabled, navigate to the edit screen to design the form 5. **Add/New screen** - If adding is enabled, navigate to the add screen to design the new item form ### How to Navigate to Each Screen In the Layout Editor: 1. **Collection screen**: Select the tab in Navigation - this is the default view 2. **Detail screen**: Click any item in the preview panel - the Layout Editor switches to show the detail screen's components 3. **Edit screen**: On the detail screen, click the Edit button/action in the preview - this navigates to the edit form 4. **Add screen**: On the collection screen, click the Add/+ button in the preview - this navigates to the add form **Important**: The component list in the left sidebar changes based on which screen you're viewing. Make sure you're on the correct screen before adding or configuring components. ### Design Each Screen Thoughtfully Don't just design the collection screen and leave the rest as defaults: - **Detail screens** should be rich and informative - use Title components, organize with Containers, add inline collections for related data - **Edit/Add forms** should be well-organized - group related fields, use appropriate input types, add helpful hints - **Collection screens** should use the right style for the data (Table, Card, List, etc.) Each screen type deserves attention. Users will interact with all of them. ### Replace Default Components When you create a "Screen from data", Glide adds generic default components. **Delete these defaults and design the screen yourself** using components appropriate for the data. **Why replace defaults:** - Default components are generic and don't leverage Glide's rich component system - They miss opportunities for better UX (Contact buttons for people, Maps for locations, Charts for metrics) - They don't create visual hierarchy or organization - The app looks like a template instead of a custom-built solution **How to replace:** 1. Navigate to the screen (collection, detail, edit, or add) 2. Select and delete the default components in the left sidebar 3. Add components that match the data and use case 4. Organize with Containers, add visual interest with Title components **Examples of better component choices:** | Data Type | Default | Better Choice | |-----------|---------|---------------| | Employee with email/phone | Fields component | **Contact** component (tap-to-call/email buttons) | | Address/location | Text field | **Map** component or **Location** component | | Numeric KPIs | Fields component | **Big Numbers** component | | Progress/completion | Number field | **Progress** bar component | | Person with photo | Image + text | **Profile** title component | | Project with banner | Image + text | **Cover** title component | | Related items | Hidden or single field | **Inline Collection** showing all related records | | Status field | Text | **Headline** with emoji from If-Then-Else column | | Long description | Text field | **Rich Text** component | | Multiple metrics | Multiple fields | **Container** with side-by-side Big Numbers | **Detail screen example - Employee:** Instead of default Fields component showing all columns: 1. **Profile** title - photo, name, job title 2. **Contact** component - email and phone with tap actions 3. **Location** component - office address 4. **Container** with: - **Headline** "About" - **Rich Text** - bio/description 5. **Container** with: - **Headline** "Team" - **Inline Collection** - other employees in same department This creates a polished, purposeful screen instead of a data dump. ## Collection Styles **This is one of the most important design decisions.** The collection style determines how users interact with your data. Always evaluate whether the current style is optimal for the task. ### Available Styles | Style | When to Use | |-------|------------| | **Card** | Visual layout with images, photos, or rich metadata. Good for browsing, shows multiple fields per item | | **List** | Compact and scannable. Shows 2-3 key fields. Best for simple data where users need to scan quickly | | **Table** | Data-dense, columnar format. Excellent for comparing values across many rows (prices, dates, quantities) | | **Data Grid** | Editable table. Like Table but allows inline editing of data | | **Checklist** | For boolean/checkbox fields. Great for task lists and to-dos | | **Calendar** | For date-based data. Shows events on a timeline or calendar grid | | **Kanban** | For status/workflow data. Organize items by column (e.g., To Do → In Progress → Done) | | **Custom** | Build your own layout for specialized use cases | ### How to Choose the Right Style Ask yourself these questions: 1. **What task are users trying to accomplish?** 2. **Do they need to compare values across items?** → Use Table or Data Grid 3. **Do they need visual context for each item?** → Use Card 4. **Do they need to scan and find quickly?** → Use List 5. **Is there a workflow or status progression?** → Use Kanban or Checklist 6. **Are items date-based?** → Use Calend
Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.