AB

View saved version →

---
name: ab-lead-intake
description: Capture a new lead into AB Sales (ActionBridge CRM) from whatever the user has — an email, a meeting note, a business card, a company name — creating the lead with clean fields, logging the source context as a note, and scheduling the follow-up. Use when the user says to add, register, or capture a lead, prospect, or potential customer.
---

# Lead intake in AB Sales

Turn raw context into a well-formed lead with a follow-up attached, in one pass.

## Extract before you create

From the user's material (email, notes, a URL), extract: company `name` (required), `email`, `website`, `contact_name`, `phone`, `industry`, and `source` (where this lead came from — "inbound email", "conference", "referral"). Ask only for what's genuinely missing and matters — at minimum the company name; an email address makes the lead actionable.

## Check for duplicates

Resolve the workspace via `ab_crm_workspaces`, then `ab_crm_list_leads` with `query` = the company name (try the domain too). If a match exists, **update it instead of creating a duplicate**: `ab_crm_update_lead` for changed fields plus `ab_crm_add_note` with the new context.

## Create

1. `ab_crm_create_lead` with the extracted fields. Put a one-line gist in `notes`; long source material goes in step 2.
2. `ab_crm_add_note` (`parent_type` lead, `parent_id` = new lead id) with the source context — the email text or meeting notes, condensed but preserving specifics (names, numbers, dates, stated needs).
3. **Always schedule the follow-up** — an untracked lead is a lost lead: `ab_crm_create_activity` with `related_type` lead, `activity_type` (call / email / meeting / follow-up), a `subject` that states the goal, and `scheduled_start` (default: 2 business days out; sooner if the material shows urgency).

## Report

Confirm compactly: lead name + id, fields captured, what's missing, and when the follow-up is scheduled. If the user wants the first outreach written now, hand over to ab-lead-outreach.

## Notes

Leads start as New and auto-promote to InformationFilled once enriched — no need to set status manually at intake. If tools refuse for licensing, say so plainly (AB Sales needs its own license).

View saved version →

---
name: ab-lead-outreach
description: Draft and — only with explicit confirmation — send follow-up email to a lead in AB Sales (ActionBridge CRM), grounded in the lead's history, then log the outcome. Use when the user wants to follow up with, reply to, email, or reach out to a lead or prospect.
---

# Lead outreach in AB Sales

Personalized follow-up email with a strict confirmation gate: **a real email leaves the building.**

## Ground the draft

1. Resolve workspace (`ab_crm_workspaces`) and lead (`ab_crm_list_leads` with `query`, then `ab_crm_get_lead`).
2. Read the history before writing a word: `ab_crm_list_notes` and `ab_crm_list_emails` for the lead, `ab_crm_list_activities` for scheduled touchpoints. The draft must reference something real (their stated need, the last conversation) — never send a generic blast.

## Draft

Plain text (the tool does not interpret HTML; line breaks are preserved). Keep it short: 3 short paragraphs at most — context hook, the value/next step, a single clear ask. Subject: specific and small ("Next step on the pilot", not "Following up"). Show the user the full draft — subject and body — and ask for explicit confirmation to send.

## Send — the hard rules

- **Never call `ab_crm_send_email_to_lead` without the user's explicit yes to the exact draft shown.** Any edit means show it again.
- The server enforces its own guardrails and will answer `Refused:` when the lead has opted out, workspace automation is paused, or no outbound mailbox is configured. Relay refusals as-is and stop — do not look for another way to send.
- One send per confirmation. Sending again requires asking again.

Call with `workspace_id`, `lead_id`, `subject`, `body`. The send is logged on the lead automatically.

## After sending

Close the loop: `ab_crm_complete_activity` (with an `outcome`) if this send fulfills a scheduled follow-up, and `ab_crm_create_activity` for the next touchpoint (default ~1 week out) so the thread never dangles. Confirm to the user: sent from which mailbox, to whom, and when the next follow-up is scheduled.

## If the user only wanted a draft

Deliver the draft and offer to store it as a note on the lead (`ab_crm_add_note`) — don't leave good writing stranded in chat.

View saved version →

---
name: ab-project-manager
description: Create, update, complete, and organize tasks in AB Projects (ActionBridge) the right way — resolving project and option IDs first, always logging a change note, and handling assignees, dates, subtasks, and dependencies. Use whenever the user asks to add, change, finish, reassign, schedule, or break down a task in AB Projects.
---

# AB Projects task management

You manage tasks through the ActionBridge MCP tools. Follow these conventions so every change lands correctly and the team sees why it happened.

## Before any write

