feat(resolve-pr-feedback): add cross-invocation cluster analysis

[tmchow]

Summary

• Replace the dead verify-loop re-entry gate signal with a cross-invocation awareness signal that detects multi-round review patterns on the same PR
• Broaden the get-pr-comments script's jq filter to include resolved threads in a new cross_invocation envelope — zero additional GraphQL calls
• Add three-mode resolver assessment for cross-invocation clusters: band-aid (redo), correct-but-incomplete (investigate sibling code), sound-and-independent (context only)

What changed

get-pr-comments script — The jq filter now also selects resolved threads (isResolved == true), sorted by recency, limited to the last 10. Outputs a cross_invocation object with signal (boolean: resolved + unresolved both exist) and resolved_threads array. Existing output keys are unchanged.

SKILL.md — The cluster gate table replaces "Verify-loop re-entry" with "Cross-invocation" (cross_invocation.signal == true). When the signal fires, resolved threads are included in category assignment and spatial grouping alongside new threads. Cluster briefs gain a <prior-resolutions> element. A dispatch boundary rule ensures resolved threads participate in clustering but are never individually re-dispatched. The verify loop is simplified to rely on the cross-invocation signal for re-entry detection.

pr-comment-resolver agent — Cluster mode now parses <prior-resolutions> and uses a three-mode assessment when prior resolutions are present. The "correct but incomplete" mode is the highest-value case: prior fixes were right but reveal a broader pattern in untouched sibling code. A new example demonstrates this mode.

Motivation

The verify-loop re-entry gate was architecturally dead — it required new threads to appear between push and verify, but automated reviewers post minutes later while verify runs seconds after push. This left the volume gate (3+ items) as the only working trigger for cluster analysis, missing the exact scenario clustering was designed for: recurring feedback about the same problem class across multiple rounds with 1-2 threads each.

Test plan

• bun test — 534 tests pass
• bun run release:validate — metadata in sync
• Manual: run the skill on a PR with resolved threads to verify the cross_invocation envelope appears in script output
• Manual: run on a PR with both resolved and unresolved threads to verify cluster analysis fires

Post-Deploy Monitoring & Validation

No additional operational monitoring required — this changes skill orchestration content (markdown instructions and a jq filter), not runtime infrastructure.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1083b2f614

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[tmchow]

Include resolved-thread text needed for categorization (thread)

Addressed in 9c2f5bf: added first_comment_body (the original reviewer feedback) to the resolved thread projection. That's the text the skill needs to assign concern categories during clustering. Full thread history isn't needed — just the initial feedback that describes the concern.