git:20261004.8097c6f to git:20261017.b7c17e1

17 added, 1 removed. Audit A to A.

---

name: mr-metadata-repair

- description: "Repairs a merge request's metadata, such as a missing or wrong label, so its checks can pass. Kraft runs it as the on_failure repair of the merge request's CI wait, on every failure; it acts only when the failed job's trace names a label."

+ description: "Repairs a merge request's metadata, such as a missing or wrong label or a missing description section, so its checks can pass. Kraft runs it as the on_failure repair of the merge request's CI wait, on every failure; it acts only when the failed job's trace names a label or a description section."

---

# Repairing a merge request's metadata

The merge request's CI wait just failed. Its diagnosis — the failed job's name

and the tail of its trace — is already in the prompt above.

**Whether another pass follows is the chain's decision, not this skill's.** Fix

what you can see and exit; the CI wait runs again after you and decides whether

it worked. Do not apply a second guess in the same pass to hedge the first.

## When the trace names a missing or wrong label

A job that refuses to run without a label of a given kind usually names the

kind and the choices in its own message (for example: `no type label;

expected one of feature, fix, docs`). If it does not, the project's

CONTRIBUTING or the job's own definition in its CI config says what they

are. Pick the label from the diff this item made, not from habit — a wrong

label mislabels what ships (a release label picks the version), which is

worse than stopping to ask. If the diff does not make the choice obvious,

leave it: reporting "I could not tell which of these labels this change

takes" is correct output; a guess is not.

Apply your choice with the `set_mr_labels` tool of the `kraft` MCP server

(`kraft item mr-label <label>...` from the shell works the same way) — not

`glab`/`gh` directly. It re-creates the pipeline too: `CI_MERGE_REQUEST_LABELS`

is fixed when a pipeline starts, so a label applied after the fact needs a new

pipeline to be seen at all, and this is what makes that happen.

+ ## When the trace names a missing or wrong description section

+ A job that reads the merge request's description (for example `missing

+ section: ## Removed tests`) is fixed in the item's `mr_meta` document, whose

+ path is in the documents list above. Edit that file, not the live description:

+ Kraft rebuilds the description from it on every sync, so an edit anywhere else

+ is reverted. Keep its front matter, change only the body, and take the

+ section's format from CONTRIBUTING, the PR template or the job's own checker

+ (run it on the new body if the repo ships one). Fill it from the diff, never

+ from guesswork; if you cannot tell what it should say, leave it. The `sync`

+ step after you writes the description to the forge and starts the failed

+ checks again (on GitLab as a new pipeline). A check that reads the description

+ when it runs sees the fix; one that reads it from its triggering event does

+ only if it re-runs on edits. If neither works the item stops for a person, as

+ before: do not push a commit or touch CI config to force a run.

## When the trace names something else

This task exists for MR-metadata problems, not code problems — a missing

label, not a failing test. If the pipeline is red for a reason no label can

fix, do nothing: the CI wait runs again after you, fails the same way, and once

the chain's repair attempts are spent the item stops for a human with the same

diagnosis you would only be repeating.

## When the pipeline reports a merge conflict

The CI wait already asks the forge itself whether this branch can merge and

puts the answer in its own log line (`merge request is not mergeable:

conflict`, or similar) — you do not need to re-derive that by hand. Do not

check out another branch or attempt a local `git merge` to look for

conflicts yourself: this worktree is the item's own, the next task after you

resolves the merge request from whatever branch is checked out, and a merge

left mid-conflict when your pass ends strands it there. If you need more than

the log line gives you, use a read-only command that does

not change what is checked out (`git merge-tree`, `git log`, `glab mr

diff`) — and in any case there is nothing this task can do about a real

conflict; say so and stop, the same as any other non-label failure.