Scope Guard

You are about to build something. This skill reads the spec, splits it into requirements, and checks each one against the product insights your customers have already given you. It ends by telling you what to change about the spec, not just what customers said.

Usage

/closedloop-scope-guard check this spec against customer evidence: <paste your PRD>
/closedloop-scope-guard does anyone actually want the things in ENG-1204?
/closedloop-scope-guard we're about to build tiered export permissions. Is that grounded?

Paste a spec, a PRD, a ticket, or a plain description of what is about to be built. A file path works too.

What You Get

Your spec, split into numbered requirements: shown back to you first, so you can correct the split before anything is checked against it
A coverage verdict per requirement: covered, partly covered, or not covered, decided by reading the matched themes rather than by a similarity score
Evidence attributed to the theme it came from: insight count, customer count, deal blockers, and verbatim quotes with names and dates, one block per matched theme
Rejected matches, out loud: which themes were discarded and why, so you can disagree with a specific line instead of the whole report
What the spec misses: needs customers raised in this area that no requirement covers
A “what to change” section: one imperative verdict per requirement, each grounded in a quote you can read

The Six Verdicts

Verdict	What it means
Sharpen	The evidence describes the need more precisely than the requirement does. Here are the words to change.
Split	The evidence describes two mechanics that would be built and tested separately.
Merge	Customers describe two of your requirements as steps in one workflow.
Add	Customers raised a need in this area that no requirement covers.
No evidence	Nothing in the feedback describes this requirement.
Build as written	Covered, precise, nothing to change.

Design Principles

Read only. The skill never writes anything, never edits a spec, and never touches your roadmap. Never “do not build this”. A requirement with no evidence may be a compliance need, a platform bet, or something nobody has been asked about. Support channels are where people report what is broken, not where they ask for what they are contractually required to have. The build decision stays yours. Every number sits under a theme name. One requirement routinely matches several different needs, so there is no single requirement-level total to quote. Reject a theme and its line simply drops. A verdict must quote its evidence. “Sharpen this” with nothing under it is an opinion.

MCP

Claude Code Skills

For product

For engineering

For sales

For marketing

For leadership

For customer success

For everyone

Usage

What You Get

The Six Verdicts

Design Principles

​Usage

​What You Get

​The Six Verdicts

​Design Principles

Usage

What You Get

The Six Verdicts

Design Principles