A reviewer on your team leaves a comment on one of the assistant's merge requests: the probe it proposed points at the wrong port. That comment is collected within minutes, answered in the thread, and becomes evidence for a change to the instructions that produced the MR, proposed as a merge request of its own. The next run is then checked against what you said.
orders-api has no readiness probe, so the assistant
proposes one on the container port, 8080. Reasonable
from the manifest alone. Wrong for this service: the health
endpoint is served by a sidecar on 8081.
The reviewer writes what they would write to a colleague. No template, no form. Closing an MR without merging is a signal too, and closing it with a reason is the strongest one.
A thumbs-down reaction on its own is not read; write a sentence.
A collection job reads new comments on the assistant's MRs and issues, Slack corrections and closed proposals, and stores each with the proposal it belongs to. No model call happens here.
It polls every 5 minutes while people are actively commenting and backs off to every 2 hours when things are quiet. The assistant's own comments are excluded, so it 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 in the thread straight away and confirms again when the work
is done.
Only people on an allowlist can trigger them.
Unanswered feedback is sorted into skip directives, acknowledgements ("thanks", "LGTM") and substantive comments. Substantive ones get a written answer in the thread: the root cause and what changes. Today that answer is written with a maintainer in the loop and posted by the assistant, which can also retitle the MR and marks the feedback as answered.
Once enough feedback has accumulated for one agent, a weekly analysis reads it against that agent's current prompt and proposes a specific wording change, as a low-risk draft MR against your installation's prompt configuration. Closed-with-a-reason items weigh most, and the operator's own words are quoted in the rationale.
This pass is built and held dormant while its threshold is calibrated; today the same changes are made by hand from the answered-feedback queue.
After the next full run, the team operating the assistant matches each comment to the new proposal for the same workload and judges it: fixed, recurs, partial or not re-emitted. A fix that quietly introduced a new mistake is flagged too.
Prompts are reloaded before every model call, so once a merged prompt change is deployed it applies to the next proposal, with no restart.
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 and held dormant while its threshold is calibrated. The title, labels and section headings are the ones 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 probe targeted the main container's port while the health route is served by a sidecar. One reviewer closed an MR with the 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. The change makes the probe follow the container that serves the health route, and requires the description to say which one was chosen.
| 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 previous wording is restored on the next call.
Matches what we keep correcting by hand. Merging.
A system that rewrites its own instructions needs firm edges. These are the ones it has.
/reprompt and /skip only act for listed users, and each trigger is acted on once./reprompt and /skip with immediate acknowledgement