/win-loss-review

name: win-loss-review
description: >
  Explain why a closed monday CRM deal was won or lost. Reads the deal's stage history, Emails & Activities timeline, notes and column changes, compares it with other closed deals on the same board, and writes a short evidence-based review. Use when someone asks "why did we win/lose Acme", "win-loss review for this deal", "closed-lost analysis", "what was the loss reason really", "what went wrong with this deal", "post-mortem on this opportunity" or "what can we learn from this closed deal". Works on one closed deal at a time. Not for open deals (offer daily-briefing on the board instead).
argument-hint: "[closed deal name or link — 'why did we lose Acme', 'win-loss review for this deal']"
user-invocable: true
allowed-tools: [Read, AskUserQuestion, mcp__plugin_monday-crm_monday__get_user_context, mcp__plugin_monday-crm_monday__search, mcp__plugin_monday-crm_monday__get_board_info, mcp__plugin_monday-crm_monday__get_column_type_info, mcp__plugin_monday-crm_monday__get_board_items_page, mcp__plugin_monday-crm_monday__get_board_activity, mcp__plugin_monday-crm_monday__get-timeline-items, mcp__plugin_monday-crm_monday__get-custom-activities, mcp__plugin_monday-crm_monday__extract_signals, mcp__plugin_monday-crm_monday__get_updates, mcp__plugin_monday-crm_monday__search_meetings_content, mcp__plugin_monday-crm_monday__get_meetings_content, mcp__plugin_monday-crm_monday__change_item_column_values, mcp__plugin_monday-crm_monday__update_items, mcp__plugin_monday-crm_monday__create_column, mcp__plugin_monday-crm_monday__create_doc, mcp__plugin_monday-crm_monday__get_asset_upload_url, mcp__plugin_monday-crm_monday__finalize_asset_upload]

Win / loss review

Produce an evidence-based explanation of why one closed deal was won or lost. Every claim must point to something you read. If the evidence is thin, say so instead of guessing.

0. Rules

• Connector check first: call `get_user_context`. On error, tell the user to install and connect the monday MCP connector, and stop.
• Reading is free. Writing (board columns, new columns, files, docs) happens only after the user confirms the exact values (step 7c). The recommended path is to save the result on the deal item, so offer it once, clearly, and do not nag.
• Never assume board, column or label names. Discover them (step 2).
• Never invent a reason. People act on these reviews, so a finding needs at least one cited data point (a stage change, an email, a note, a number).
• Mark the deal outcome from the data, not from the user's wording, and tell the user if they differ.
• One deal per run. If the user asks for several, run them one after another and keep each result separate. Do not write one deal's data into another item.

1. Ask the first-run questions (once per conversation, after the deal is confirmed closed)

First run step 2 (find the deal and confirm it is Won or Lost). Then ask both questions in one message with `AskUserQuestion`, skipping any the user already answered or said "always" or "never" about, and remember the answers.

1. **Depth:** "Short analysis or deep analysis?"

• **Short (default):** bottom line, key facts, do-next-time.
• **Deep:** adds the full stage timeline, week-by-week activity, ranked drivers with dated evidence and a full comparison with other closed deals.

2. **Board update (recommended):** "Should I save the result on the deal item in monday, so the review stays with the deal and your team can see and report on it?" Options: yes (recommended), or no (chat and artifact only).

If the user is unsure, recommend yes and short. Do not start the heavy reads (steps 3 to 5) until depth is answered.

2. Find the deal and the board structure

1. Resolve the deal: item link, or search by name. If several match, list them (name, owner, value, stage) and ask which one. 2. Call `get_board_info` (columns only) for the deal's board. Identify by column type, not by title:

• Stage: the status column used for the pipeline (labels like New, Discovery, Proposal, Negotiation, Won, Lost).
• Owner: people column. Value: numbers column. Expected close date: date column. Close probability, last interaction date, loss reason (dropdown or status) if present.
• Contacts and accounts: board-relation column.
• Activities timeline: a column of type `unsupported`. It cannot be read as a column value. Use the timeline tool.
• A long text column, if the user wants to write there (step 7c).

3. Confirm the outcome: current stage label (Won or Lost) and group (for example "Closed Won"). Classify unusual endings explicitly: "no decision" or "went dark" is a loss, a deal that was reopened is judged by its latest close, and a deal won and later churned is judged on the win only (mention the churn). 4. If the deal is not closed, stop and tell the user a post-mortem needs a closed deal. Offer to review it once it closes, or to run `daily-briefing` on the board instead.

3. Read the stage history

Call `get_board_activity` with the board id, `itemIds` set to the deal, `includeData: true` and a `fromDate` early enough to cover the deal's creation (use the item's `created_at`, or one year back). `get_board_activity` has no paging: if the response looks cut off, split the range into smaller `fromDate` / `toDate` windows. Stop at about 300 events; if there are more, say the history is truncated.

From the events, build an ordered list of stage changes:

• `update_column_value` events on the stage column. `previous_value.label.text` is the old label, `value.label.text` the new one.
• `move_pulse_from_group` events for group moves (for example Active Deals to Closed Won).
• `create_pulse` for creation and its source (form, import, manual).
• Owner changes (`update_column_value` on the people column).
• Changes to value, expected close date and close probability.

The `created_at` field on events is a 17-digit monday timestamp. Divide by 10,000,000 to get Unix seconds. If the response