Build a useful GitHub issue review

1. Preserve repository identity and collection completeness

The input identifies demo/field-notes, the review window, retrieved and total counts, and missing page two. Every record retains its kind and source URL. These are synthetic records with deliberate .invalid links; their symptoms do not establish real bugs in a current Hermes release.

A live collector should retain its actual pagination state alongside the records. A polished summary cannot recover issues that were never retrieved. Here the accepted result explicitly says complete is false and retains the missing page, so the review cannot be mistaken for an exhaustive repository audit.

2. Ask for symptoms and evidence, not confident diagnoses

The accepted prompt asks Hermes to infer candidate groups from the bodies and platform/version context. It does not tell the model which issue numbers belong together. Each group must include its issue IDs, source URLs, missing evidence and a concrete next diagnostic action. A possible_duplicate relationship remains tentative.

An earlier contract-driven trial supplied the intended grouping; the retained accepted result comes from a fresh trial with that hint removed. This tests the narrow grouping decision on these records. It does not establish reliable deduplication for arbitrary repositories, languages or incident types.

3. Inspect the groups against the original reports

The output places 101 and 102 together as possible_duplicate because both describe Linux startup after a reboot and overlap around process detection. It asks for logs, timelines, process/PID information and service setup before treating the two reports as one cause. Windows issue 103 remains separate.

Issue 104 also remains separate. Its report is too vague to support a diagnosis, so the next action requests the operating system, version, reproduction steps, timestamps and affected component. This is more useful than inventing a fix from a generic title. Read the accepted output below to inspect those actual questions.

4. Keep pull requests and issue outcomes distinct

Record 105 is excluded from the issue groups because it is a pull request. The output does not treat the proposed change as merged or released. All four retrieved user issues appear once, and every group preserves the same source URLs as its input records.

GitHub documents that issue endpoints can include pull requests. The fixture uses an explicit kind field to make that distinction visible; a real adapter must inspect the corresponding upstream fields. Repository access, issue retrieval and remote state were not tested by this local synthesis trial.

How to reproduce and extend the exercise

Download sources.json, the accepted result, prompt and receipt. Run the prompt in a separate folder with the bounded file-only invocation in REPRODUCE.md. Compare the candidate group membership, missing-evidence questions and completeness flag against the fixture. Source hashes should remain unchanged.

For a live review, first obtain an authorized read-only connection, bound the repository and time window, and retain collection failures. Suggested comments or label changes should remain proposals until that separate operation is authorized. This example performed no repository writes.

Inspect and reproduce

The source fixtures, original model outputs, prompts and execution receipts are below. Use a separate folder and your existing Hermes setup. Replace <trial-folder> in prompts with that folder. A local test run is not evidence of unattended production reliability.

{
  "repository": "demo/field-notes",
  "complete": false,
  "missingPages": [2],
  "repositoryActionsTaken": [],
  "excludedPullRequestIds": [105],
  "groups": [
    {
      "issueIds": [101, 102],
      "relationship": "possible_duplicate",
      "sourceUrls": [
        "https://example.invalid/demo/field-notes/issues/101",
        "https://example.invalid/demo/field-notes/issues/102"
      ],
      "missingEvidence": [
        "Gateway and service startup logs from the same reboot",
        "Exact reboot and restart timeline",
        "Process/PID details showing whether a stale PID file or process check caused the false already-running state",
        "Service configuration and startup mechanism"
      ],
      "nextAction": "Ask whether both reports reproduce on the same Linux distribution and service setup; collect logs, the exact reboot-to-failure steps, PID/process listings, and service configuration to test whether the gateway failure and stale-process detection share a cause."
    },
    {
      "issueIds": [103],
      "relationship": "standalone",
      "sourceUrls": [
        "https://example.invalid/demo/field-notes/issues/103"
      ],
      "missingEvidence": [
        "Reproduction steps",
        "Application and connection logs",
        "Windows version and architecture",
        "Whether the issue occurs after install, launch, sleep/resume, or a service restart",
        "Connection target and network context"
      ],
      "nextAction": "Ask for exact Windows version, reproduction steps, logs, connection target, and whether restarting the app or network changes the Connecting state."
    },
    {
      "issueIds": [104],
      "relationship": "standalone",
      "sourceUrls": [
        "https://example.invalid/demo/field-notes/issues/104"
      ],
      "missingEvidence": [
        "Operating system",
        "Application and agent version",
        "Reproduction steps and frequency",
        "Logs and timestamps",
        "What stops and whether it can be restarted"
      ],
      "nextAction": "Ask for OS, version, exact component that stops, reproduction steps and frequency, timestamps, logs, and whether manual restart restores operation."
    }
  ]
}