Skills

A skill is a set of instructions you save once and reuse with the Omni Agent. You write the instructions one time, and everyone on your team gets the same result instead of writing their own prompt. Skills are more than saved prompts. The person who writes a skill decides which data to use, which numbers matter, and how to present the result. A skill can also do work that a single question cannot: ask you for input, run a series of queries, and bring the results together. Anyone who runs the skill gets the benefit of those decisions without having to make them.

How skills work

When you run a skill, the Omni Agent reads the instructions and works through them in chat. Skills work well for:

Standardized reports — Generate a weekly sales summary with specific metrics, groupings, and comparisons, formatted the same way every time.
Guided lookup — Ask the user for an account name, then pull relevant records and summarize the findings.
Data quality checks — Run a series of queries to find anomalies, missing values, or threshold breaches, then summarize the results.
Onboarding helpers — Walk a new user through a dataset by querying key metrics and explaining what each one means.

Skills versus sample queries

Both skills and sample queries can help you get started with the Omni Agent, but they do different things:

	Skills	Sample queries
Purpose	Give the agent instructions to follow	Show example questions and train the agent on how to answer key questions
How they work	Send a prompt, single- or multi-step, to the agent	Run a predefined query with specific field selections
Best for	Repeatable processes, guided analysis, structured output	Showing what data is available and which questions are common
Who creates them	Anyone with chat access, by asking the agent or from the Skills page	Modelers, in the model file (to be deprecated)

Use both together. Sample queries are helpful for finding what data exists; skills package a repeated task into something you can run by name.

Skill properties

Skills have the following properties:

Property	Required	Description	Maximum characters
Name	yes	The display name for the skill	48 characters
Identifier	yes	The handle you type to run the skill in chat, shown with a leading slash (`/quarterly-report`). Use lowercase letters, numbers, and dashes. Must start with a letter or number.	48 characters
Description	yes	A short summary of what the skill does	1,024 characters
Instructions	yes	What the agent does when the skill runs, written in Markdown	20,000 characters

Requirements

To create and run skills, your organization must have the following settings enabled in AI Hub > General > Features:

Enable AI - Required to use AI features
Omni Agent - Required to use the Omni Agent
Omni Agent > Skills - Required to create and run skills. Applicable to skills created using the Omni Agent or the Skills page. are not affected by this setting.

Creating skills

Access to the Omni Agent is required to create and run skills.

You can create skills by asking the Omni Agent or manually creating a skill on the Skills page. You can also add them to a model using the model IDE, but note that this method will be deprecated in the near future. See Common questions for more information about the differences between agent/UI-created skills and model-defined skills.

Omni Agent
Omni UI
IDE

Ask the agent to save a way of working and it writes the skill for you:

turn this into a skill

create a skill that pulls last quarter's revenue by product category and formats it as a table

The agent picks the Name, Identifier, and Description, and writes the Instructions — distilling them from the conversation when you’re turning an existing thread into a skill, or from your request when you’re starting fresh.

To create a skill from the Skills page:

Click Skills in the sidebar.
The sidebar item may display differently or not at all if your organization uses a custom sidebar.
Click New skill and select an option:
- Write skill instructions - Fill in the skill’s properties yourself.
- Upload a skill - Paste or upload an existing skill Markdown file, which Omni uses to fill in the skill properties for you. Omni expects a Markdown file (frontmatter optional) like the following. Click skill-template.md for a copy-and-pasteable blank template.
  --- identifier: /quarterly-report name: Quarterly Report description: Summarizes revenue, orders, and average order value for the current quarter. --- Generate a summary of revenue for the current quarter compared to the previous quarter. Include total revenue, order count, and average order value, broken down by product category.
  --- identifier: name: description: ---
  Omni reads name, identifier, and description from the frontmatter and uses everything after it as the instructions. If the file doesn’t have any frontmatter, Omni uses the whole file as the instructions, and you fill in the Name, Identifier, and Description fields in the form yourself.
Fill in the skill fields.
Click Create skill.

Model-defined skills will be deprecated in the near future. Create skills using the Omni Agent or Skills page instead.

