PR and MR Answer Packs

Answer Packs attach scoped repository context to GitHub pull requests and GitLab merge requests. Snipara listens to the review event, builds a source-grounded pack for the changed surface, extracts explicit source-authored rationale into review-pending decision candidates, and publishes the result back to the provider-native review surface.

The flow

The pack is generated for the pull request or merge request, not for a generic repository search. That is the difference: the active AI client gets context aligned to the current branch, changed paths, indexed symbols, and relevant project history.

Where this fits

PR/MR Answer Packs are one surface in a larger Workflow Continuity mechanism. The same evidence should look different before editing, while resuming, and during review.

Start Work Brief shape

The Start Work Brief is the pre-edit artifact that feeds a better PR later. In the current implementation, snipara-companion team-sync start-work can fetch the hosted brief when the workspace is configured, and the same evidence model then flows into resume and review. That is not a claim that every repository already has a generated backend brief.

After implementation and review, the PR Answer Pack should reuse the same evidence: what changed, why the author chose it, which decisions still apply, which assumptions went stale, and what tests prove the touched surface. Missing rationale stays missing; the pack does not invent it from retrieved context or generated judgment.

Provider-native surfaces

The first useful surface is the repository provider itself. Snipara publishes the pack where reviewers and agents already look, while the dashboard keeps status and regeneration controls available for maintainers.

What a pack contains

Answer Pack contract

The current provider surfaces are the GitHub Check Run plus optional sticky PR comment, and a GitLab sticky merge request note. Treat this schema as the product contract for how an Answer Pack should be read by agents and humans. Internal payloads remain machine-versioned; that identifier is operational metadata, not a public product label.

{
  "repository": "owner/repo",
  "pull_request": {
    "number": 31,
    "head_sha": "eeaa70d",
    "base_branch": "main",
    "title": "Refactor authentication middleware"
  },
  "scope": {
    "changed_files": ["apps/web/src/lib/github/app.ts"],
    "impacted_symbols": ["getInstallationToken", "loadPrivateKey"],
    "context_documents": ["docs/development/CODING_STANDARDS.md"]
  },
    "sections": [
      "PR Scope",
      "Review Rationale",
      "Changed Files",
      "Impacted Symbols",
      "Repository Context",
      "Related Conventions And Architecture",
      "Implementation History",
      "Team Sync Review",
      "Reviewer Hints",
      "Verification Checklist",
      "Source Map",
      "Agent Handoff",
      "Caveats"
    ],
  "publication": {
    "github_check_name": "Snipara Answer Pack",
    "github_sticky_comment_marker": "<!-- snipara-pr-answer-pack -->",
    "gitlab_sticky_note_marker": "<!-- snipara-gitlab-mr-answer-pack -->"
  }
}

What agents should do with it

Claude Code, GitHub Copilot, Codex, Cursor, and other AI coding clients should treat the pack as the first context briefing for the review. It does not replace reading files or running tests. It reduces rescanning and gives the agent a better starting map.

• scoped repository cognition
• relevant architectural continuity
• high-quality contextual grounding
• source-aware implementation history

Setup

GitHub PR Answer Packs are generated by the hosted Snipara GitHub App. GitLab MR Answer Packs use the connected GitLab account and project webhook. Once connected, review events queue Answer Packs and push events keep the repository index fresh.

npx create-snipara --github