Scoring rules for daily churn-risk detection — usage decline, support friction, billing/payment risk, and renewal proximity — plus how to combine them into a ranked at-risk list with a reason and a suggested next step per account.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Query per-account activity trend over a rolling window (active seats, key-feature events, login frequency over the last 30 days vs. the prior 30). Classify:
| Usage signal | Criteria |
|---|---|
| Stable/growing | Flat or increasing vs. prior window |
| Declining | ≥20% drop in core activity vs. prior window |
| Dormant | Near-zero activity for 14+ days on a previously active account |
Pull thread volume and tone per account over the same window.
| Support signal | Criteria |
|---|---|
| Normal | Thread volume in line with the account's history |
| Rising friction | Thread count up materially vs. baseline, or repeated unresolved threads |
| Escalated | An open thread flagged urgent/escalated, or explicit cancellation language |
Pull payment status and renewal date per account.
| Billing signal | Criteria |
|---|---|
| Healthy | Payments current, renewal more than 45 days out |
| At risk | One missed or failed payment in the last billing cycle |
| Renewal-imminent | Renewal within 30 days |
No single signal alone is high risk. Weigh combinations:
| Combination | Risk |
|---|---|
| Declining/dormant usage alone | Low–medium — watch |
| Declining usage + rising/escalated support | Medium–high |
| Any usage signal + a failed payment | High |
| Declining/dormant usage + renewal-imminent | High |
| Rising/escalated support + renewal-imminent | High |
| Declining usage + rising support + (renewal-imminent or failed payment) | Highest — surface first |
| Stable usage, normal support, healthy billing | Not at risk — omit from the list |
For every account that clears the "watch" bar, write:
Sort highest risk first. Post one message to {{alert_channel}}: for each account, its rank, risk level, the reason, and the next step. Post exactly once per run — this is a fresh session, so there is no prior list to update or diff against; the whole list is recomputed and reposted every day.
</workflow> <guardrails> - **Read-only, always.** Postgres and Stripe are read-only connectors, and the Plain API key (`PLAIN_API_KEY`) is scoped to read access only. Never write to an account, a ticket, or a subscription, even if the credential would technically allow it. - **One output.** The Slack post to {{alert_channel}} is the only thing that leaves the sandbox. No emails, no ticket replies, no billing actions. - **No memory between runs.** Each run is a fresh session; recompute from the current state of all three systems rather than assuming anything from the prior day's list. - **Scoped secrets.** Postgres and Stripe access is brokered server-side through connectors; the Plain API key is injected as an environment variable. No raw credential is ever pasted into chat. - **People decide, not the agent.** The list flags risk and suggests a next step; a human on customer success decides whether and how to act. </guardrails> </skill>まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Policy runbook for turning a Slack access request into a least-privilege, policy-checked GitHub or AWS IAM grant. Covers the role-to-grant mapping, extra-scrutiny cases, the approval handshake, and how an applied grant gets logged.
日本語の概要は準備中です。原文の説明を表示しています。
Get a complete picture of any company or person before outreach. This skill always works with web search, and gets significantly better with enrichment and CRM data.
日本語の概要は準備中です。原文の説明を表示しています。
Daily read-only ad-performance runbook — budget pacing, CPA/ROAS drift, underperforming ads and keywords, and anomaly detection across Google Ads and Meta Ads, plus how to rank and word optimization recommendations for {{alert_channel}}.
日本語の概要は準備中です。原文の説明を表示しています。
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
日本語の概要は準備中です。原文の説明を表示しています。
Extraction, PO matching, duplicate detection, and overcharge tolerance for processing incoming vendor invoices from {{invoice_label}} against the POs and ledger in {{ap_ledger}}. Load this before extracting a single invoice so every one is checked to the same standard and only genuine exceptions reach a human, with no invoice ever scheduled for payment by the agent.
日本語の概要は準備中です。原文の説明を表示しています。
Daily brand-mention monitoring loop for {{brand_terms}}. Searches news, social platforms, and forums for new mentions, dedupes against the ledger of mentions already reported, classifies sentiment and notability, and posts a digest with suggested response drafts to {{slack_channel}} — never posts, replies, or comments anywhere.
日本語の概要は準備中です。原文の説明を表示しています。