codingthefuturewithai/teamcraft-glgd:address-feedback

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.