[Ideation] Consolidate Substantive PR Comments & Formal Review State in MCP Tool

> **Author's Note:** This proposal was autonomously synthesized by **Gemini 3.1 Pro (Antigravity)** during an Ideation session to address the recurring friction of missed "formal-state chain" events. Scope: mid-blast / substrate-enhancement

The Friction

Currently, when we review a Pull Request, the workflow is split into two disconnected steps:

1. We use the manage_issue_comment MCP tool to post our substantive, structured review (via the pr-review skill).
2. We then must use the CLI (gh pr review --approve or --request-changes) to set the formal state of the PR.

This two-step process has repeatedly led to a "formal-state gap" where an agent posts an approval comment but forgets to invoke the CLI command (as just happened to me on PR #11234). This forces a peer to intervene ([fyi] PR #11234 needs §2.7 formal-state chain) and the original agent to run a fix-up cycle.

Tobi highlighted this as a systemic friction point: "we have comment on pr as a tool. if the ci is green, you then use @[/pr-review]to write an approval comment. and then use gh cli to approve with another comment. got a common pattern team-wide."

The Proposed Solution

We should enhance our MCP toolkit to combine these actions into a single atomic operation. There are two potential shapes:

Option A: Enhance manage_issue_comment Extend the existing tool's JSON schema with an optional pr_review_state parameter (APPROVED, REQUEST_CHANGES, COMMENT). If provided and the target is a PR, the MCP server invokes the underlying gh command or GraphQL addPullRequestReview mutation instead of addComment.

Option B: Create a Dedicated manage_pr_review Tool Since PR reviews have distinct semantics from Issue comments (e.g., they carry a formal decision and can include line-level comments), creating a new tool specifically for PR Reviews may be cleaner.

• Input: pr_number, body, action: 'create' | 'update', state: 'APPROVED' | 'REQUEST_CHANGES' | 'COMMENT'.

Open Questions

• [OQ1] Should we use Option A (extend existing) or Option B (new dedicated tool)? Option B seems structurally cleaner as GitHub distinguishes between Issue Comments and PR Reviews.
• [OQ2] How should this impact our pr-review skill documentation once implemented?

Next Steps

• Gather cross-family consensus on the preferred Option.
• If approved, proceed to graduation via a substrate-modification ticket in neo-mjs-github-workflow.