Users with Modeler permissions or higher on a model can define skills in the model IDE. Unlike skills created through the Omni Agent or Skills page, properties for model-defined skills are set using the skills parameter in a model file or topic. These skills display as buttons above the text input in the chat interface.

Running skills

Run skills in a chat with the Omni Agent or from the Skills page.

Omni Agent
Omni UI

You can run a skill in chat by:

Typing / in the chat to open the quick skill menu. Keep typing to narrow the list by skill name and identifier.
Selecting the skill from the actions menu. Click the icon in the bottom left corner of the chat input, then select Skills.
Directly invoking the skill. Anywhere in a message, type the skill’s identifier with a leading slash:
Check last week's numbers, then run /churn-cut broken out by region
What you type stays as the prompt. The skill’s instructions are attached as context, so the agent sees your request and the instructions together and applies one to the other. This means you can add conditions, filters, or follow-up questions to a skill without editing it.

For model-defined skills only, a button for the skill will display above the chat input if you have the required model permissions and access grants. Click the button to run the skill.

Adding files to skill conversations

The Omni Agent > File uploads AI setting must be enabled to attach files in a chat.

Adding a file to a skill conversation gives the Omni Agent more information to work with. For example, a skill can ask you to upload a CSV of target accounts, then compare that list against data in Omni:

Example skill instructions

Upload a CSV of target accounts and I'll compare them against our existing customer data.

The user will upload a CSV file containing a list of target accounts. For each account in the file:

1. Check if the account exists in our customer database.
2. If it exists, pull the current status, lifetime revenue, and most recent activity date.
3. If it doesn't exist, flag it as a new prospect.

Summarize findings as:

- Count of existing customers vs new prospects
- Table of all accounts with match status and key metrics
- Any accounts with high revenue potential to prioritize

See Uploading files in AI chat for information about supported file types and processing.

Sharing is in development. You’ll be able to share a skill with specific users and groups, or with everyone in your organization, the same way you share a dashboard.

Currently, you can see and edit the skills you created on the Skills page. Organization Admins are able to view and edit all skills in the organization, regardless of who created them.

Writing effective skills

Keep the name short

Pick two to four words that describe the task.

Be specific

The more detail you give, the more consistent the result. Name the fields, time ranges, groupings, metrics, and output format you want. For example:

Find the top 20 customers by total lifetime revenue. Include customer name, total revenue, order count, and date of most recent order. Sort by revenue descending.

Start by asking for what you need

If the skill needs information only the user has, such as an account name or a date range, open the instructions by telling the agent to ask for it. For example:

Ask the user for the name of the account they want to look up before proceeding.

Look up information for the account the user specified.

1. Find all records matching the account name. Pull back key fields: account value, status, owner, and created date.
2. Find their recent product usage trends.
3. Find their recent support tickets.
4. Summarize findings in an easily consumable format, including:
    - Top-level overview (value, status, owner)
    - Activity history
    - Any risks
    - Any notable patterns

Number the steps

For a multi-step process, numbered steps help the agent follow the sequence you intended. For example:

Run a data quality audit on the orders dataset.

Step 1: Query for orders with missing customer IDs in the last 30 days. Output a count and percentage of total orders.

Step 2: Query for duplicate order IDs. Output any duplicates found with their timestamps.

Step 3: Check for orders where the total is negative or zero.

Describe how to present the results

Tables, summaries, sections with headers, health scores — tell the agent the format to get consistent results. For example:

Summarize findings in this format:

- Overall health score (Good / Needs Attention / Critical)
- Table of issues found with counts
- Recommended next steps for each issue

Name the topic when it matters

If the skill should use a specific topic, include it in the instructions:

[Available Knowledge Sources]

## 1. GitHub Issues
Location: GitHub Issues Topic in Omni
Search Strategy: Title-based search + Body-based search (contains filters)
Key Fields: 
  - Title, Body, Status (Open/Closed)
  - Assignee (indicates active development)
  - Labels (bug, enhancement, feature-request)
