Sk write review isolation

Skill gustavo-meilus/superpipelines/plugins/superpipelines/skills/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.From its SKILL.md

Install

npx -y skills add gustavo-meilus/superpipelines --skill sk-write-review-isolation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.0 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

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>

Executor: Writes output for a given task.
SpecReviewer: Reviews for compliance (Stage 1).
- FAIL: Executor fixes issues → Re-run Stage 1.
- PASS: Proceed to Stage 2.
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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.