How do I install the Sk Write Review Isolation skill?

Run npx skillmds@latest add gustavo-meilus/sk-write-review-isolation in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Sk Write Review Isolation safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Sk Write Review Isolation?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Sk Write Review Isolation free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Sk Write Review Isolation?

gustavo-meilus (@gustavo-meilus) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Sk Write Review Isolation by gustavo-meilus

Name: Sk Write Review Isolation
Author: gustavo-meilus

Sk Write Review Isolation

Enforces structural separation between the writing agent and the reviewing agent, with Stage 1 (spec compliance) hard-gating Stage 2 (code quality). Use when dispatching a reviewer after a pipeline worker has produced output, when authoring any pipeline step that requires formal verification against a specification, or when implementing a two-stage review loop.

File contents

Write/Review Isolation — Two-Stage Review Protocol

Enforces a non-negotiable separation between the agent authoring code and the agent reviewing it. Loaded by agents that dispatch reviewers, author multi-stage pipelines, or implement tasks requiring formal verification against a specification.

The Two-Stage Protocol

STAGE 2 — CODE QUALITY REVIEW

Agent: pipeline-quality-reviewer.
Inputs: Same as Stage 1, plus the Stage 1 PASS verdict.
Goal: Evaluate maintainability, naming, separation of concerns, and edge-case handling.
Exit Condition: Terminal PASS only when all critical and major issues are resolved.

The Review Loop

Red Flags — STOP

"The output looks fine, I'll skip Stage 1." → STOP. Spec compliance is the primary defense against production regressions.
"I'll mention this AC issue in the Stage 2 report." → STOP. Re-dispatch Stage 1 immediately.
"I added a helper that wasn't in the spec, but it's clearly needed." → STOP. This is over-build. Re-architect the spec or remove the helper.

Rationalization Table

Reference Files

sk-pipeline-patterns/SKILL.md — Pattern 5 integration.
pipeline-spec-reviewer.md — Spec reviewer blueprint.
pipeline-quality-reviewer.md — Quality reviewer blueprint.
sk-rationalization-resistance/SKILL.md — Resistance mechanism standards.

---name: sk-write-review-isolationdescription: Enforces structural separation between the writing agent and the reviewing agent, with Stage 1 (spec compliance) hard-gating Stage 2 (code quality). Use when dispatching a reviewer after a pipeline worker has produced output, when authoring any pipeline step that requires formal verification against a specification, or when implementing a two-stage review loop.---# Write/Review Isolation — Two-Stage Review Protocol> Enforces a non-negotiable separation between the agent authoring code and the agent reviewing it. Loaded by agents that dispatch reviewers, author multi-stage pipelines, or implement tasks requiring formal verification against a specification.<overview>`WRITE_REVIEW_ISOLATION: STRUCTURAL_ON_TIER1_1B_1D; CONVENTION_ONLY_ON_TIER2` is a fundamental invariant of the Superpipelines architecture. By separating the writer from the reviewer and splitting the review process into Stage 1 (Spec Compliance) and Stage 2 (Code Quality), the protocol prevents context bleed, detects over-build early, and ensures that only verified code is promoted. On Tier 1 (CC), Tier 1b (OC), and Tier 1d (Codex) the separation is enforced structurally via per-agent permission boundaries. On Tier 2 (Cursor/Windsurf/Cline) the same protocol runs as a convention — the orchestrator MUST surface this degradation at run start and run end so reviews are treated as advisory rather than structurally guaranteed.</overview><glossary> <term name="Stage 1 (Spec Compliance)">A binary check answering: "Does the output match the spec exactly?"</term> <term name="Stage 2 (Code Quality)">A qualitative check answering: "Is the code maintainable, idiomatic, and robust?"</term> <term name="Over-build">Adding features or logic not explicitly requested by the specification; results in a Stage 1 FAIL.</term></glossary>## The Two-Stage Protocol<protocol>### STAGE 1 — SPEC COMPLIANCE REVIEW- **Agent**: `pipeline-spec-reviewer`.- **Inputs**: `spec.md`, output files, and the executor's status report.- **Goal**: Verify every acceptance criterion is present and verifiable. Flag any unrequested output as **Over-build**.- **HARD-GATE**: Stage 2 cannot begin until Stage 1 returns a `PASS`.### STAGE 2 — CODE QUALITY REVIEW- **Agent**: `pipeline-quality-reviewer`.- **Inputs**: Same as Stage 1, plus the Stage 1 `PASS` verdict.- **Goal**: Evaluate maintainability, naming, separation of concerns, and edge-case handling.- **Exit Condition**: Terminal `PASS` only when all critical and major issues are resolved.</protocol><EXTREMELY-IMPORTANT>Stage 1 spec compliance review MUST pass before Stage 2 code quality review begins. This order is not optional. Running Stage 2 on spec-noncompliant output is wasted work and risks propagating incorrect logic.</EXTREMELY-IMPORTANT>## The Review Loop<loop_diagram>1. **Executor**: Writes output for a given task.2. **SpecReviewer**: Reviews for compliance (Stage 1). - **FAIL**: Executor fixes issues → Re-run Stage 1. - **PASS**: Proceed to Stage 2.3. **QualityReviewer**: Reviews for quality (Stage 2). - **FAIL (Critical/Major)**: Executor fixes issues → **Re-run Stage 1** (to ensure the fix didn't break compliance). - **PASS**: Task complete; update `pipeline-state.json`.</loop_diagram><invariants>- **Instance Isolation**: The writing agent and reviewing agent must be separate model instances with fresh context.- **Full Re-review**: Any code change triggered by Stage 2 MUST trigger a fresh Stage 1 review.- **No Scope Creep**: Reviewers must stay within their defined stage scope (e.g., Stage 1 does not flag formatting; Stage 2 does not flag missing ACs).</invariants>## Red Flags — STOP- "The output looks fine, I'll skip Stage 1." → **STOP**. Spec compliance is the primary defense against production regressions.- "I'll mention this AC issue in the Stage 2 report." → **STOP**. Re-dispatch Stage 1 immediately.- "I added a helper that wasn't in the spec, but it's clearly needed." → **STOP**. This is over-build. Re-architect the spec or remove the helper.## Rationalization Table<rationalization_table>| Excuse | Reality || :--- | :--- || "Separate instances are pointless." | Fresh context forces new reasoning paths and prevents "assumption blindness." || "Stage 1 is just a sanity check." | Stage 1 catches the most expensive bugs (wrong logic/output). It is the primary gate. || "Re-Stage 1 is over-engineering." | Code quality fixes often break specification compliance. Re-verification is mandatory. || "Over-build is a bonus for the user." | Over-build invalidates the contract that parallel workers and dependent steps rely on. |</rationalization_table>## Reference Files- `sk-pipeline-patterns/SKILL.md` — Pattern 5 integration.- `pipeline-spec-reviewer.md` — Spec reviewer blueprint.- `pipeline-quality-reviewer.md` — Quality reviewer blueprint.- `sk-rationalization-resistance/SKILL.md` — Resistance mechanism standards.

Frequently asked questions