> For the complete documentation index, see [llms.txt](https://help.jurisphere.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.jurisphere.ai/jurisphere-word-add-in/core-features/review-playbook.md).

# Review Playbook

What a Review Playbook is, how it differs from a Skill, when your team should build one and how the two step build once and run everywhere lifecycle works across the web app and the Word Add-In.

## Overview

A Review Playbook is how your team turns the way you *actually* negotiate contracts. Your ideal position on a clause, the fallbacks you'll live with, the language that should always get flagged - into something Jurisphere can apply automatically, every time, for every reviewer, on every matter of that type.&#x20;

### What a Review Playbook actually captures

Ordinarily, reviewing a standard agreement means starting from scratch every time. Re-deciding, clause by clause, what is acceptable, what needs pushback and what is a dealbreaker. A Review Playbook captures that judgment once, as a structured set of:

* **Ideal (starting) positions:** What you'd ask for if you could get exactly what you wanted on a given clause.
* **Acceptable fallbacks:** One or more positions you'd live with if the ideal position is not achievable, often ranked from most to least preferred.
* **Language that should always be flagged (dealbreaker):** Outcomes that are never acceptable, regardless of context.

Once built, a Playbook is created once on the Jurisphere web platform and can be reused across every matter of that contract type from then on, within the Word Add-In.

***

### When a Review Playbook is the right tool

<table data-view="cards"><thead><tr><th align="center"></th><th></th><th></th></tr></thead><tbody><tr><td align="center"><h4>Repetitive Contract Types</h4></td><td>MSAs, NDAs, leases, financing documents, etc. </td><td>Anything your team reviews often enough that reinventing the standard each time wastes effort.</td></tr><tr><td align="center"><h4>High Volume Review</h4></td><td>Where consistency across dozens or hundreds of agreements matters more than any single review being individually creative.</td><td></td></tr><tr><td align="center"><h4>Multi-level review structures</h4></td><td>Where juniors and seniors both touch the same contract type, and you want the same standard applied regardless of who's reviewing.</td><td></td></tr><tr><td align="center"><h4>Client specific positions</h4></td><td>Where a particular client or matter requires positions that deviate from the firm’s general standard and must be applied uniformly in their cases.</td><td></td></tr></tbody></table>

Playbooks are especially effective wherever the same clauses come up for negotiation again and again and the institutional knowledge of "what we actually accept" needs to travel reliably between people, rather than living in one senior lawyer's head.

***

## Review Playbook vs. Skill vs. a One off Question

All three can plausibly answer "is this document okay?" but they're built for different shapes of that question and knowing which one you're actually reaching for, saves time.

<table><thead><tr><th width="100.73175048828125"></th><th>One off Review Question</th><th>Skill</th><th>Review Playbook</th></tr></thead><tbody><tr><td><strong>Best for</strong></td><td>Something you only need to ask once or twice.</td><td>You want a consistent check or instruction run across many documents, without retyping it every time. The task being checked for is not specific to one contract type’s negotiated positions, just a repeatable task.</td><td>You’re dealing with a recurring contract type where your team has standard, ranked negotiating positions, not just ‘check for X’. They have specific demands, acceptable fallbacks and unacceptable terms.</td></tr><tr><td><strong>Typical output</strong></td><td>A grounded answer with citations.</td><td>Your format and style being retained with citations.</td><td>A clause-by-clause pass against your defined positions, with citations and deviations flagged.</td></tr><tr><td><strong>Examples</strong></td><td>You're reviewing a vendor contract and want to know: <em>"Does this indemnity clause exclude consequential damages and if so, for which party?"</em> You'll probably never need this exact question again on this exact clause and it's not worth building anything to answer it. Just ask, in <a href="/jurisphere-word-add-in/core-features/ask-juris/reviewing-documents.md">Reviewing Documents</a>.</td><td>You have a recurring, specific format - for example, flagging any clause that references a data processing obligation, so your privacy team can be looped in. You can create and use it as a Skill which is a fixed, repeatable prompt. See <a href="/workflows/creating-custom-skills.md">how to build one yourself</a>.</td><td>Your team reviews NDAs regularly and has a negotiated stance on confidentiality survival: ideally 5 years, acceptable down to 3 years for clients with less leverage and never below 1 year. A Skill can indicate a survival period or flag a short one, but it can’t natively encode specific numbers as acceptable or unacceptable based on a ranked structure. This structure exists only in a Review Playbook.</td></tr></tbody></table>

***

### The Two Step Process

{% stepper %}
{% step %}

### Build it once on the web platform

Define your positions, fallbacks and priorities for a given contract type. You can either do it by adding rules manually or by allowing Jurisphere to extract them from a precedent or policy document you already trust.

See [Building Review Playbooks](/jurisphere-word-add-in/core-features/review-playbook/building-review-playbooks.md) for the complete walkthrough, including the full anatomy of a rule and several worked examples across contract types.
{% endstep %}

{% step %}

### Run it on Jurisphere Word Add-In

Once built, run your Playbook against any open Word document from the **Review Playbooks** tab of the panel. Every matter of that contract type is subject to the same standard.

See [Running Review Playbooks](/jurisphere-word-add-in/core-features/review-playbook/running-review-playbooks.md) for the complete walkthrough, including how flagged deviations surface inline and what your options are for acting on each one.
{% endstep %}
{% endstepper %}

***

## What's next

<table data-view="cards"><thead><tr><th align="center"></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td align="center"><h4>Building Review Playbooks</h4></td><td>The full rule anatomy and worked examples, whether you build manually or generate from a document.</td><td><a href="/jurisphere-word-add-in/core-features/review-playbook/building-review-playbooks.md">Building Review Playbooks</a></td></tr><tr><td align="center"><h4>Running Review Playbooks</h4></td><td>Selecting a Playbook in Word, reading flagged deviations and acting on them.</td><td><a href="/jurisphere-word-add-in/core-features/review-playbook/running-review-playbooks.md">Running Review Playbooks</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.jurisphere.ai/jurisphere-word-add-in/core-features/review-playbook.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
