teamcraft-glgd:address-feedback

What this skill does

## Goal

Check whether a reviewer has left open feedback on your MR. If there is none, say so clearly — the developer knows they can move on or keep waiting. If there is feedback, work through it together: understand what the reviewer is asking, make code changes where warranted, reply to threads, resolve what's addressed, and push — leaving the MR ready for the reviewer's next pass.

## Hard Constraints

- Never resolve a discussion thread without the developer confirming the concern is addressed.
- Never push without explicit developer confirmation.
- This skill addresses reviewer feedback only — automated code health and security findings were handled by complete-issue.
- Never make code changes the developer hasn't approved. Present the proposed change first.
- If `git push` fails due to auth, follow the guidance in `references/git-push-guidance.md` exactly — detect, stop, guide the developer, and wait.

## Find the MR

The issue IID comes from `$ARGUMENTS`. If not provided, ask. Identify the project from `.teamcraft/project.md` or git remote context. Find the MR linked to this issue — look for an open MR on a branch matching `*[IID]-*`.

## Check for Open Feedback

Fetch all discussion threads on the MR. Separate:
- **Open threads with reviewer comments** — the feedback to address
- **System notes** (commits added, pipeline status, draft toggled) — ignore these
- **Already resolved threads** — ignore these

If there are no open reviewer threads: tell the developer clearly — "No open feedback on MR !X yet. Nothing to address." Stop there. The developer can check again later or follow up with the reviewer directly.

If there is open feedback, continue.

## Present the Feedback

Summarize all open threads clearly before proposing any action. Group by type:

- **Change requests** — reviewer is asking for something to be different
- **Questions** — reviewer wants clarification or explanation
- **Suggestions** — reviewer is proposing an improvement but not requiring it
- **Nitpicks** — minor style or preference comments

For each thread, show: what the reviewer said, what file/line it's on (if applicable), and your read of what they're asking for.

Ask: "Which of these do you want to address now?"

## Work Through Each Item

For each item the developer wants to address:

**If a code change is needed:**
- Propose the change and get explicit approval before touching any file
- Make the change
- Confirm with the developer before moving on

**If a reply is warranted:**
- Draft the reply and show it to the developer before posting
- Post via `mcp__gitlab__create_merge_request_discussion_note`

**If the developer decides not to address an item:**
- Draft a reply explaining why (deferring, won't fix, disagree) and show it before posting
- Do not resolve the thread — leave it open for the reviewer to see the response

## Commit and Push

If any code changes were made:
- Commit with a message referencing the IID and briefly describing what was addressed — e.g., `fix: address review feedback — [what changed] (#[IID])`
- Confirm with the developer before pushing
- Push the branch

## Resolve Addressed Threads

For each thread where the developer confirmed the concern is fully addressed, resolve it via `mcp__gitlab__resolve_merge_request_thread`. Do not resolve threads where the developer left a "won't fix" or "deferring" reply — leave those open for the reviewer.

## Done

Summarize:
- How many threads were resolved
- How many remain open (and why — waiting on reviewer response, deferred, etc.)
- Whether the branch was pushed

The reviewer can now run their review again to see the updated code and responses.