A reviewer on your team comments on one of the assistant's merge requests (MRs). The comment says that the proposed probe points at the wrong port. The assistant collects that comment on its next poll and answers it in the thread. The comment also becomes evidence for a change to the instructions (the prompt) that produced the MR. The assistant proposes that change as an MR of its own. Then the team checks the next run against what you said.
orders-api has no readiness probe (a check that tells
Kubernetes when a pod can receive traffic). So the assistant
proposes one on the container port, 8080. That is
reasonable from the manifest alone. It is wrong for this service. A
sidecar (a second container in the same pod) serves the health
endpoint on 8081.
The reviewer writes what they would write to a colleague. There is no template and no form. Closing an MR without merging is also a signal. Closing it with a reason is the strongest signal.
The assistant does not read a thumbs-down reaction that comes without words, so write a sentence.
A collection job reads new comments on the assistant's MRs and issues, Slack corrections and closed proposals. It stores each one with the proposal it belongs to. This step makes no AI model (LLM) call.
The job polls every 5 minutes while people actively comment. When things get quiet, it slows down in steps to every 2 hours. So the first comment after a quiet period can wait up to 2 hours. The job excludes the assistant's own comments, so the assistant never learns from itself.
/reprompt regenerates the MR's diff on the next cycle,
usually within 15 minutes. /skip turns "not for this
resource" into a one-line annotation MR. The assistant acknowledges
each command in the thread straight away. It confirms again when
the work is done.
Only people on an allowlist can trigger these commands.
The assistant sorts unanswered feedback into skip directives, acknowledgements ("thanks", "LGTM") and substantive comments. Substantive comments get a written answer in the thread. The answer gives the root cause and says what changes. As of October 2026, a maintainer helps to write the answer, and the assistant posts it. The assistant can also retitle the MR, and it marks the feedback as answered.
When enough feedback accumulates for one agent, a weekly analysis reads it against the agent's current prompt. The analysis proposes a specific wording change. The proposal is a low-risk draft MR against your installation's prompt configuration. Items that people closed with a reason weigh most. The rationale quotes the operator's own words.
This pass is built, but it stays dormant while we calibrate its threshold. Until then, people make the same changes by hand from the answered-feedback queue.
After the next full run, the team that operates the assistant matches each comment to the new proposal for the same workload. Then it gives a verdict: fixed, recurs, partial or not re-emitted. The team also flags a fix that quietly introduced a new mistake.
The assistant reloads prompts before every model call. So a merged prompt change applies to the next proposal as soon as you deploy it. No restart is needed.
ports: - containerPort: 8080 + readinessProbe: + httpGet: { path: /healthz, port: 8080 } + periodSeconds: 10
/healthz is served by the auth sidecar on 8081; 8080 has no health route and would mark every pod unready. Same for every service using the sidecar pattern./reprompt8081, read from the sidecar's containerPort in the same pod spec.containerPort of the main container; sidecars were not considered. Next: prefer a container that already declares a health route on /healthz in the same pod. The diff here has been regenerated.config/prompts.yaml · analyse_manifest When proposing a readiness or liveness probe: - - Use the container's declared port. + - Use the port of the container that serves the health + route. If a sidecar in the same pod declares /healthz or + /ready, probe the sidecar's port, and say so in the + description.
Illustrative, and In development. The weekly pass that writes this MR is built, but it stays dormant while we calibrate its threshold. The title, labels and section headings are the ones that it writes.
gitops-ai/prompt-improvement-repo-scan-analyse-manifest into main · 1 file · +4 −1Source feedback group: repo_scan · Target file: config/prompts.yaml · Prompt key: analyse_manifest
Three of four comments on probe proposals in the last 30 days say the same thing. The probe targeted the main container's port, but a sidecar serves the health route. One reviewer closed an MR with this reason:
Wrong port. orders-api's /healthz is served by the auth sidecar on 8081; 8080 has no health route and would mark every pod unready.
The current instruction ("use the container's declared port") produces exactly this result. The change makes the probe follow the container that serves the health route. It also requires the description to say which container the assistant chose.
| Source | Proposal | Feedback |
|---|---|---|
| closed_proposal ⚠️ high priority | Add readiness probe to orders-api | Wrong port; health route is on the sidecar (8081). |
| gitlab_note | Add liveness probe to payments-api | Same sidecar pattern, same wrong port. |
| slack | n/a | "the probe proposals keep ignoring that our sidecar serves /healthz on 8081" |
| gitlab_note | Add readiness probe to inventory-api | Port fine; path should be /ready. |
Generated by FeedbackTuningAgent from 4 feedback item(s).
analyse_manifest: |
…
When proposing a readiness or liveness probe:
- - Use the container's declared port.
+ - Use the port of the container that serves the health
+ route. If a sidecar in the same pod declares /healthz or
+ /ready, probe the sidecar's port, and say so in the
+ description.
…
Revert this MR. The assistant restores the previous wording on the next call.
Matches what we keep correcting by hand. Merging.
A system that rewrites its own instructions needs firm limits. These are the limits it has.
/reprompt and /skip act only for listed users. The assistant acts on each trigger once./reprompt and /skip with immediate acknowledgement