plan-review-rerun-cli-drift-and-git-contention
Recover iterative plan-review work when provider CLI wrappers drift, fresh reviews expose stale governance text, and active git pre-push processes make committing unsafe.
Best use case
plan-review-rerun-cli-drift-and-git-contention is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Recover iterative plan-review work when provider CLI wrappers drift, fresh reviews expose stale governance text, and active git pre-push processes make committing unsafe.
Teams using plan-review-rerun-cli-drift-and-git-contention should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/plan-review-rerun-cli-drift-and-git-contention/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How plan-review-rerun-cli-drift-and-git-contention Compares
| Feature / Agent | plan-review-rerun-cli-drift-and-git-contention | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Recover iterative plan-review work when provider CLI wrappers drift, fresh reviews expose stale governance text, and active git pre-push processes make committing unsafe.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Plan Review Rerun: CLI Drift + Governance Hygiene + Git Contention Use this when hardening a `status:plan-review` issue through repeated adversarial review waves, especially when provider dispatch partially fails or another agent/process is actively using git. ## Trigger conditions - A plan has old review waves (`r2`, `r3`, etc.) and new review findings against newer text. - Provider fanout returns `UNAVAILABLE` due CLI syntax drift, not a substantive review. - A fresh review identifies stale plan metadata, stale issue-status claims, or stale approval-artifact wording. - `git add`, `git status`, `git commit`, or `git push` are blocked by active pre-push/git processes or `.git/index.lock`. ## Workflow 1. Revalidate live state before editing. - `gh issue view <issue> --json labels,state,comments,url` - Read the plan header, `## Adversarial Review Summary`, and `docs/plans/README.md` row. - Check local approval marker only after live labels: `.planning/plan-approved/<issue>.md`. 2. Treat provider wrapper failure as a tool problem, not review signal. - Current Codex CLI may reject `codex exec --no-interactive` with rc=2. - If `plan-review-fanout.sh` emits `UNAVAILABLE (codex CLI failed ... unexpected argument '--no-interactive')`, rerun Codex without `--no-interactive` or record Codex as unavailable. - Do not count an UNAVAILABLE artifact as approval. 3. Patch the actual plan blockers from substantive providers. - Example: if Gemini says tests install a dependency directly and bypass `pyproject.toml`, change the plan to reinstall from project metadata (`uv pip install --python <venv>/bin/python -e .`) rather than `pip install package`. - If adding a dependency absent from `uv.lock`, prefer bare `uv lock` plus diff inspection over `uv lock --upgrade-package <pkg>`. - If TDD-red tests might fail at collection time, require imports inside test functions so each intended test fails for the expected reason. - If a plan requires creating a follow-up issue, include that GitHub action in the explicit scope boundary. - For TOML/structured config edits, require TOML-aware edits or exact existing-array patches that preserve syntax. 4. Patch governance hygiene in the same pass. - Header status/revision should match current reality (`draft v4`, `plan-review`, etc.). - Evidence should state the current live issue label, not historical `status:plan-approved` drift after rollback. - Acceptance criteria should require fresh current-draft review artifacts, not stale `-r3.md` or old self-review artifacts. - Risks should explain any earlier approval drift as resolved if the issue is now correctly back in `status:plan-review`. 5. Re-review narrowly before broader rerun. - Use a delegated or independent reviewer for a fast governance-hygiene review after patches. - Ask specifically about stale status, stale review-artifact references, command-policy drift, and scope contradictions. - Keep the issue not approval-ready unless a fresh current-draft substantive review has no MAJOR findings. 6. Avoid git contention. - If `git add`/`status` fails with `.git/index.lock`, check `ps -ef | grep '[g]it'` before removing locks. - If an active `git remote-https`, pre-push hook, or quality gate is running, do not kill it just to land planning edits unless explicitly authorized. - Post a progress comment with exact local artifacts prepared for commit and leave the worktree for the active writer to clear. - Only remove `.git/index.lock` when no real git process is running. 7. Recover when the terminal/fanout path itself is unstable. - If the terminal tool fails before running commands (for example `FileNotFoundError: [Errno 2] No such file or directory: '%s'`), switch to `execute_code` with `subprocess.run(..., cwd='<repo>')` for git, `gh`, and review commands rather than abandoning the gate. - If a combined fanout command times out, rerun providers one at a time (for example `--providers=codex` then `--providers=Codex`) and read the regenerated provider artifacts directly. - If ad-hoc provider CLI reruns stall with empty stdout/logs, do not wait indefinitely: poll once or twice, kill the stuck process, preserve any successful provider output, and record the stalled provider as infrastructure/tooling state rather than substantive review signal. - For non-interactive reruns, prefer an explicit prompt file plus the provider's documented stdin mode. Avoid shell patterns that confuse the wrapper into waiting for stdin (for example a positional prompt while stdin is still open, or giant command substitutions that bypass expected file input). If a wrapper prints "Reading additional input from stdin..." or "no stdin data received" and then hangs, relaunch with corrected stdin handling or mark unavailable. - Treat review artifacts as stale unless they were generated after the latest plan commit or patch. A MAJOR artifact that predates the final patch is diagnostic input, not current gate evidence. - When a provider rerun downgrades to MINOR with an empty Blockers list, patch only governance/clarity minors that materially affect implementability before the final gate; do not churn the plan for cosmetic findings. - Before citing review artifacts in a committed plan, verify the artifact path is trackable in the target repo. If `scripts/review/results/` is ignored, either use an already-tracked review-artifact location such as `docs/reports/` or explicitly force-add only when repo policy allows it; do not cite ignored local-only files as durable approval evidence. ## GitHub progress comment template ```text #<issue> plan-redraft/re-review progress update. Review results: - Codex: UNAVAILABLE because <tool failure>. No substantive signal. - Gemini/other: <VERDICT> with blockers: ... Plan patches applied locally: - ... Follow-up review: - <reviewer> returned <VERDICT> for governance hygiene. Current landing status: - Local files are patched, but not committed/pushed because <active git/pre-push process>. Avoiding git contention. Local artifacts prepared for commit once git clears: - <paths> ``` ## Pitfalls - Do not downgrade a plan to approved just because a prior self-review returned APPROVE; stale self-review artifacts do not satisfy a fresh current-draft review requirement. - Do not let `UNAVAILABLE` Codex/Gemini artifacts hide the need for real cross-provider review. - Do not run direct `pip install <missing-dep>` as the green proof for a dependency-declaration fix; it can bypass the project metadata and mask the core bug. - Do not force-remove `.git/index.lock` while another agent's pre-push hook or git process is still active.
Related Skills
plan-review-prompt-refresh-after-plan-edits
Refresh reviewer prompt files from the latest on-disk plan before every adversarial re-review. Prevents Codex/Gemini from critiquing stale plan text after local edits.
workspace-hub-overnight-plan-monitor
Monitor and reconcile workspace-hub overnight planning or implementation batches, including process status, result artifacts, issue/commit verification, and controlled failed-lane recovery.
plan-gated-issue-execution-wave
Execute a multi-issue architecture/planning wave in a plan-gated repo, then safely transition approved issues into implementation with file-based Codex prompts, local approval markers, subprocess monitoring, and cleanup handling for sandbox/hook edge cases.
mixed-ops-vs-repo-fix-plan-boundary
Plan mixed operational-vs-repo remediation issues by proving live-state classification first, then only proposing code changes for confirmed repo-owned failure paths.
wave-based-parallel-plan-execution
Orchestrate phase execution by discovering dependencies, grouping into waves, spawning subagents, and collecting results with optional wave filtering
tdd-verification-and-adversarial-review
Verify pre-written TDD tests pass, conduct adversarial code review on committed diffs, and route findings to existing issues
plan-gated-issue-validation-workflow
Systematic validation pattern for plan-approved GitHub issues with pre-existing deliverables
plan-gated-issue-implementation
Workflow for executing pre-approved GitHub issues with mandatory validation checkpoints
multi-role-agent-contract-review-pipeline
Execute a 4-role agent team (Planner/Architect/Reviewer/Integrator) pipeline for self-reviewing knowledge artifacts before delivery
gsd-adversarial-review-pattern
Catch hidden test failures by running adversarial review on sparse-data edge cases before final push
adversarial-code-review-tdd
Systematic adversarial review pattern to identify breaking assumptions in already-passing test suites
adversarial-code-review-for-committed-diffs
Systematic process for reviewing already-committed code changes to catch type inconsistencies, edge cases, and docstring gaps