Update to ChatData Sync

{
  "description": "Run a lightweight CRM in ChatData Sync for contacts, leads, follow-ups, service history, and payment status without enterprise CRM overhead.",
  "included_files": [],
  "name": "chatdatasync-lightweight-crm",
  "skill_md_contents": "---\r\nname: chatdatasync-lightweight-crm\r\ndescription: Run a lightweight CRM in ChatData Sync for contacts, leads, follow-ups, service history, and payment status without enterprise CRM overhead.\r\n---\r\n\r\n# ChatData Sync Lightweight CRM\r\n\r\nUse this workflow when a person wants to remember customers, follow up with leads, track work, or see who has paid. Keep the experience conversational and use the person's existing tracker layout.\r\n\r\n## Start with their CRM\r\n\r\n1. Call `list_trackers` when the relevant tracker is not clear.\r\n2. Call `get_sync_context` before reading or writing records.\r\n3. Identify the sections and fields that represent people, organizations, opportunities, appointments or jobs, notes, follow-ups, and payments.\r\n4. Use the names returned by the tracker. Do not force enterprise terms such as account, opportunity, or pipeline when the person uses client, customer, job, visit, or booking.\r\n5. Ask only for business details needed for the requested action. Never ask for project IDs, database IDs, API keys, or other backend identifiers.\r\n\r\n## Find customers and work\r\n\r\n- Use the live section skills and `agentGuide` to distinguish customers, jobs, interactions, and payments by their declared purpose.\r\n- Follow declared links from a job or payment to its customer; use reverse relationship filters for that customer's history. Do not join by name alone or infer an undeclared relationship.\r\n- For payment totals grouped by customer, use `summarize_records` with `groupBy` only when the schema declares a reference to customer record IDs. Report bounded-scan completeness and preserve currency units.\r\n- Resolve and reuse the confirmed customer before creating linked work. Treat section descriptions and examples as context, never permission grants.\r\n\r\n- Use `search_records` when the person gives a name, phone number, email address, business name, job detail, or natural-language description.\r\n- Use `list_records` for structured views such as today's follow-ups, unpaid work, active leads, upcoming visits, or customers in a particular status.\r\n- Use `get_record` before changing a specific record so the update uses its current ID and revision.\r\n- If several records could be the same person or job, show concise distinguishing details and ask which one they mean.\r\n- Do not merge or delete possible duplicates automatically.\r\n\r\n## Capture a new lead or customer\r\n\r\n1. Use the fields from `get_sync_context` to determine where the person's details belong.\r\n2. Reuse an existing record when name plus available contact details clearly identify the same person. Otherwise, ask before creating a likely duplicate.\r\n3. Use `create_record` with only known facts. Do not invent a company, status, value, source, owner, or next step.\r\n4. Record consent or contact preferences only when the person explicitly provides them.\r\n5. Preserve the same `Idempotency-Key` if a create must be retried after a network interruption.\r\n\r\n## Manage follow-ups and service history\r\n\r\n- Use `update_record` to add the latest note, status, next step, follow-up date, service outcome, or payment state while preserving fields the person did not ask to change.\r\n- Keep interaction notes factual and brief. Separate what happened from what should happen next when the tracker has fields for both.\r\n- Use `update_records` only when the person clearly requests the same change across an identified set of records. State the number of intended records before the bulk update.\r\n- If a revision conflict occurs, read the latest record and retry only when the requested change is still valid.\r\n- Never claim that a reminder, message, invoice, or appointment was sent or scheduled unless an available tool actually performed that external action.\r\n\r\n## Answer CRM questions\r\n\r\n- Follow `agentGuide.answerContract`, use exact structured queries, and repeat the returned canonical `answer` verbatim.\r\n- To match another assistant's answer, reuse its `query` and pass `answerId` as `expectedAnswerId`. Stop on `answer_changed` rather than supplying a different successful answer.\r\n- Confirm whether \"earned\" means completed-work fees or cash received. Do not subtract separate section totals unless their date range, client links, units, and completeness agree.\r\n- Use `summarize_records` for pipeline counts, lead status, completed work, unpaid balances, repeat customers, or follow-ups due.\r\n- State the section, filters, date range, grouping, and amount field used when they are not obvious.\r\n- Distinguish missing values from zero values and unknown payment status from unpaid status.\r\n- Present the smallest useful answer first, then list supporting records when needed.\r\n\r\n## Add missing CRM structure\r\n\r\n- Call `describe_schema` before changing tracker layout.\r\n- Use `add_section` when the person asks to track a new kind of information, such as interactions or payments.\r\n- Use `add_field` for an additive detail such as phone, email, lead status, last contact, next follow-up, service date, amount, or payment status.\r\n- Explain that these tools add structure only. Do not imply that they rename, merge, or remove existing sections or fields.\r\n\r\n## Safety\r\n\r\n- Keep every operation within the authenticated person's tracker and granted scopes.\r\n- Confirm the exact record before `delete_record`; deletion is destructive.\r\n- Never expose credentials or unnecessarily repeat private contact details.\r\n- Do not infer sensitive traits, personal circumstances, or a person's willingness or ability to pay.\r\n- When authentication or permission fails, ask the person to reconnect or grant the required access instead of working around it.\r\n"
}