> ## Documentation Index
> Fetch the complete documentation index at: https://closedloop.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Scope Guard

> Check a spec, PRD, or ticket against what customers actually said before engineering time goes into it. Every requirement gets a verdict.

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.