Skip to main content
AI SRE is available to accounts on an On-call Pro or higher subscription, with no application needed. Starting September 16, 2026, 08:00 Beijing time, it must be activated in the console before use and is billed on actual usage; see billing terms.

​
Overview

A Skill is a reusable capability bundle. Every skill consists of two parts:
  • A SKILL.md instruction document that tells the agent “when to use it, how to use it, and what steps to follow”;
  • The allowed tools declared by the skill, plus optional supporting resource files (scripts, templates, sub-documents, etc.).
A skill is packaged as a Skill archive (.zip or .tar.gz, with extension .zip / .skill / .tar.gz / .tgz) and uploaded to AI SRE; a .tar.gz is normalized to canonical zip at install. The archive’s root directory must contain a SKILL.md file; all other resource files can be placed anywhere inside the archive and will be read by the agent on demand during execution. Once enabled, the skill becomes visible and callable by the agent in the session. The agent can autonomously decide when to invoke a skill, or you can explicitly trigger it in the chat box with /<skill-name> (e.g., /skill-creator). When triggering explicitly, you can append arguments: /<skill-name> arg1 arg2. The SKILL.md body can reference positional arguments with $1…$9 (whitespace-split) and the full raw remainder with $ARGUMENTS; these placeholders are substituted with the actual values before the turn is sent. If you just want to mention /skill-name in a message (for example, asking “what does \/skill-name do?”) without triggering it, add a backslash escape at the start of the message: a message starting with \/ has that leading backslash stripped and is sent as plain text instead of being parsed as a command.
Cross-team skill name conflicts and the @ qualifier. Skill names must be unique within a team, but different teams may each own a skill with the same name. When two teams both have an enabled skill with the same name and both are in scope for the current session, a bare /<skill-name> cannot resolve to either and is rejected with a hint listing the qualified forms. In that case, use /<skill-name>@<team_id> to disambiguate (e.g., /deploy@5). The @ character is therefore reserved and cannot be used in skill names.
The difference between Skills and MCP: MCP provides connectivity to external tools; Skills provide the methodology for orchestrating those tools to complete a category of tasks. They work together — a skill declares in SKILL.md which tools it needs, including built-in tools and MCP tools in the form mcp:server/tool.

​
SKILL.md Format

SKILL.md consists of two parts — YAML frontmatter (metadata) and a body (human-readable instructions for the agent) — separated by ---:
Frontmatter fields:
Use venues for skills that structurally depend on one kind of environment — for example, a skill that needs a local binary, local files, or a private-network service on the environment’s host simply cannot work inside a Cloud Sandbox. With venues: [byoc] declared, the skill neither appears in the agent’s available-skills list nor can be triggered by /<skill-name> in a Cloud Sandbox session; only sessions bound to a self-hosted Runner can see and call it.
Tools can be specified in two ways:
  • Built-in tools: write the tool name directly. Available built-in tools include read, write, edit, bash, grep, glob, skill, mcp, todo, time, webfetch, web_search, and others.
  • MCP tools: write them as mcp:server/tool (e.g., mcp:my-server/query). At upload time, only the existence of the MCP server is validated; the specific tool name is verified when the MCP is loaded during a session.
