--- name: gitlab-review-fix-threads description: Address existing unresolved GitLab merge request threads with the local gitlab-review CLI. Read unresolved threads, inspect code, implement fixes in the current checkout one by one, reply with what changed, and never resolve the threads yourself. license: MIT compatibility: codex --- # GitLab Review Thread Fixes Use this skill when the task is to work through existing unresolved GitLab merge request threads in the current checkout, make the requested code changes locally, and post follow-up replies back to GitLab without resolving the threads. ## Preconditions - Assume `gitlab-review` is already installed and available on `PATH`. Invoke it directly like any other CLI. - Work from the merge request source branch checkout, or from a checkout that contains the source branch code you are expected to modify. - If you run from this checkout root, the CLI auto-loads a repo-local `.env` via `dotenvy`. If you run outside the checkout, export: - `GITLAB_API_URL` - `GITLAB_PERSONAL_ACCESS_TOKEN` - optional `GITLAB_REVIEW_NOTE_PREFIX` - If `GITLAB_API_URL` or `GITLAB_PERSONAL_ACCESS_TOKEN` is missing, stop and tell the user exactly which variable is missing. Ask them to provide it or remind them that they may have forgotten the repo `.env`. - Do not invent placeholder values or continue with partial configuration. - Prefer `gitlab-review --format human ...` for this workflow. - The tool applies the configured robot prefix automatically. Do not include it manually in `--body`. - This is a fix workflow, not a fresh review workflow. Do not go hunting for new unrelated findings unless the user explicitly asks for another review pass. ## Safety Defaults - Start by reading unresolved threads before editing code. - Work one thread at a time so code changes and replies stay attributable. - Inspect the surrounding diff and file context before making a change. - Use existing build and test commands from the repository. Do not invent new validation tools. - Reply on every thread you addressed, but do **not** resolve any thread yourself. The reviewer should decide when to resolve. - If a thread appears already fixed, invalid, or not actionable, still leave a concise follow-up reply explaining that conclusion and leave the thread unresolved. - `thread reply` does not support `--dry-run`, so verify the selector and wording before posting the reply. ## Command Map - Every command below that accepts `--repo` / `--branch` also accepts `--url ` instead. - Resolve `--repo` / `--branch` from a pasted MR URL: `gitlab-review --format human locator ` - Resolve the MR: `gitlab-review --format human summary --repo --branch ` - Get the high-level review view: `gitlab-review --format human context --repo --branch ` - List unresolved notes and thread roots: `gitlab-review --format human note list --repo --branch --page 1 --per-page 100 --group-by path --unresolved-only` - Show a full thread by selector: `gitlab-review --format human thread show --repo --branch --id ` - Show selected diffs: `gitlab-review --format human diff show --repo --branch --selector ` - Read source, target, or both versions of a file: `gitlab-review --format human file show --repo --branch --ref both --path --line-numbers` - Search repository paths or content without checking out the branch: `gitlab-review --format human tree search --repo --branch --scope --query ` - Materialize the MR into `/tmp`: `gitlab-review --format human materialize --repo --branch ` - Reply to a thread after implementing a change: `gitlab-review --format human thread reply --repo --branch --id --body ""` ## Thread-Fix Workflow 1. Resolve the merge request and confirm you are working against the right checkout. If all you have is a pasted merge request URL, derive the CLI flags first: ```bash gitlab-review --format human locator https://gitlab.example.com/group/project/-/merge_requests/42 ``` Then confirm the MR: ```bash gitlab-review --format human summary --repo --branch gitlab-review --format human context --repo --branch ``` 2. Inventory unresolved threads before touching code. ```bash gitlab-review --format human note list \ --repo \ --branch \ --page 1 \ --per-page 100 \ --group-by path \ --unresolved-only ``` If the visible result count spans multiple pages, page through all results before deciding the queue is complete. 3. Work through unresolved threads one by one. For each thread: - inspect the full discussion with `thread show` - inspect the surrounding diff, source, target, and related code with `diff show`, `file show`, `tree search`, or `materialize` - decide what code change is needed in the current checkout - implement the fix locally - run the relevant existing tests or build checks - reply on the thread with what changed and how you validated it 4. Keep the response tied to the thread you fixed. Use `thread show` first: ```bash gitlab-review --format human thread show \ --repo \ --branch \ --id ``` Then, after the code change and validation, reply: ```bash gitlab-review --format human thread reply \ --repo \ --branch \ --id \ --body "" ``` 5. Do not resolve the thread. - Never run `thread resolve` in this workflow. - The reviewer should inspect the new code and decide whether to resolve the discussion. - If multiple threads point to the same underlying issue, reply in each thread so the reviewer can see the status where they left the feedback. 6. If you cannot or should not make a change, still leave a follow-up reply. Examples: - the concern is already fixed in the current code - the thread is based on a misunderstanding of the implementation - the requested change conflicts with an explicit requirement - additional user guidance is needed before changing behavior In all of those cases, leave the thread unresolved and explain the conclusion clearly. ## Working Standard - One thread at a time. - Fix the code first, then reply. - Keep replies factual and specific to the thread. - Prefer mentioning concrete validation such as the test command you ran. - Do not expand into a broad new MR review unless the user asks.