Expose canonical PR review and merge prompt through project skills and MCP tooling #296

Closed
opened 2026-07-07 00:26:34 -05:00 by jcwalker3 · 0 comments
Owner

The PR review/merge prompt has grown into a long safety-critical workflow specification. Users should not have to paste the full prompt every time they ask an LLM to review the next PR.

Problem

Manual prompt pasting is error-prone. Different LLMs may receive stale versions, shortened versions, or miss recent rules such as:

  • branches-only worktrees
  • no raw MCP repair during review
  • no background task tools
  • complete PR inventory proof
  • already-landed PR gate
  • candidate vs reviewed head SHA
  • no approve/merge replay commands in blocked handoffs
  • precise mutation classification
  • final-report proof requirements

Required behavior

  1. Store the canonical PR review/merge workflow in the repository as a durable project skill or runbook.

  2. Expose it through an MCP-accessible helper so an LLM can retrieve the current canonical prompt before reviewing PRs.

  3. Add a short user-facing trigger prompt such as:

    Review the next eligible PR using the canonical project PR review workflow.

  4. The LLM must retrieve and follow the stored canonical workflow before starting PR work.

  5. The stored workflow must be versioned and reviewed like code.

  6. The final report must include the workflow version/hash used.

  7. The canonical workflow must include:

    • identity/profile/capability gates
    • author safety
    • branches-only worktree rule
    • infrastructure stop handling
    • complete PR inventory/pagination proof
    • already-landed PR gate
    • validation and diff review requirements
    • merge preflight
    • recovery handoff rules
    • final report schema
  8. Add tests or prompt validators that reject PR review reports that did not load or cite the canonical workflow.

Acceptance criteria

  • User can give a short request instead of pasting the full prompt.
  • LLM retrieves the canonical PR review/merge workflow from the repo/tooling.
  • Final report includes the workflow version/hash used.
  • Prompt changes happen in one durable place.
  • Tests prevent stale or missing workflow retrieval.
The PR review/merge prompt has grown into a long safety-critical workflow specification. Users should not have to paste the full prompt every time they ask an LLM to review the next PR. ## Problem Manual prompt pasting is error-prone. Different LLMs may receive stale versions, shortened versions, or miss recent rules such as: * branches-only worktrees * no raw MCP repair during review * no background task tools * complete PR inventory proof * already-landed PR gate * candidate vs reviewed head SHA * no approve/merge replay commands in blocked handoffs * precise mutation classification * final-report proof requirements ## Required behavior 1. Store the canonical PR review/merge workflow in the repository as a durable project skill or runbook. 2. Expose it through an MCP-accessible helper so an LLM can retrieve the current canonical prompt before reviewing PRs. 3. Add a short user-facing trigger prompt such as: `Review the next eligible PR using the canonical project PR review workflow.` 4. The LLM must retrieve and follow the stored canonical workflow before starting PR work. 5. The stored workflow must be versioned and reviewed like code. 6. The final report must include the workflow version/hash used. 7. The canonical workflow must include: * identity/profile/capability gates * author safety * branches-only worktree rule * infrastructure stop handling * complete PR inventory/pagination proof * already-landed PR gate * validation and diff review requirements * merge preflight * recovery handoff rules * final report schema 8. Add tests or prompt validators that reject PR review reports that did not load or cite the canonical workflow. ## Acceptance criteria * User can give a short request instead of pasting the full prompt. * LLM retrieves the canonical PR review/merge workflow from the repo/tooling. * Final report includes the workflow version/hash used. * Prompt changes happen in one durable place. * Tests prevent stale or missing workflow retrieval.
jcwalker3 added the status:in-progress label 2026-07-07 08:15:42 -05:00
sysadmin removed the status:in-progress label 2026-07-07 09:11:16 -05:00
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#296