The AI SRE runtime bundles a few skills that are available without installation. flashduty is one such reference: it uses the fduty CLI to cover the entire Flashduty API, allowing the agent to investigate incidents, read AI insights, query alerts, correlate changes, and more — use it as a template when writing your own skills. Another bundled skill is github, which the agent self-selects from <available_skills> to let AI SRE work directly inside a GitHub repository — explore code, investigate PRs and commits, and open a PR or issue on request; it requires the GitHub App (cloud) or the runner host’s gh (BYOC). A third bundled skill is gitlab, symmetric with github in capability: the agent self-selects it to work directly inside a GitLab repository — explore code, trace MRs and issues, and open an MR or issue on request; it requires the GitLab App (cloud) or the runner host’s glab (BYOC). See Apps.There is also flashduty-docs: it downloads Flashduty’s official documentation (both the Chinese and English page sets, the glossary and the Open API specs) into the runtime environment and answers questions about how the product itself works by searching it by topic — features, settings, limits, plans, compatibility, SDK behaviour and performance impact, API fields and errors — across On-call, RUM, Monitors, AI SRE, Status Page, the platform and Open API. Its answers cite public docs.flashduty.com links and are drawn from the docs alone; where the docs do not cover something it says so plainly. It only reads documentation and does not replace hands-on work (actual RUM instrumentation belongs to rum), and the docs bundle’s address is injected by the platform, so there is nothing to configure.
Those are examples, not the whole set: the runtime also bundles init, insight, artifact-design, alert-governance, monit-query and more, and the set grows between releases. What the agent actually sees in a session is <available_skills>; to find out which bundled skills a given session has, just ask the agent.

​
Install from Marketplace

The skill catalog is part of the plugin catalog on Customize → Plugins → Overview: skill templates are listed alongside MCP templates and the built-in Apps, grouped by category, with skills in their own Skill category (they also appear under the “All” tab, tagged Skill). The search box above the catalog filters by name or description, the tabs narrow the list to one category, and “See all N” next to a category heading expands that category; the search term and the selected tab live in the page URL, so leaving and coming back lands you where you were.
1

Find the template

On Customize → Plugins → Overview, find the template under the Skill category; each row shows the template name and description.
2

Confirm the install

An uninstalled row has a round + button on its right; clicking + or the row itself opens the Install skill "<name>" confirmation dialog: “Installs to the account — available to all members.” Marketplace installs are always shared scope (shared = account level), with no owner selection. Click Install to actually call the install endpoint — this copies the template content into your account as a regular skill entry and marks its source template (shown on the list as a From Marketplace — <template name> v<version> tooltip). A successful install reports "<name>" installed.
3

Manage what is installed

An installed row no longer shows +; it shows Enabled. Managing and updating it happens on the Customize → Plugins → Skill list — see “Management and Inspection” and “Automatic and Manual Updates” below.
New accounts are automatically pre-installed with a set of official Marketplace templates: browser-automation (a browser automation CLI for operating websites, dashboards, and monitoring UIs), mcp-builder (guides you through building an MCP server), monit-query (Monit data source queries), and skill-creator (see “Add in conversation” below). These pre-installed skills behave exactly like manually installed skills — you can enable/disable, uninstall, or update them to the latest version under “Management and Inspection” below.
Name conflicts: if a skill with the same name already exists in your account and it was not installed from the same template (for example, a custom skill you uploaded by hand), the install is rejected — a Marketplace install never overwrites or takes over such a skill, even with overwrite-update selected. Delete the custom skill first, then install the Marketplace template with that name.

​
Automatic and Manual Updates

When a Marketplace template publishes a newer version, the corresponding skill entry displays an Update available badge. Whether the update is applied automatically depends on whether the skill has been modified locally:

Clean skill (unmodified)

A skill that has not been locally modified after installation is automatically updated to the latest Marketplace version when the list loads — no manual action required. A notification appears after a successful update.

Modified skill

A skill that has been locally edited or re-uploaded is skipped by auto-update to avoid overwriting your changes. It retains the Update available badge, and you must manually click to update and confirm the overwrite.
Updating a modified skill overwrites your local changes with the latest Marketplace version and cannot be undone. The UI displays an “Overwrite update” confirmation dialog — proceed with caution. After reinstalling the Marketplace version, the local-modification flag is cleared and the skill returns to a clean state, re-enrolling in automatic updates.

​
Custom Skills

