An engineer mentions the assistant in Slack about a workload that is misbehaving. It finds the manifests that describe it, works out a concrete change and answers in the same thread. When a proposal is not wanted, one line in Slack turns "no thanks" into a reviewed annotation in git, so the same suggestion does not come back next week.
No command syntax to learn. The engineer describes the problem the way they would to a colleague: the workload, the namespace, what they want looked at.
The assistant acknowledges within seconds, in the thread, so everyone in the channel can see it picked the request up.
The request is parsed with plain patterns, no extra model call:
quoted names, phrases like deployment orders-api,
namespace hints such as in namespace shop, and cluster
or repository hints. Filler words ("keeps", "please", "can you")
are dropped.
Manifests are matched on namespace first, then on name, kind and repository. The best matches become the context for the analysis.
A repository in context mode contributes what it knows but never receives an MR. Only repositories in full mode can get a proposal.
When tool servers are configured, the analysis can walk live cluster state through a bounded tool loop: list the pods, read the last termination reason, check the reconcile status. Every tool is read-only and there is a hard ceiling on calls per request.
This path is built and opt-in; the default answers from the manifests in git.
Suggestions below the confidence floor are dropped. A proposal that already exists for the same repository is not opened twice. The diff goes through the same safety guard as scheduled scans: large removals are escalated to high risk and held for review.
The reply lists each proposal with its category and risk. By default the draft MR is opened by the next scheduled submit rather than straight from Slack, so the reply says "draft MR pending review". Teams that want it immediately can switch on auto-submit.
If nothing matched, it says what it searched and suggests how to be more specific. It does not invent a change.
When the draft MR is opened, a card lands in the proposals channel: 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.
A different thread: the assistant proposed monitoring for a batch
job 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 and
stores it as its own proposal. Once merged, that class of proposal
stops for that resource, across every future run.
skip-all opts the resource out of everything. The same
commands work as /skip comments on the MR itself.
A message starting with feedback or wrong
is recorded for the tuning pass and acknowledged.
review <MR> asks the reviewer to look at any MR,
including ones a human 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.Illustrative: names and numbers are invented. A Slack-originated proposal is a normal draft MR, with the same labels and gates as one from a scheduled scan, and 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?"
Raises orders-api's memory limit from 512Mi to 768Mi and its request from 384Mi to 512Mi, so the scheduler reserves what the pod actually uses at peak.
Low. Resource-only change to one Deployment; no selector, port or image change. Three replicas roll 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 modified).
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?
Not wanted? Comment /skip on this MR, or skip <MR> in Slack, and the assistant prepares a skip annotation for this Deployment instead.
Diff touches only the resources block of one Deployment. The new request fits under the seven-day peak with headroom, and the limit is not below the request. LGTM.
A chat interface makes it easy to ask for things. These are the rules that keep that from becoming a way around review.
skip / skip-all from Slack, and /skip on MRsfeedback / wrong corrections recorded for tuningreview <MR> from Slack, via the on-demand reviewer