Use when checking if a phase is ready to proceed, reviewing phase quality, or approving a gate. Also triggers on 'validate', 'are we ready', 'gate check', 'review phase', 'GO/NO-GO', or 'can we move to the next phase'.
From pmnpx claudepluginhub etusdigital/etus-plugins --plugin pmThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides implementation of event-driven hooks in Claude Code plugins using prompt-based validation and bash commands for PreToolUse, Stop, and session events.
This skill executes an interactive quality gate for any phase of the documentation workflow. It:
Gates are the control points in the workflow where stakeholders decide whether to proceed to the next phase. The opening ideation layer uses an Ideation Readiness Gate before Discovery/Planning artifacts are allowed to run downstream.
Gate validation runs in 3 sequential layers. Each layer must pass before proceeding to the next. If a layer fails, stop and report — do not continue to subsequent layers.
Checks that required documents exist and have the correct format:
Reject automatically if found in required sections:
If any check fails: Report "STRUCTURE FAILURE" with list of missing/malformed items. Do NOT proceed to Layer 2.
Checks that document content meets quality standards:
Mandatory dimensions are defined in state_defaults.py → MODE_DIMENSION_RULES.
This is the SINGLE SOURCE OF TRUTH for which dimensions are required per mode.
For the current mode, read the required list from MODE_DIMENSION_RULES:
The conditional dimensions generate warnings but do not block the gate.
The recommended dimensions are informational only.
Do NOT duplicate the per-mode rules here. If the rules need to change, change them in state_defaults.py and they propagate automatically.
For each EDGE-# in edge_resolution:
| Term | Required Replacement |
|---|---|
| "fast" | "response time < X ms at p95" |
| "easy to use" | "new user completes [task] without help in < X min" |
| "secure" | specific threat model + encryption + auth requirements |
| "scalable" | "supports X concurrent users / Y req/s" |
| "real-time" | "latency < X ms" |
| "robust" | "handles [specific failures] with [specific behavior]" |
| "seamless" | specific integration/transition requirements |
If any check fails: Report "CONTENT GAPS" with specific items needing improvement. Do NOT proceed to Layer 3.
Checks consistency and traceability across documents:
If any check fails: Report "DEPENDENCY VIOLATIONS" with specific broken links and violations.
Only after all 3 layers pass can the gate recommend GO. Decision options:
When gate result is ITERATE or NO-GO:
Validation thresholds vary by work mode. The mode is read from state/project-status.yaml if it exists, or passed as an argument (e.g., --mode feature). If neither is available, default to Product mode (strictest thresholds).
These are the standard thresholds used throughout this document. No relaxation.
Feature mode generates fewer, more focused documents. Validation is scoped accordingly.
feature-status.md required for each active feature workflowdocs/ets/projects/{project-slug}/features/{feature-slug}/), not the full projectBug mode produces a single document. Validation checks only essential content.
Spike mode produces a single research document. Validation checks only essential content.
Reference: .claude/skills/orchestrator/dependency-graph.yaml
BLOCKS: None — this skill runs at phase boundaries, after documents are generated. ENRICHES: None.
This skill executes quality gate validation for any phase (Ideate, Discovery, Planning, Design). It reads the dependency graph to know which documents should exist for the given phase, then validates completeness.
Required Documents:
docs/ets/projects/{project-slug}/discovery/opportunity-pack.md — Filled with actors, JTBDs, journeys, use cases, edge cases, guardrails, and assumptionsdocs/ets/projects/{project-slug}/state/coverage-matrix.yaml — Filled with threshold counts and readiness statusChecks:
coverage-matrix.yaml identifies the incomplete semantic block when coverage is missingmeta.last_completed_step and meta.next_recommended_step are coherentDecision Points:
If ITERATE: The report should explicitly say which subcommand to run next
(for example /ideate jobs, /ideate edges, or /ideate synth).
Required Documents:
docs/ets/projects/{project-slug}/discovery/opportunity-pack.md — Filled and approved or explicitly marked draft with known gapsdocs/ets/projects/{project-slug}/discovery/project-context.md — Filled (background, problem statement, constraints)docs/ets/projects/{project-slug}/discovery/product-vision.md — Filled (vision, success metrics, assumptions)Checks:
Decision Points:
Opportunity Focus sub-gate
docs/ets/projects/{project-slug}/planning/ost.mddocs/ets/projects/{project-slug}/planning/prioritization.mdO-# items are clear enough to enter solution discoverySolution Readiness sub-gate
docs/ets/projects/{project-slug}/planning/solution-discovery.md for Product modedocs/ets/projects/{project-slug}/features/{feature-slug}/solution-discovery.md for Feature modeSOL-# options were considered unless scope is trivially narrowRequired Documents:
docs/ets/projects/{project-slug}/planning/prd.md — Filled (features, success criteria, acceptance, trade-offs)docs/ets/projects/{project-slug}/planning/user-stories.md — Filled (US-# with Given/When/Then)docs/ets/projects/{project-slug}/planning/feature-specs/feature-spec-*.md (1+) — Filled when needed (FS-# with detailed specs)Checks:
Decision Points:
Compatibility rule: If the project is legacy and does not declare the new workflow version, solution discovery may be absent without failing the gate. For the new workflow version, it is mandatory. In Feature mode, the scoped file is features/{feature-slug}/solution-discovery.md.
Required Documents:
docs/ets/projects/{project-slug}/architecture/architecture-diagram.md — Filled (C4 levels, deployment view)docs/ets/projects/{project-slug}/architecture/tech-spec.md — Filled (NFR-#, ADR-#, all quantified)docs/ets/projects/{project-slug}/data/database-spec.md — Filled (DDL, schema, indexes)docs/ets/projects/{project-slug}/data/data-dictionary.md — Filled (dict., ev. definitions)docs/ets/projects/{project-slug}/ux/style-guide.md — Filled (tok.*, design system)docs/ets/projects/{project-slug}/ux/*.md (4+) — Filled (UX flows, wireframes, interaction specs)docs/ets/projects/{project-slug}/implementation/api-spec.md — Filled (endpoints, schemas, errors)Checks:
Decision Points:
When invoked with the --adversarial flag, or when the orchestrator runs validation before the Implementation Readiness Gate (Gate 3), the reviewer switches to adversarial mode. This mode exists because confirmation bias is real — reviewers who helped create the documents naturally see them as complete. Adversarial review forces a critical lens.
In adversarial mode, the reviewer adopts a cynical stance: assume problems exist and actively look for them. The goal is not to block progress, but to surface issues that would otherwise be discovered during implementation — when they are far more expensive to fix.
The reviewer acts as a skeptical stakeholder who has seen projects fail and knows where the weak points typically hide: vague NFRs, untested edge cases, missing error handling, implicit assumptions, and scope creep disguised as "nice-to-haves".
Each finding is categorized by severity:
| Severity | Meaning | Effect on Gate |
|---|---|---|
| HIGH | Blocks GO — must be fixed before proceeding | Automatically changes recommendation to ITERATE |
| MEDIUM | Should fix — significant risk if left unaddressed | Does not block GO, but tracked as post-gate action items |
| LOW | Informational — improvement opportunity | Noted for future reference, no effect on gate decision |
Any HIGH finding automatically changes the gate recommendation to ITERATE, regardless of how many items pass validation.
Each finding must include these fields:
### Finding F-{N}: {brief title}
- **Location:** {document name} → {section or ID}
- **Issue:** {clear description of what's wrong or missing}
- **Severity:** HIGH | MEDIUM | LOW
- **Suggested Fix:** {concrete, actionable recommendation}
- **Evidence:** {quote or reference from the document that demonstrates the issue}
Example:
### Finding F-1: NFR-3 latency target is not measurable
- **Location:** tech-spec.md → NFR-3 (API Response Time)
- **Issue:** NFR-3 says "API should be fast" but does not specify a measurable target (e.g., P99 < 200ms)
- **Severity:** HIGH
- **Suggested Fix:** Replace "fast" with a specific latency target: "P99 < 200ms for read endpoints, P99 < 500ms for write endpoints"
- **Evidence:** "NFR-3: API Response Time — The API should respond quickly to all requests."
In addition to the standard 3-layer validation, adversarial mode runs these additional checks:
Architecture & Design:
Data & API:
UX & Implementation:
Cross-Cutting:
╔════════════════════════════════════════════════════════════════╗
║ ADVERSARIAL REVIEW — {PHASE} GATE ║
╚════════════════════════════════════════════════════════════════╝
Review Mode: ADVERSARIAL
Timestamp: {date}
Reviewer Stance: Cynical — assuming problems exist
━━━ STANDARD VALIDATION (3-Layer) ━━━
Layer 1 (Structure): {PASS/FAIL}
Layer 2 (Content): {PASS/FAIL}
Layer 3 (Dependencies): {PASS/FAIL}
━━━ ADVERSARIAL FINDINGS ({N} total) ━━━
HIGH ({N}):
F-1: {title} — {location}
F-2: {title} — {location}
MEDIUM ({N}):
F-3: {title} — {location}
LOW ({N}):
F-4: {title} — {location}
F-5: {title} — {location}
━━━ RECOMMENDATION ━━━
Status: {GO | ITERATE}
Reason: {rationale — if ITERATE, list HIGH findings that must be resolved}
━━━ ACTION ITEMS ━━━
Before proceeding:
1. {fix for HIGH finding F-1}
2. {fix for HIGH finding F-2}
Post-gate (tracked):
3. {fix for MEDIUM finding F-3}
━━━ DECISION REQUIRED ━━━
{standard decision prompt}
For each gate, present a checklist with checkmarks:
=== DISCOVERY GATE CHECKLIST ===
Document Completeness:
✓ project-context.md present and filled (X% complete)
✓ product-vision.md present and filled (X% complete)
Validation Checks:
✓ No SST violations
✓ No unresolved TODOs
Stakeholder Alignment:
? Have key stakeholders reviewed vision? (user input)
? Are constraints documented and accepted? (user input)
Status: [GO / ITERATE / NO-GO]
At the end of each gate, present these options:
| Decision | Effect | Next Phase |
|---|---|---|
| GO | Approve phase completion, proceed | Next phase (e.g., Planning → Design) |
| ITERATE | Return to current phase, address feedback | Repeat current phase |
| NO-GO | Phase failed, major issues found | Reassess project or kill project |
| DESCOPE | Remove features/scope (Planning/Implementation gates only) | Reduce scope, re-validate |
| REDESIGN | Major redesign needed (Implementation Readiness only) | Return to Design phase |
Present the gate results to the user in an interactive session:
╔════════════════════════════════════════════════════════════════╗
║ DISCOVERY GATE VALIDATION REPORT ║
╚════════════════════════════════════════════════════════════════╝
Timestamp: 2026-03-14 10:30:00 UTC
Phase: Discovery
Scope: docs/ets/projects/{project-slug}/
━━━ DOCUMENT COMPLETENESS ━━━
✓ project-context.md: 100% (all sections filled)
✓ product-vision.md: 95% (1 section has [TODO])
━━━ VALIDATION CHECKS ━━━
✓ SST compliance: No violations
✓ No unresolved TODOs
━━━ RECOMMENDATION ━━━
Status: GO ✓
Reason: Vision and constraints are clear. Team alignment confirmed in standup.
━━━ DECISION REQUIRED ━━━
Ready to proceed to Planning Phase?
Options:
1. GO — Approve phase, proceed to Planning
2. ITERATE — Return to Discovery, address feedback
3. NO-GO — Major issues, kill project
Enter decision (1/2/3) or explanation:
state/reports/gate-log.md for audit trail)state/reports/gate-log.md for traceabilitydocs/ets/projects/{project-slug}/.guides/gate-checklists.md — Detailed checklists for all 3 gatesdocs/ets/projects/{project-slug}/state/reports/gate-log.md — Append gate decision recordThis skill requires a phase argument to validate:
discovery, planning, design, implementationdocs/ets/.memory/project-state.md → Current phase (primary)state/workflow-state.yaml (secondary)The output is a gate recommendation. Validate:
$ARGUMENTS → docs/ets/.memory/project-state.md → state/workflow-state.yaml (in this order)project-state.md for Current phase and Current mode — this is the most reliable source since it is auto-updated by hook on every document save.check-sst and check-traceability skillsstate/reports/| Error | Severity | Recovery | Fallback |
|---|---|---|---|
| Phase not specified and no phase.json | Medium | Ask user which phase | Default to earliest incomplete phase |
| Expected documents all missing | High | Recommend: "Phase not started yet" | Suggest running the phase first |
| check-sst or check-traceability fails | Medium | Report partial results | Note which validation couldn't run |
| Output validation fails | High | Mark gate as ITERATE | Don't allow GO with incomplete validation |