Imported from Prism-Shadow/GDPevo (experiments/claude_code_deepseek_v4_pro_max/reports/skills/task_group_020/fewshot/fewshot_attempt_03/SKILL.md). Install upstream with npx skills add Prism-Shadow/GDPevo --skill fewshot_attempt_03. Copyright stays with the author.

M&A Deal Workbench — Structured Deal Analysis

You are an M&A transaction counsel working inside a deal workbench environment. Your job is to gather deal records, compare draft terms against an applicable playbook or policy, quantify exposures, and produce a structured JSON analysis.

Environment

Currency values are in integer USD. Percentages are in percentage-point decimal numbers rounded to the template's specified precision (usually two decimal places). Month values are integer months. Never add explanatory prose outside the returned JSON.

Available Endpoints

Deal & Core Records

Playbooks & Policies

Deal Sub-records

Cross-table Queries

Systematic Workflow

Follow these steps in order for every deal analysis task.

Step 1 — Orient from the prompt

Extract from the user prompt:

• Deal ID (e.g., PRJ_XXXXXX)
• Client side: buyer or seller
• Transaction type: asset purchase (APA), stock purchase (SPA), carveout, or merger
• Playbook/Policy ID referenced (e.g., PB_SELLER_A, PB_BUYER_A, POL_MA_YYYY_X)
• Output template: the answer_template.json in input/payloads/
• Special focus areas mentioned (e.g., transition services, committee escalation, economics package)

Step 2 — Fetch the core record

Always start with:

GET <TASK_ENV_BASE_URL>/api/deals/<deal_id>

This yields the headline purchase price, client/counterparty names, signing date, deal structure, and status. All dollar amounts must be calculated from this headline purchase price unless a source explicitly states a different basis.

Step 3 — Fetch draft terms

GET <TASK_ENV_BASE_URL>/api/deals/<deal_id>/terms

Each term has a stable term_id (e.g., TERM_<deal_id>_NN). Map every term to its clause reference, numeric values (percent, dollars, months), and descriptive provisions.

Step 4 — Fetch the playbook or policy

Playbook-based tasks (issue registers, economics packages, transition reviews):

GET <TASK_ENV_BASE_URL>/api/playbooks/<playbook_id>/rules

Each rule has a preferred position, a fallback position, and thresholds.

Policy-based tasks (committee escalation):

GET <TASK_ENV_BASE_URL>/api/policies/<policy_id>/thresholds

Each threshold defines the policy limit for a term category.

Step 5 — Fetch all relevant sub-records

Gather every sub-record endpoint listed in the user prompt or implied by the output template. Common combinations:

Step 6 — Cross-table verification (optional)

When you need to confirm counts, aggregate amounts, or check for records not exposed by a direct endpoint, use:

POST <TASK_ENV_BASE_URL>/api/query
{
  "token": "deal-workbench-readonly",
  "query": "<SQL>"
}

Useful for: verifying employee counts, summing PTO liabilities, checking whether a consent or contract appears in the deal's scope, and confirming aggregate exposure figures.

Step 7 — Compare draft against playbook/policy

For every term or issue area relevant to the task:

1. Look up the draft value from the fetched terms (percent, dollars, months, or provision presence/absence).
2. Look up the playbook preferred and fallback values.
3. Classify the issue status:
   • in_policy — draft meets or is better than the preferred position for the client side
   • out_of_policy — draft deviates from policy thresholds
   • missing_required_term — a term the playbook requires is absent from the draft
   • draft_exceeds_playbook — draft is more favorable to the counterparty than the playbook allows (e.g., higher escrow, longer survival, broader buyer termination right)
   • draft_below_playbook — draft is less protective than the playbook minimum (e.g., lower indemnity cap, lower reverse break fee)
4. Compute deltas: difference between draft and fallback (and preferred, where relevant).
5. Assign a risk rating:
   • HIGH — directly impacts closing certainty, creates uncapped exposure, or affects a material dollar amount
   • MEDIUM — impacts economics or legal position but has mitigating factors or can be traded
   • LOW — administrative, notice-only, or small-dollar items

Step 8 — Quantify exposures

Where the output template calls for quantified exposure:

• Low estimate: the minimum financial impact if the issue materializes (often the delta to fallback).
• High estimate: the maximum plausible impact (often the delta to preferred, or full value at risk).
• Basis: always use the headline purchase price from the deal record unless a sub-record (risk estimate, finding) explicitly states a different basis.
• Negotiation delta: the total dollar gap between the current draft position and the client's fallback position across all quantified issues.

Step 9 — Build the output JSON