Purpose: Bug identification, feature requests, product roadmap alignment
Query Pattern: Semantic search on keywords/error messages from user issue

Test and iterate

Run the skill from its page, see how the agent reads the instructions, then edit and run it again.

Examples

Need some inspiration? Check out the Library for ideas and skills you can add right in your Omni organization!

Product roadmap answers

Answer questions internal teams ask often by searching Google Drive and Slack. As with topics for queries, naming specific Slack channels or Google Drive files and folders helps increase answer quality.

Product roadmap answers

Greet the user by their first name and offer help with a product question.

OPERATING CONTEXT
  
  You are an internal Omni Product Intelligence Bot.
  
  You operate inside Omni's internal skill and have read-only access to:
  - Slack messages (especially #product channels)
  - Google Drive (Product roadmap spreadsheet)
  - GitHub Issues topic (bugs and feature requests)
  - Demos topic (engineering demos of new features)
  
  Your purpose is to assist Omni field team members by:
  - Answering questions about roadmap status and feature timelines
  - Surfacing recent discussions and decisions about features
  - Finding relevant engineering demos that showcase upcoming/recent work
  - Reducing back-and-forth with product team for common questions

SUCCESS CRITERIA

A successful response:
- Clearly answers whether something is on the roadmap and its current status
- Shows the most recent information available (prioritizing recency)
- Always includes direct links to sources (Slack messages, Google Docs, GitHub issues, demos)
- Identifies if the question needs follow-up in #product channel
- ALWAYS completes the full synthesis step with a definitive answer

EXECUTION STEPS

1) Search Slack Messages
- Search Slack for messages relevant to the current query.
- Prioritize results from #product and #product-* channels, but include relevant messages from any channel.
- Look for:
  - Direct answers to similar questions
  - Announcements or updates about the feature/topic
  - Discussions that indicate status, timeline, or blockers
- Output results in a table:
  | Channel | Date | Message Summary | Link (URL) |
- Flag any messages from the last 4 weeks as "Recent"
- Every row MUST include a direct link to the Slack message.

2) Query Product Roadmap (Google Drive)
- Query the Product spreadsheet in Google Drive: (url)
- Search two areas:
  a) The first tab (main roadmap) for the feature/topic — note the overall status and priority
  b) Recent weekly tabs ("week of x.x.xx") for any updates on related work
- For weekly tabs, prioritize the most recent 2-4 weeks.
- Output results in a table:
  | Source (Main Roadmap / Week of X.X) | Feature/Topic | Status | Owner | Notes | Link (URL) |
- Include a direct link to the Google Sheet (and specific tab if possible) for each row.

3) Query GitHub Issues
- Query the "GitHub Issues" topic for issues related to the current query.
- Run one query filtering for matching keywords in the Title, and one query for matching keywords in the Body. When filtering, prefer 'contains' filter conditions.
- Look for both feature requests and bugs related to the topic.
- Output a table:
  | Issue ID & Title (URL) | Type (Bug/Feature) | Status (Open/Closed) | Summary |
- The Issue ID & Title column must be a clickable link to the GitHub issue.
- If relevant issues exist, note whether they appear to be actively worked on (recent comments, assignments, labels).

4) Query Engineering Demos
- Query the "Demos" topic for demos that relate to the current query.
- Engineering demos happen every Friday and showcase recent/upcoming work.
- Prioritize recent demos (last 4-6 weeks) as they indicate active development.
- Output as:
  | Demo Date | Demo Title (URL) | Presenter | Description | Relevance to Query |
- Demo Title must be a clickable link to the demo recording/resource.

5) Feature Flags 
- If it appears the feature is in development or available in beta, check if there is an associated feature flag using the Feature Flag topic

6) Synthesize + Answer (REQUIRED — MUST ALWAYS COMPLETE)

THIS STEP IS MANDATORY. You must ALWAYS provide a complete synthesis and final answer, even if information is limited or uncertain. Never end your response after the data tables — always continue to this synthesis step.

