Issue acceptance check

Last updated

When a pull request closes an issue, Argus verifies that the diff actually addresses what the issue asks for. No manual setup — if you use GitHub's native issue-linking, Argus picks it up.

How to trigger

You have three options, any of which work:

  1. PR body text — write Closes #123, Fixes #123, or Resolves #123. Cross-repo: Closes owner/repo#123.
  2. GitHub UI— use the "Development" panel on the right side of the PR page to link an issue. No PR description change needed.
  3. Non-closing mention — Related to #123 or refs #123 also triggers the check (catches PRs that partially address issues).

Argus pulls the issue via GitHub's closingIssuesReferences GraphQL field, so any of the above works transparently.

How to structure issues

Argus extracts acceptance criteria from structured sections. Use one of these headings in your issue body:

  • ## Acceptance Criteria
  • ## Definition of Done
  • ## Expected Behavior
  • ## Steps to Reproduce

Under the heading, write specific criteria as a bulleted list or checklist. Be specific.Instead of "login works", write "POST /login returns 401 on invalid credentials" — Argus can verify specific behavior against the diff.

If no structured section is found, Argus treats the entire issue body as one free-form criterion.

Verdicts

Each criterion gets one of four labels:

  • addressed — the diff provably satisfies it (with a file:line citation)
  • partial — the diff addresses some aspects but not all
  • unaddressed — the diff doesn't touch it
  • ambiguous — the criterion is too vague or the diff's intent isn't clear

Cross-repo issues

If the issue lives in a different repo and Argus isn't installed there, the link shows up as "no access" in the summary. The primary review still completes normally.

Disable

Go to Settings → Featuresto toggle the check off. It's enabled by default because it's cheap (~1-2k extra tokens per linked issue) and catches real bugs.