In addition to installing from the Marketplace, you can upload your own skill packages. On the skill list page, click Upload Skill and fill in the form: At upload time, the system automatically validates that: the archive is a valid zip, SKILL.md exists in the root directory, the frontmatter is parseable, name follows the naming rule (letter-led, letters/digits/-/_ only, 1–64 characters), and all declared tools are valid (built-in tools exist, MCP servers exist). Skill names must be unique within a team — a duplicate name within the same team is rejected with a prompt to choose a different name; different teams may each own a skill with the same name.
All metadata other than the skill name (description, version, tags, author, tools, etc.) is parsed from SKILL.md’s frontmatter and does not need to be entered separately in the form.

​
Overwrite upload (Replace)

When you want to replace an existing skill with a new version, the upload endpoint supports two overwrite modes. The UI presents a “Replace” confirmation dialog at the appropriate moment: Both modes return the updated skill object on success. If the target skill does not exist, a 404 error is returned — neither mode silently creates a new skill. Without the replace parameter (the default), a name collision is rejected outright; the upload endpoint never implicitly overwrites an existing skill.

​
Add in conversation (skill-creator)

Besides uploading a zip, you can create and refine skills right inside an AI SRE session. skill-creator is a Flashduty-provided Marketplace skill, pre-installed into your account by default, that exists specifically to “build skills.” Trigger it with /skill-creator in any session, or just describe what you want in natural language: Add in conversation at the top right of the skill list page opens a new session with a pre-filled brief: “I want to add a Skill. First ask me whether I’m authoring it myself or installing an existing one from the web. For an existing one, search a few candidates for me to pick from, and install the one I choose.” In other words the agent first asks whether you want to author a new one or install an existing one; for an existing one it checks the plugin catalog / Marketplace first, searches the web only when the catalog has nothing, and installs what you pick. The prompt is only pre-filled, never sent automatically. The button appears only when you have a scope you can author into: always when you can author at account scope, otherwise when the current scope filter selects exactly one team you belong to (or you belong to only one team).
  • Create from scratch: say “help me create a skill for troubleshooting X,” or after an investigation, “turn that workflow into a skill.” skill-creator clarifies your intent, drafts the SKILL.md, optionally sets up test cases and iterates on them, and saves the result as a skill in your account once you’re happy.
  • Find an existing one online: when you enter through “Add in conversation” and choose to install an existing skill, the agent checks the plugin catalog first and searches the web only when the catalog has nothing; once you pick one it completes the install, which becomes a regular skill entry.
  • Rewrite & optimize: click “Edit in Chat” in a skill’s detail panel to have skill-creator rewrite that skill; it can also tune the description to improve triggering accuracy.
Once the draft is ready, the agent saves it as a skill with one click. If the name conflicts with an existing skill, a “Replace” confirmation dialog appears — under the hood this invokes the replace-by-name mode (replace=true, no skill_id).
Skill archive size limits: archives saved by the agent in-conversation are capped at 10 MB; archives uploaded via the web form or file upload in a session are capped at 100 MB.

​
Management and Inspection

The skill list displays each skill’s name (with source template badge, Update available marker, and Local runner only badge), scope (shared or team), version, enabled toggle, and an actions column. Skills that declare venues: [byoc] carry a Local runner only badge whose tooltip reads “Available only in sessions bound to a local runner; unavailable in cloud sandbox sessions”; Marketplace template cards show the same badge, so you know a template needs a self-hosted Runner before you install it. The toolbar above the list provides a scope filter (All / Account / Team) and a search box that filters the list by keywords in the name, description, or author.
Toggle using the switch in the list or the detail panel. Only enabled skills are visible to the agent; a disabled skill is invisible to the agent and cannot be invoked.
Click the edit button to update the description and owner (scope). Marketplace-installed skills are permanently shared scope, so the scope is not editable in the form. To modify skill content, download the zip, edit it, then re-upload (this creates a new version and marks the skill as modified).
In the detail panel, select “Replace” to overwrite the current skill content with a new zip. The SkillID remains unchanged, so any existing references (e.g., /<skill-name> triggers) continue to work.
Download the complete zip package (including SKILL.md and all resource files) for offline editing or backup.
Removes the skill from the current scope. Any active sessions currently using it will continue to fail until the skill is reinstalled. This action requires confirmation.