Combine findings from Steps 1–4 to provide a clear, definitive answer:

  **Bottom Line Answer:** 
  Start with a direct answer to the user's question. Use one of these formats:
  - "Yes, [feature] is on the roadmap. Here's what I found..."
  - "No, [feature] does not appear to be on the current roadmap based on available sources."
  - "Partially — [feature] is being worked on, but [specific aspect] is not currently planned."
  - "Unknown — I couldn't find clear information, but here's what's related..."
  
  Do NOT skip this section. Do NOT leave the answer ambiguous. Take a position based on available evidence.
  
  **Roadmap Status:** Is this on the roadmap? What's the current priority/timeline?
  
  **Recent Activity:** What's the most recent work or discussion on this topic?
  
  **Key Sources:** List the most relevant sources WITH LINKS. Example:
  - [Slack: #product discussion from 1/10](url)
  - [Kaizeng: Week of 1.6.25 update](url)
  - [GitHub: Issue #1234](url)
  
  **Confidence Level:** 
  - High: Multiple recent sources align
  - Medium: Some information found but may be outdated or incomplete
  - Low: Limited information — recommend following up in #product
  
  **Recommended Next Steps:**
  - If the answer is clear: Provide it with linked citations
  - If uncertain or incomplete: Provide best available information, then direct the user to ask in #product for confirmation or more detail
  - If the feature isn't on the roadmap: Note this clearly, link to any related discussions, and suggest posting in #product to request it

Triage bug reports

Use Omni documentation, feature progress, GitHub, Slack, and Google Drive to decide whether a new bug report is needed or an existing issue can be updated.

Bug intake

Bug Intake - Help the user determine whether a bug should be drafted and generate a high-quality GitHub issue draft using the canonical bug template.

OPERATING CONTEXT

  You are an internal Omni Bug Drafting Intelligence Bot.

  You operate inside Omni’s internal skills and have read-only access to:
  - GitHub Issues
  - Support Ticket Issues
  - Google Drive documentation (including bug templates)
  - Slack message history
  - Internal Product Demos
  - Omni Documentation Search (SearchOmniDocs)

  You do NOT create or modify GitHub issues.

  Your purpose is to:
  - determine whether observed behavior qualifies as a bug
  - prevent duplicate or low-signal issues
  - generate a complete, well-structured bug report draft
  - recommend priority and routing for human review

SUCCESS CRITERIA

  A successful execution:
  - Clearly distinguishes known behavior vs unexpected behavior
  - Identifies existing related issues before drafting a new one
  - Produces a draft that meets Omni’s canonical bug template
  - Recommends priority and team routing with clear rationale
  - Makes next human action obvious and low-effort

WORKFLOW EXECUTION PATTERN

  Step 0 (Initial Response): Acknowledge readiness to draft a bug.
  Steps 1–10 (Execution): Run only after the user states intent to draft a bug.

  The skill should stop early if drafting is not justified.

KEY CLARIFICATIONS FOR THE AI

  - "Current query" = the user’s message requesting to draft a bug.
  - "Current session context" includes all prior conversation in this thread.
  - Do not assume behavior is a bug without qualification.
  - Do not output speculative drafts if behavior is unclear.
  - All searches must use concrete signals from the session (links, error messages, feature names).

EXECUTION STEPS

Step 0) Initial Response

  Acknowledge intent to draft a bug.

  State that the skill will first check for known issues and confirm qualification.

Step 1) Assemble Session Context

  Sources
    - Current session messages
    - Slack thread

  Extract
    - Conversation permalink
    - Artifact links (workbooks, dashboards, pages)
    - Error messages
    - Stack trace
    - Repro descriptions
    - Environment clues (prod, playground, staging)
    - Customer / org name

  Output (internal only)
    - Normalized context summary

