An engineer mentions the assistant in Slack about a workload that is misbehaving. The assistant finds the manifests that describe the workload. It works out a concrete change and answers in the same thread. If you do not want a proposal, one line in Slack turns "no thanks" into a reviewed annotation in git. Then the same proposal does not come back next week.
You do not need to learn command syntax. The engineer describes the problem as they would to a colleague. They name the workload, the namespace and what they want the assistant to look at.
The assistant acknowledges within seconds, in the thread. Everyone in the channel can see that it picked up the request.
The assistant reads the request with plain patterns. It makes no extra AI model (LLM) call.
It looks for quoted names, phrases like deployment orders-api,
namespace hints such as in namespace shop, and cluster
or repository hints. It drops filler words ("keeps", "please", "can you").
The assistant matches manifests on namespace first. Then it matches on name, kind and repository. The best matches become the context for the analysis.
A repository in context mode shares what it knows, but never receives an MR. Only repositories in full mode can get a proposal.
If you configure tool servers, the analysis can check live cluster state through a bounded tool loop. It can list the pods, read the last termination reason and check the reconcile status. Every tool is read-only. Each request has a hard ceiling on calls.
This path is built and opt-in. By default, the assistant answers from the manifests in git.
The assistant drops suggestions below the confidence floor. It does not open a proposal twice if one already exists for the same repository. The diff goes through the same safety guard as scheduled scans. The guard escalates large removals to high risk and holds them for review.
The reply lists each proposal with its category and risk. By default, the next scheduled submit opens the draft MR. Slack does not open it directly. So the reply says "draft MR pending review". Teams that want the MR immediately can switch on auto-submit.
If nothing matched, the reply says what the assistant searched. It suggests how to be more specific. The assistant does not invent a change.
When the assistant opens the draft MR, a card lands in the proposals channel. The card shows the repository, category, risk, which agent produced it, the first lines of the reasoning and a button to the MR. Alert-driven changes go to the alerts channel instead. High-risk proposals can mention a named group.
Here is a different thread. The assistant proposed monitoring for a batch
job that the team is retiring. An allowlisted operator replies
skip <MR> monitoring. The assistant builds a
one-line change that adds a skip annotation to that resource. It
stores the change as its own proposal. After you merge it, that class of proposal
stops for that resource, in every future run.
skip-all opts the resource out of everything. The same
commands work as /skip comments on the MR itself.
The assistant records a message that starts with feedback or wrong
for the tuning pass, and acknowledges it.
review <MR> asks the reviewer to look at any MR,
including MRs that a person wrote In development.
The draft MR from the first thread is below.
orders-api in namespace shop keeps OOMKilling since the promo started, can you look at its memory limits?→ list_workloads(namespace="shop") orders-api 3/3 ready restarts 14 (6h) → describe_object(pod orders-api-7c9f…) lastState.terminated.reason: OOMKilled limits.memory: 512Mi → prometheus_query(max_over_time(working_set[7d])) peak 509Mi · p95 431Mi → flux_reconcile_health(apps-shop) Ready · last applied 2d ago
title: Raise orders-api memory limit 512Mi → 768Mi category: resources risk: low source: slack_command diffs: 1 file, +2 −2
platform-prod) — draft MR pending reviewplatform-prodplatform-prod!57 — an annotation-add change adding monitoring to Deployment/legacy-batch is stored as proposal 3f2a…. The review gates then decide draft MR vs NEEDS_REVIEW.metadata: name: legacy-batch + annotations: + gitops-assistant/skip: monitoring
/healthz on 8081platform-prod!61: approve, quality 88/100, 1 concern.This example is illustrative. The names and numbers are invented. A proposal that starts in Slack is a normal draft MR. It has the same labels and gates as one from a scheduled scan. It carries the original request as evidence.
gitops-ai/raise-orders-api-memory-limit into main · 1 file · +2 −2Requested in Slack: "deployment orders-api in namespace shop keeps OOMKilling since the promo started, can you look at its memory limits?"
This MR raises the memory limit of orders-api from 512Mi to 768Mi. It raises the request from 384Mi to 512Mi. The scheduler then reserves what the pod actually uses at peak.
Low. The change touches resources only, in one Deployment. It changes no selector, port or image. Three replicas restart one at a time.
orders-api, three pods.OOMKilled terminations over the next 24 hours.| Signal | Value |
|---|---|
| Memory limit (git) | 512Mi |
| Peak working set, 7 days | 509Mi |
| p95 working set, 7 days | 431Mi |
| Restarts, last 6 hours | 14, all OOMKilled |
Matched manifests: apps/shop/orders-api/deployment.yaml (changed), hpa.yaml and the chart values in app-repo (context only, not changed).
resources:
requests:
cpu: 250m
- memory: 384Mi
+ memory: 512Mi
limits:
- memory: 512Mi
+ memory: 768Mi
On-demand Slack request: deployment orders-api in namespace shop keeps OOMKilling since the promo started, can you look at its memory limits?
If you do not want this change, comment /skip on this MR, or write skip <MR> in Slack. The assistant then prepares a skip annotation for this Deployment instead.
The diff touches only the resources block of one Deployment. The new request fits under the seven-day peak with headroom. The limit is not below the request. LGTM.
A chat interface makes it easy to ask for things. These rules stop it from becoming a way around review.
skip / skip-all from Slack, and /skip on MRsfeedback / wrong corrections recorded for tuningreview <MR> from Slack, through the on-demand reviewer