Skip to main content
Playbook prompting is different from ad-hoc prompting. When you write a playbook rule, you’re creating a reusable instruction that needs to work across many different contracts. The prompt must be specific enough to catch real issues but flexible enough to handle variations.

​
The three-part rule structure

Every playbook rule has three components that work as a mini workflow:

​
Part 1: The rule (issue spotting)

This tells the AI what to look for. It filters which clauses get attention.

​
Part 2: The action (redlining guidance)

This tells the AI what changes to make when it finds an issue.

​
Part 3: The comment (explanation)

This tells the AI how to explain the change to the counterparty. Each part builds on the previous one, creating a complete review process.

​
Writing effective rules

​
Be specific about what to flag

The rule acts as a filter. Too broad and it catches everything. Too narrow and it misses variations. Too broad: “Check for problematic payment terms” Too narrow: “Flag if payment terms exceed exactly 45 days” Just right: “Flag payment terms exceeding 30 days net, including any provisions that delay payment start date”

​
Use keywords that appear in contracts

Reference actual contract language rather than abstract concepts: 
Look for: "audit rights" "right to audit" "inspection rights" "review of records"
Not just: "oversight provisions"

​
Include placement hints

If the AI adds clauses in wrong places, guide it: 
This insurance requirement should follow other liability-related provisions like indemnification or limitation of liability

​
Use negative scoping

Tell the AI what’s out of scope for this specific rule: 
This rule covers on-site audits only. Ignore remote audits, document reviews, and financial audits.

​
Writing redlining guidance

​
Provide exact language when possible

If you have standard fallback language, include it: 
If missing, add: "Vendor's liability shall not exceed the fees paid in the twelve (12) months preceding the claim."

​
Describe the concept when flexibility is needed

Sometimes you want the AI to adapt to context: 
Limit audit rights to once per year during business hours with reasonable notice

​
Specify the style of edit

Tell the AI how to make changes: 
Add qualifiers like "commercially reasonable" rather than deleting
Insert as a separate subsection, not inline
Use strikethrough and brackets, not clean changes

​
Include conditional logic

Use if-then patterns for different scenarios: 
If customer is government entity: Accept standard federal audit rights
If commercial customer: Limit to annual audits
If startup: Push back entirely

​
Writing comment guidance

​
Remember it’s a prompt, not the comment

Don’t write the exact comment. Write instructions for creating comments: 
Explain this protects confidential information while allowing reasonable oversight

​
Include tone instructions

Specify how the comment should sound: 
Professional but firm. Emphasize business rationale, not legal theory.

​
Add escalation language

Include when something needs human review: 
If this is rejected, add comment: "Please escalate to legal team for discussion"

​
Modular rule design

​
Break complex issues into multiple rules

Instead of one giant liability rule, create separate rules for:
  • Liability caps
  • Liability exclusions
  • Super caps for certain claims
  • Mutual vs one-sided limitations
This makes rules reusable and easier to debug.

​
Create building blocks

Core concepts like confidentiality appear in many contracts. Write these rules once and reuse them:
  • NDA playbook → confidentiality rules
  • MSA playbook → includes same confidentiality rules
  • DPA playbook → includes same confidentiality rules

​
Test individual rules

When a rule isn’t working, you can test and fix it without affecting others.

​
Common playbook patterns

​
The protective rule

Prevents specific unfavorable terms: 
Rule: Must not require us to audit our subcontractors
Action: Delete or limit to providing existing documentation
Comment: We manage our vendor relationships independently

​
The requirement rule

Ensures something essential is included: 
Rule: Must include data breach notification timeline
Action: If missing, add "within 72 hours of discovery"
Comment: Industry standard for breach notification

​
The threshold rule

Triggers action at certain levels: 
Rule: Insurance requirements exceeding $5M
Action: Cap at $5M unless special circumstances
Comment: Aligns with our current coverage levels

​
Testing and refinement

​
Run rules against multiple contracts

Test each rule on 5-10 different contracts to ensure it:
  • Catches what it should
  • Doesn’t trigger false positives
  • Produces appropriate redlines
  • Generates useful comments

​
Watch for drift

Rules that work today might not work after model updates. If a rule starts failing consistently, it needs revision.

​
Check rule interactions

Sometimes rules conflict with each other. Test the full playbook, not just individual rules.

​
When playbooks work best

​
Ideal for:

  • Standardized agreements (NDAs, DPAs, BAAs)
  • Routine reviews with consistent positions
  • High-volume contract processing
  • Training consistency across team members

​
Less suitable for:

  • Highly negotiated custom agreements
  • Novel deal structures
  • Agreements where every term is negotiable
  • One-off strategic partnerships

​
The key insight

Playbook rules are different from regular prompts because they need to work reliably across many scenarios. They’re not just instructions – they’re codified expertise that scales your legal knowledge across every review. Think of each rule as training a permanent team member who will handle this specific issue the same way every time, across hundreds of contracts.

​
Remember

The goal isn’t to automate everything. It’s to automate the routine stuff so you can focus on what requires real legal judgment. Good playbook rules handle the 80% of issues that have standard responses, freeing you to tackle the 20% that need creativity and strategy.