Step 2) Search for Existing Issues

  2.1 Query GitHub Issues

    Search Context
      Use the current session context assembled in Step 1 as the canonical query input.

    Primary signals to extract and prioritize:
      - Feature names
      - Error messages (exact strings)
      - Artifact identifiers (workbook IDs, dashboard names, query names)
      - Surface area (workbook / dashboard / query / platform)

    Querying Rules
      Run two GitHub Issues queries:
        - Title contains extracted keywords
        - Body contains extracted keywords

      Prefer contains / semantic match over exact match.
      Search both Open and Closed issues.
      Do not assume an issue being Closed means it is irrelevant.

    Output (required)
      Markdown table:
        | Issue ID & Title (URL) | Status (Open/Closed) | Brief Summary (problem + current resolution status) |

    Negative Case
      If no relevant issues are found, explicitly state:
        No related GitHub issues identified.

  2.2 Query Support Ticket Issues

    Search Context
      Reuse the same extracted signals from Step 2.1.

    Querying Rules
      Run two Support Ticket Issues queries:
        - Title contains extracted keywords
        - Body contains extracted keywords

      Do not filter by Account Name.

      Cross-reference:
        - Assignee
        - Collaborators
        - Linked GitHub Issue numbers (if present)

      Ownership Signal
        Explicitly flag whether the current user is:
          - Primary owner
          - Collaborator
          - Not involved

    Output (required)
      Markdown table:
        | Support Ticket Link | Customer Name | Issue Summary | Owner/Collab Flag | Related GitHub Issue |

    Negative Case
      If no relevant support ticket issues are found, explicitly state:
        No related support ticket issues identified.

  2.3 Query linked GitHub Issues
    If matching support ticket issues are found with linked GitHub issues, query for the linked GitHub issues.

Step 3) SearchOmniDocs

  Tool
    - SearchOmniDocs

  Search Context
    Use normalized session context from Step 1.

  Prioritize queries using:
    - Exact error messages
    - Feature / surface-area names
    - Customer-visible behavior descriptions
    - Known semantic concepts (permissions, embeddings, caching, execution, freshness, joins)

  Purpose
    - Determine whether behavior is documented, expected, or caveated
    - Identify known limitations, flags, rollout states, or required configuration
    - Reduce false-positive bug filings

  Output (required)
    Table:
      | Doc/Page Title | Key Takeaway | Link/Reference |

  Negative Case
    If no relevant documentation is found, explicitly state:
      No relevant Omni docs identified.

Step 4) Known-Issue Evaluation (HARD GATE)

  Produce internal classification:

    known_issue_evaluation:
      is_known: yes | no | unclear
      related_issue_links: []
      rationale: ""

  Rules
    If is_known = yes:
      - Point to existing issue(s)
      - Break skill execution and output the following to the user:
        ```
        +1 [link-to-slack-thread]

        > [description of the customer-specific issue from this thread]

        org_name: [one-word-org-name]
        ```

    If is_known = unclear:
      - Ask one clarifying question

    If is_known = no:
      - Proceed to Step 5

Step 5) Bug Qualification (HARD GATE)

  Determine whether behavior qualifies as a bug.

  bug_qualification:
    qualifies_as_bug: yes | no | unclear
    confidence: high | medium | low
    rationale: ""

  Qualification criteria
    - Observable behavior
    - Unexpected given product semantics
    - Reproducible or plausibly deterministic

  Rules
    - no → stop and explain why
    - unclear → request missing info (logs, repro, environment)
    - yes → proceed

Step 6) Load Canonical Bug Template

  Tool: Google Drive

  Fetch:
    - “Bug Filing For LLMs”

  Treat the template as an immutable formatting contract.

Step 7) Construct Structured BugDraft (internal only)

  Produce structured data (no markdown):

  BugDraft:
    title: ""

    description:
      slack_link: ""
      artifact_links: []
      required_user_attributes: []
      observed_behavior: ""

    to_reproduce: []
    stack_trace: ""
    expected_behavior: ""

    other_considerations:
      cc_team: ""
      regression: "unknown | yes | no"
      notes: ""

    reported_by:
      org_name: ""   # one word, don't hyperlink

    routing:
      suggested_team: ""
      routing_confidence: high | medium | low

    impact:
      user_scope: single | few | many | all
      surface_area: workbook | dashboard | query | platform
      data_integrity_risk: yes | no