1. **Resolve the project.** Call `ab_get_my_projects` and match the user's wording to a project name. If several match, ask which one. Never guess a `project_id`.
2. **Resolve option IDs.** Status, type, and environment are per-project GUIDs — call `ab_get_project_options` for the project and use the IDs it returns. Priorities are fixed: `1` = High, `2` = Medium, `3` = Low.
3. **Resolve people.** Assignees are membership IDs from `ab_get_project_members`. Match by name or email; if ambiguous, ask.

## Creating a task

Call `ab_create_task` with `project_id`, `title`, and always a `note` explaining why the task is being created — the note is shown to the team in the change log and Teams channel. Add what the user gave you: `description` (Markdown), `priority`, `assignee_id`, `due_date` (yyyy-MM-dd), `status`, `type`, `environment`. For a subtask, set `parent_task_id`. For "X must finish before Y", set `depends_on_task_ids` on the later task.

- Write titles as short imperatives ("Fix login redirect", not "The login is broken").
- If the user's request contains several distinct deliverables, propose splitting into a parent task with subtasks before creating.

## Updating and completing

- Find the task first: `ab_search_tasks` (keyword) or `ab_get_my_tasks`, then `ab_get_task` for full detail before changing anything.
- `ab_update_task` changes only the fields you pass. Always include `note` saying what changed and why. Dates: `start_date` must not be after `due_date` — the server rejects it. Dependencies change via `add_predecessors` / `remove_predecessors`.
- `ab_complete_task` marks a task done (idempotent). Prefer it over setting a status manually.
- Progress comments belong in `ab_add_comment`, not in the description.

## Reporting back

After a write, relay the confirmation (task ID, what changed). If the tool answers with a refusal — not a member, read-only Viewer role, or a licensing block — explain it plainly and point admins to Settings → Manage licenses for seat issues; don't retry.

## What this skill does not do

Standup or weekly summaries (see ab-standup-reporter / ab-weekly-review), and project documents (see ab-wiki-writer).

View saved version →

---
name: ab-sales-pipeline-review
description: Review the sales pipeline in AB Sales (ActionBridge CRM) — funnel health, stale leads, open opportunities, and recommended next actions. Use when the user asks how their pipeline, funnel, leads, or deals are doing, wants a sales summary, or asks what to focus on in sales today.
---

# Pipeline review in AB Sales

A health check with recommendations, grounded in the workspace's real CRM data.

## Gather

1. `ab_crm_workspaces` — resolve the workspace (ask if the user has several).
2. `ab_crm_get_sales_context` — the workspace's current sales summary; start from this.
3. `ab_crm_get_pipeline` — opportunity stages and values.
4. `ab_crm_list_leads` with `status` filters to size the funnel stages; a plain call for the newest. Leads sit in statuses like New → InformationFilled → Contacted → Qualified (New leads auto-promote to InformationFilled when enriched).
5. `ab_crm_list_activities` — what's scheduled vs. overdue; an opportunity with no next activity is drifting.

## Judge

Flag, in order of revenue impact:
- **Stale qualified leads** — qualified but no activity logged recently; these cost the most.
- **Opportunities without a next step** — no scheduled activity and no `next_step` set.
- **New leads never touched** — created but still unenriched/uncontacted.
- **Close dates in the past** — `expected_close` already passed while the opportunity is open: either update the date honestly or close it.

## Compose

```
**Pipeline review — {workspace} — {date}**
Funnel: {counts per stage, one line}
Open value: {sum by stage from the pipeline}
⚠ Needs attention: {top 3-5 flagged items, each with WHY and the suggested move}
Suggested today: {2-3 concrete actions}
```

## Acting on it

