teamcraft-jcg:address-feedback

What this skill does

## 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.