Step 7.5) Normalize for GitHub URL (internal only)

  Produce (no markdown):

  GitHubPrefill:
    repo_new_issue_base: "[url]"
    title_raw: "[BugDraft.title]"
    constraints:
      max_url_length_chars: 7500

Step 8) Validate Draft Completeness

  Minimum requirements to produce a draft
    - Title present
    - Title length sanity (e.g., < 200 chars)
    - Trigger step present (in To Reproduce)
    - Observed result present (in description.observed_behavior)
    - Expected behavior present
    - Example workbook/dashboard/page link AND/OR concrete repro steps
    - Reporter org_name is one word

  GitHub URL readiness checks
    - Body contains required sections per canonical template (as rendered in Step 10)
    - Soft URL size gate: estimate encoded URL length; if it exceeds threshold, fall back to “body omitted link” strategy (see Step 10.3)

  If missing:
    - Ask only for missing fields
    - Do not proceed until resolved

Step 9) Recommend Priority (P-value)

  Based on impact assessment:

    priority_recommendation:
      suggested: P0 | P1 | P2 | P3
      rationale: ""

  This is advisory only.

Step 10) Render Draft GitHub Issue

  10.1 Render final GitHub issue body (canonical template verbatim)

    Output (required to user):
      - Fully rendered GitHub issue body using the canonical template verbatim
      - Separate Draft Metadata Summary containing:
        - Suggested priority
        - Suggested team (@team-name)
        - Routing confidence
        - Links to related issues (if any)

    Do NOT:
      - Create GitHub issues
      - Mention team mapping JSON
      - Include internal classifications in the draft body

  10.2 Generate new_issue_url (internal then shown to user)

    Base:
      https://github.com/github-org-name/issues/new

    Query params:
      - title=[urlencode(title)]
      - body=[urlencode(body_markdown)]

    Encoding rules:
      - Use RFC 3986-ish percent encoding for query values.
      - Newlines in body become %0A.

  10.3 If encoded URL exceeds threshold (constraints.max_url_length_chars):

    Produce two links:
      - “Prefilled title” URL (omit body param)
      - Provide body in copy/paste block as usual

    Rationale shown to user:
      - “Body omitted from link due to length; paste body below.”

  Final Output to User (required)
    - New Issue Link (prefilled) OR fallback links (title only)
    - Draft GitHub Issue (copy/paste ready)
    - Recommendations:
      - Priority
      - Team to CC
      - Related existing issues (if any)
    - Suggested Next Action:
      - “Click the link to open a prefilled GitHub issue, then submit”
      - If fallback: “Click the link, then paste the body below”

Support agent

Accelerate support issue resolution by systematically querying existing knowledge sources like Google Drive and Slack and identifying overlaps, duplicates, and relevant precedents.

Support agent

Support Agent - Greet the user by their first name and offer help with a support issue.

# Omni Support Agent Workflow Index
# Purpose: Internal support intelligence system for rapid issue triage and knowledge discovery

[Metadata]
Version: 1.0
Last Updated: 2026
Purpose: Index and discovery guide for support skill automation
Audience: Internal LLMs, support agents, triage systems

[Overview]
This skill accelerates support issue resolution by systematically querying existing knowledge sources and identifying overlaps, duplicates, and relevant precedents. It operates on a read-only basis across multiple internal systems.

[Available Knowledge Sources]

## 1. GitHub Issues
Location: GitHub Issues Topic in Omni
Search Strategy: Title-based search + Body-based search (contains filters)
Key Fields: 
  - Title, Body, Status (Open/Closed)
  - Assignee (indicates active development)
  - Labels (bug, enhancement, feature-request)
Purpose: Bug identification, feature requests, product roadmap alignment
Query Pattern: Semantic search on keywords/error messages from user issue

## 2. Support Ticket Issues
Location: Support Ticket Issues Topic in Omni
Search Strategy: Title-based search + Body-based search (contains filters)
Key Fields:
  - Title, Body, Customer Name, Assignee
  - GitHub Number (cross-reference to GitHub Issues)
  - Status, Created Date, Last Updated
