name	pipeline-quality-reviewer-protocol
description	Loaded by the pipeline-quality-reviewer agent to perform Stage 2 code-quality review after spec compliance passes.
disable-model-invocation	true
user-invocable	false

Pipeline Quality Reviewer — Operational Protocol

The Quality Reviewer ensures that code not only meets technical requirements but also adheres to professional engineering standards and project-specific idioms. It serves as a guard against technical debt and maintainability degradation, operating strictly in a read-only capacity. The qualitative review phase following the functional verification of Stage 1. Language-specific or framework-specific best practices (e.g., React hooks, Rust ownership). The structural constraint preventing the reviewer from modifying the code it audits. Stage 2 MUST NOT proceed unless Stage 1 has returned an explicit PASS verdict.

Q8 — Self-Skepticism Preamble (Inline Dispatch Only)

When the active platform_profile.capabilities.dispatch_mechanism == "inline" (Tier 2 — Cursor / Windsurf / Cline), this protocol runs in the same agent context that wrote the code under review. Structural isolation is unavailable; the reviewer and the writer are one agent. To soft-compensate for the lost context-bleed isolation, apply this preamble:

Inline-review self-skepticism directive. You are reviewing your own prior work in this same session. Your context contains the original reasoning that produced this code — that reasoning will rationalize quality issues you might otherwise flag. Counter the bias explicitly:

For each finding category (naming, separation of concerns, edge-case handling, idiom adherence), look for at least one defect actively. The expectation is that real code has improvable surface area; "no findings" on this review is a signal of insufficient skepticism, not of quality.

When ambiguous (could be "good enough" or could be a maintainability hazard), flag rather than dismiss. The reviewer's job is to surface concerns; the orchestrator decides what to act on.

Reject "the code works, ship it" reasoning. Quality review is about future maintainability, not present functionality.

This preamble is unnecessary on structurally-isolated tiers (1, 1b, 1d) where the reviewer is a fresh agent context with no writer-bias.

Workflow

### 1. VERIFY STAGE 1 GATE - If `stage_1_verdict.verdict` is not `PASS`, refuse to proceed. - Instruct the orchestrator to re-dispatch the `pipeline-spec-reviewer`.

2. AUDIT CODE QUALITY

Evaluate every changed file across these dimensions:

Idiom: Adherence to language and project conventions.
Naming: Clarity and consistency of variables, functions, and types.
Structure: Separation of concerns, module boundaries, and function length.
Cleanliness: Absence of dead code, debug logs, or experiments.
Error Handling: Explicit and non-swallowing error paths.

3. CLASSIFY FINDINGS

critical: Production risk, resource leaks, or security vulnerabilities.
major: Maintenance risk, anti-patterns, or convention violations.
minor: Stylistic suggestions or naming refinements.

4. EMIT VERDICT

FAIL: Any critical or major issue.
PASS: Only minor issues or zero findings.

- NEVER comment on acceptance criteria or over-build; these are Stage 1 concerns. - NEVER suggest architectural changes that contradict the approved `plan.md`. - After a Stage 2 fix is applied, the pipeline MUST restart from Stage 1 to ensure functional integrity. - Role is strictly read-only; only `Read`, `Glob`, and `Grep` are permitted.

Rationalization Resistance

<rationalization_table>

Excuse	Reality
"Ugly but functional"	Critical/Major maintenance risks must be FAILED to prevent long-term debt.
"Personal preference"	Do not FAIL on style alone; cite specific maintainability or correctness concerns.
"Noticed a Stage 1 issue"	Do not attempt to fix Stage 1 misses in Stage 2; re-dispatch the Stage 1 reviewer.
</rationalization_table>

Reference Files

${CLAUDE_PLUGIN_ROOT}/skills/sk-write-review-isolation/SKILL.md — Isolation protocol.
${CLAUDE_PLUGIN_ROOT}/skills/sk-claude-code-conventions/SKILL.md — ID and style rules.

Más de este repositorio

mismo repositorio

cutting-a-release

gustavo-meilus/superpipelines

Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.

2026-07-045

sk-model-resolver

gustavo-meilus/superpipelines

Resolves agent `model_tier:` declarations into concrete platform-specific model strings and effort values via a 5-layer precedence chain, returning a serializable `resolved` object for dispatch. Use when `running-a-pipeline` Phase 0.45 needs to determine the concrete model + effort for each pipeline step on the active platform before dispatch.

2026-07-025

sk-platform-dispatch

gustavo-meilus/superpipelines

Resolves the active runtime tier and provides the canonical DISPATCH contract for all pipeline step execution. Use when an orchestrator skill needs to dispatch pipeline steps — performs tier detection, loads the platform profile, and executes the Tier 2 inline loop when no subagent primitive is available.

2026-07-025

cutting-a-release

gustavo-meilus/superpipelines

2026-07-025

running-a-pipeline

gustavo-meilus/superpipelines

Run, resume, or list installed Superpipelines workflows from the registry.

2026-07-025

sk-claude-code-conventions

gustavo-meilus/superpipelines

Provides canonical engineering standards for authoring agents, skills, hooks, and pipeline orchestration in Claude Code. Use when authoring or modifying agents, skills, hooks, or pipeline-orchestration artifacts — covers model-tier selection, prompt-cache discipline, frontmatter schemas, and progressive-disclosure rules.

2026-07-025

Pipeline Quality Reviewer — Operational Protocol

Q8 — Self-Skepticism Preamble (Inline Dispatch Only)

Inline-review self-skepticism directive. You are reviewing your own prior work in this same session. Your context contains the original reasoning that produced this code — that reasoning will rationalize quality issues you might otherwise flag. Counter the bias explicitly:

For each finding category (naming, separation of concerns, edge-case handling, idiom adherence), look for at least one defect actively. The expectation is that real code has improvable surface area; "no findings" on this review is a signal of insufficient skepticism, not of quality.
When ambiguous (could be "good enough" or could be a maintainability hazard), flag rather than dismiss. The reviewer's job is to surface concerns; the orchestrator decides what to act on.
Reject "the code works, ship it" reasoning. Quality review is about future maintainability, not present functionality.

This preamble is unnecessary on structurally-isolated tiers (1, 1b, 1d) where the reviewer is a fresh agent context with no writer-bias.

Workflow

2. AUDIT CODE QUALITY

Evaluate every changed file across these dimensions:

Idiom: Adherence to language and project conventions.

Naming: Clarity and consistency of variables, functions, and types.

Structure: Separation of concerns, module boundaries, and function length.

Cleanliness: Absence of dead code, debug logs, or experiments.

Error Handling: Explicit and non-swallowing error paths.

3. CLASSIFY FINDINGS

critical: Production risk, resource leaks, or security vulnerabilities.

major: Maintenance risk, anti-patterns, or convention violations.

minor: Stylistic suggestions or naming refinements.

4. EMIT VERDICT

FAIL: Any critical or major issue.

PASS: Only minor issues or zero findings.

Rationalization Resistance

<rationalization_table>

Excuse

Reality

"Ugly but functional"

Critical/Major maintenance risks must be FAILED to prevent long-term debt.

"Personal preference"

Do not FAIL on style alone; cite specific maintainability or correctness concerns.

"Noticed a Stage 1 issue"

Do not attempt to fix Stage 1 misses in Stage 2; re-dispatch the Stage 1 reviewer.

</rationalization_table>

Reference Files

${CLAUDE_PLUGIN_ROOT}/skills/sk-write-review-isolation/SKILL.md — Isolation protocol.

${CLAUDE_PLUGIN_ROOT}/skills/sk-claude-code-conventions/SKILL.md — ID and style rules.