HACP

Workflow example

PR Review Control Loop for AI-assisted engineering teams

Fewer bad merges, less duplicate bot noise, less context juggling, and clearer human merge decisions. The workflow returns one owner-grade posture and keeps a cleaner approval trail.

Workflow in 8 steps

  1. PR comes in with a claim.
  2. HACP builds a context packet.
  3. Reviewers/bots return findings.
  4. Findings are classified into identifier labels: placeholder pending actionable duplicate resolved outdated informational failed_check passed_check waiver_required
  5. Agent or human fixes only actionable items.
  6. Validation reruns.
  7. Human sees merge decision posture identifiers: not_ready blocked waiver_required ready_for_owner_decision
  8. Human makes merge/no-merge/waiver decision.

PR review context packet fields

  • PR URL / repo / branch / base
  • PR claim
  • changed files
  • protected invariants
  • relevant specs/docs/issues
  • required checks
  • reviewer/bot roster
  • known out-of-scope paths
  • active findings
  • stale assumptions
  • stop conditions
  • validation commands
  • final owner decision requirement

3-minute demo

Show one PR loop from claim to posture in one pass: classification isolates noisy signals, remediation stays scoped to actionable items, and rerun evidence updates owner posture.

Presenter talk track:

  • Bot confidence is input, not authority.
  • Checks passing is input, not authority.
  • A reviewer saying "ready" does not equal merge-ready.
  • A report or review presence is not completion proof.
  • Human owner decision remains required.

Decision gate output

The loop computes one posture for owner review: not_ready, blocked, waiver_required, or ready_for_owner_decision.

This is decision support, not autonomous merge action. Required checks and reviewer signals remain evidence inputs, not authority grants.

Required boundaries

  • HACP does not auto-merge PRs.
  • HACP does not mutate GitHub by itself.
  • HACP does not execute code by itself.
  • A reviewer saying "ready" does not equal merge-ready.
  • A report or review presence is not completion proof.
  • Human owner decision remains required.

Other workflows that use the same loop

  • Launch-Change Approval for public/payment-impacting mutations can use the same source-context, evidence, and human-decision pattern.
  • Human Readiness Gates for human-only workflow failures can preserve stop reasons, send-back notes, and final owner decisions.

HACP remains the protocol/control layer underneath this workflow. PR review is one concrete example of human-approved coordination, not autonomous execution.