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.Documentation Index
Fetch the complete documentation index at: https://docs.pincites.com/llms.txt
Use this file to discover all available pages before exploring further.
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:Include Placement Hints
If the AI adds clauses in wrong places, guide it:Use Negative Scoping
Tell the AI what’s out of scope for this specific rule:Writing Redlining Guidance
Provide Exact Language When Possible
If you have standard fallback language, include it:Describe the Concept When Flexibility is Needed
Sometimes you want the AI to adapt to context:Specify the Style of Edit
Tell the AI how to make changes:Include Conditional Logic
Use if-then patterns for different scenarios:Writing Comment Guidance
Remember It’s a Prompt, Not the Comment
Don’t write the exact comment. Write instructions for creating comments:Include Tone Instructions
Specify how the comment should sound:Add Escalation Language
Include when something needs human review: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
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:The Requirement Rule
Ensures something essential is included:The Threshold Rule
Triggers action at certain 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