Clean a stale `status:plan-review` queue by separating missing-plan drift
Scanned 9/9/2026
Install to Claude Code
npx -y skills add vamseeachanta/workspace-hub --skill plan-review-queue-governance-cleanup --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Plan Review Queue Governance Cleanup?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/vamseeachanta-plan-review-queue-governance-cleanup-workspace-hub)More formats (shields.io, HTML) on the badges page.
---
name: plan-review-queue-governance-cleanup
description: Clean a stale `status:plan-review` queue by separating missing-plan drift
from real review blockers, posting governance comments, removing stale labels, and
materializing durable review artifacts for delegated/Hermes reviews.
version: 1.0.0
author: Hermes Agent
category: coordination
tags:
- github
- planning
- governance
- queue-cleanup
- adversarial-review
---
# Plan-Review Queue Governance Cleanup
Use when a repo has many open GitHub issues labeled `status:plan-review` and you need to determine which are:
- real plan-review items
- mislabeled missing-plan drift
- reviewed but blocked by fresh MAJOR findings
- plausible approval-track items
## Why this exists
A live `status:plan-review` label alone is not trustworthy. In practice, queues drift in two common ways:
1. issues get labeled `status:plan-review` before a canonical `docs/plans/` artifact exists
2. fresh adversarial review returns MAJOR, but the blocker evidence only exists in chat/logs and never becomes a durable repo artifact + GitHub comment
This skill keeps the queue operationally honest.
## Required evidence surfaces
For each issue, audit all of:
1. live GitHub labels/state
2. canonical local plan file under `docs/plans/*issue-<N>-*.md`
3. local review artifacts under `scripts/review/results/*-plan-<N>-*.md`
4. local approval marker `.planning/plan-approved/<N>.md` if relevant
## Classification
### A. Missing-plan drift
Criteria:
- issue still labeled `status:plan-review`
- no canonical `docs/plans/*issue-<N>-*.md`
- usually no plan-review artifacts either
Action sequence:
1. Post a short governance comment explaining the issue is mislabeled as `status:plan-review` without a canonical local plan artifact.
2. Remove the stale `status:plan-review` label.
3. Do not present the issue as pending approval or pending provider review.
4. Re-enter it into the queue only after a real canonical plan is drafted and review artifacts exist.
## B. Real plan file exists, but fresh review is blocking
Criteria:
- canonical plan file exists
- fresh review returns `MAJOR`
- issue is still being treated as approval-track or under-reviewed
Action sequence:
1. Save a durable repo artifact summarizing the fresh review under:
`scripts/review/results/YYYY-MM-DD-plan-<issue>-<reviewer>.md`
2. Post a concise GitHub issue comment with:
- verdict
- top blockers
- explicit statement: not approval-ready
- required next step: revise plan, rerun adversarial review
3. Keep the issue out of approval-ready discussion until the plan is revised.
## C. Review-complete / possible approval-track
Criteria:
- canonical plan exists
- durable review artifacts exist
- no fresh unresolved MAJOR blocker in the latest review wave
Action:
- surface separately as the shortlist for user attention
- still verify latest review verdicts before calling anything approval-ready
## Durable-artifact rule for delegated/Hermes reviews
This is the key live-use lesson.
If you use `delegate_task` or Hermes subagents to review a plan:
- the chat/subagent output is **not** itself a canonical review artifact
- you must materialize a durable summary file in `scripts/review/results/`
- you should also post a concise GitHub issue comment in the same pass
Otherwise later queue audits will miss the blocker evidence because it only lived in chat history.
Recommended naming:
- `scripts/review/results/YYYY-MM-DD-plan-<issue>-hermes-parallel.md`
- or another reviewer suffix that truthfully identifies the source
## GitHub comment safety
When posting governance comments or review summaries, use `gh issue comment --body-file ...`.
Do not inline markdown-heavy comments with `--body`.
## Minimal execution pattern
1. Enumerate open `status:plan-review` issues.
2. For each issue, check plan-file existence and review-artifact existence.
3. Split into buckets:
- missing-plan drift
- fresh-MAJOR blocked
- review-complete / shortlist
4. For missing-plan drift:
- post governance comment
- remove stale label
5. For fresh-MAJOR blocked:
- save durable local review artifact
- post concise blocker summary comment
6. Recompute the queue and only then present the cleaned shortlist to the user.
## Output format to user
Give counts first, then grouped issue lists:
1. removed from queue as drift
2. blocked by MAJOR findings
3. remaining review-complete shortlist
This makes the next action obvious and avoids mixing governance cleanup with approval decisions.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!