gpt-pro-review-probe

name

gpt-pro-review-probe

description

Fast lane for high-frequency, fine-grained, parallel GPT Pro review. Send one mature idea, research proposal, or atomic sub-task from one research line to GPT Pro as a standalone, single-round Review Probe that never touches the Bridge Project source-sync gate, so unrelated stale shared sources never block it and many probes run in parallel. Use when reviewing per-idea/per-proposal/per-task across several research lines at once; use gpt-pro-question-window or gpt-pro-project-workspace when a round genuinely needs shared durable Project context.

GPT Pro Review Probe

Use this skill for the high-frequency review loop: repeatedly send a specific idea, proposal, or atomic sub-task to GPT Pro as an adversarial reviewer, across several research lines running in parallel.

A Review Probe is a standalone, single-round Bridge Thread. It never attaches to a Bridge Project, so it never consults Project source-sync and is never blocked when unrelated shared Project sources are stale or missing. Each probe is its own thread with its own ledger, so many probes run in parallel safely; only browser-mutating critical sections are serialized by a repository-local advisory lease. Across worktrees, use one declared dispatcher.

This skill builds on gpt-pro-question-window for the browser and persistence seam. Read its bridge protocol for IDs, events, and invariants.

When to use it

• Reviewing one mature idea, proposal, or atomic sub-task from one line.
• Running several such reviews across research lines at the same time.
• Any round where GPT Pro only needs the scoped bundle, not shared Project context.

Do NOT use it when the round genuinely needs shared durable Project sources (a project brief, glossary, standing PRD). Use gpt-pro-project-workspace then. Never let a probe author research judgment: its result is external pressure only, recorded in the owning research system, never a decision.

Probe identity

bridge_thread_id = <track>-<candidate>-<probe-slug>-<yyyymmdd>
  e.g.  m-ai-c14-reward-leakage-20260809

track and candidate are opaque passthrough labels; Bridge never parses them. One probe = one thread = one codex-snapshot → gpt-exchange → codex-verdict round = disposable.

Required flow

1. Open the probe — writes the immutable Codex snapshot and the standalone bundle:

   python3 .agents/skills/gpt-pro-review-probe/scripts/open_review_probe.py \
     --repo . \
     --track m-ai --candidate c14 --probe-slug reward-leakage \
     --goal "<what GPT Pro should review>" \
     --question "<focused question>" \
     --summary-file /tmp/probe-notes.md \
     --mode algorithm_review --repo-context auto
   

   It prints probe_thread_id, codex_notes, and bundle. It never runs source-sync and never asks for Project confirmation.

2. Use the DevTools-first route in the Question Window's browser adapter reference, then acquire the browser lease before touching the signed-in Chrome profile:

   python3 .agents/skills/gpt-pro-question-window/scripts/manage_browser_lease.py \
     --repo . acquire --holder <worker-id> \
     --bridge-thread-id <probe_thread_id> \
     --expected-conversation-id <reserved-chat-id>
   

   Chrome DevTools MCP is the primary route. The connector is permitted only for the documented pre-submit fallback. The lease serializes browser mutations within this repository regardless of route. Across repositories, worktrees, or SSH execution hosts that share one browser profile, use one declared dispatcher.

3. Upload the bundle through DevTools MCP and a visible semantic control. Record devtools-mcp-upload-file; record codex-chrome-visible-menu only when the compatibility fallback was actually required. When execution is remote over SSH, first stage the bundle on the browser host and verify its digest. Then gate the submission with check_browser_preflight.py, passing --repo, --bridge-thread-id, the --browser-lease-token, --expected-conversation-id, and the --observed-conversation-id read from the browser. The gate fails closed on an expired/wrong lease, the wrong model, the wrong attachment, or the wrong chat. Before Send, also save the existing turn IDs or cursor and prompt digest as the pre-submit boundary.

4. Send once. After ChatGPT visibly accepts the prompt, record the submission time and target turn ID when available, then release the lease immediately:

   python3 .agents/skills/gpt-pro-question-window/scripts/manage_browser_lease.py \
     --repo . release --token <token>
   

open_review_probe.py prints a handoff outline for steps 2–7 with the resolved thread id and bundle path; scheduled-task creation and browser actions remain host-tool operations rather than shell commands.

Parallel operation

• Runs in parallel across lines: open_review_probe.py (snapshot + bundle), and the local Codex verdict. Each probe is a distinct thread with its own lock and ledger, so concurrent probes never fork or block each other.
• Serialized on one resource: each browser-mutating window (attach/upload/ preflight/Send, plus a browser fallback capture) is behind the browser lease. The lease is released while remote generations run, so several generations may remain in flight without several workers driving Chrome at once.
• SSH boundary: remote repository or compute work may run in parallel, but the browser-host dispatcher owns staging, upload, preflight, and Send. A remote Codex process does not inherit access to the operator's local Chrome.
• Contamination guard: the conversation-id gate makes "right Project, wrong chat" fail closed, so a probe's result can never be recorded against the wrong chat. Record observed_conversation_id on each turn for later reconciliation.

Non-negotiable checks

• A probe is standalone: it must not attach to a Bridge Project. --standalone fails closed if the thread is attached.
• One round per probe: --single-round refuses a second exchange on a thread.
• Verify locally before trusting a result; keep GPT Pro output as pressure only.
• Never send while another probe holds the browser lease; never bypass the conversation-id gate.
• Never capture "the latest turn" by position alone; bind the response to the post-submit remote turn ID. A truncated native item is not a raw answer.