Clearskies

View saved version →

---
name: ai-update-salesforce-field
description: >-
  Put one Salesforce field under AI maintenance with a clearskies workflow: after a
  relevant call, AI finds the right record, checks the transcript is actually useful,
  generates a value, and writes it to the field. Use when a RevOps user wants AI to
  automatically keep a specific SFDC field up to date from meeting content — e.g.
  "have AI keep Opportunity Next Steps updated", "auto-fill our Onboarding Next Step
  field after calls", "update a chosen SFDC field automatically after customer meetings",
  or
  when they pick a field for AI to own. Builds the call-ended → role filter → find
  record → relevance-agent → should-continue gate → generation-agent → updateSalesforce
  pattern, using two reusable field-agnostic agents with all field-specifics in the step
  messages. It proposes or drafts first and never publishes or edits a live workflow
  without explicit approval.
---

# Auto-update a Salesforce field with AI

This skill helps RevOps put **one Salesforce field under AI maintenance**. After a
qualifying call ends, the workflow finds the Salesforce record tied to the meeting's
account, scores whether the transcript is genuinely relevant to the target field,
generates the field's new value if so, and writes it back to Salesforce.

Two AI steps do the work, and both are **reusable and field-agnostic**: a **relevance
agent** and a **generation agent**. Their templates carry no field- or organization-specific
content — everything specific to a field arrives in the step `userMessage`. So the same
two agents serve every field you put under AI maintenance; only the messages change.

It is the field-specific recipe on top of the general clearskies mechanics — for node
shapes, validation, and safe publishing, defer to the **clearskies-workflow-builder**
skill and `workflow_capabilities_get`.

## Load connected-data context

Search first with `schema_search` for the target field concept and record lookup
relationship. Use the ranked matches to select candidate objects and fields, then call
`object_get_fields_schema` for the target and lookup objects before building filters or
writes. Disclose search warnings and never treat search as exhaustive proof. Use
`object_definitions_list` only when a complete configured object list is required. Always use
`object_get_fields_schema` to verify the complete target and lookup object schemas before
building the workflow.

## Operating rule

Build from the reference pattern, but **never publish or modify a live workflow until
the user explicitly approves that side effect.** Default to a proposed config, or a
draft plus a dry run. A test run (`workflow_test_run_start`) is always safe — it never
writes to Salesforce — so **always dry-run a valid *and* an invalid case before
publishing.** `workflow_validate` confirms shape and that references resolve, but it
does not prove the workflow behaves correctly at runtime.

Read [references/generic-ai-update-pattern.md](references/generic-ai-update-pattern.md)
before generating a config, prompt, or draft — it holds both reusable agent templates
and their `userMessage` templates.

## What it builds

```
trigger-1 (callEnded)
 → filter-1  role gate on meeting.attendees.UserRoleId
 → find-1    the target Salesforce record for {{meeting.accounts.Id}}
 → filter-2  require find-1.records to be non-empty
 → agent-1   reusable RELEVANCE agent (field-specifics in its userMessage)
 → filter-3  continue only if agent-1's output has should_continue: true
 → agent-2   reusable GENERATION agent (field-specifics in its userMessage)
 → updateSalesforce: write {{agent-2.output}} to the field on {{find-1.records.sfRecordId}}
```

Each line shows the node **id** (a `{{...}}` reference handle — it must stay in the
`<type>-<n>` form, e.g. `agent-1`); the ids are numbered in flow order here. Set a
descriptive `data.label` on every node (e.g. *Evaluate relevance*, *Generate field
update*, *Find target record*) — that's t

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: clearskies-workflow-builder
description: >-
  Author, edit, validate, and safely publish workflows and agents on the clearskies workflow-builder MCP (tools
  workflow_capabilities_get, workflows_create/update/publish, workflow_validate,
  workflow_variables_get, workflow_test_run_start, workflow_runs_get/list, agents_*,
  object_*). Use whenever the user wants to build, change, debug, or publish a
  clearskies workflow or agent — e.g. "make a workflow that…", "update the
  workflow that…", "why did my workflow fail", "publish this workflow" — or describes a
  scheduled/call/Salesforce-triggered automation that finds CRM records, runs an agent,
  posts Slack, sends email, or writes Salesforce, even without saying "workflow" (e.g.
  "every morning DM me my open deals"). Key rule: workflow_validate checks structure and
  references but not runtime behavior, so ALWAYS dry-run with workflow_test_run_start
  before publishing.
---

# clearskies workflow builder

Building a clearskies workflow looks easy and is full of quiet traps. The tools
happily accept configurations that validate clean and then silently misbehave at
runtime — writing to the wrong record, resolving a variable to empty string, or
finding nothing. This skill encodes the order of operations and the specific traps
so a workflow you ship actually does what the user asked.

## Load connected-data context

When object or field discovery is needed, call `schema_search` first with the workflow's
business concept. Use the ranked results only to select candidates; keep pagination
cursors with the same query and filters, disclose warnings, and call
`object_get_fields_schema` for each selected object before authoring filters or writes.
Use `object_definitions_list` only when a complete configured object list is required. For
audits, enumerate every field on each selected and related object with
`object_get_fields_schema` rather than treating search results as exhaustive.

