chore(skills): add mr-review-triage skill

README.md

@@ -14,9 +14,10 @@ Shared MCP setup guides and reusable agent skills for internal team use.
 ## Available Skills
 
 - `skills/mr-resolve/README.md` - interactive helper for GitLab MR review threads
+- `skills/mr-review-triage/README.md` - conservative checker for whether MR review comments were actually addressed
 
 ## Recommended Flow
 
 1. Set up GitLab MCP first using `mcps/gitlab/README.md`
-2. Install the skill from `skills/mr-resolve/`
-3. Use the skill on merge requests with unresolved review feedback
+2. Install `skills/mr-review-triage/` to verify which threads are safe to resolve
+3. Use `skills/mr-resolve/` when you want to implement changes for unresolved feedback

skills/mr-review-triage/README.md

@@ -0,0 +1,48 @@
+# mr-review-triage
+
+Conservative helper for checking whether GitLab MR review comments were actually addressed.
+
+## What It Does
+
+- reads MR discussion threads
+- focuses on unresolved reviewer feedback
+- compares the original concern with the current MR and local file state
+- classifies each thread as resolved, unresolved, partial, or needing reviewer decision
+- resolves only the threads the user explicitly confirms are safe
+
+## What It Does Not Do
+
+- does not edit code
+- does not commit
+- does not auto-resolve threads
+
+## Requires
+
+GitLab MCP must already be configured.
+
+See `../../mcps/gitlab/README.md`.
+
+## Install
+
+Install from the shared repo with `skills.sh`:
+
+```bash
+npx skills add https://github.com/jblxo/agent-tooling --skill mr-review-triage
+```
+
+## Example Prompts
+
+```text
+Check whether my comments on https://gitlab.eman.cz/group/project/-/merge_requests/42 were addressed
+```
+
+```text
+/mr-review-triage !42
+```
+
+## Intended Behavior
+
+- analyze first
+- classify conservatively
+- ask before resolving anything
+- leave debatable threads open

skills/mr-review-triage/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: mr-review-triage
+description: >
+  Analyze GitLab merge request review threads, compare them with the current MR
+  and local code state, classify which comments are already addressed versus still
+  open, and only resolve threads after explicit user confirmation. Do not edit
+  code. Requires a configured `gitlab` MCP server.
+---
+
+# MR Review Triage
+
+Check whether GitLab MR review comments were actually addressed before resolving them.
+
+## Input
+
+Accept one of:
+
+- full MR URL
+- short ref like `!42`
+- current branch MR if the user clearly refers to the active MR
+
+If the input is `!42`, derive the project from `git remote get-url origin`.
+
+## Workflow
+
+1. Fetch MR metadata with `get_merge_request`.
+2. Fetch discussions with `mr_discussions`.
+3. Ignore pure system notes and non-resolvable items.
+4. Focus on reviewer threads unless the user explicitly asks for all review feedback.
+5. Prioritize unresolved reviewer threads.
+6. Fetch changed files or diffs for code context.
+7. Read the current local files referenced by those threads.
+8. Compare the original concern with the current implementation.
+
+Present a short summary:
+
+```text
+MR !42: title
+source-branch -> target-branch
+N unresolved reviewer threads across M files
+```
+
+Then triage each thread.
+
+## Classification
+
+Use exactly one of these labels per thread:
+
+- `Resolved in code`
+- `Not resolved`
+- `Partially resolved`
+- `Needs decision`
+
+For each thread:
+
+1. Quote the reviewer concern briefly.
+2. Show the referenced file and line or file-level location.
+3. Explain whether the current code addresses the concern.
+4. Give one short classification reason.
+
+Use `Needs decision` when the code changed, but the reviewer still needs to confirm the direction or tradeoff.
+
+## Resolution Rules
+
+Default behavior is analysis only.
+
+If the user asks to resolve threads:
+
+- resolve only threads clearly classified as `Resolved in code`, unless the user explicitly says otherwise
+- do not resolve `Needs decision` automatically
+- do not post replies unless the user asks for reply text or posting
+- do not edit code
+
+Before resolving anything, present the exact threads you think are safe to resolve and wait for confirmation.
+
+## Output
+
+Return the result in this structure.
+
+### MR
+- title
+- source and target branch
+- review status summary
+
+### Safe To Resolve
+- threads that appear resolved in code
+- one short reason per thread
+
+### Keep Open
+- threads that are not resolved, partially resolved, or need decision
+- one short reason per thread
+
+### Suggested Replies
+- optional short English reply text only where helpful
+- if none, say so explicitly
+
+### Next Step
+- `Resolve selected threads`
+- `Reply first, then resolve`
+- `Keep open and request more changes`
+
+## Constraints
+
+- Do not edit code.
+- Do not create commits, branches, or PRs/MRs.
+- Do not resolve any thread without explicit user confirmation.
+- Do not over-read the repo; inspect only the files needed for verification.
+- Ask at most one clarification question if the MR or reviewer scope is ambiguous.