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.