## The golden rule

**`workflow_validate` confirms the graph is well-formed and that its references
resolve** — it rejects dangling `{{...}}` references, template paths a trigger doesn't
expose, unknown filter `fieldId`s, cycles, and a `findRecords` with no selection method
(unknown Salesforce objects come back as a warning). **What it cannot do is prove the
workflow behaves correctly at runtime:** whether a find actually returns records, that
an `updateSalesforce` targets more than the first record, that a
`{{find.records.some_field}}` projection resolves, or that a structured filter's
`fieldId` resolves on the workflow path. A `{"valid": true}` means "well-formed and
references exist," not "this works." The only trustworthy behavioral check is a **dry
run** (`workflow_test_run_start` → `workflow_runs_get`), where you read the actual
per-step inputs and outputs. Never publish on validation alone.

## Order of operations

Follow these in order. Don't skip to publishing.

1. **Read the available workflow capabilities.** Call `workflow_capabilities_get` first — node
   types, trigger types, and other options can change over time. It is the source of truth
   for shape; `references/lessons.md` is the
   source of truth for the traps it omits.
2. **Learn from a working example.** Call `workflows_list` with `includeConfig: true`
   and read a published workflow similar to the target. This is how you discover real
   filter field ids and proven node shapes — see the "field IDs" trap below.
3. **Design the graph**, applying the traps in `references/lessons.md`. Add a
   `runAgent` node only if the task needs real AI reasoning; skip it for pure data
   forwarding.
4. **Create or update as a draft** (`workflows_create` / `workflows_update`). Both
   write a draft; nothing runs until you publish. On a published workflow,
   `workflows_update` writes a pending draft and leaves the live version untouched
   until you publish. For incremental edits to an existing draft, `workflow_node_patch`
   applies an order

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: use-clearskies-revenue-data
description: Query and synthesize revenue context from the clearskies MCP across connected CRM objects, accounts, contacts, deals, employees, meetings, call transcripts, and email. Use whenever a user asks to research an account or person, inspect pipeline or CRM data, prepare for or recap a meeting, find call or email evidence, or answer a revenue question from clearskies outside the workflow builder.
---

# Use clearskies revenue data

Use the available clearskies data without assuming which CRM, objects, fields, or history are connected.

## Discover schema proportionally

- When the relevant object or field is unknown, ambiguous, or cross-object, call `schema_search` with the business concept and a modest page size. Use ranked matches to select candidates, keep cursors with the same query and filters, disclose warnings, and never treat bounded results as exhaustive.
- When the object is known but its field contract is not, call `object_get_fields_schema`. Use its query-facing `fieldId` and only its declared filters, enums, relationships, and write metadata.
- When the object and field IDs have already been verified in the current task, skip schema discovery and query directly.
- Use `object_definitions_list` only for a complete configured-object inventory.
- For an audit, inspect every field on each selected primary and related object. Use `schema_search` to select those objects only when the audit scope is ambiguous.

## Choose tools

- Use `accounts_list`, `contacts_list`, `deals_list`, and `employees_list` for the standard objects.
- Use `account_get_contacts` and `account_get_deals` after identifying an account.
- Use `crm_records_list` only for custom object types returned by live schema discovery.
- Use `records_aggregate` for counts and numeric summaries. Also inspect rows when the user asks for names or examples, when anomalies or data quality matter, or during an audit. Never list pages solely to count them.
- `schema_search` can surface activity objects such as `event` even when `object_definitions_list` omits them. Call `object_get_fields_schema` with the selected activity `objectType` before using unfamiliar filters.
- Use `events_list` for chronological activity or exact filters. Use `events_search` for semantic topic search; entity filters are optional.
- Use `events_get_contents` only after selecting specific event IDs whose transcript, email body, or other content is needed.
- Use `calendar_get_upcoming` only for future calendar windows.
- When exposed, use `support_tickets_list` and `github_activities_list` for their dedicated activity types.
- When exposed, call `identity_get` to verify the signed-in user when identity matters. Prefer `ownedByMe` over manually filtering by the returned person ID.
- When available, `deep_research` starts a longer-running research job. Use it only when the user explicitly requests deep research, then follow its status tool until completion.

## Keep the high-value guardrails

- Resolve an account, contact, or employee before requesting its activity. Before attributing a quote or finding, batch-resolve every cited account, contact, and employee ID with the corresponding list tool. Keep Clearskies UUIDs, people IDs, and external CRM IDs distinct.
- Use `externalIds` for Salesforce or Gong identifiers. Prefer exact names, domains, or emails before partial matching.
- For “my” records or pipeline, set `ownedByMe: true`. If it errors, report the error; never silently remove ownership scope.
- Follow cursors when completeness matters. Do not claim completeness from a truncated page.
- Use supported relative CRM dates or RFC3339/date-only fixed values; never pass epoch numbers. For recent past activity, set explicit UTC bounds with `endTime` equal to now. Disclose any widened range.
- For calls or transcripts, start with bounded meeting filters and use the provider filter when known. A provider-linked event does not prove transcript availabili

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.