shipshitdev/prd-quality-gate
bundles/dev-loop/skills/prd-quality-gate/SKILL.md
PRD completeness validation. Use to check that a PRD (or issue body that serves as one) contains the required sections before it is handed to a planning/execution agent, so the plan is built from a complete spec instead of hallucinated scope. Run it as a blocking gate or a warning-only lint.
$ install --global
skillsauthnpx skillsauth add shipshitdev/library prd-quality-gateInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Aug 20, 2026, 3:14 AM26.9s2 files scanned
SKILL.md
- name:
- prd-quality-gate
- description:
- PRD completeness validation. Use to check that a PRD (or issue body that serves as one) contains the required sections before it is handed to a planning/execution agent, so the plan is built from a complete spec instead of hallucinated scope. Run it as a blocking gate or a warning-only lint.
- version:
- 1.1.0
- tags:
- prd, planning, validation, quality-gate, spec, requirements, ears
<prd_quality_gate> A well-formed PRD (or the issue body that serves as one) must contain ALL of the following sections as markdown headings (## or ###).
Required sections:
- Executive Summary
- Problem Statement
- Goals
- Functional Requirements
- Acceptance Criteria
- Verification Plan
Acceptance Criteria must be written in EARS (Easy Approach to Requirements Syntax) so each bullet is machine-checkable and pass/fail without judgement. Every bullet under Acceptance Criteria must match one of:
- WHEN <trigger> THE SYSTEM SHALL <response> (event-driven)
- WHILE <state> THE SYSTEM SHALL <response> (state-driven)
- WHERE <feature> THE SYSTEM SHALL <response> (optional feature)
- IF <condition> THEN THE SYSTEM SHALL <response> (unwanted behavior)
- THE SYSTEM SHALL <invariant> (ubiquitous)
A bullet that does not match this grammar (case-insensitive regex
^\s*(\d+\.\s*)?(WHEN|WHILE|WHERE|IF|THE SYSTEM)\b.*\bSHALL\b) is free-form
prose, not a verifiable criterion.
When the quality gate is ENABLED (blocking):
- Missing any required section → fail immediately with an actionable message listing the missing sections.
- Any Acceptance Criteria bullet that is not EARS-shaped → fail, quoting each offending bullet and the EARS pattern it should take.
- The author must update the PRD and re-run the gate before planning proceeds.
When the quality gate is DISABLED (default, warning-only):
- Missing sections → log a warning.
- Non-EARS Acceptance Criteria bullets → log a warning listing each offending bullet.
- Planning proceeds. The planner should still note the gaps in its output.
Section matching is case-insensitive against ## and ### headings. Exact heading text must appear (e.g. "## Executive Summary" or "### Goals"). Headings nested inside code fences are ignored by convention (they are examples, not structure). </prd_quality_gate>
Related Skills
shipshitdev/weekly-review
development
VerifiedTrustedCommunity
Coordinates a weekly engineering review of board accuracy, recent code changes, operational health, and scoped cleanup. Use for a recurring repository health review or a review of the last several days.
35SKILL.mdUpdated Sep 6, 2026
shipshitdev/project-board
testing
VerifiedTrustedCommunity
Audits project board configuration and prepares explicitly requested setup, copy, or normalization changes while preserving the existing workflow and provider boundaries. Use when inspecting a board's fields, columns, scope, or configuration.
35SKILL.mdUpdated Sep 6, 2026
shipshitdev/board-sync
testing
VerifiedTrustedCommunity
Reconciles a project board with current work and delivery evidence, reports incomplete coverage and metadata gaps, and applies only approved provider-supported field changes. Use when auditing board drift, reviewing blocked work, or assessing upcoming delivery.
35SKILL.mdUpdated Sep 6, 2026
shipshitdev/how
development
VerifiedTrustedCommunity
Walk through how a subsystem works. Use for "how does X work", code walkthroughs before changing something, and placement or ownership questions. Explains architecture, runtime flow, and onboarding mental models. Can critique architecture. Use why for motivation.
35SKILL.mdUpdated Aug 31, 2026