Skills DirectorySearch all skills ↗AI agent skill · by @omnara-ai
Sre Agent
Deploy or update the SRE Agent on Omnara, a production investigator that diagnoses issues across AWS and source code and reports the likely cause with evidence. Use when the user asks to deploy, set up, update, or remove the SRE agent.
Archived 2026-10-23 · Source updated 2026-10-11 · License: Apache-2.0. Check the original repository for the latest version.
SKILL.md instructions
# Deploy the SRE Agent
You are setting up an Omnara agent for the user from `agent.yaml` in this
folder. The goal: an agent profile the user has watched run once, reachable
wherever they want it (their own app, Slack, Discord, or the Omnara
console), and
optionally running a daily health check.
The steps below are the usual path and have the exact commands. Skip anything
that's already done (for example, the secrets and profile exist and the user
only wants to add code access), follow the user's lead if they want a different
order, and narrate briefly as you go.
- Start from `agent.yaml` as written. If the user wants something different
(the instruction, data sources, model, or how they reach the agent), change
it and tell them what you changed.
- If a command fails, read the error and fix it; `npx omnara <command> --help`
and [docs.omnara.com](https://docs.omnara.com) have the details. If you're
stuck, show the user the error.
The commands use the Omnara CLI (`npx omnara`) because its login handles auth
in one step; add `--json` when you need to read IDs from the output. They're a
reference, not a requirement: the Omnara MCP tools, the
[REST API](https://docs.omnara.com/api-reference/openapi.yaml), or the SDK work
too, and the flags map directly to API fields. What matters is the result:
secrets for the data sources, a profile from the filled-in `agent.yaml`, and
whatever the user picks in steps 8 and 9. Slack and Discord setup is simplest
with the CLI.
## 1. Connect to Omnara
1. Run `npx omnara whoami`. If it reports that you aren't logged in, run
`npx omnara login` in an interactive terminal, share the approval link it
prints, and wait until the user approves.
2. Pick the org and project. `npx omnara whoami --json` lists the user's orgs,
and `npx omnara projects list --org <org-id> --json` lists an org's
projects.
- If there's only one org and one project, use them.
- If there are several of either, ask the user which to use. Suggest the
current defaults from `npx omnara config` if they're set, otherwise the
project named `Default`.
Save the choice with `npx omnara config --org <org-id> --project <project-id>`.
Remember the project ID; later steps need it.
## 2. Describe the system
Ask the user about the production system the agent will investigate:
- `COMPANY_NAME`: the company or product name, for example `Acme`.
- What it is and its main services, and how they run on AWS (ECS, Lambda,
EKS, EC2), plus where logs live. Write this as `SYSTEM_CONTEXT`: two to four
sentences on a single line, for example
`Acme is a checkout API for online stores. It runs an API and a worker on ECS Fargate behind an ALB, with RDS Postgres and SQS, primarily on AWS. Logs go to CloudWatch Logs under /ecs/acme-*.`
If the user has AWS CLI access and wants you to, you can draft it from
`aws ecs list-services`, `aws lambda list-functions`, and similar
read-only calls.
- `AWS_REGION`: the region production runs in, for example `us-west-2`.
- Whether they want the agent to read their code (step 4). It's optional and
makes answers sharper.
Show `SYSTEM_CONTEXT` to the user and adjust until they're happy. If they
can say more about their logs or metrics (for example, every request writes
one structured log line with its errors and database queries), add a short
section for each under `# Available Data` in step 6, like the `## AWS` one.
## 3. Create read-only AWS credentials
The agent reaches AWS through the
[AWS MCP Server](https://docs.aws.amazon.com/aws-mcp/latest/userguide/what-is-mcp-server.html),
which signs each call with these credentials, so their IAM policy is what
keeps the agent read-only. Use a dedicated IAM user with only the AWS managed
policies `ViewOnlyAccess` and `CloudWatchReadOnlyAccess`. They cover
describing resources, metrics, alarms, and reading logs, but not S3 object
contents or secret values.
Skip this step if the secret already exists:
`npx omnara secrets list --owner-kind project --owner-project-id <project-id> --name sre-agent-aws --json`.
If it does, ask whether to reuse it and note its `id`.
1. Create the IAM user, either way:
- **You do it**, if the user has the AWS CLI signed in to the production
account with IAM permissions and says go ahead. This writes the keys
straight to `.env` without showing them:
```sh
aws iam create-user --user-name omnara-sre-agent
aws iam attach-user-policy --user-name omnara-sre-agent \
--policy-arn arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
aws iam attach-user-policy --user-name omnara-sre-agent \
--policy-arn arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess
aws iam create-access-key --user-name omnara-sre-agent \
--query 'AccessKey.[AccessKeyId,SecretAccessKey]' --output text \
| awk '{print "AGENT_AWS_ACCESS_KEY_ID=" $1 "\nAGENT_AWS_SECRET_ACCESS_KEY=" $2}' >> .env
```
- **The user does it** in the IAM console: **Users** → **Create user** →
**Attach policies directly** (`ViewOnlyAccess`,
`CloudWatchReadOnlyAccess`), then on the user's **Security credentials**
tab, **Create access key**. Ask them to add the keys to a `.env` file in
the current directory and tell you when it's saved (pasting them in the
chat also works):
```sh
AGENT_AWS_ACCESS_KEY_ID=...
AGENT_AWS_SECRET_ACCESS_KEY=...
```
2. Create the secret:
```sh
set -a && . ./.env && set +a
npx omnara secrets create --owner-kind project --owner-project-id <project-id> \
--name sre-agent-aws --material-kind aws_credentials \
--material-access-key-id "$AGENT_AWS_ACCESS_KEY_ID" \
--material-secret-access-key "$AGENT_AWS_SECRET_ACCESS_KEY" --json
```
Note the `id` (`sec_…`) as `AWS_SECRET_ID`. If the user prefers a role,
add `--material-role-arn` (and `--material-external-id` if the role's
trust policy requires one); Omnara assumes it with these keys.
## 4. Let the agent read the code (optional)
Recommended: with the repository cloned on a machine, the agent can trace an
error to the code behind it and cite the exact lines. Ask which repository
(`GITHUB_REPO`, as `owner/name`). One repository is supported as written.
- **Public repository:** nothing to store.
- **Private repository:** the user creates a
[fine-grained token](https://github.com/settings/personal-access-tokens/new)
with read-only **Contents** access to that repository and adds it to `.env`
as `AGENT_GITHUB_TOKEN=...`. Check for an existing secret named
`sre-agent-github` as in step 3, otherwise create it:
```sh
set -a && . ./.env && set +a
npx omnara secrets create --owner-kind project --owner-project-id <project-id> \
--name sre-agent-github --material-kind generic \
--material-value "$AGENT_GITHUB_TOKEN" --json
```
Note the `id` as `GITHUB_TOKEN_SECRET_ID`.
## 5. Pick the model (and machine pool)
1. `npx omnara grant models list --json`: each item has
`model.provider_config` and `model.name`. Ask the user which model to use.
Suggest `openai/gpt-6-astra` on `omnara-openrouter` if it's granted (the
instruction was tested with it); otherwise suggest the strongest reasoning
model on the list. Name a couple of alternatives rather than the whole
list, and show everything if they ask. The choice gives
`MODEL_PROVIDER_CONFIG` and `MODEL_NAME`.
2. Only if the agent reads the code (step 4):
`npx omnara grant pools list --json`; each grant's `machine_pool.name` is a
candidate `MACHINE_POOL`. Use the only one, or ask if there are several. If
there are none, tell the user the project needs a machine pool for code
access, and continue without it if they prefer.
## 6. Create the agent
1. Copy `agent.yaml` from this folder to `./sre-agent.yaml` in the current
directory. If this folder isn't available locally, download
https://raw.githubusercontent.com/omnara-ai/omnara/main/examples/sre-agent/agent.yaml
instead.
2. Remove what the user isn't using:
- No code access: delete the `## Source Code` section of the instruction,
`machine_sources`, and the `tools:` block at the end.
- Public repository: delete the `secret_env_overlay` block.
3. Replace every remaining placeholder:
| Placeholder | Value |
| --- | --- |
| `{{COMPANY_NAME}}` | from step 2 |
| `{{SYSTEM_CONTEXT}}` | from step 2 |
| `{{AWS_REGION}}` | from step 2 |
| `{{AWS_SECRET_ID}}` | the `sec_…` ID from step 3 |
| `{{GITHUB_REPO}}` | from step 4 |
| `{{GITHUB_TOKEN_SECRET_ID}}` | from step 4 |
| `{{MODEL_PROVIDER_CONFIG}}` | from step 5 |
| `{{MODEL_NAME}}` | from step 5 |
| `{{MACHINE_POOL}}` | from step 5 |
Then confirm nothing is left: `grep -n '{{' sre-agent.yaml` must print
nothing.
4. Check for an existing profile: `npx omnara profiles list --name sre-agent --json`.
- None: `npx omnara profiles create --name sre-agent --file ./sre-agent.yaml --json`
- Exists: `npx omnara profiles update <agent-profile-id> --file ./sre-agent.yaml --json`
Note the profile's `id` and `current_config_id` from the output.
## 7. Run a first health check
```sh
npx omnara agents launch --profile <agent-profile-id> --config <current-config-id> \
--message "Run a production health check." --json
```
Give the user the link to watch it work:
`https://app.omnara.com/projects/<project-id>/agents/<agent-id>`. It takes a
few minutes, longer on the first run while the machine clones the repository.
The user can reply in the console with a real question, such as a recent
alert or "why was checkout slow yesterday at 3pm?". If the agent reports an
AWS call as denied, that's the read-only policy working; only widen it if the
user wants that data.
## 8. Choose where to use it
Ask where the user wants to talk to the agent, offering these in this order.
Any combination is fine.
**Their own app, existing or new (recommended).** Put the agent where the
user's team already works: inside their existing product or internal tool, or, if there's no
natural home, a small UI built for it. Both are the same integration: launch
agents from the profile and stream their replies with the TypeScript SDK
(`@omnara/sdk`) or the REST API; see [docs.omnara.com](https://docs.omnara.com).
Anything else that can call the API can start the agent the same way; for
example, their alerting webhook can start an investigation with the alert text
as the message. The app needs an org API key: the user creates one on the
dashboard's **API Tokens** page (**Organization** tab → **New token**), then
grants it a role on this project from the key's detail panel. Help them wire
it in, or build the UI with them.
**Slack.** The bot answers wherever it's mentioned, and thread replies become
instructions to the agent. An incidents or alerts channel works well.
If `npx omnara integrations list --json` already has an integration named
`sre-agent-slack` from an earlier run of this skill, reuse it whatever its
state, since names are unique in a project. If
`npx omnara integrations get <integration-id> --json` doesn't list this profile
under `settings.launcher.profiles`, add it with
`npx omnara integrations profiles <integration-id> --profile-ids <agent-profile-id>`;
the flag replaces the list, so repeat each profile already there. Then, if its
`state` is `active`, skip to its last step. If it's `disconnected`, setup didn't
finish: skip step 2, and redo step 1 only if the token in `.env` has expired.
1. The user creates an app configuration token at
[api.slack.com/apps](https://api.slack.com/apps) under **Your App
Configuration Tokens** → **Generate Token**. It expires after about 12
hours. Have the user add it to `.env` as `SLACK_APP_CONFIG_TOKEN=...`.
2. Create the integration with this profile in its launcher, so a mention
starts this agent, and note the `itg_…` ID it returns:
```sh
npx omnara integrations create --name sre-agent-slack \
--integration-kind slack_thread \
--settings '{"launcher":{"profiles":["<agent-profile-id>"]}}' --json
```
The name is permanent and names the agent's Slack tools
(`int__sre-agent-slack__post_message`).
3. Create the Slack app and connect it:
```sh
set -a && . ./.env && set +a
npx omnara integrations slack <integration-id> --app-name "SRE Agent" \
--app-configuration-token "$SLACK_APP_CONFIG_TOKEN"
```
Ask before choosing a different app name; it's how the team mentions the
bot. It opens a Slack authorization page that the user approves before it
expires.
4. Tell the user to invite the bot to a channel (`/invite @SRE Agent`) and
mention it: "@SRE Agent why are checkout requests failing?"
**Discord.** Works like Slack: the bot answers in a new thread wherever
it's mentioned in a server channel, and replies in the thread go to the
same agent. It doesn't answer direct messages.
If an integration named `sre-agent-discord` already exists, reuse it the same
way: add this profile if it's missing. If it's `active`, skip to step 5; Omnara
can't tell whether steps 5 and 6 were done in Discord, so check them with the
user. If it's `disconnected`, skip step 3 and do the steps that weren't done,
passing the current `setup_revision` from
`npx omnara integrations get <integration-id> --json` in step 4.
1. The user creates an application named "SRE Agent" in the
[Discord Developer Portal](https://discord.com/developers/applications);
ask before choosing a different name, since it's how the team mentions
the bot. They copy the **Application ID** and **Public Key** from
**General Information**. Under **Bot**, they select **Reset Token** to copy
the bot token, turn on **Message Content Intent**, and turn off **Public
Bot** so only they can add it (if Discord refuses, first set
**Installation** → **Install Link** to **None**). Have the user add the
values to `.env`:
```sh
DISCORD_APPLICATION_ID=...
DISCORD_PUBLIC_KEY=...
DISCORD_BOT_TOKEN=...
```
2. Store the bot token and note the `sec_…` ID. If a secret named
`sre-agent-discord-bot-token` already exists
(`npx omnara secrets list --owner-kind project --owner-project-id <project-id> --name sre-agent-discord-bot-token --json`),
reuse its ID; if the user has reset the token since, have them paste the new
one into it on the dashboard's **Secrets** page (the ID stays the same).
Otherwise:
```sh
set -a && . ./.env && set +a
npx omnara secrets create --owner-kind project --owner-project-id <project-id> \
--name sre-agent-discord-bot-token --material-kind generic \
--material-value "$DISCORD_BOT_TOKEN" --json
```
3. Create the integration with this profile in its launcher, and note the
`itg_…` ID and `setup_revision` it returns:
```sh
npx omnara integrations create --name sre-agent-discord \
--integration-kind discord_thread \
--settings '{"launcher":{"profiles":["<agent-profile-id>"]}}' --json
```
The name is permanent and names the agent's Discord tools
(`int__sre-agent-discord__post_message`).
4. Connect the bot. Omnara checks the token and finds the bot's user:
```sh
set -a && . ./.env && set +a
npx omnara integrations configure <integration-id> \
--expected-setup-revision <setup-revision> \
--provider-tenant-id "$DISCORD_APPLICATION_ID" \
--credential-secret-id <secret-id> \
--provider-config "{\"public_key\":\"$DISCORD_PUBLIC_KEY\"}" --json
```
5. Under **General Information**, the user sets **Interactions Endpoint URL**
to `https://app.omnara.com/api/integrations/discord/<application-id>/interactions`
and saves; the buttons on the bot's questions need it. Discord checks the
URL when it's saved, so this has to come after step 4.
6. The user adds the bot to their server by opening this link, which asks
only for the permissions the bot needs:
`https://discord.com/oauth2/authorize?client_id=<application-id>&scope=bot&permissions=309237746752&integration_type=0`.
Then they mention it in a channel: "@SRE Agent why are checkout requests
failing?"
**Omnara console.** Already done: every agent launched from the profile shows
up in the console.
## 9. Run a daily health check (optional)
A schedule works with any of the above. Ask whether the user wants a daily
health check, and for the time and timezone (default: weekdays at 9am in the
user's timezone). Set `--cron` and `--timezone` from their answer:
```sh
npx omnara crons create --name sre-agent-daily \
--target-type profile --target-agent-profile-id <agent-profile-id> \
--cron '0 9 * * 1-5' --timezone America/Los_Angeles \
--message-template 'Run the daily production health check.' --json
```
If `npx omnara crons list --name sre-agent-daily --json` already shows a
trigger, change it with `npx omnara crons update <cron-trigger-id>` (same
flags) instead of creating a second one.
Each firing launches a fresh agent from the profile. It shows up in the
console, and the user's app can pick it up through the SDK or API. To get
each check in a Slack or Discord channel, mention the bot in that channel
once, then
create the trigger with `--target-type agent --target-agent-id <agent-id>`
(the agent ID from that conversation's console URL), so every check posts to
that thread.
## 10. Wrap up
Summarize what you created: the secrets, the IAM user if you made it, the
profile, and the Slack or Discord integration or cron trigger if any. Remind
the user to delete `.env` or move the keys somewhere safe. Then tell them:
- **Add a data source or change anything else:** ask a coding agent with this
skill. It reuses the secrets and updates the profile in place.
- **Remove it:** delete the cron trigger (`npx omnara crons delete <id>`),
delete the Slack and Discord integrations, if any
(`npx omnara integrations delete <integration-id>`), or, if other agents
share it, rerun `npx omnara integrations profiles` with only their
profiles. Then run `npx omnara profiles delete <agent-profile-id>`, delete
each secret with `npx omnara secrets delete <secret-id>`, and delete the
`omnara-sre-agent` IAM user's access key (or the user) in AWS.
With Discord, also delete the application in the Discord Developer Portal.