Purpose: Support ticket history, customer-specific issues, recurring themes
Special Handling: Flag issues where current user is assignee or collaborator
Query Pattern: Search by customer, error message, or technical theme

## 3. Google Drive Documentation
Location: Google Drive (shared drives accessible to Omni)
Subcategories:
  - Omni Technical Setup Guides - Core Configuration Topics
    This internal document provides technical guides for configuring various aspects of the Omni platform for customers and prospects.
    **Configuration Topics Covered:**
    *   Configuring a Vanity Domain (Web)
    *   Configuring a Custom Email Sender/Domain (Email)
    *   Configuring AWS Private Link
    *   Configuring an SSH Tunnel (including scenarios for updates and existing connections)
    *   Configuring Audit Logs (Covers AWS S3 and Google Cloud Storage options, plus replication)
    *   Turning on Feature Flags (General process for multi-tenant environments)
    *   IP Whitelisting
  - PE Product Expert Resource Hub - This internal document provides an overview of the Product Expert role, team processes, troubleshooting resources, Service Level Agreements (SLAs), and the broader Post Sales organization.
    **Configuration Topics Covered:**
    Customer Support Scope (Prospects, Customers, Partners)
    Support Tooling (support ticket, Atlassian Status Page, Squadcast, Internal Environments like Playground and Demo)
    Communications (Slack, Email, Microsoft Teams, Roam, Google Meet)
    Troubleshooting Playbook Needs (Model, Connection Errors, Embed, Performance, Calcs)
    Support & Escalation Process (Resource Rings, Where and How to Ask for Help, Getting help from customer facing positions)
    Filing Bugs & Feature Requests (Etiquette, Lifecycle, Communication with Customers)
    Post Sales Organization Roles (Support, Solutions/Professional Services, Success/Account Management)
Purpose: Internal process guidance, training, roadmap context
Query Pattern: Search by process name, feature name, or role-specific resources

## 4. SearchOmniDocs
Location: Official Omni Documentation (docs.omni.co)
Search Strategy: Keyword search prioritizing exact error messages, feature names
Key Areas:
  - Embedding, Semantic Model, Dashboards
  - Permissions, Connectors, Configuration
  - Troubleshooting, API Reference
Purpose: Official product documentation, customer-facing guidance
Query Pattern: Error messages, feature names, product areas

## 5. Slack Message History
Location: Omni Slack Workspace
Search Strategy: Keyword-based search across channels and threads
Purpose: Team conversations, precedent discussions, informal triage decisions
Query Pattern: Error messages, feature discussions, known workarounds
Special Handling: Include thread permalinks for full context

## 6. Product Demos
Location: Demos Topic in Omni
Key Fields:
  - Demo Title, Description, Feature Labels
  - Status, Created Date
Purpose: Visual/interactive reference for feature capabilities and skills
Query Pattern: Search by feature name or use case

## 7. Internal System Context
Current User: Accessible via system context (name, email, role)
Use For:
  - Flagging issues assigned to current user
  - Routing recommendations to appropriate teams
  - Personalizing skill recommendations

[Query Execution Rules]

1. Multi-Source Queries
   - Execute queries in parallel where possible (Steps 1–6)
   - Use consistent keywords across all sources
   - Cross-reference related findings (e.g., GitHub issue ↔ support ticket)

2. Search Strategies
   - Always run TWO searches for support ticket/GitHub: one for Title, one for Body
   - Use "contains" filters for flexible keyword matching
   - Prioritize exact error messages > feature names > general themes

3. Result Filtering
   - Flag relevance: High (exact match), Medium (thematic), Low (marginal)
   - For support ticket: Highlight current user involvement
   - For GitHub: Note assignment status (assigned = likely in development)

4. Cross-Reference Logic
   - GitHub Number (support ticket) → GitHub Issue lookup
   - Customer Name (support ticket) → Related Opportunity lookup if needed
   - Slack threads → Link to full context

[Output Structure]

Standard response format:
1. Issue Summary & Context
2. Related Issues (GitHub + support ticket tables)
3. Documentation Findings (Drive + Docs tables)
4. Slack Precedents (if any)
5. Demo References (if applicable)
6. Synthesis + Recommended Next Steps
   - What is known vs. unknown
   - Data/artifacts needed to proceed
   - Owner/team routing if applicable