On confirmation only: log follow-ups as activities (`ab_crm_create_activity` with `related_type`/`related_id`, an `activity_type`, `subject`, `scheduled_start`), fix opportunity fields (`ab_crm_update_opportunity` — `next_step`, realistic `expected_close`, or `close` with a `loss_reason` when it's dead), and add context as notes (`ab_crm_add_note`). For drafting or sending an email to a lead, hand over to ab-lead-outreach. The review itself is read-only.

View saved version →

---
name: ab-standup-reporter
description: Generate the user's daily standup from AB Projects (ActionBridge) — what's in progress, what's due today, and what's blocked, formatted to share in chat. Use when the user says "standup", "daily report", "what's on my plate today", or asks for their day's tasks across projects.
---

# Daily standup from AB Projects

Produce a short, share-ready standup for the user. Data first, then format.

## Gather

1. `ab_get_schedule` (no `project_id`) — overdue, due-today, and this-week tasks across all the user's projects.
2. `ab_get_my_tasks` — all active assigned tasks; use it to spot in-progress work that has no due date (the schedule won't show those).
3. If any task looks blocked or stalled and detail matters, `ab_get_task` on just that task to check dependencies ("Blocked: yes") and recent comments. Don't fetch every task — only the ones you'll call out.

## Compose

Default format (adapt to the user's stated style if they have one):

```
**Standup — {today's date}**
✅ Recently done / in motion: {1-3 items with [taskId]}
🎯 Today: {due-today tasks + the one or two most important in-progress items}
⚠️ Blockers: {overdue tasks and dependency-blocked tasks, each with what it's waiting on; write "none" if clear}
```

- Keep it under ~10 lines; per item: `[taskId] title — one clause of context`.
- Overdue items always appear, oldest first, marked with how many days overdue.
- If the schedule comes back "No tasks due this week. You're clear!", say so positively and list at most the top 2 in-progress items.

## After presenting

Offer exactly one follow-up: post it somewhere or act on a blocker (e.g. "want me to bump the due date on [id]?" → hand off to ab-project-manager conventions: update with a `note`). Don't write anything to AB unless asked — standup generation itself is read-only.

View saved version →

---
name: ab-weekly-review
description: Run a weekly review of AB Projects (ActionBridge) work — what got done, what slipped, what's blocked, and a proposed plan for next week. Use when the user asks for a weekly review or retro, wants to know what slipped or is overdue or blocked across projects, or asks to plan next week.
---

# Weekly review from AB Projects

A retro plus a forward plan, grounded in the actual task data. Read everything before judging anything.

## Gather

1. `ab_get_my_projects` — the projects in scope (note overall progress percentages).
2. `ab_get_schedule` — overdue / due-today / this-week across projects.
3. `ab_get_my_tasks` — the full active list; anything with due dates in the past week that's still open counts as slipped.
4. For each apparent blocker or long-stalled task (pick the few that matter), `ab_get_task` — check `Blocked: yes`, predecessors, and the latest comments so you can say *why* it's stuck, not just that it is.

## Compose

```
**Weekly review — week of {date}**

Done this week: {completed/moved items, celebrate briefly}
Slipped: {tasks whose due date passed while open — [taskId] title, new-reality note}
Blocked: {each with the blocking task or reason, from real dependency data}
Next week: {proposed top 3-5, ordered — due dates first, then unblocking moves, then priorities}
```

- Be honest, not cheerful: if most items slipped, the review should say so and look for the pattern (one overloaded person? one stuck dependency chain?).
- When one task blocks several others, lead with it — unblocking it is the highest-leverage move of next week.

## Turning the plan into changes

Only on the user's confirmation, apply the plan with ab-project-manager conventions: `ab_update_task` with realistic new `due_date`s and a `note` like "Rescheduled in weekly review", `ab_complete_task` for anything actually finished but never closed. Never silently rewrite dates during the review itself.

View saved version →

---
name: ab-wiki-writer
description: Write, update, and organize project documents (wiki pages) in AB Projects (ActionBridge), and link them to the tasks they support. Use when the user wants to document a decision, write up meeting notes, create a guide or spec as a project document, update an existing wiki page, or attach a document to a task.
---

# Project documents (wiki) in AB Projects

Documents are Markdown pages per project, versioned on every save, with their own discussion threads and task links.

## Before writing

1. Resolve the project via `ab_get_my_projects` (ask if ambiguous).
2. `ab_get_wiki_tree` for that project — see the existing folder structure and check whether a page on this topic already exists. **Prefer updating an existing page over creating a near-duplicate.**
3. If updating, `ab_get_wiki_article` first and edit from the real current content — never overwrite from memory.

## Creating

`ab_create_wiki_article` with `project_id`, `title`, `content` (Markdown), and a `parent_path` that fits the existing tree (e.g. `/guides`); add `tags` for findability. Structure content for a team, not a chat: a one-paragraph summary at top, then headed sections, decisions stated with their why, and open questions listed explicitly at the end.

## Updating

`ab_update_wiki_article` with `article_id`, the **complete** new `content` (a save replaces the whole body and creates a new version), and an `edit_note` saying what changed — the note is the team's change log. Preserve sections you weren't asked to touch.

## Linking to tasks

When a document supports specific work — a spec for a feature task, notes from the meeting that spawned tasks — connect them: `ab_link_task_wiki` with `task_id` and `wiki_article_id` (idempotent). Mention the link in your summary so the user knows navigation exists in both directions. `ab_unlink_task_wiki` undoes only the association; it never deletes anything.

## Discussion vs. content

Feedback about a document goes to its thread via `ab_add_wiki_comment`, not into the body. Suggest a comment when the user's input is commentary ("I think this section is outdated") rather than replacement text.

## Refusals

Viewer-role members and users without a seat can't write documents — if a tool refuses, explain that plainly rather than retrying (seats: Settings → Manage licenses).