> For the complete documentation index, see [llms.txt](https://docs.datasentinel.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datasentinel.io/manual/ai-connector/use-the-assistant/skill-commands.md). # Skill commands reference Every command the Datasentinel Skill answers to, what each one does, what it needs, and the plain-language phrases that trigger the same analysis. The Datasentinel Skill is driven by conversation: describe what you want and the assistant picks the right analysis. The Skill loads on demand. Once installed, the assistant keeps only its name and description in context; when a request is about Datasentinel (PostgreSQL performance, instances, sessions, the platform itself), it pulls in the full instructions and starts driving the MCP tools. One Skill serves every platform: it discovers all the MCP servers named with the `datasentinel-` prefix, so adding a second platform needs no Skill change. The Skill also answers to a short list of **named commands**, prefixed with the verb `datasentinel`. Commands are useful when you already know which analysis you want, when you set up or test a connection, and when you want a predictable entry point in a script or a scheduled run. This page lists every command the Skill understands. Type `datasentinel help` in the assistant at any time to get the same list, in your language, adapted to your session. ## If the Skill does not load If the assistant answers generically (no Datasentinel tool calls in the response), load the Skill by hand: * Use the assistant's own Skill invocation: `/datasentinel` in Claude Code, Antigravity CLI or Mistral Vibe CLI, `$datasentinel` in Codex, `@datasentinel` in ChatGPT, `/skill:datasentinel` in Deep Agents Code. * Or name it in the prompt: `Use the datasentinel skill to check the platform status.` If the Skill never loads, it is usually installed in a folder the assistant does not read. Each assistant's page in this section gives the right location and how to list the Skills it discovered. For the symptoms of a conversation running without the Skill, and the checks per assistant, see [The Skill did not load](/manual/ai-connector/troubleshooting/skill-not-loaded.md). ## How to run a command Both forms below reach the same code path in the Skill: use whichever your assistant supports. | Form | Where it applies | Example | | --------------------------- | ----------------------------------------------------------------------------------------------------------------- | ---------------------- | | `/datasentinel ` | Assistants that expose Skills as slash commands, such as Claude Code, Google Antigravity CLI, or Mistral Vibe CLI | `/datasentinel status` | | `datasentinel ` | Any assistant, written in the prompt. In ChatGPT, attach the Skill with `@datasentinel` first. | `datasentinel status` | | `datasentinel` (no command) | Opens a short interactive menu: platform status, session (`whoami`), instance list, or a report. | `/datasentinel` | {% hint style="info" %} **Commands are shortcuts, not the only way in.** Every command has a plain-language equivalent, shown in the *Ask instead* column below. "Why was prod-db slow between 2 and 3pm yesterday?" runs the same analysis as `datasentinel ash` with that window, and the assistant routes it on its own. {% endhint %} ## Connection and setup These commands check the wiring between the assistant, the MCP server, and the platform. The first three need no sign-in, so they are the ones to run right after [configuring an assistant](/manual/ai-connector/readme.md#configure-an-assistant), before the first sign-in. | Command | What it does | Needs | Ask instead | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | --------------------------------------------- | | `help` | Shows the usage guide: command list, report types, example prompts, and tips. | Nothing | "How do I use this?" | | `version` | Prints the version stamp of the Skill copy you are running, and where the latest one is published. | Nothing | "Is my skill up to date?" | | `platforms` | Lists the Datasentinel platforms discovered in this session (every MCP server named `datasentinel-*`). | Nothing | "Which platforms are configured?" | | `status` | Reports the health of the platform's services through the MCP server. | Sign-in | "Check the platform status" | | `whoami` | Your session at a glance: platform, identity, privilege, real-time access, token kind and expiry, skill version and folder, style, language, charts. When the connection is not signed in, explains how to sign in for your assistant. `token` is an alias. | Sign-in | "Who am I connected as?", "How do I sign in?" | `platforms` enumerates the connections themselves; `status` tells you whether the platform behind a connection is up. Run them in that order when a setup misbehaves: see the test section of your assistant's configuration guide, for example [Configure Claude Code](/manual/ai-connector/connect-a-cli-assistant/configure-claude-code.md#test-the-mcp-server-and-skill). `whoami` has its own page, with every row of its answer explained: [Check your session with whoami](/manual/ai-connector/use-the-assistant/whoami-command.md). `version` answers a different question: whether the Skill itself is current. Every release of the Skill carries a timestamp on the line right under the frontmatter of its `SKILL.md`, and the command prints that timestamp as is. Compare it with the same line at the top of `SKILL.md` on the `main` branch of the [datasentinel-skill](https://github.com/datasentinel/datasentinel-skill) repository: a later timestamp there means an update is available, so pull the clone or re-upload the zip. The assistant never fetches the repository to make that comparison for you, and it needs no platform call to answer. If your copy has no version line at all, it predates the stamp and is out of date for certain. ## Inventory and fleet | Command | What it does | Needs | Ask instead | | ----------- | ---------------------------------------------------------------------------------------------------------- | -------------------- | ------------------------------------------------------ | | `instances` | Lists the PostgreSQL instances you can see, with an overview by tag, then narrows the list step by step. | Sign-in | "What do we monitor in production?" | | `fleet` | Ranks many instances (the whole fleet or a tag cohort) by load over a window, to find where to look first. | Sign-in, time window | "Which databases are busiest in production this week?" | `instances` answers *what exists*: names, roles, versions, sizes, tags, last collection. `fleet` answers *how they behave*: load, waits, the instance to drill into. See [Browse and navigate your fleet](/manual/ai-connector/analyze-and-tune-workloads/browse-your-fleet.md) and [Analyze across multiple instances](/manual/ai-connector/analyze-and-tune-workloads/analyze-across-instances.md). ## Analyze one instance over a past window Each of these commands asks you to confirm an instance and a time window of at most 24 hours before it calls the platform. | Command | What it does | Needs | Ask instead | | ------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------- | --------------------------------------------------- | | `ash` | Session load (average active sessions) and the wait mix over the window, with the top queries behind it. | Sign-in, time window | "What ran on prod-db between 02:00 and 03:00?" | | `io` | I/O-bound drill-down: confirms the storage wait, then attributes it to statements and tables. | Sign-in, time window | "Was prod-db disk-bound last night?" | | `query` | Deep-dive on one SQL query: execution statistics, per-query waits, and the captured execution plan. | Sign-in, time window | "Analyze the slowest query on crm-db this morning" | | `tables` | Table and index health: bloat proxy, sequential scans, missing or unused indexes, autovacuum keeping up. | Sign-in, time window | "Any missing indexes on orders-db in the last 24h?" | | `locks` | Lock contention over the window: blocking chains collapsed to root blockers, contended objects, deadlocks. | Sign-in, time window | "What was blocking on orders-db at 2am?" | | `compare` | Compares two windows on the same instance: load, wait mix, query set, configuration, and the queries driving the delta. | Sign-in, two time windows | "Is today worse than yesterday on prod-db?" | | `annotations` | Monitoring health: explains gaps, flatlines, and repeated collection errors in the data. | Sign-in, time window | "Why is there a hole in the metrics around 3am?" | | `wal` | Why the write-ahead log is large or commits are slow, and which statements generate the volume. | Sign-in, time window, TECHNICAL | "Why is WAL so large on prod-db since midnight?" | | `config` | Reviews an instance's parameters against its version, role, and host, or lists what changed during the window. | Sign-in, time window, TECHNICAL | "What parameters changed on prod-db last night?" | | `system` | Host resources (CPU, memory, swap, load) and whether PostgreSQL is the cause or something else on the machine. | Sign-in, time window, TECHNICAL | "Is the host of billing-db CPU-bound?" | | `replication` | Replication health: per-standby lag, unreplayed backlog, paused replay. | Sign-in, time window, TECHNICAL | "Is the replica of crm-db lagging?" | {% hint style="info" %} **TECHNICAL rows.** `wal`, `config`, `system`, and `replication` report server-level measurements, so the Skill reserves them for the TECHNICAL style. A PLAIN-style user who asks for one is not refused: the assistant asks what the application is experiencing, runs the matching workload, comparison, or diagnostic analysis, and delivers the infrastructure outcome as a verdict rather than raw numbers. The styles are described under [Communication style](/manual/ai-connector/readme.md#communication-style). {% endhint %} See [Analyze a workload over a time window](/manual/ai-connector/analyze-and-tune-workloads/analyze-a-workload.md) for the `ash` starting point and the drill-downs that follow it. ## Look at live activity These commands query the instance as it is right now. They need no time window, and they require **real-time access** on your account, granted through the [Live360](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/features/key-features/live360) module. Without it, the assistant does not offer them and redirects to the closest historical analysis. | Command | What it does | Needs | Ask instead | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | ----------------------------------------------- | | `current-sessions` | Live active sessions on an instance: who is running what, and what they wait on. | Sign-in, real-time access | "What's running on billing-db right now?" | | `current-blocking` | Live blocking chains: the sessions holding locks and the sessions stuck behind them. | Sign-in, real-time access | "Is anything blocking on orders-db right now?" | | `maintenance` | Live progress of VACUUM, CLUSTER, index builds, ANALYZE, and COPY. Falls back to historical autovacuum and bloat signals without real-time access. | Sign-in, real-time access | "Is the vacuum on orders still running?" | | `explain` | Live execution plan of a statement you paste, or the generic plan of a captured query on PostgreSQL 16 or later. Estimates only, nothing is executed. | Sign-in, real-time access | "What plan does this get on crm-db: SELECT ..." | See [Diagnose a live performance spike](/manual/ai-connector/analyze-and-tune-workloads/diagnose-live-spike.md), [Investigate a blocking scenario](/manual/ai-connector/analyze-and-tune-workloads/investigate-blocking-scenarios.md), and [Explain execution plans](/manual/ai-connector/analyze-and-tune-workloads/explain-execution-plans.md). ## Diagnose and verify | Command | What it does | Needs | Ask instead | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | ---------------------------------------- | | `diag` | Broad triage when something is wrong and the cause is unknown: connections, WAL and disk, host, locks, queries, maintenance, monitoring. Localizes the fault, then routes to the matching deep-dive. | Sign-in | "prod-db is slow, find out what's wrong" | | `prove ` | Justifies finding number N from the current analysis: the evidence, the reasoning, the alternatives ruled out, and a verdict. | A finding already stated in the session | "Are you sure about finding 2?" | `diag` defaults to *now* and degrades gracefully without real-time access. When no instance is named, it runs a fleet ranking first and diagnoses the instance that surfaces. `prove` inherits the instance and window of the finding, so it asks no new question. Its verdict can be *holds*, *holds with caveats*, or *does not hold*: when the evidence is thinner than the original wording implied, the assistant corrects the finding rather than defending it. ## Generate reports | Command | What it does | Needs | Ask instead | | --------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------- | ------------------------------------------------------------------- | | `report ` | Asks the platform to build a PDF report for one instance and returns a single-use download link. | Sign-in, instance name, time window | "Generate a full PDF report for prod-db for last night 22:00-23:00" | `` is one of the platform's PDF report types: | Type | Content | | ------------- | -------------------------------------------------------- | | `full` | Instances, queries, server, and workload in one document | | `workload` | Session history overview | | `top-queries` | Top SQL statements ranked by a metric of your choice | | `query` | Deep-dive on a single query | The PDF is produced server-side by Datasentinel, with the same content as the [Reporting](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/features/key-features/reporting) feature of the web interface. {% hint style="info" %} **HTML and Markdown are not report types.** They are the two formats of the report the assistant itself builds from the analysis you are looking at. Ask for them in plain language once an analysis is on screen: "give me an HTML report for that period", or "give me that as Markdown, something I can paste into Jira". See [Keep, export, and revisit your analyses](/manual/ai-connector/analyze-and-tune-workloads/what-you-can-analyze.md#keep-export-and-revisit-your-analyses). {% endhint %} ## What the commands need {% tabs %} {% tab title="Sign-in" icon="key" %} Every command except `help`, `version`, and `platforms` needs a **signed-in connection** to the platform. * The first time an assistant uses the Datasentinel MCP server, it opens the Datasentinel login page in your browser. Sign in with your platform login and password, the same ones as the web interface. * The assistant then holds a token on your behalf and renews it silently. You sign in again only after ten days without using the server, or when an administrator revokes the session. * The assistant never asks you for a token or a password in the conversation. If it reports that the server needs authentication, run `whoami`: it explains how to sign in for your assistant. * Scripts and scheduled jobs use a user token instead: obtained from the web interface or the API, valid 24 hours, and configured in the client as an authorization header. See [Refresh the user token automatically](/manual/ai-connector/developers/refresh-user-token.md) to renew it on a schedule. {% endtab %} {% tab title="Time window" icon="clock" %} Historical analyses run over a window of **at most 24 hours**, and the assistant never picks one silently. * Give a range ("between 14:00 and 15:00 yesterday") and it is used as is. * Give a single moment ("around 3am") and the assistant offers three windows around it (plus or minus 10, 20, or 30 minutes) and waits for your choice. * Times are read in your local time zone unless you say they are UTC. * `compare` needs two windows of similar duration; live commands and `diag` need none. {% endtab %} {% tab title="Real-time access" icon="bolt" %} `current-sessions`, `current-blocking`, and `maintenance` query the live cluster through the Datasentinel agent. * They are available only when your account has real-time access through the [Live360](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/features/key-features/live360) module. * The queries they run are read-only and transit through the platform; the assistant never holds a PostgreSQL credential. * Without real-time access the assistant does not list them and proposes the historical equivalent instead. {% endtab %} {% tab title="Style" icon="user-group" %} Your account carries your role, as configured under [Users & Roles](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/implementation/platform-usage/configuration/users-and-roles). * The role selects the communication style of every response: **TECHNICAL** for a Data admin, **PLAIN** for a Developer. When the role cannot be determined, the Skill uses PLAIN. * Four commands report server-level measurements and are reserved for the TECHNICAL style: `wal`, `config`, `system`, and `replication`. In the PLAIN style, the outcome arrives as a verdict through the workload, comparison, or diagnostic analyses instead. * Say "switch to plain language" or "switch to technical" at any time to switch style for the rest of the conversation. {% endtab %} {% endtabs %} ## Phrases that change the conversation A few plain-language phrases act on the session itself rather than on your data. They are not commands, so they take no `datasentinel` prefix. | Say | Effect | | ----------------------------------------------------- | --------------------------------------------------------------------------------------- | | "switch to plain language" / "I'm not a DBA" | Switches to the PLAIN communication style. | | "switch to technical" / "I'm a DBA" | Switches to the TECHNICAL communication style. | | "text only" | Replaces charts and metric cards with Markdown tables for the rest of the session. | | A message in another language | The assistant answers in the language of your first message and switches when you ask. | | "prove it" / "are you sure?" / "show me the evidence" | Runs `prove` against the most recent finding. | | "give me an HTML report" / "give me that as Markdown" | Exports the analysis on screen as an interactive HTML file or a portable Markdown file. | {% hint style="info" %} **One step at a time.** The assistant stops after every result and ends with a short menu of next steps drawn from what the data showed. It never chains analyses on its own: pick an option, run a command, or ask the next question. {% endhint %} ## Where to go next {% content-ref url="/pages/8qsup0or6GikxlWBb5Gk" %} [What you can analyze](/manual/ai-connector/analyze-and-tune-workloads/what-you-can-analyze.md) {% endcontent-ref %} {% content-ref url="/pages/7XkGwTwrvjKd43bU95BD" %} [Browse and navigate your fleet](/manual/ai-connector/analyze-and-tune-workloads/browse-your-fleet.md) {% endcontent-ref %} {% content-ref url="/pages/LOr8fRFJ0UAJgJpqrY7c" %} [Configure Claude Code](/manual/ai-connector/connect-a-cli-assistant/configure-claude-code.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.datasentinel.io/manual/ai-connector/use-the-assistant/skill-commands.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.