Mr Metadata Repair

---
name: mr-metadata-repair
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.