> ## 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.

# Prompts

> MCP prompts are slash commands the server ships to your agent. Right now there is one: prd, which writes a PRD from real customer evidence.

Tools are what your agent calls. **Prompts are what you call.** The ClosedLoop AI MCP ships them as slash commands, so they show up in your agent alongside everything else you type.

There is one today.

## `prd`

You need a PRD and the evidence is spread across four hundred calls nobody has time to re-read.

```
/closedloop-ai:prd calendar management
```

The command takes one argument, the feature or topic. It appears under whatever you named the connection when you added the MCP, so if you followed the [setup guide](/docs/mcp-server/overview) that is `closedloop-ai`.

## What comes back

It pulls the clustered problems and then the individual quotes behind them, and writes a lean PRD framed as a job to be done:

* **A JTBD statement** in one fixed shape: *when I \[situation], but \[barrier], help me \[goal], so I \[outcome]*. The goal describes what the customer wants rather than the thing you would build, and the sharpest verbatim quote sits under it
* **Job stories**, one per distinct use case in the evidence, each naming the customers behind it
* **The demand signal**: how many customers raised it, flagged with deal blockers and churn where they exist
* **Current alternatives**: what customers hire today instead, taken from what they described as their workaround, and why each one fails them
* **Proposed solution**, held to the minimum the job stories actually require, with a line on what you are not building in order to build it
* **What we're not doing**: the scoping calls a teammate would otherwise assume were in scope
* **Success metrics**, one per outcome, and only things an engineer can instrument. No surveys.
* **A falsifiable hypothesis**: what confirms the bet, what forces a rescope, and what tells you the assumption was wrong
* **Open questions**, limited to ones whose answer changes what you build

## Every claim traces to evidence

The prompt's standing instruction is that requirements come from the evidence and nowhere else. A PRD it writes for a feature nobody has mentioned will be thin, and that thinness is the answer.

Pair it with [Spec](/docs/skills/spec), which takes the same evidence and your codebase and produces the technical design. If you run both, the demand-signal numbers in the spec are expected to match the PRD exactly.