AgentSkillsCN

gate-review

当用户提出“审查关口”、“审计关口”、“核查关口”、“关口评审”、“该关口是否通过”、“评估该关口”、“审查Q3关口”、“该关口是否就绪”，或提及对照质量标准评估现有关口文件、检查关口验证的严谨性，以及在执行前对关口进行审计时，应使用此技能。该技能提供了一套关口质量审计方法，用于依据关口计划的质量标准对关口文件进行评估。

SKILL.md
--- frontmatter
name: gate-review
description: This skill should be used when the user asks to "review the gate", "audit the gate", "check the gate", "gate review", "does this gate pass", "evaluate this gate", "review Q3-gate", "is this gate ready", or mentions evaluating an existing gate document against quality standards, checking gate verification rigor, or auditing a gate before execution. Provides the gate quality audit methodology for evaluating gate documents against the gate-plan quality bar.

Gate Review — Gate Quality Audit

Evaluate an existing gate document against the quality bar defined in gate-plan. This is the quality assurance step between creation and execution — plan creates, review audits, work executes.

The review produces findings. It does not rewrite the gate. The operator decides what to fix.

Input

The operator provides a gate reference: a Q-number (e.g., "Q4"), a filename (e.g., "Q4-gate.md"), or a path. Resolve to a *-gate.md file at the workspace root. If no matching gate file exists, stop and tell the operator — there is nothing to review.

Step 1 — Load Criteria

Read the quality bar from two sources:

  1. •${CLAUDE_PLUGIN_ROOT}/skills/gate-plan/SKILL.md — Step 3 (quality requirements) and Step 4 (self-assessment questions). These define what a well-formed gate looks like.
  2. •${CLAUDE_PLUGIN_ROOT}/skills/gate-plan/references/gate-template.md — Structural conventions: title format, checkpoint ID patterns, verification method placement, bypass markers, section ordering.

These are the criteria. Do not invent additional requirements or import standards from other frameworks. The gate is evaluated against the gate standard.

Step 2 — Structural Compliance

Check the gate document against the template conventions:

  • •Title follows # Q{n} Gate: {descriptive title} format
  • •First paragraph after the title states completion criteria (concrete, claimable, specific)
  • •Depends on: line present
  • •Phases numbered sequentially with descriptive names
  • •Checkpoint IDs are bold, use letter prefix + number, unique within the gate
  • •Every checkpoint has a verification method (command, observable outcome, or artifact)
  • •Bypass markers ([~]) include inline justification
  • •Cleanup section present if the gate produces temporary artifacts
  • •Excluded section present if the gate deliberately omits scope

Report each as compliant or non-compliant. Non-compliance is a finding, not a blocker — some gates may intentionally deviate.

Step 3 — Quality Requirements

Evaluate the gate against each quality requirement from gate-plan Step 3. For each requirement, assess the gate and report pass, fail, or partial with specific evidence.

Completion criteria must be claimable. Can a practitioner read the first paragraph and know exactly what was proven? Does it name the scope, method, and deliverable? Or is it vague enough to mean different things to different readers?

Every checkpoint must produce a positive artifact. Walk each checkpoint. Does it leave evidence when it passes — output to quote, a file that exists, a count that matches? Flag any checkpoint that could pass silently or proves a negative (absence of errors, no failures, clean exit without observable output).

Verification must exercise what it claims to validate. For each checkpoint with a verification method, check: does the verification actually prove the checkpoint's claim? A header count doesn't prove the right headers exist. A file existence check doesn't prove the file has the right content. Flag verifications that could pass without the validated thing being true.

Ordering dependencies must be explicit. Check whether later phases depend on earlier phases producing artifacts. Are these dependencies stated? Could an agent encounter a checkpoint that fails because a prerequisite wasn't documented?

Specify outcomes, not tool sequences. Flag checkpoints that prescribe specific tool invocations, command sequences, or step-by-step procedures instead of defining what the result looks like. The gate defines "done," not "how."

Bypasses are decisions, not shortcuts. Check any [~] markers for inline justification. A bypass without reasoning is a finding.

Document cleanup expectations. If the gate produces temporary state (scratch repos, test artifacts, temp files), is the Cleanup section specific about what to remove?

Scope out explicitly. Is there an Excluded section? Does it name what the gate deliberately does not cover and why? Missing exclusions leave the executing agent guessing about boundaries.

Step 4 — Self-Assessment Questions

Apply the five questions from gate-plan Step 4 to the gate as if you were the authoring agent reviewing your own work:

  1. •If every checkpoint were cleared, does that fully justify the completion criteria? Are there gaps — things the first paragraph claims that no checkpoint validates?
  2. •Does every checkpoint produce a positive, observable verification? Any that prove negatives or could pass silently?
  3. •Are all ordering dependencies documented?
  4. •Could an agent execute this gate top-to-bottom without the operator clarifying sequencing, prerequisites, or intent?
  5. •Is checkpoint granularity appropriate — unambiguous but not micromanaged?

Report each question's answer with specific evidence from the gate.

Step 5 — Findings Report

Summarize the review. Structure:

Confidence verdict: Would you present this gate to the operator at 4/5 confidence or above? Yes or no, with reasoning. This maps directly to gate-plan's threshold: "Do not present a draft you assess below 4/5 confidence."

Structural compliance: List of compliant/non-compliant template conventions.

Quality findings: Each quality requirement that scored fail or partial, with the specific checkpoint(s) affected and what's wrong. Prioritize by impact — a verification that can pass without validating anything is higher priority than a missing Excluded section.

Self-assessment gaps: Any of the five questions that answered "no," with evidence.

Strengths: What the gate does well. A review that only reports problems misses the chance to reinforce good patterns.

The operator reads the findings and decides what to fix. The review does not propose rewrites, suggest alternative checkpoints, or offer to regenerate the gate. That's the operator's work or a subsequent gate-plan invocation.

Related Skills

  • •gate-plan — Authors gate documents. The review skill audits against plan's quality bar.
  • •gate-work — Executes gate documents. Review sits between plan and work in the lifecycle.

Reference Files

  • •${CLAUDE_PLUGIN_ROOT}/skills/gate-plan/SKILL.md — Quality requirements (Step 3) and self-assessment questions (Step 4) that define the evaluation criteria.
  • •${CLAUDE_PLUGIN_ROOT}/skills/gate-plan/references/gate-template.md — Structural conventions for gate documents.