codingthefuturewithai/teamcraft-jcg:address-feedback

Goal

Check whether a reviewer has left open feedback on your PR. 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, push — and then instruct the developer to resolve addressed threads in the GitHub UI. Leave the PR ready for the reviewer's next pass.

Hard Constraints

• 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.
• Thread resolution is not available via gh CLI. GitHub has no CLI equivalent for resolving review threads. At the end of this skill, instruct the developer to resolve addressed threads in the GitHub UI. This is a known capability gap, not an error.
• All GitHub interactions go through the gh CLI only. All PR operations run via Bash.

Find the PR

The Jira issue key comes from $ARGUMENTS. If not provided, ask. Identify the GitHub repo from .teamcraft/project.md or git remote -v via Bash. Find the PR linked to this issue — look for an open PR on a branch matching the issue key: gh pr list --head [branch-name] via Bash, where the branch name contains the issue key.

Check for Open Feedback

Fetch all PR comments and review threads via gh pr view [PR-number] --comments via Bash. Separate:

• Open reviewer comments and review threads — 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 PR #N 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 gh pr comment [PR-number] --body "..." via Bash
• If replying to a specific comment thread, use gh pr comment [PR-number] --reply-to [comment-id] --body "..." via Bash if the flag is supported in the installed gh version; otherwise post a plain comment that clearly references the thread

If the developer decides not to address an item:

• Draft a reply explaining why (deferring, won't fix, disagree) and show it before posting
• Post it — leave the thread open for the reviewer to see the response

Commit and Push

If any code changes were made:

• Commit with a message referencing the Jira issue key and briefly describing what was addressed — e.g., fix: address review feedback — [what changed] (PROJ-42)
• Confirm with the developer before pushing
• Push the branch

Resolve Addressed Threads

Thread resolution is not available via the gh CLI. After pushing, instruct the developer:

"To mark addressed threads as resolved, open the PR in the GitHub UI and resolve each thread. Based on our work, the following threads are ready to resolve: [list threads]. Leave any 'won't fix' or 'deferring' threads open for the reviewer."

This step is the developer's to complete in the browser.

Done

Summarize:

• How many threads were worked through
• How many remain open (and why — waiting on reviewer response, deferred, etc.)
• Whether the branch was pushed
• Which threads the developer should resolve in the GitHub UI

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