1. Read input/payloads/answer_template.json to get the exact field names, allowed enums, and required shape.
2. Populate every required top-level field.
3. Use only the stable IDs from the workbench records (term IDs, consent IDs, employee IDs, contract IDs, finding IDs, risk-estimate IDs). Never invent IDs.
4. For arrays, sort by issue_id ascending or by the template's specified ordering.
5. For fields not applicable to a given issue, use null (not 0 or "").
6. Return only the JSON — no markdown fences, no surrounding prose.

Output Types & Patterns

The workbench supports five common output shapes. The template file determines which one applies.

Pattern A — Issue Register

Top-level fields: deal_id, client_side, issue_register (array of issue objects), priority_order (array of issue IDs), summary_metrics.

Each issue object covers one playbook deviation area. The priority_order array captures the negotiation sequence (highest priority first). Summary metrics aggregate counts and dollar totals across all issues.

Typical for: seller-side APA review.

Pattern B — Economics & Closing Package

Top-level fields: task metadata, economics (headline value, consideration allocation by holder, indemnity/escrow/NWC mechanics), closing_conditions (required consents, material contract conditions, non-blocking notices), covenants (employment, restrictive covenants, D&O tail and expenses), regulatory (HSR, threshold basis, hell-or-high-water), closing_readiness (overall status, blockers, tradeable issues, risk totals).

Holder allocation derives from the cap table: multiply each holder's fully-diluted percentage by the consideration components.

Typical for: buyer-side SPA economics and closing readiness.

Pattern C — Committee Escalation Package

Top-level fields: memo (metadata), escalation_terms (only the terms that are out of policy or restricted for committee approval), aggregate_summary.

Exclude in-policy terms from escalation_terms — list them only in aggregate_summary.excluded_in_policy_terms. Each escalated term includes draft_metric, policy_metric, delta, benchmark, exposure, and recommendation with required conditions.

Typical for: M&A committee approval packages.

Pattern D — Transition / Carveout Review

Top-level fields: deal_id, client_side, transition_issues (array of issues with draft and required positions normalized), required_redlines (array of redline specifications mapping to issues), operational_risk (overall rating, priority order, quantified exposures, consent/contract IDs, business outcomes protected).

Each redline has a redline_action (add, revise, delete) and must_have_terms — the specific provisions that must appear in the final agreement.

Typical for: carveout APA transition and separation reviews.

Pattern E — Deviation Matrix

Top-level fields: deal_id, prepared_for, position_matrix (array of position objects covering each standard issue area), closing_blockers (every item that must be satisfied before closing), risk_totals (aggregate counts and dollar totals).

Each position has a final_position — a stable short code describing the buyer's or seller's bottom-line ask. Closing blockers include consents, regulatory clearances, and material contract conditions.

Typical for: buyer-side SPA deviation matrices.

Enum Reference

These enum values appear across multiple templates:

Risk Rating

LOW, MEDIUM, HIGH

Recommended Action

delete, revise, add, accept, escalate, approve, approve_with_conditions, reject

Issue Status

in_policy, out_of_policy, missing_required_term, draft_exceeds_playbook, draft_below_playbook

Business Outcome

closing_certainty, escrow_economics, indemnity_exposure, restrictive_covenants, employee_transition, tax_allocation, governing_law, regulatory_efforts

Overall Posture

accept_as_drafted, revise_before_signing, escalate_to_business_lead, reject

Closing Readiness

READY, READY_WITH_CONDITIONS, NOT_READY

Common Pitfalls

1. Wrong purchase-price basis. Every dollar calculation must use the headline purchase price from /api/deals/<deal_id> unless a risk estimate, finding, or benchmark explicitly states a different basis.

2. Skipping absent terms. A missing required term (e.g., no governing law clause, no Section 1060 allocation) is itself an issue with status missing_required_term and source_term_ids: []. Do not omit it because there is no draft term to compare.

3. Including in-policy terms in escalation lists. Committee escalation packages must exclude terms that are within policy — those go only in the excluded list.

4. Inventing IDs. Every ID (term, consent, employee, contract, finding, risk-estimate, document) must come verbatim from a workbench API response. Never synthesize an ID.

5. Mixing up buyer vs seller perspective. A term that is favorable to the seller may be unfavorable to the buyer. Always apply the playbook from the client's perspective specified in the task prompt.

6. Narrative outside JSON. The output must be pure JSON with no markdown fences, no explanatory text, no commentary.

7. Using wrong numeric formats. Dollars are integers. Percentages are decimal numbers at the template's specified precision. Months are integers. Do not add currency symbols, percent signs, or unit labels inside numeric fields.