| name | iterative-plan-redraft-semantic-guardrails |
| title | Iterative Plan Redraft Semantic Guardrails |
| description | Harden a repeatedly re-reviewed documentation/contract plan after adversarial reviewers keep finding semantic gaps despite new test rows. |
| author | vamseeachanta |
| author_url | https://github.com/vamseeachanta/workspace-hub/tree/main/.claude/skills/workspace-hub-learned/iterative-plan-redraft-semantic-guardrails |
| license | MIT |
| version | 0.1.0 |
| execution_mode | open |
| jurisdiction | general |
| practice | general |
| language | en |
| tags | ["planning","adversarial-review","docs-contracts","semantic-guardrails","workspace-hub"] |
Iterative Plan Redraft Semantic Guardrails
Use when a plan has already gone through one or more adversarial review waves and reviewers keep finding that the draft is still not approval-ready because the plan text is internally inconsistent or the proposed tests only prove word presence, not semantics.
When this applies
Typical signals:
- the plan has been patched after review, but the
## Adversarial Review Summary still says FAIL / MAJOR as if it applies to the new text
- reviewers say a requirement is "independently testable" only in the weak sense that it has its own test row, but the test is just a phrase-presence check
- documentation/contract plans add new docs without bringing them under existing stale-reference guardrails
- the plan cites a local artifact/report and reviewers flag ambiguity about whether it is canonical branch truth or only local attestation
- open questions remain in the Risks section even though TDD/acceptance criteria already assume the decision is settled
Core lessons
- Historical review state must be marked as historical
- If you materially patch a plan after a review wave, do NOT leave the body saying the draft currently
FAILs unless that still truly applies to the patched text.
- Rewrite the section so prior verdicts are labeled as historical/superseded.
- Add a current-state line like
PENDING RE-REVIEW until the next rerun lands.
- Exact pass conditions beat generic presence checks
For docs/contract plans, reviewers will often reject tests like:
- "requirement present"
- "daily cadence language present"
- "forbidden string absent"
Strengthen them into exact pass conditions such as:
- exact phrases that must appear
- required co-location rules (same section/paragraph)
- required companion obligations (for example, not just mention daily freshness, but also require refreshing a named artifact)
- exact field names
- exact allowed enum values
- minimum example counts (
>= 3 concrete signatures, not just "multiple")
- Resolve open-vs-required contradictions
- If acceptance criteria or tests already lock a decision, do not leave the same question open under Risks/Open Questions.
- Either resolve the question in the plan or make the acceptance criteria conditional.
- Reviewers will mark this as a MAJOR internal contradiction.
