# Fewshot Attempt 01 > M&A Deal Workbench Review Skill - Skill: `prism-shadow/fewshot-attempt-01-47` (Agent Skill) - Install (CLI): `npx skillmds@latest add prism-shadow/fewshot-attempt-01-47` - Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/fewshot-attempt-01-47/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: prism-shadow (https://skillmd.com/u/prism-shadow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/prism-shadow/fewshot-attempt-01-47 --- # M&A Deal Workbench Review Skill ## Overview This skill provides a reusable workflow for reviewing M&A transaction records using a deal workbench REST API. It covers seller-side and buyer-side deal review, committee escalation, carveout transition review, and deviation matrices across asset purchases, stock purchases, and mergers. ## Environment The deal workbench is a running REST API. Its base URL is provided as `` in task prompts (typically `http://task-env:9020/`). A read-only SQL endpoint is available at `POST /api/query` with bearer token `deal-workbench-readonly`. All GET endpoints are unauthenticated. ### Available API Endpoints **Deal-level records:** - `GET /api/deals/` — deal metadata, headline purchase price, parties, structure - `GET /api/deals//terms` — current draft agreement terms - `GET /api/deals//documents` — agreement documents and exhibits - `GET /api/deals//benchmarks` — market benchmark data for terms - `GET /api/deals//risk-estimates` — quantified risk estimates - `GET /api/deals//cap-table` — capitalization table (stock deals) - `GET /api/deals//consents` — third-party consent requirements - `GET /api/deals//employees` — employee data, counts, PTO liability - `GET /api/deals//material-contracts` — material customer/supplier contracts - `GET /api/deals//regulatory` — HSR, antitrust, and other regulatory facts - `GET /api/deals//diligence-findings` — diligence findings and flags - `GET /api/deals//notes` — deal team and negotiation notes **Reference data:** - `GET /api/playbooks` — list available playbooks - `GET /api/playbooks//rules` — playbook rules (preferred and fallback positions) - `GET /api/policies` — list available policies - `GET /api/policies//thresholds` — policy thresholds for committee approval - `GET /api/search` — search across records (use sparingly) **Cross-table queries:** - `POST /api/query` — read-only SQL. Send `{"token": "deal-workbench-readonly", "query": ""}`. Use for cross-table checks when a single endpoint is insufficient. ### Web UI fallback The workbench also has a web UI at the base URL. You may browse `/workspace` to navigate deal records visually if the API alone is insufficient, but prefer the API for structured data extraction. ## General Workflow ### Phase 1 — Gather Records 1. **Identify the deal, your client side (buyer/seller), and the applicable playbook or policy** from the task prompt. 2. **Fetch the deal record** (`GET /api/deals/`) to extract: - Headline purchase price (the basis for all dollar calculations) - Deal structure (asset purchase, stock purchase, merger) - Counterparty names and key dates 3. **Fetch draft terms** (`GET /api/deals//terms`) — these are the current draft agreement provisions. 4. **Fetch the playbook or policy rules** — the source of truth for your client's positions: - For playbook-driven reviews: `GET /api/playbooks//rules` - For policy/committee reviews: `GET /api/policies//thresholds` 5. **Fetch all supporting records** relevant to the task scope. At minimum: - Risk estimates (`/risk-estimates`) - Consents (`/consents`) — identify closing conditions and amounts at risk - Regulatory (`/regulatory`) — HSR status, thresholds, hell-or-high-water - For stock deals: cap table (`/cap-table`) - For employment issues: employees (`/employees`) — counts, PTO liability, service credit needs - For material contracts: material-contracts (`/material-contracts`) — revenue at risk - For diligence-backed issues: diligence-findings (`/diligence-findings`) - For benchmark comparisons: benchmarks (`/benchmarks`) - For deal-team context: notes (`/notes`) and documents (`/documents`) ### Phase 2 — Compare Draft vs. Playbook/Policy For each relevant term category, compare the **draft value** against the **playbook preferred** and **playbook fallback** (or **policy threshold**) values: 1. **Draft exceeds playbook** — the draft is worse for your client than the fallback. Flag as an issue with `recommended_action: "revise"`. 2. **Draft below playbook** — the draft is better than the fallback but below preferred. If the delta is material, flag with `recommended_action: "revise"` or `"add"` to seek improvement. 3. **Missing required term** — no draft term exists but the playbook/policy requires an affirmative provision. Flag with `recommended_action: "add"`. 4. **In policy** — the draft is within acceptable bounds. Mark accordingly; exclude from escalations unless the task asks for full registers. **Critical rule**: Treat absent seller-protective or buyer-protective terms as issues when the surrounding deal data shows the term is needed (e.g., HSR is required but no HSR condition exists in the draft). ### Phase 3 — Calculate Quantified Impacts All dollar calculations flow from the headline purchase price unless a specific record (risk estimate, consent record, employee data) states a different basis. **Standard calculation rules:** - **Currency**: Integer dollars (no cents). Round to nearest integer. - **Percentages**: Follow the answer template's precision. Common conventions: - Percent points to two decimal places for policy comparisons - Percent points to one decimal place for economics summaries - Whole percent points for transition reviews - Holder percentages to four decimals for cap-table allocations - **Months**: Integer values. - **Dates**: `YYYY-MM-DD` format. - **Dollar amounts from percent**: `headline_value × (percent / 100)`, rounded to integer. - **Delta amounts**: `draft_amount - fallback_amount` or `fallback_amount - draft_amount` depending on whether the draft is above or below the desired position. The delta should represent how much the draft deviates from the fallback. **Stable IDs**: Always use the exact IDs from the workbench records (term IDs, consent IDs, contract IDs, risk estimate IDs, employee IDs). Never invent IDs. Use empty arrays `[]` for source fields when a term is missing from the draft. ### Phase 4 — Prioritize and Summarize **Priority ordering** — rank issues from highest negotiation priority to lowest. General heuristics: - Closing certainty issues (financing conditions, reverse break fees, HSR, regulatory) typically rank highest. - Economics (escrow, indemnity caps) come next. - Employee/operational continuity follows. - Governance (governing law, tax allocation) typically rank lower. - Within a tier, prefer higher risk rating and larger quantified exposure. **Summary metrics** — aggregate across all issues: - Count issues by risk rating (HIGH, MEDIUM, LOW) - Sum quantified exposures (low and high estimates) - Count required closing consents, employees, PTO liability - Compute total negotiation delta across all issues ### Phase 5 — Produce the Answer 1. **Read the answer template** from `input/payloads/answer_template.json`. It defines the exact JSON shape, allowed enums, and required fields. 2. **Fill every required field** per the template. Use `null` only where the template explicitly allows it and the value is genuinely unavailable. 3. **Use allowed enums exactly** as spelled in the template. Do not invent new enum values. 4. **Return only JSON** — no explanatory prose, no markdown fences unless the task explicitly permits them. The response must be parseable as a single JSON object. 5. **Sort arrays** as the template instructs (typically by stable ID or by priority rank). ## Task-Type Specific Guidance ### Seller-Side APA Issue Register (buyer-drafted paper) - Compare buyer draft against seller playbook rules. - Issue categories typically include: financing conditions, reverse break fees, escrow (percent, amount, release months), indemnity cap and basket, survival periods, non-compete/non-solicit, employee continuity, transition services, tax allocation, governing law/forum, consent conditions, materiality scrape, HSR covenants. - For each issue provide: source term IDs, business outcome, issue status, risk rating, recommended action, required position code, and all applicable draft/playbook/delta values. - Dollar amounts derived from headline purchase price. ### Buyer-Side SPA Closing & Economics Package - Cover economics (headline value, upfront cash, stock, milestones), holder-level allocation from cap table, indemnity package (cap, survival, materiality scrape), escrow (basis, amount, release), NWC adjustment. - Identify closing conditions: required consents, material-contract conditions, non-blocking notices. - Cover employment covenants (service credit, PTO, WARN risk), restrictive covenants, D&O tail and transaction expenses. - Assess regulatory: HSR required, threshold basis, hell-or-high-water. - Produce closing readiness assessment: overall status, risk rating, blockers vs. tradeable issues. ### M&A Committee Escalation Package - Read the committee policy thresholds first — they define what needs escalation. - Only escalate terms that are **out of policy**. Exclude in-policy terms (list them in the excluded section). - For each escalated term: provide draft metric, policy metric, delta, benchmark comparison (median, upper quartile, position), quantified exposure (low/high), recommendation, and required conditions. - Categories typically include: reverse termination fee, fiduciary out, rep & warranty survival, MAE carveouts. - Aggregate summary includes risk counts, total quantified exposure, excess RTF amount, overall recommendation, committee action text, and negotiation priority. ### Carveout APA Transition Review - Focus on transition and separation terms specific to carveout deals. - Key categories: IP/domain transition (trademark license, domain redirect), TSA scope/duration/fees, Section 1060 purchase-price allocation, transfer-tax split, employee continuity (field/operations), customer consent conditions, closing deadline/outside date extensions, governing law/forum. - For each transition issue: normalize draft values and required positions into comparable shapes. - Provide required redlines linked to issues, each with redline action and must-have terms. - Summarize operational risk: overall posture, quantified exposures (stranded costs, PTO, consent amounts at risk, revenue at risk, disruption estimates), required closing consent IDs, business outcomes protected. ### SPA Deviation Matrix (Buyer-Side) - Compare each position category against buyer playbook. - For each issue: source term IDs, status, risk rating, recommended action, final position (from template enum), priority rank. - Track: draft vs. preferred vs. fallback percents, months, amounts, shortfalls. - Special fields: basket status, knowledge qualifier status, escrow agent status, release status (found/not_found/not_applicable). - Identify closing blockers: consent blockers, regulatory blockers, material-contract blockers — each with blocker type, risk rating, amounts at risk, annual revenue, required action. - Risk totals aggregate: headline purchase price, issue counts by status, closing blocker count, consent amount at risk, contract revenue requiring consent, indemnity cap shortfalls, modeled exposure range, highest exposure category. ## Common Pitfalls to Avoid 1. **Wrong purchase-price basis**: Always use the headline purchase price from the deal record for percent-to-dollar conversions unless a specific record states otherwise. 2. **Inventing IDs**: Never fabricate term, consent, contract, employee, or risk-estimate IDs. Pull them directly from workbench records. 3. **Silent omissions**: If the task asks for all issues of a certain type, produce them all — don't skip low-risk or in-policy items unless the template explicitly says to exclude them. 4. **Enum mismatches**: Match allowed enum values exactly as spelled in the answer template. Case and underscores matter. 5. **Unit errors**: Confirm the template's required precision for percentages. Some ask for two decimal places, some for one, some for whole points. 6. **Extra-text contamination**: Return only the JSON object. No markdown fences, no preamble, no "Here is the answer" — unless the task prompt explicitly allows narrative. 7. **Cross-deal contamination**: Do not assume records from one deal apply to another. Each deal has its own isolated data. 8. **Overlooking missing terms**: A term missing from the draft is itself an issue when the playbook/policy/transaction facts require it. Flag it with empty `source_term_ids` and status `missing_required_term`.