reviewfollow-uplisted

# Review Follow-Up Follow up on my review of: $ARGUMENTS You are the reviewer. The question is not "did the author reply?" but "did the fix actually grasp each concern, or go through the motions?" Status is a signal. The code is the verdict. Report any mismatch between the two (resolved but not fixed, unresolved but fixed) as a finding. All diff and file reading happens in Explore sub-agents. Your main session holds only the structured verdicts they return, never raw diffs, keeping my development context free. ## Context - Remote URL: !`git remote get-url origin 2>/dev/null || echo "unavailable"` - Branch: !`git branch --show-current 2>/dev/null || echo "unavailable"` ## Workflow ### Resolve Target If `$ARGUMENTS` carries a URL or identifier, use it. If it's empty, detect the current branch's open PR/MR. Pick the platform from `git remote get-url origin`, then: - GitHub: `gh pr view --json url,state --jq '.url'` - GitLab: `glab mr view --output json | jq -r '.web_url'` Both resolve the current branch with no positional argument. Ask me for a URL only if detection comes up empty. A closed or merged PR still resolves, so surface the `state` for me to confirm before proceeding. For GitLab, load the `gitlab:api` and `gitlab:merge-request` skills for API patterns and MR tooling. ### Sync to the Latest Pushed State Your assessment must reflect what the author actually pushed. The worktree-behind-origin trap: judging a local worktree that is N commits behind origin make