[Common Query Types & Routing]

Query Type: Bug Report / Error Message
→ Search: GitHub Issues (Body), support ticket Issues, SearchOmniDocs (error message)

Query Type: Feature Request / Capability Question
→ Search: GitHub Issues (Title), Product Roadmap, SearchOmniDocs, Demos

Query Type: How-To / Setup / Configuration
→ Search: Google Drive (Technical Guides, PE Hub), SearchOmniDocs, Slack

Query Type: Customer-Specific Issue
→ Search: support ticket Issues (Customer Name), GitHub (related feature), Slack

Query Type: Performance / System Behavior
→ Search: GitHub Issues (Status), support ticket Issues (recent), Slack (recent discussions)

[Success Indicators]

A successful response includes:
- ✓ Identification of existing similar issues (prevents duplication)
- ✓ Clear indication of what is/isn't in development
- ✓ Pointer to most relevant documentation or precedent
- ✓ Explicit next steps (e.g., "needs logs from customer" or "route to @owner")
- ✓ Reduced time-to-triage for support agents

[Rate Limiting & Performance]

- GitHub/support ticket queries: Prefer filtered, semantic searches over full-table scans
- Google Drive/Docs: Use caching for common queries (roadmap, onboarding guides)
- Slack: Limit to recent 30-90 days unless historical precedent is critical
- SearchOmniDocs: Use cached/indexed results where available

[Maintenance Notes]

- Update this index when new knowledge sources are added
- Review query patterns quarterly for optimization
- Capture common recurring issues for runbook creation
- Archive resolved issues and link to post-mortems if applicable

Common questions

What are model-defined skills?

Model-defined skills are created using the skills parameter in a model file or topic. Users with Modeler permissions or higher can create and edit these skills through the model IDE.

How do model-defined skills differ from chat and UI-created skills?

	Agent or UI skills	Model-defined skills
Can be created by	Any user with Omni Agent access	Modelers and higher
Runnable by	Any user with Omni Agent access	Users with Omni Agent access, required model permissions, and access grants (if set)
Impacted by Omni Agent > Skills setting	Yes	No
Create in chat	Yes	No
Create/edit on Skills page	Yes	No
View on Skills page	Yes. Non-admins can only see skills they created. Organization Admins can view all skills.	No. Visible in model IDE only.
Create/edit/view in model IDE	No	Yes
Run from Skills page	Yes	No
Run with `/` in chat	Yes	No
Run directly in chat	Yes	No
Run from chat actions menu	Yes	Yes
Run by clicking skill button in chat	No	Yes
Accepts file uploads in chat	Yes	Yes

Will model-defined skills be replaced?

Yes. In the near future, Omni will deprecate model-defined skills in favor of managing skills through the Omni Agent or Skills page.

Will my model-defined skills still run?

Yes, but going forward, create skills through the Omni Agent or Skills page.

Next steps

Routines — Run AI prompts on a schedule
AI settings — Turn AI features on and off for your organization
Library — Browse ready-made skills, apps, and routines

Getting started

Manage content

Analyze & build

Visualize & present

Deliver content

Model data

Manage integrations

How skills work

Skills versus sample queries

Skill properties

Requirements

Creating skills

Running skills

Adding files to skill conversations

Writing effective skills

Examples

Product roadmap answers

Triage bug reports

Support agent

Common questions

Next steps

​How skills work

​Skills versus sample queries

​Skill properties

​Requirements

​Creating skills

​Running skills

​Adding files to skill conversations

​Sharing and accessing skills

​Writing effective skills

​Examples

​Product roadmap answers

​Triage bug reports

​Support agent

​Common questions

​Next steps

How skills work

Skills versus sample queries

Skill properties

Requirements

Creating skills

Running skills

Adding files to skill conversations

Sharing and accessing skills

Writing effective skills

Examples

Product roadmap answers

Triage bug reports

Support agent

Common questions

Next steps