​
Detail Panel

Click any row in the list to open the skill’s detail panel:
  • Left side: the file tree of the skill package (SKILL.md, README.md, etc. are prioritized as the default preview file).
  • Right side: content preview of the selected file, with the skill description shown at the top.
  • Header area: skill name (short reference in the form skill-xxxxxx), scope label (shared / team name), source template version badge (hover to see “From Marketplace — template name v<version>”), Update available marker, author, version, and the full SkillID.
  • Actions: try in chat (injects /<skill-name> into a new session), update to latest version, edit in chat, replace, download, uninstall.
  • Try asking: if the skill declares examples in the SKILL.md frontmatter, a Try asking toggle appears below the header area of the detail panel, collapsed by default — the sample questions are not laid out until you click it; expanding it lists up to 2 sample questions, and clicking one opens a new session with that skill plus the question pre-filled (never sent automatically). The bottom of the expanded area carries the hint “Clicking a question opens a new chat with it filled in. Review it, then send.”
When a skill package is too large to preview, the detail panel displays the file size and suggests using “Download” instead.

​
Scope

Skills share the same two-level scope model with other resources (Knowledge, MCP, Agents, environments), divided into account level and team level: Edit permissions: team-level skills can be acted on only by members of that team — organization admins must join the team first; account-level skills can be acted on only by the account owner or an account administrator. There is no “creator retains rights” exception. Rows you cannot edit appear as read-only in the list. Create and reassign: to upload a new team-level skill, you must belong to the target team; account-level upload is limited to the account owner or admins. Marketplace installs are the exception: they are always shared scope (account level), any account member can install one (no owner/admin permission required), and no team can be chosen at install time. When editing an existing skill, the account owner or admins can move it to any team to recover resources left behind by empty teams or departed members; regular members can move it only to teams they belong to. However, Marketplace-installed skills cannot be reassigned to a team — their scope is shown as a fixed account value in the edit form. A small number of legacy team-scoped Marketplace skills from earlier versions can be promoted to account scope via Set to Shared in the detail panel. Set to Shared carries the same gate as account-level upload: only the account owner or admins can do it — a regular member cannot self-serve the promotion even for their own team’s skill, and the denied action prompts them to ask an admin to make it shared. Runtime visibility: at session start, only shared-scope (account-level) skills and skills belonging to the team bound to the current session are loaded into the session. Skills and MCP servers from other teams are mounted into the current session on demand only after the agent reads that team’s knowledge during an investigation. The account is the sole security boundary at runtime, and using a team-level skill is bound by the same visibility rules — a team is no longer just an ownership and editing tag on this surface.
The / autocomplete dropdown in the chat input only shows shared-scope skills plus team-level skills for teams you belong to — and that visibility is the resolution boundary, not just menu cosmetics. Manually typed slash commands pass through the exact same per-row scope gate (“resolve == visible”), so a team-level skill outside the current session’s reach is never parsed or executed. Concretely: in a team session, invoking another team’s command is rejected with a message explaining why; in a personal session, the command resolves (mounting the team on demand) only for members of the team that owns the skill — a non-member’s input is refused exactly as if the command did not exist.

Manage Knowledge

Use DUTY.md and knowledge to provide the agent with team context and troubleshooting experience.

MCP (External Tools)

Connect external tools so skills can invoke them in SKILL.md using mcp:server/tool.

Agent

Extend AI SRE’s collaboration and task-delegation capabilities with Agents.

Console

Explicitly trigger a skill in a session with /<skill-name>, or let the agent invoke it autonomously.

Overview

Learn about AI SRE’s overall capabilities and positioning.