preserved-plan-refile-with-attested-review-wave
Reopen a previously closed GitHub issue with a preserved local plan, rewrite it into a conservative draft, and drive iterative attested adversarial review waves until it is truly approval-ready.
Best use case
preserved-plan-refile-with-attested-review-wave is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Reopen a previously closed GitHub issue with a preserved local plan, rewrite it into a conservative draft, and drive iterative attested adversarial review waves until it is truly approval-ready.
Teams using preserved-plan-refile-with-attested-review-wave 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/preserved-plan-refile-with-attested-review-wave/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How preserved-plan-refile-with-attested-review-wave Compares
| Feature / Agent | preserved-plan-refile-with-attested-review-wave | 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?
Reopen a previously closed GitHub issue with a preserved local plan, rewrite it into a conservative draft, and drive iterative attested adversarial review waves until it is truly approval-ready.
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.
Related Guides
SKILL.md Source
# Preserved Plan Re-file With Attested Review Wave Use when: - an issue was previously closed or rolled back - the repo still has a preserved `docs/plans/...` artifact - #2405-style attested review infrastructure is available - you need to reopen/re-file the issue without pretending the old plan is still valid ## Why this exists A preserved plan that survived a closed issue often contains stale workflow state, stale review-history claims, and assumptions that were never revalidated against live repo state. Simply reopening the issue and relabeling it wastes cycles. The reliable path is: 1. convert the plan back to `draft` 2. reopen the issue with a governance comment 3. run fresh attested adversarial review 4. tighten only the still-live blockers 5. do not advance to `status:plan-review` until reviewers stop returning MAJOR ## Workflow ### 1. Verify live state first Always check before editing: - `gh issue view <n> --json state,labels,title` - required healthcheck / test command for the infrastructure you rely on - current `origin/main` tip - existence of the preserved plan file If the issue is closed, do not keep `plan-review` wording in the plan header. ### 2. Rewrite the preserved plan into a conservative draft Update the plan file to: - set `Status: draft` - clearly mark it as a re-file draft, not approval-ready - remove stale review-artifact claims unless the files still exist - distinguish: - required inputs - optional/reporting-only inputs - degraded/fail-closed behavior - make identity and matching contracts explicit - make scheduler/publication behavior explicit if the plan mentions automation Important: if a reviewer found a contradiction, rewrite the contract itself — do not just add commentary around the contradiction. ### 3. Reopen the issue with a scoped governance comment Use `gh issue reopen <n> -c "..."` and explain: - why the issue is being reopened - that the plan is now back in draft/revision mode - that fresh adversarial review follows Do not add `status:plan-review` yet. ### 4. Run fresh attested adversarial review immediately Use the standard adversarial prompt with the attestation-aware clause. Save canonical artifacts under `scripts/review/results/`. Recommended naming: - `YYYY-MM-DD-vN-plan-<issue>-codex.md` - `YYYY-MM-DD-vN-plan-<issue>-gemini.md` ### 5. Tighten by converging on live blocker themes After each wave, summarize the remaining blockers into a short list and edit only those. Common blocker buckets seen in preserved-plan refiles: - stale workflow state (`closed` issue but plan claims `plan-review`) - missing or stale review artifact references - undefined identity/matching contract - undefined degraded-vs-fail-closed behavior - scheduler/publishing semantics not specified tightly enough - duplicate/deduplication behavior undefined - output schema mismatches across plan sections - source-surface deduplication missing for multi-inventory detectors (`index.jsonl` + ledgers/manifests + registries) - cross-domain coverage semantics left implicit (`doc_key` match in wrong wiki/domain should not silently count as covered) - exit-code contract missing even though the plan talks about dry-run, degraded runs, or scheduled publication - publication mode ambiguous (CLI flag vs config-driven mode), which lets reviewers reject the plan for mismatched runtime vs scheduler behavior - locking specified at two layers (shell + Python) without one authoritative owner, creating deadlock/ambiguity risk - heterogeneous source schemas described with vague phrases like "field or equivalent" instead of concrete field names + fallback order ### 6. Keep GitHub and repo state aligned After each major revision wave: - post a short GitHub comment summarizing new artifacts and remaining blockers - update `docs/plans/README.md` to reflect `draft` / re-file-in-progress state - do not label `status:plan-review` while reviews are still MAJOR ### 7. Commit docs-only progress incrementally Safe commit pattern: - plan draft rewrite + first review wave - later revision-wave tightening + new review artifacts This preserves the tightening history and avoids losing learning between waves. ## Operational rules - A preserved plan is not approval-ready just because it already exists. - Fresh MAJOR review evidence outranks older optimistic review history. - Remove unverified or irrelevant live-state claims unless attestation covers them. - If a blocker list narrows, keep the issue open and still in draft; do not prematurely advance labels. - Approval readiness requires both plan quality and governance-state cleanliness. ## Suggested commit messages - `docs(plans): reopen #NNNN with v4 review wave` - `docs(plans): continue #NNNN adversarial revision wave` - `docs(plans): tighten #NNNN review contracts` ## Exit condition The issue is ready to move to `status:plan-review` only when: - the plan header/readme row say draft -> plan-review consistently - latest external review wave is no worse than MINOR - GitHub comment history links the current canonical review artifacts - no stale closed-issue or stale-approval contradictions remain
Related Skills
digitalmodel-orcawave-orcaflex-proof-workflows
Class-level digitalmodel OrcaWave/OrcaFlex readiness, semantic-proof, fixture-proof, and closeout workflows.
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.
orcawave-orcaflex-readiness-audit
Audit the real readiness of digitalmodel OrcaWave/OrcaFlex spec-driven workflows by reconciling workspace-hub issues, source/tests, semantic-equivalence boundaries, and wiki synthesis gaps.
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