Update to monday CRM

{
  "description": "Daily prioritized CRM pipeline briefing. Reads the user's monday deals board, ranks deals by new activity, stall age, and commitments due today, then publishes a timestamped `Morning Briefing` update on a pinned item or a new doc in the user's workspace. Use when someone says \"what should I focus on today\", \"morning briefing\", \"what's hot in my pipeline\", \"what changed on my deals\", \"pipeline summary\", or any variation of a daily CRM digest.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 185
    },
    {
      "relative_path": "assets/icon.png",
      "size_in_bytes": 22022
    },
    {
      "relative_path": "examples/01-default-mode-admin.md",
      "size_in_bytes": 3972
    },
    {
      "relative_path": "examples/02-non-admin-fallback.md",
      "size_in_bytes": 5897
    },
    {
      "relative_path": "references/chat-only-briefing.md",
      "size_in_bytes": 5799
    },
    {
      "relative_path": "sample-output.md",
      "size_in_bytes": 2665
    }
  ],
  "name": "morning-briefing",
  "skill_md_contents": "---\nname: morning-briefing\ndescription: Daily prioritized CRM pipeline briefing. Reads the user's monday deals board, ranks deals by new activity, stall age, and commitments due today, then publishes a timestamped `Morning Briefing` update on a pinned item or a new doc in the user's workspace. Use when someone says \"what should I focus on today\", \"morning briefing\", \"what's hot in my pipeline\", \"what changed on my deals\", \"pipeline summary\", or any variation of a daily CRM digest.\n---\n\n# Morning Briefing\n\n> **Platform notes (ChatGPT and Codex).** Before any write, show the concrete action or batch and obtain explicit approval. Use only tools exposed in this session; if a named tool is missing, say so and stop that step. Use visible plain-text `monday-crm-skill-id: <skill>` markers; monday Docs can strip HTML comments. Read back newly created artifacts to verify their marker. Before creating, search within the relevant workspace and read candidate content; match title, skill marker, board or item, and date or period. Treat surviving legacy `<!-- monday-crm-skill-id: … -->` and `<!-- claude-skill-id: … -->` markers as matches. If a candidate has the right title and generated-by footer but lacks a marker, or matching is ambiguous or incomplete, do not create or update automatically: show the candidate and ask the user. If search or read-back is unavailable, stop the write. For meeting recaps also include and verify a visible `meeting-id: <id>` marker; if either marker is missing, do not infer a match or create a duplicate automatically.\n\nProduces a daily prioritized briefing over the user's monday CRM pipeline and **publishes it as a monday artifact** (update on a pinned item, or a doc in the user's workspace) so the briefing lives inside monday — not just in the chat. Replaces the five-minute \"let me scan my deals\" routine.\n\nFlow: **Trigger → Gather → Synthesize → Show draft → offer publication (α, opt-in) → Share (β, opt-in) → Proactive extension (opt-in)**.\n\n## Input\n- Optional: board name or ID from the user's request.\n- Optional: user pre-declared mode (Default / Silent / Proactive) via project instructions or one-shot prompt.\n\n## Output\n- **α (default):** A monday update on a pinned \"My Morning\" item OR a new doc in the user's personal workspace, titled `Morning Briefing — <weekday>, <Mon DD>`. Body carries the `Generated by monday CRM plugin` footer + a visible plain-text marker `monday-crm-skill-id: morning-briefing` for idempotency. Markdown brief printed in the chat as a mirror.\n- **β (Share mode):** Notification to manager + update on team-rollup board.\n- **Proactive extension:** Per-deal `create_update` on stalled deals; `create_notification` for commitments due today.\n\n## Knowledge\n- Bucket priority + criteria (§ Step 5 below).\n- Shared artifact conventions (§ Shared patterns at the bottom of this file).\n\n## Tools (MCP)\n- `get_user_context` — resolve user + favorite boards.\n- `list_workspaces` — enumerate workspaces when search is ambiguous.\n- `search` — find CRM boards matching `deals|opportunities|pipeline|leads`.\n- `get_board_info` — board schema + column IDs + labels.\n- `get_column_type_info` — resolve columns by type when names aren't English.\n- `get_board_items_page` — pull active deals, recently closed, recent activity.\n- `board_insights` — aggregate fallback when >200 active deals.\n- `create_update` — publish α to pinned item, post proactive nudges on stalled deals.\n- `create_doc` — publish α as a doc when no pinned item exists.\n- `create_notification` — β share to manager; proactive alert for commitments due today.\n- `list_users_and_teams` — resolve recipient for β share.\n- `read_docs` / `update_doc` — find and append to an existing same-day briefing doc. (No generic GraphQL tool is used; if a lookup isn't covered by a named tool, skip it and say so.)\n\n## Cross-skill handoffs\n- **From none (entry point):** User-initiated daily run.\n- **To forecast-dashboard:** If the briefing surfaces a \"forecast hygiene\" issue (missing close date or amount on non-closed deals), suggest the user run the `forecast-dashboard` skill for a structured view.\n- **To board-diagnosis:** If >30% of deals are unowned, or any bucket misses core fields, suggest the `board-diagnosis` skill.\n\n\n## Draft first, then offer publication\n\nUse available read-only tools to prepare the complete requested deliverable before asking to publish. Present it as a readable, editable artifact in the host when available; otherwise show the full draft in chat. A native monday dashboard or board cannot be created outside monday: present a concrete preview or blueprint, not a claim that it exists. State meaningful missing data or assumptions. Then ask once whether to publish the displayed draft to the specified monday destination; allow edits or decline. On decline, retain the draft and stop without monday writes. On approval, publish only the shown content and concrete actions the user approved. Separately describe and obtain approval for record edits, notifications, contacts, automations, or other actions not included in that publication. Do not ask to choose a mode before producing the draft; use read-only default behavior. Ask only for information essential to prepare a useful, accurate draft, and state reasonable defaults. This draft-first rule takes precedence over earlier or later mode and publish-first instructions.\n\n---\n\n\n\n## Offer a useful next step\n\nAt the end of a completed response, offer one specific, relevant next thing ChatGPT can do based on what is actually available: offer to investigate a priority deal or draft a follow-up based on the briefing. Ask whether the user wants that help; do not begin it before they respond. Do not repeat an existing unanswered question or make the offer when the task cannot continue because of a connection or permission failure. Do not promise capabilities, events, or results that have not been verified. Approval to explore or draft is not approval to publish, send, or change CRM data.\n\n## Step 0: Connector check\n\n**Goal:** Fail fast if the user has no monday MCP connection. No partial writes, no guessing.\n\n1. Try `get_user_context`.\n2. If the tool is missing, returns auth-style error, or the user has no accessible workspace:\n   - Print exactly: *\"I don't see the monday connector active on this session. Install it from https://monday.com/mcp, then run this skill again.\"*\n   - Stop. Do not proceed.\n3. If connector works, cache `user.id` and `user.name` for Step 7 artifact metadata.\n\n> **PAUSE**: do not write any `create_*` call before Step 6, and never before Step 0 passes.\n\n---\n\n## Step 1: Detect mode\n\nUse read-only default behavior while preparing the briefing. Do not ask for a mode. Offer proactive changes only after the briefing and obtain approval for their concrete scope.\n\nHard safety rail regardless of mode: **no deletes, no cross-workspace moves, no amount-column writes**. Stage, owner, last-touch, and source column edits are allowed when bundled in a batched-confirm plan (Default mode) with approval of the concrete batch in every mode.\n\n---\n\n## Step 2: Resolve the deals board (Gather)\n\n**Goal:** Land on a single `boardId` — or a confirmed set — before reading any deal data.\n\n1. If the user passed a board from the user's request:\n   - Numeric → use as `boardId` directly.\n   - String → `search` with `searchType: \"BOARD\"`, `searchTerm: <arg>`. If exactly one match, use it. If multiple, ask by asking the user (offer short numbered options).\n2. If the user didn't name a board:\n   - Call `get_user_context`. Scan `relevantBoards` + `favorites` for names matching `deals|deal|opportunities|opportunity|pipeline|leads|sales`.\n   - If one candidate → use it.\n   - If multiple → a short question to the user with numbered options: \"Which board should I brief on?\" + option \"all of them\".\n   - If zero → `list_workspaces` → `search(\"deal\")`. Still zero → print: *\"I don't see a CRM-shaped board in your workspaces. If you have one under a different name, tell me the name or ID. Otherwise see the `board-diagnosis` skill once a board is connected.\"* Stop.\n\nIf the user picks \"all\", run Steps 3-7 per board and publish one combined α artifact.\n\n---\n\n## Step 3: Read board schema (Gather)\n\n**Goal:** Resolve column IDs by type, not by English name — global teams (Investment, Wealth Mgmt) have non-English column titles.\n\n1. `get_board_info(boardId)`. Cache the column list.\n2. Walk the columns and classify by **type**, preferring title hints where present:\n\n| Concept | Type match | Title hint | Fallback |\n|---|---|---|---|\n| Stage | `status` | contains \"stage\", \"status\" | first `status` column with `is_done` labels |\n| Owner | `people` | contains \"owner\", \"rep\", \"person\" | first `people` column |\n| Value | `numbers` | unit `$`, or title contains \"value\", \"amount\", \"revenue\", \"size\" | first `numbers` column with unit symbol |\n| Close probability | `numbers` | unit `%`, or title contains \"probability\", \"%\" | first `numbers` column with `%` unit |\n| Expected close date | `date` | title contains \"close\", \"expected\", \"target\" | earliest-named `date` column matching |\n| Last interaction | `date` | title contains \"interaction\", \"activity\", \"touch\", \"contacted\" | latest `date` column that's not close-date |\n| Forecast value | `formula` | title contains \"forecast\", \"weighted\" | skip if absent |\n\n3. For any column where type-match is ambiguous, call `get_column_type_info` to confirm settings (e.g., `unit.symbol`, `labels[].is_done`).\n4. If a required column (stage, value, owner) is missing:\n   - Degrade gracefully — continue without that dimension, note it in the final brief under a \"Data hygiene\" line, and suggest the `board-diagnosis` skill.\n\nIf core columns are missing, produce the useful partial brief and label its limitations; do not ask whether to proceed unless the missing data makes a meaningful brief impossible.\n\n---\n\n## Step 4: Identify Won / Lost labels (Gather)\n\n**Goal:** Distinguish \"closed\" from \"active\" without hardcoding English.\n\nFrom the stage column's `settings.labels`:\n- **Won** = labels with `is_done: true`.\n- **Lost** = labels where text matches `lost|closed lost|cerrado perdido|verloren|perdu` (lowercased contains).\n- If no `is_done: true` exists, ask the user which labels mean \"won\".\n\nCache label `id` values for filters. The `index` field is display order, not the filter value. Before filtering, call `get_column_type_info(columnType: \"status\", fetchMode: \"guidelines\")` and use the documented compare-value shape.\n\n---\n\n## Step 5: Pull deal data — three filtered passes (Gather)\n\n**Goal:** Three parallel `get_board_items_page` calls get us active deals, recent closures, and recent activity in one round-trip.\n\n**Pass A — Active deals** (everything not Won or Lost):\n```\nget_board_items_page(\n  boardId,\n  filters: [{ columnId: \"<stage_id>\", compareValue: [<won_label_id>, <lost_label_id>], operator: \"not_any_of\" }],\n  includeColumns: true,\n  columnIds: [<stage_id>, <owner_id>, <value_id>, <probability_id>, <close_date_id>, <last_interaction_id>, <forecast_id>],\n  limit: 200\n)\n```\n\n**Pass B — Recently closed** (Won or Lost since yesterday):\n```\nget_board_items_page(\n  boardId,\n  filters: [{ columnId: \"<stage_id>\", compareValue: [<won_label_id>, <lost_label_id>], operator: \"any_of\" }],\n  orderBy: [{ columnId: \"<close_date_id>\", direction: \"desc\" }],\n  limit: 50\n)\n```\nThen in-memory filter to items with `updated_at` within last 24h.\n\n**Pass C — Recent activity:** reuse Pass A results; sort by `updated_at desc`; take anything within 24h.\n\n### Volume edge cases\n- **Pass A returns `cursor` / more pages:** paginate until you have 2,000 items OR `cursor` is null. Cap at 2,000 most-recent by `updated_at` and flag sampling in the brief: *\"Sampled the 2,000 most-recently-updated deals — full board has N.\"*\n- **Board has >10K items:** stop paginating at 2,000 and surface the sampling note above.\n- **`get_board_items_page` 429 (rate limit):** exponential backoff 3x (1s, 2s, 4s). On the third failure: *\"monday is rate-limiting right now. Retry in 60 seconds, or narrow to fewer boards.\"* Stop — no partial α artifact.\n- **`board_insights` errors (9% baseline):** if invoked as a fallback and it fails, skip that strand; add *\"couldn't analyze `<strand>` — retry later\"* to the hygiene line.\n- **>200 active deals in Pass A:** switch bucket listings to per-stage summary using `board_insights` aggregates; keep per-deal detail only on Slipping + Stale.\n\n---\n\n## Step 6: Synthesize (Synthesize)\n\n**Goal:** Rank deals by what actually needs action today. Prioritize: (a) new activity, (b) stalled >14d, (c) commitments due today.\n\nFor each deal in Pass A, compute category membership:\n\n| Bucket | Criteria |\n|---|---|\n| Slipping | close_date in past AND stage not Won/Lost |\n| Stale | last_interaction > 14d ago AND stage in non-closed |\n| Follow-up | last_interaction > 7d ago AND probability ≥ 50% |\n| Hot | probability ≥ 70% AND last_interaction ≤ 7d AND close_date ≤ 30d |\n| New | created within last 7d AND stage = earliest-index label |\n| Commit-today | close_date = today AND stage ≠ Won/Lost (drives β proactive notification) |\n\nA deal can match multiple buckets — display in the **most actionable** one: **Commit-today > Slipping > Stale > Follow-up > Hot > New**.\n\nIf the Last interaction column is missing or blank, do not substitute `updated_at` as evidence of customer contact; state that age-based buckets cannot be evaluated for those records. If probability is missing, do not assume zero or infer a Hot bucket.\n\nPipeline totals:\n- Active pipeline = Σ value for Pass A.\n- Forecast = Σ forecast_value if present, else Σ (value × probability/100) for records with an actual probability. If neither forecast values nor probabilities are available, report forecast as unavailable, not zero. If only some records can be weighted, label the partial coverage and its denominator.\n- Closing this week = count + Σ value where close_date in current week.\n- Yesterday wins = Σ value for Pass B Won.\n- Yesterday losses = count of Pass B Lost.\n\n---\n\n## Step 7: Present draft and offer publication (Publish)\n\n**Goal:** Prepare and show the complete briefing first, then offer to publish it in monday.\n\n### Decide the target\n\n1. Search the user's personal workspace (or the deals board) for an item named `My Morning` (exact, case-insensitive). If found → `create_update` on that item.\n2. Else: `create_doc` in the user's personal workspace with title `Morning Briefing — <weekday>, <Mon DD>, <YYYY>`.\n3. **Idempotency:** before creating anything, search for an existing same-day artifact by exact title `Morning Briefing — <weekday>, <Mon DD>` AND containing the visible plain-text marker `monday-crm-skill-id: morning-briefing` in its body. If found, **update it in place**: append to the existing doc with `update_doc`, or, for an item update, post a reply on that update (`create_updates` with its parent update id) instead of a new top-level post. Never duplicate. (`get_updates` finds existing updates.)\n\n### Brief content (the body of the update / doc)\n\n```markdown\n# CRM Morning Briefing — <weekday>, <Mon DD>\n\nmonday-crm-skill-id: morning-briefing\n\n## Pipeline at a glance\n- Active pipeline: $<total>K across <N> deals\n- Forecast: $<forecast>K (weighted)\n- Closing this week: <N> deals, $<value>K\n\n## Yesterday's movements\n- Won: <deal> ($<value>K, <owner>)\n- Lost: <deal> ($<value>K, <owner>)\n\n## Needs you today\n\n### Closing today (<N>)\n- <deal> — <stage>, $<value>K, owner <name>, last touch <X days ago>\n\n### Slipping (<N>)\n- <deal> — <stage>, $<value>K, expected <date> (<X> days overdue), owner <name>\n\n### Going cold (<N>)\n- <deal> — <stage>, no touch in <X> days, owner <name>\n\n### Follow-up (<N>)\n- <deal> — <stage>, <probability>%, last touch <X days ago>\n\n## On track\n- <deal> — <stage>, <probability>%, closing in <X> days, owner <name>\n\n## Data hygiene\n- <N> deals missing owner · <N> missing close date · <N> missing amount\n- (Run the `board-diagnosis` skill for a full audit.)\n\n---\nGenerated by monday CRM plugin · <ISO timestamp> · ask for the `morning-briefing` skill again to refresh.\n```\n\n### Confirm-before-write (Default mode)\n\nShow the complete briefing first, then ask: *\"Publish this briefing to <target> in monday CRM?\"* Accept edits or no; do not write without yes.\n\nAll modes require confirmation of this concrete write plan before execution.\n\n### Print to chat\n\nShow the complete brief before the publication question. After successful publication, include the verified URL; if declined or unsuccessful, keep the draft and say it was not published.\n\n### Error on publish\n- Write fails due to perms: report the error and retain the draft. Offer an alternative destination, but get approval for that new destination before writing.\n- Non-admin can't `create_dashboard`: not applicable to this skill (no dashboard in α). The fallback doesn't apply here.\n\n---\n\n## Step 8: Share β (opt-in)\n\n**Goal:** Notify manager / post to team rollup. Only runs if user explicitly asked (\"share this with my manager\", \"post to the team\", or Proactive mode selected Share).\n\n1. `list_users_and_teams` → resolve recipient. If user has a declared manager in their profile metadata, default to that; else a short question to the user with numbered options with top-5 most-linked teammates.\n2. `create_notification({ user_id: <user id>, target_id: <artifact item id>, target_type: \"Project\", text: \"Morning briefing for <Mon DD>\" })`.\n3. Optional: `create_update` on a team-rollup board — one whose name suggests a team or sales rollup (e.g. contains \"team\", \"rollup\", or \"sales\"), or one the user names explicitly. These are not default monday CRM boards, so resolve by `search` / a short question to the user with numbered options rather than assuming a fixed name; if none is found, ask the user which board to post to. Same footer + skill-id-comment convention as the personal-workspace artifact.\n4. Confirm the recipient and notification before calling `create_notification` in every mode.\n\n---\n\n## Step 9: Proactive extension (opt-in)\n\n**Goal:** Act on the briefing — not just render it.\n\nOnly runs if mode = Proactive and the user approves the concrete proposed actions or batch before execution.\n\nFor each deal in **Stale** bucket:\n- `create_update(itemId, text: \"*Follow-up nudge:* No activity in <X> days. What's the next step?\")`.\n\nFor each deal in **Commit-today** bucket:\n- `create_notification({ user_id: <deal owner id>, target_id: <deal item id>, target_type: \"Project\", text: \"Commitment due today on <deal> — $<value>K\" })`.\n\nFor each deal where the transcript / chat made a clear stage transition signal (e.g., user typed \"mark Acme as Negotiation\"): bundle the stage edits into the batched-confirm plan from Step 7 — never write standalone.\n\n### Guard rails\n- If `(Stale count + Commit-today count) > 20`: batch into **one** review-list doc (`Proactive actions — <date>`, with the `monday-crm-skill-id: morning-briefing` marker in body) rather than 20 individual confirms. Print a single prompt: *\"20+ proactive actions queued — open the list and confirm in bulk?\"*\n- Never post on deals the user doesn't own unless the user is the board admin AND gave Proactive approval this session.\n- Safety rail still applies: no deletes, no amount-column writes, no cross-workspace moves.\n\n---\n\n## Step 10: Close the loop\n\n**Goal:** Leave a clean audit trail for Tom (and for red-flag monitoring post-GA).\n\n- Print a one-line summary: `Published Morning Briefing — <date>. <N> deals scanned, <N> actions posted, <N> pending.`\n- If any write failed mid-run: list which ones and say the user can re-run to retry; compensating delete is **only** required for batched multi-item writes (Step 9) that were partially written before halt.\n\n---\n\n## Shared patterns (apply to every step)\n\n- **No title prefix.** Artifact discoverability is via the `Generated by monday CRM plugin · <ISO timestamp>` footer and the embedded `monday-crm-skill-id: <skill>` visible plain-text marker in update/doc bodies. For items the plugin creates, use `Source = AI assistant` on a status column (auto-create the column with user confirm if missing).\n- **Idempotency before create.** Always search for same-day artifact (by title + skill-id marker) first. Update, don't duplicate.\n- **Safety rail.** No deletes, no amount-column writes, no cross-workspace moves. Stage/owner/last-touch/source edits OK in a batched-confirm plan.\n- **Ask once per session**, not per deal, when entering Proactive mode.\n- **Type-based column resolution**, not name-based — global teams have non-English columns.\n\n---\n\n## Error handling reference\n\n| Failure | Behavior |\n|---|---|\n| Connector not installed | Step 0 stops; print install link. |\n| No CRM board | Step 2 stops; offer path to the `board-diagnosis` skill once a board exists. |\n| Board >10K items | Cap at 2K most-recent, flag sampling. |\n| MCP tool error (retryable) | Exponential backoff 3x; on third fail, skip that strand, surface partial brief with hygiene note. |\n| Same-day artifact exists | Update in place via item/doc ID. |\n| User halts mid-session | Keep writes up to halt; report any partial work and do not delete CRM records. |\n| 429 rate limit | Backoff 3x, then *\"monday is rate-limiting; retry in 60s or narrow to fewer boards.\"* Stop. |\n| Non-admin publish perms | Degrade `create_update` → `create_doc` → print-only. |\n| Multiple CRM boards | a short question to the user with numbered options with \"all of them\" option. |\n| Non-English column names | Resolve by type via `get_column_type_info`. |\n| Proactive writes >20 | Batch into one review-list doc. |\n\n---\n\n## Completion criteria\n\n- [ ] Step 0 (connector check) ran and passed.\n- [ ] Exactly one α artifact was created or updated (no duplicate — verified via skill-id visible plain-text marker).\n- [ ] The artifact body carries the `Generated by monday CRM plugin` footer + `monday-crm-skill-id: morning-briefing` marker.\n- [ ] The chat mirror includes the artifact URL on the last line.\n- [ ] Any failed writes are listed in the final summary line.\n- [ ] Safety rail held: no deletes, no amount-column writes, no cross-workspace moves.\n- [ ] Stage/owner/last-touch edits (if any) ran inside a batched-confirm plan.\n- [ ] If Proactive mode ran, the concrete proposed actions were approved before execution.\n\n---\n\n## Reference\n\nFor a compact, chat-only version of the briefing (bucket rules, output format, edge cases, column write formats), see `references/chat-only-briefing.md`. Use it when the user wants the brief printed in chat without publishing to monday.\n"
}