clawskills-mcp 0.7.1 → 0.7.3

package/README.md

@@ -32,8 +32,9 @@ No install needed. Add this to your MCP client config:
 ### Via Docker
 
 ```bash
-# From repo root
-docker build -t clawskills-mcp -f mcp-server/Dockerfile .
+# From repo root — the build context must be the root, since the image
+# copies skills/ and playbooks/ from there.
+docker build -t clawskills-mcp .
 docker run --rm -i clawskills-mcp
 ```
 

package/dist/index.js

@@ -308,19 +308,27 @@ server.setRequestHandler(ListToolsRequestSchema, async () => ({
     tools: [
         {
             name: "list_skills",
-            description: "List all available ClawSkills API integration skill docs.",
+            description: "List the slugs of every available API integration skill doc, with a one-line summary of each. " +
+                "Read-only; takes no arguments; returns a short list (currently 14 entries), not the doc bodies. " +
+                "Call this first when you do not yet know which platform slug to pass to get_skill, or to check whether a platform is covered at all before falling back to general knowledge.",
             inputSchema: { type: "object", properties: {}, required: [] },
         },
         {
             name: "get_skill",
-            description: "Retrieve a ClawSkills skill doc by name (slug). Optionally specify a section (e.g. 'auth', 'rate-limits', 'recipes') to get just that part.",
+            description: "Fetch the integration guide for one SaaS platform: authentication, rate limits, pagination, error handling, and tested request recipes. " +
+                "Read-only. Returns Markdown. A whole doc is large (roughly 20-40 KB), so pass `section` to retrieve just the part you need unless you genuinely want everything. " +
+                "Use this when you already know the platform; use search_skills instead when you know the problem but not the platform. " +
+                "Each doc carries a `Last validated` date in its header indicating when it was last checked against the vendor's live documentation.",
             inputSchema: {
                 type: "object",
                 properties: {
-                    name: { type: "string", description: "Skill slug, e.g. 'salesforce', 'github', 'figma'" },
+                    name: {
+                        type: "string",
+                        description: "Skill slug, lowercase, exactly as returned by list_skills. One of: asana, dynamics365, figma, github, hubspot, jira, linear, monday, notion, salesforce, servicenow, slack, stripe, zendesk.",
+                    },
                     section: {
                         type: "string",
-                        description: "Optional section name. Aliases: auth, rate-limits, errors, pagination, recipes, gotchas, webhooks, overview, fields",
+                        description: "Optional. Return only this section instead of the whole document. One of: auth, rate-limits, errors, pagination, recipes, gotchas, webhooks, overview, fields. Omit to return the full doc.",
                     },
                 },
                 required: ["name"],
@@ -328,49 +336,70 @@ server.setRequestHandler(ListToolsRequestSchema, async () => ({
         },
         {
             name: "search_skills",
-            description: "Search across all skill docs for a query string. Returns matching excerpts with context. Useful when you don't know which skill to fetch.",
+            description: "Full-text search across all 14 platform skill docs, returning matching excerpts with surrounding context rather than whole documents. " +
+                "Read-only. Use when you know the problem but not which platform doc answers it — for example a specific error code, header, or auth mechanism. " +
+                "Searches single-platform docs only; use search_clawskills if the task spans two systems.",
             inputSchema: {
                 type: "object",
                 properties: {
-                    query: { type: "string", description: "Search query, e.g. '429 retry', 'OAuth scopes', 'webhook signature'" },
+                    query: {
+                        type: "string",
+                        description: "Free-text query matched against document contents. Works best with concrete API terms, e.g. '429 retry', 'OAuth scopes', 'webhook signature'.",
+                    },
                 },
                 required: ["query"],
             },
         },
         {
             name: "list_playbooks",
-            description: "List all available ClawSkills workflow playbooks.",
+            description: "List the slugs of every available cross-tool workflow playbook, with a one-line summary of each. " +
+                "Read-only; takes no arguments; returns a short list (currently 4 entries), not the playbook bodies. " +
+                "Playbooks describe how to wire two systems together end to end; single-platform API questions are covered by list_skills instead.",
             inputSchema: { type: "object", properties: {}, required: [] },
         },
         {
             name: "get_playbook",
-            description: "Retrieve a ClawSkills workflow playbook by name (slug).",
+            description: "Fetch one cross-tool workflow playbook: the trigger, source of truth, field mapping, idempotency and dedup keys, retry and partial-failure policy, and reconciliation steps for syncing two systems. " +
+                "Read-only. Returns Markdown, typically a few KB. " +
+                "Use this when the task spans two platforms (for example 'create a Jira issue from a Zendesk ticket'); use get_skill when the task involves only one.",
             inputSchema: {
                 type: "object",
                 properties: {
-                    name: { type: "string", description: "Playbook slug, e.g. 'zendesk-jira-bug-escalation'" },
+                    name: {
+                        type: "string",
+                        description: "Playbook slug, lowercase, exactly as returned by list_playbooks. One of: hubspot-asana-onboarding, salesforce-hubspot-lead-sync, slack-jira-incident, zendesk-jira-bug-escalation.",
+                    },
                 },
                 required: ["name"],
             },
         },
         {
             name: "search_playbooks",
-            description: "Search across workflow playbooks for a query string and return matching excerpts with context.",
+            description: "Full-text search across the cross-tool workflow playbooks, returning matching excerpts with surrounding context. " +
+                "Read-only. Use for orchestration concerns that recur across integrations — idempotency, dedup keys, rollback, partial failure — when you do not know which playbook covers them.",
             inputSchema: {
                 type: "object",
                 properties: {
-                    query: { type: "string", description: "Search query, e.g. 'idempotency', 'rollback', 'customer impact'" },
+                    query: {
+                        type: "string",
+                        description: "Free-text query matched against playbook contents, e.g. 'idempotency', 'rollback', 'customer impact'.",
+                    },
                 },
                 required: ["query"],
             },
         },
         {
             name: "search_clawskills",
-            description: "Search across both skills and playbooks. For workflow-shaped queries, playbooks are ranked ahead of generic skill matches.",
+            description: "Full-text search across both the platform skill docs and the workflow playbooks in one call, returning matching excerpts with context. " +
+                "Read-only. Playbooks are ranked ahead of skill matches for workflow-shaped queries. " +
+                "Prefer this as the default entry point when you are unsure whether the answer is a single-platform API detail or a two-system workflow; reach for search_skills or search_playbooks only when you want to restrict results to one of the two.",
             inputSchema: {
                 type: "object",
                 properties: {
-                    query: { type: "string", description: "Search query, e.g. 'closed won onboarding', 'zendesk jira escalation', 'lead sync'" },
+                    query: {
+                        type: "string",
+                        description: "Free-text query matched against both corpora, e.g. 'closed won onboarding', 'zendesk jira escalation', 'lead sync'.",
+                    },
                 },
                 required: ["query"],
             },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "clawskills-mcp",
-  "version": "0.7.1",
+  "version": "0.7.3",
   "description": "MCP server exposing ClawSkills API integration skill docs to AI agents",
   "license": "MIT",
   "author": "ClawSkills Contributors",

package/skills/ROADMAP.md

@@ -19,7 +19,7 @@ This skill set enables end-to-end automation and integration across the most com
 | Layer | Status |
 |-------|--------|
 | **14 skill docs** — Monday.com, Salesforce, Jira, Dynamics 365, HubSpot, ServiceNow, Zendesk, Asana, GitHub, Figma, Slack, Stripe, Notion, Linear | ✅ Live |
-| **MCP server** — `clawskills-mcp` v0.7.1 on npm; `list_skills`, `get_skill`, `search_skills` | ✅ Live |
+| **MCP server** — `clawskills-mcp` v0.7.3 on npm; `list_skills`, `get_skill`, `search_skills` | ✅ Live |
 | **CI pipeline** — build + test on every push/PR via `ci.yml` | ✅ Live |
 | **Release automation** — `prepare-release.yml` workflow_dispatch → release PR; `release.yml` on merge → npm publish via OIDC + tag | ✅ Live |
 | **Test suite** — Vitest unit tests + real-skills validation (required sections, ≥5 KB, all 14 tools) | ✅ Live |
@@ -83,7 +83,7 @@ The repo now needs tighter alignment between the canonical `skills/` directory,
 | Channel | Status | Next action |
 |---------|--------|-------------|
 | GitHub (public) | Ready to flip | Make repo public |
-| npm (`clawskills-mcp`) | ✅ Live — v0.7.1 | Maintain via `release.yml` |
+| npm (`clawskills-mcp`) | ✅ Live — v0.7.3 | Maintain via `release.yml` |
 | MCP registry listings | Not submitted | Submit to glama.ai, mcp.so, smithery.ai after public launch |
 | Docs website | Planned | Mintlify — fastest path to SEO-friendly browsable docs |
 | Lane A vs B | TBD | Revisit after first traction signals from public launch |
@@ -177,11 +177,12 @@ Each skill/recipe is scored on five dimensions (1–5 each):
 - **Breaking change monitoring:** Subscribe to each vendor's developer changelog:
   - Monday: https://developer.monday.com/api-reference/docs/api-versioning (versioning table) + https://developer.monday.com/changelog (entries)
   - Salesforce: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/rest_rns.htm — ⚠️ JS-rendered: the content body is injected client-side, so plain HTTP fetchers (curl, wget, GitHub Actions cron jobs without a JS engine) return only the page shell. Read it in a real browser, or use a headless-browser tool (Playwright/Puppeteer) — see https://github.com/Shanksg/clawskills/issues/12.
-    - **Workaround (found 2026-08-02):** https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_versions.htm **is** plain-fetchable and lists the highest published API version with its release name. That covers "did a new version ship?" — the most common freshness question — without a browser. Only the delta review still needs one.
+    - **Workaround (found 2026-08-02) — broken as of 2026-10-14:** the versions doc moved to https://developer.salesforce.com/docs/platform/api-rest/guide/resources-versions.html and all of developer.salesforce.com now returns `403` to non-browser fetchers. Plain-fetchable replacement for "did a new release ship?": Salesforce's Trust status API, e.g. `curl -G https://api.status.salesforce.com/v1/maintenances --data-urlencode "name=Winter '27 Major Release" --data-urlencode limit=1000` — group by `plannedStartTime` and `status` to see how far the rollout has got. It gives release names, not API version numbers, and the delta review still needs a browser.
+    - **Delta review without a GUI (verified 2026-10-14):** headless Chrome renders the help.salesforce.com release notes fine — `"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --virtual-time-budget=30000 --user-agent="<desktop Chrome UA>" --dump-dom "https://help.salesforce.com/s/articleView?id=release-notes.rn_api.htm&release=<NNN>&type=5"`, then strip tags. Release number = 262 Summer '26, 264 Winter '27 (+2 per release). This is the Playwright-free path issue #12 asked for.
   - Jira: https://developer.atlassian.com/cloud/jira/platform/changelog/
   - Dynamics 365: https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/web-api-versions (Web API version differences) + https://learn.microsoft.com/en-us/dynamics365/released-versions/microsoft-dataverse (weekly release notes)
   - HubSpot: https://developers.hubspot.com/changelog
-  - ServiceNow: https://www.servicenow.com/docs/bundle/australia-release-notes/page/release-notes/family-release-notes.html (current named release — rotate this URL on each new release; https://www.servicenow.com/docs/r/release-notes/available-versions.html lists which family is current)
+  - ServiceNow: https://www.servicenow.com/docs/r/brazil/release-notes/family-release-notes.html (current named release — rotate this URL on each new release; https://www.servicenow.com/docs/r/release-notes/available-versions.html lists which family is current)
   - Zendesk: https://developer.zendesk.com/api-reference/changelog/changelog/
   - Asana: https://forum.asana.com/c/forum-en/api/api-change-log/204 — Asana hosts their dated API changelog as a forum category (individual entries are threads under it); the developer-portal page just redirects here
   - GitHub: https://github.blog/changelog/ (entries) + https://docs.github.com/en/rest/about-the-rest-api/breaking-changes (per-version breaking-change list — the fetchable source of truth for REST API versions)

package/skills/asana/skill.md

@@ -1,6 +1,6 @@
 # Asana Skill
 
-> **Last validated:** 2026-08-02 | **API:** Asana REST API 1.0
+> **Last validated:** 2026-10-14 | **API:** Asana REST API 1.0
 > **REST base URL:** `https://app.asana.com/api/1.0`
 > **Assumed product:** Asana cloud. Enterprise controls, SCIM, and admin APIs may require additional scopes and plan-specific access.
 >
@@ -19,6 +19,15 @@
 > - **`sort_by=relevance` on project search (2026-06-04):** relevance ordering now available alongside the existing sort options.
 > - **AI teammates / agent API support announced (2026-05-28)** — not yet GA; no action required, but expect new actor types on tasks and stories.
 >
+> **⚠️ Changes since 2026-08:**
+> - **Subtasks expose inherited project memberships (2026-08-10):** new `effective_memberships` opt_field (entries carry `is_inherited`). `custom_fields` on a subtask now reflects its full ancestor project set, so new entries may appear — handle unfamiliar fields. `projects` and `memberships` still return direct memberships only.
+> - **Custom types on projects and portfolios (opt-in GA 2026-08-18):** new `custom_type` fields/filters on tasks, projects, and portfolios plus `GET /custom_types`. **Default flips 2027-01-13:** unfiltered `GET /tasks`, `GET /projects`, `GET /portfolios` will also return Asana-created custom-typed objects — don't assume a fixed set of `resource_subtype` values.
+> - **Subtask date rollups (2026-09-28):** new `has_subtasks_date_mismatch` task field and `POST /tasks/{gid}/rollup` / `POST /projects/{gid}/rollup`. Jobs gain new `resource_subtype` values (`rollup_task`, `rollup_project`).
+> - **SCIM Users/Groups pagination (2026-10-08):** opt-in via `startIndex`/`count` or `cursor`; unpaged requests unchanged.
+> - **Time tracking entry `assignee` (2026-10-09):** `assignee` field and filter added; the `user` filter on `GET /time_tracking_entries` is deprecated in favor of `assignee`.
+> - **Rich text for text custom fields (2026-10-13):** read `html_text_value`, write via `html_custom_fields`. `text_value` and plain `custom_fields` writes are unchanged.
+> - **AI teammates** remain Early Access (opt-in header `Asana-Enable: ai_teammate_actors`) as of 2026-10-14.
+>
 > **Source:** https://forum.asana.com/c/forum-en/api/api-change-log/204
 
 ## What this skill enables
@@ -129,6 +138,8 @@ Workspace
 - A task can belong to **multiple projects** simultaneously (multi-homing) via the `memberships` array.
 - `custom_fields` on tasks are only populated when the task is a member of a project that has that custom field configured (`custom_field_settings`).
 
+> ⚠️ Changed 2026-08-10: for subtasks, `custom_fields` now includes fields from the full ancestor project chain (inherited memberships), not only direct ones. Request `effective_memberships` to see which projects a subtask inherits from.
+
 ### Naming conventions
 
 - All GIDs are **strings** (even though they look like integers). Always store and compare as strings.

package/skills/dynamics365/skill.md

@@ -1,10 +1,10 @@
 # Microsoft Dynamics 365 Skill
 
-> **Last validated:** 2026-08-02 | **API:** Dataverse Web API (OData v4) v9.2
+> **Last validated:** 2026-10-14 | **API:** Dataverse Web API (OData v4) v9.2
 > **Base URL:** `https://{org-name}.crm.dynamics.com/api/data/v9.2/`
 > **Assumed product:** Dynamics 365 Sales. Other apps (Customer Service, Field Service) share the same Web API pattern.
 >
-> **Note:** Re-confirmed on 2026-08-02: v9.0, v9.1, and v9.2 still have identical Web API behavior with no breaking changes. No v9.3 or v10 announced. The 2026 release waves are PowerApps/Copilot features, not Web API surface changes. Microsoft's own guidance is to pin the version that was current when you wrote the code and test before moving up, rather than tracking the newest automatically.
+> **Note:** Re-confirmed on 2026-10-14: v9.0, v9.1, and v9.2 still have identical Web API behavior with no breaking changes. No v9.3 or v10 announced; Aug–Oct 2026 service updates (9.2.26081–9.2.26101) all stay on 9.2. The 2026 release waves are PowerApps/Copilot features, not Web API surface changes. Microsoft's own guidance is to pin the version that was current when you wrote the code and test before moving up, rather than tracking the newest automatically.
 > **Source:** https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/web-api-versions (page revision 2026-03-27)
 
 ---

package/skills/figma/skill.md

@@ -1,10 +1,11 @@
 # Figma Skill Reference
 
-**Last validated:** 2026-08-02
+**Last validated:** 2026-10-14
 **API version:** REST API v1 (stable) | Webhooks V2 (stable) | Pin `X-Figma-Api-Version` not required — versioning is path-based (`/v1/`, `/v2/`)
 **Base URL:** `https://api.figma.com` (Government: `https://api.figma-gov.com`)
 
 > **New since 2026-02:**
+> - **Folders API — August 10, 2026.** New `/v2` folder endpoints (`GET /v2/teams/:team_id/folders`, `/v2/folders/:folder_id/folders`, `/files`, `/meta`) for plans with nested folders; the v1 project endpoints are **deprecated** in favour of them. "Projects" are now called "folders" in the docs. See Recipe 6.
 > - **Plan access tokens — GA July 23, 2026.** Organization- and Enterprise-plan tokens that are **not tied to an individual user account**, with expiry up to one year and optional allowlists, managed by plan admins. This is now the recommended credential for CI/CD and org automation — it survives the token owner leaving the company, which personal access tokens do not. See Authentication below.
 > - **oEmbed API — March 25, 2026.** `oEmbed 1.0`-spec endpoint returning metadata for Figma files and published Makes. Requires the `file_metadata:read` scope.
 > - **AI Usage API — June 12, 2026.** Enterprise-only endpoint returning per-user, per-day AI credit usage. Requires the `org:ai_metering_usage_read` scope and a plan access token.
@@ -183,7 +184,9 @@ curl https://api.figma.com/v1/me \
 | `file_dev_resources:write` | Create/update dev resources |
 | `library_assets:read` | Published components and styles |
 | `library_analytics:read` | Design system analytics (Enterprise only) |
-| `projects:read` | List projects and files in a team |
+| `projects:read` | List projects and files in a team (v1 project endpoints — deprecated) |
+| `folders:read` | List folders, subfolders, and folder files (`/v2/folders`) — not usable by public OAuth apps |
+| `folder_metadata:read` | Folder metadata (`GET /v2/folders/:folder_id/meta`) |
 | `webhooks:read` | View webhook metadata |
 | `webhooks:write` | Create/update/delete webhooks |
 | `org:activity_log_read` | Activity logs (Enterprise admin only) |
@@ -457,6 +460,8 @@ def extract_tokens(file_key: str, token: str) -> dict:
 
 ### Recipe 6 — List projects and files in a team
 
+> ⚠️ Changed 2026-08-10: `GET /v1/teams/:team_id/projects`, `GET /v1/projects/:project_id/files`, and `GET /v1/projects/:project_id/meta` are **deprecated**. Replacements: `GET /v2/teams/:team_id/folders`, `GET /v2/folders/:folder_id/folders` (subfolders), `GET /v2/folders/:folder_id/files`, and `GET /v2/folders/:folder_id/meta`. These need the `folders:read` scope (`folder_metadata:read` for `/meta`), and `folders:read` cannot be used by public OAuth apps. On nested-folder plans the v1 team-projects endpoint returns only top-level folders. The v1 calls below still work. Sources: [changelog](https://developers.figma.com/docs/rest-api/changelog/), [Folders endpoints](https://developers.figma.com/docs/rest-api/folders-endpoints/).
+
 ```bash
 # Team projects
 curl "https://api.figma.com/v1/teams/TEAM_ID/projects" \

package/skills/github/skill.md

@@ -1,8 +1,8 @@
 # GitHub Skill
 
-> **Last validated:** 2026-08-02 | **API:** GitHub REST API + GraphQL API v4
+> **Last validated:** 2026-10-14 | **API:** GitHub REST API + GraphQL API v4
 > **REST base URL:** `https://api.github.com`
-> **API version header:** `X-GitHub-Api-Version: 2026-03-10` (current stable, released March 10, 2026)
+> **API version header:** `X-GitHub-Api-Version: 2026-03-10` (current stable, released March 10, 2026; still the latest as of 2026-10-14)
 > **Assumed product:** GitHub.com (cloud). GitHub Enterprise Server differs in base URL and some rate limits.
 >
 > **⚠️ Changed 2026-03-10:** REST API version `2026-03-10` shipped 26 breaking changes. `2022-11-28` still works — GitHub supports each version for at least 24 months after a successor ships — but all examples in this doc are pinned to `2026-03-10`. Changes most likely to affect automation:
@@ -113,6 +113,8 @@ Organization / User (owner)
 | **OAuth App** | User-delegated access (acting on behalf of a user) | Standard OAuth 2.0 bearer token |
 | **`GITHUB_TOKEN`** | Inside GitHub Actions workflows only | Auto-generated per-run; limited to the repository |
 
+> **⚠️ Changed 2026-08-14:** OAuth Apps can now get expiring user tokens: request the `offline_access` scope (or configure the app to always use expiring tokens) and you receive an access token valid for **8 hours** plus a refresh token valid for **6 months** without use. Refreshing returns a new token pair and invalidates the old one. Don't assume a refresh token is always present — non-expiring tokens are still possible depending on app configuration.
+
 ### Fine-grained PAT (recommended for automation)
 
 Fine-grained PATs are scoped to a single owner (user or org) and specific repositories, with per-permission grants instead of broad scopes.
@@ -170,6 +172,8 @@ curl -s https://api.github.com/repos/acme/api-service \
   -H "Authorization: Bearer ghs_..."
 ```
 
+> **⚠️ Changed 2026-10-02:** Installation tokens now use a stateless `ghs_APPID_JWT` format (rollout complete). The `ghs_` prefix and 1-hour expiry are unchanged, but tokens are now **~520 characters instead of 40**. Treat them as opaque strings: drop any 40-char/regex validation, and check DB column sizes, secret stores, proxies that cap `Authorization` header length, and log-redaction patterns. The temporary `X-GitHub-Stateless-S2S-Token` test header is ignored after 2026-11-30 — remove it.
+
 ### Required headers (always include)
 
 ```
@@ -589,6 +593,8 @@ curl -s -X POST "https://api.github.com/repos/acme/api-service/check-runs" \
 
 `conclusion` values: `success`, `failure`, `neutral`, `cancelled`, `skipped`, `timed_out`, `action_required`.
 
+> **⚠️ Changed 2026-10-01:** Check runs, workflow runs, and commit statuses — **including those created by third-party integrations via this API** — are now deleted after the repository's Actions retention period (default 90 days; max 400 for private repos, 90 for public). Previously they were kept 400+ days regardless. If you compute metrics from historical check runs/statuses, copy them to your own store.
+
 **Pitfall:** Check Runs require a **GitHub App token** (not a PAT) to render properly in the GitHub UI "Checks" tab. PATs can create check runs but they appear without the app icon and may have limited functionality.
 
 ---

package/skills/hubspot/skill.md

@@ -1,6 +1,6 @@
 # HubSpot Skill
 
-> **Last validated:** 2026-08-02 | **API:** HubSpot CRM API v3 (date-based versioning GA — March 30, 2026)
+> **Last validated:** 2026-10-14 | **API:** HubSpot CRM API v3 (date-based versioning GA — March 30, 2026; latest dated version `2026-09`, released Sep 8, 2026)
 > **Base URL:** `https://api.hubapi.com/crm/v3/objects/{objectType}`
 > **Assumed products:** CRM (Contacts, Companies, Deals) + Marketing Hub + Sales Hub
 >
@@ -16,6 +16,12 @@
 > - **Official SDKs support date-based versioning as of June 10, 2026**, generated from HubSpot's central API spec. If you pin SDK versions, upgrade before adopting `/YYYY-MM/` paths.
 > - **`hs_customer_agent_lead_status` became read-only July 13, 2026** — writes to this contact property now fail.
 > - Additive (July 2026): higher owner-property limits, larger Webhooks Journal batch sizes, and a historical API-usage chart in the developer portal.
+>
+> **⚠️ Changes since 2026-08:**
+> - **Legacy `/v1/`–`/v3/` API paths moved to unsupported status Sep 15, 2026** (no more bug, reliability, or security fixes); **enforcement September 2027**. The `/crm/v3/` paths in the recipes below still work today, but plan to migrate straight to date-based `/YYYY-MM/` paths — HubSpot says not to use v3/v4 as an intermediate step. v4 (e.g., Associations v4) support ends March 30, 2027.
+> - **Legacy private app creation disabled** — Sep 28, 2026 for new accounts, Oct 26, 2026 for existing accounts. Existing private apps keep working; new in-account integrations use **Service Keys** (see Authentication below).
+> - **`2026-09` API version (Sep 8, 2026):** admin-configured validation rules (conditional required properties, record-creator required properties, "Edit Associations" permission) are enforced on all CRM write paths in `/2026-09/` and later — expect `400 VALIDATION_ERROR` with codes like `MISSING_CONDITIONAL_REQUIRED_PROPERTY`. Pipeline/stage deletes also validate references by default from `2026-09`.
+> - **Pipelines API V1 sunset December 4, 2026** — migrate to the `2026-09` Pipelines API (`/crm/pipelines/2026-09/{objectType}`).
 
 ---
 
@@ -103,6 +109,8 @@ Custom properties are created via the Properties API and referenced by their `na
 
 ### Private App Token (recommended for automation)
 
+> ⚠️ Changed 2026-09-28: creating new legacy private apps is disabled (Sep 28, 2026 for accounts created on/after that date; Oct 26, 2026 for existing accounts). Existing private app tokens keep working. For new in-account integrations, create a **Service Key** instead (**Development → Keys → Service keys → Create service key**, add scopes, copy the key) and send it exactly the same way: `Authorization: Bearer {service_key}`. Service keys are REST-only — they cannot authenticate webhooks or UI extensions; use an app for those. Rotating a key expires the old one (immediately or after 7 days). Docs: https://developers.hubspot.com/docs/apps/developer-platform/build-apps/authentication/account-service-keys
+
 1. In HubSpot → Settings → Integrations → Private Apps → Create a private app.
 2. Select scopes (see table below).
 3. Copy the generated token — it is shown only once.

package/skills/jira/skill.md

@@ -1,6 +1,6 @@
 # Jira Skill
 
-> **Last validated:** 2026-08-02 | **API:** Jira Cloud REST API v3
+> **Last validated:** 2026-10-14 | **API:** Jira Cloud REST API v3
 > **Base URL:** `https://{your-domain}.atlassian.net/rest/api/3/`
 > **Assumed product:** Jira Cloud (Software or Service Management). Note differences from Jira Data Center where applicable.
 >
@@ -523,6 +523,8 @@ updated >= "2026-02-18"
 - Before creating, search: `summary ~ "your-dedup-key" AND project = PROJ` — if found, update instead of create.
 - Use a dedicated text custom field (e.g., `External ID`) for reliable deduplication.
 
+> ⚠️ Changed 2026-10-06: JQL `=`, `IN`, and `NOT IN` on text fields now do an exact *phrase* search: the phrase can appear anywhere in the field, not only as the whole value. `"External ID" = "zendesk:123"` can now also match a longer value that contains that phrase. After the search, check that the field value equals your key exactly before you treat a hit as a duplicate. Source: https://developer.atlassian.com/cloud/jira/platform/changelog/
+
 ---
 
 ## Reliability: rate limits, retries, idempotency

package/skills/linear/skill.md

@@ -1,6 +1,6 @@
 # Linear Skill
 
-> **Last validated:** 2026-08-02 | **API:** GraphQL (no versioned URL path)
+> **Last validated:** 2026-10-14 | **API:** GraphQL (no versioned URL path)
 > **GraphQL endpoint:** `https://api.linear.app/graphql`
 > **Assumed product:** Linear (cloud). The same API powers all Linear workspaces.
 > **⚠️ OAuth note:** Apps created after October 1, 2025 issue short-lived access tokens (24 hr) and require refresh token rotation. Apps created before that date used long-lived tokens until the April 1, 2026 migration deadline, which has now passed — the migration endpoint `POST /oauth/migrate_old_token` returns **`410 Gone`** as of May 21, 2026. Un-migrated apps must re-authorize from scratch.

package/skills/monday/skill.md

@@ -1,11 +1,13 @@
 # Monday.com Skill
 
-> **Last validated:** 2026-08-02 | **API:** monday.com GraphQL API | **Current version:** `2026-07` (July 1, 2026)
+> **Last validated:** 2026-10-14 | **API:** monday.com GraphQL API | **Current version:** `2026-07` (July 1, 2026)
 > **Note:** monday.com uses GraphQL exclusively — not REST. All requests go to a single endpoint.
-> **Versions:** RC=`2026-10` (deprecates 2027-01-15) | Current=`2026-07` | Maintenance=`2026-04` | Deprecated: `2025-10`, `2025-01`, `2024-10` (routed to `2025-04` as of Feb 15, 2026)
+> **Versions:** RC=`2026-10`, `2027-01` | Current=`2026-07` | Maintenance=`2026-04` | Deprecated: `2025-10`, `2025-01`, `2024-10` (routed to `2025-04` as of Feb 15, 2026)
 >
 > **⚠️ Changed 2026-07-01:** `2026-07` is now the stable Current version and the default when no `API-Version` header is passed. `2026-04` moved to Maintenance — bug fixes only, no new features. All examples below pin `2026-07`.
 >
+> **Note (2026-10-14):** the published schedule had `2026-10` becoming Current on Oct 1, 2026, but the live API (`query { versions { kind value } }`) still reports `2026-07` as Current and `2026-10` as RC. Keep pinning `2026-07` until `2026-10` is actually promoted.
+>
 > monday.com announces deprecations at least six months ahead, so a version reaching Maintenance is your migration signal, not an emergency.
 
 ---
@@ -146,7 +148,7 @@ Or with API version header (recommended — always pin a specific version):
 API-Version: 2026-07
 ```
 
-> **Important:** Always pin a version header in production. Without it, requests default to `Current`, which changes quarterly and can break your integration. Current as of 2026-08-02: `2026-07`.
+> **Important:** Always pin a version header in production. Without it, requests default to `Current`, which changes quarterly and can break your integration. Current as of 2026-10-14: `2026-07`.
 
 ### OAuth 2.0 scopes (least privilege)
 

package/skills/notion/skill.md

@@ -1,6 +1,6 @@
 # Notion Skill
 
-> **Last validated:** 2026-08-02 | **API version:** `2026-03-11` (latest stable)
+> **Last validated:** 2026-10-14 | **API version:** `2026-03-11` (latest stable)
 > **REST base URL:** `https://api.notion.com/v1/`
 > **Assumed product:** Notion (cloud). The `Notion-Version: 2026-03-11` header is required on every request.
 >
@@ -632,13 +632,16 @@ Always paginate using `start_cursor` + `has_more` — do not assume 100 results
 
 ### Rate limits
 
+> **⚠️ Changed 2026-09-09:** the flat "~3 req/sec" average is replaced by a fixed 60-second window per connection, sized by workspace plan, plus a separate shared per-workspace budget and some per-endpoint limits. Since 2026-09-24, `429`/`529` bodies carry `additional_data.retry_after` and `additional_data.rate_limit_reason`. Source: [Request limits](https://developers.notion.com/reference/request-limits), [changelog](https://developers.notion.com/page/changelog).
+
 | Limit | Value | Notes |
 |-------|-------|-------|
-| Global | **3 req/sec average** | Burst above this is allowed; sustained throughput is ~3/sec |
-| Response on limit | HTTP `429`, code `"rate_limited"` | |
-| Backoff header | `Retry-After` (integer seconds) | Always honour this value |
-
-There is no separate rate limit per endpoint — it's a single workspace-level budget.
+| Per connection | **600 req/min** (Business, Enterprise) / **180 req/min** (all other plans) | Fixed 60-second window; spend at any pace within it. `Retry-After` ≤ 60 s |
+| Per workspace | Shared budget across all of the workspace's connections, scales with plan | Can throttle you even when your connection is under its limit; `Retry-After` may exceed 60 s |
+| Per endpoint | Some endpoints have their own limits | `rate_limit_reason: public_api_endpoint_rate_limit` |
+| Response on limit | HTTP `429`, code `"rate_limited"`; `additional_data.rate_limit_reason` says which limit | `public_api_request_blocked` means API access is restricted — do **not** retry |
+| Overload | HTTP `529`, code `"service_overload"` | Retry exactly like a `429` |
+| Backoff header | `Retry-After` (integer seconds), echoed as `additional_data.retry_after` (string) | Always honour this value |
 
 ### Retry with exponential backoff
 
@@ -655,7 +658,7 @@ def notion_request(method: str, url: str, **kwargs) -> dict:
     })
     for attempt in range(5):
         resp = requests.request(method, url, headers=headers, **kwargs)
-        if resp.status_code == 429:
+        if resp.status_code in (429, 529):
             wait = int(resp.headers.get("Retry-After", 2 ** attempt))
             time.sleep(wait)
             continue
@@ -730,6 +733,7 @@ def upsert_page(database_id: str, external_id: str, properties: dict) -> dict:
 | 503 | `service_unavailable` | Notion offline or request timed out (60s limit) | Retry; break up large block payloads |
 | 503 | `database_connection_unavailable` | Notion DB unreachable | Retry with backoff |
 | 504 | `gateway_timeout` | Request processing timed out | Reduce payload size; retry |
+| 529 | `service_overload` | Notion temporarily overloaded | Wait `Retry-After` seconds; retry like a `429` |
 
 ### Common issues
 
@@ -805,7 +809,7 @@ All integration activity is visible in **Notion → Settings → Connections** (
 - [ ] `POST /v1/search` with `query: "<page title>"` finds the test page
 - [ ] Request sent without `Notion-Version` header returns `400` with code `missing_version`
 - [ ] Request to a page not shared with integration returns `404` with code `object_not_found`
-- [ ] Rapid requests (>3/sec) trigger `429`; `Retry-After` header is present; retry succeeds
+- [ ] Rapid requests (>180/min, or >600/min on Business/Enterprise) trigger `429`; `Retry-After` header is present; retry succeeds
 - [ ] Payload with 101 blocks in `children` returns `validation_error`
 - [ ] Upsert pattern: create, then call upsert again with same external ID → updates, does not duplicate
 

package/skills/salesforce/skill.md

@@ -1,14 +1,18 @@
 # Salesforce Skill
 
-> **Last validated:** 2026-08-02 | **API:** Salesforce REST API + Bulk API v2 | **Version:** v67.0 (Summer '26)
+> **Last validated:** 2026-10-14 | **API:** Salesforce REST API + Bulk API v2 | **Version:** v67.0 (Summer '26)
 > **Assumed product:** Sales Cloud (CRM). Adjust object availability for other clouds.
-> **Version note:** v64.0 = Summer '25, v65.0 = Winter '26, v66.0 = Spring '26, **v67.0 = Summer '26 (current GA)**. All examples in this doc pin `/services/data/v67.0/`. Older versions stay supported under Salesforce's ~3-year API support window.
+> **Version note:** v64.0 = Summer '25, v65.0 = Winter '26, v66.0 = Spring '26, **v67.0 = Summer '26**, v68.0 = Winter '27 (rolling out Oct 2026). All examples in this doc pin `/services/data/v67.0/`. Older versions stay supported under Salesforce's ~3-year API support window.
 >
-> **Re-confirmed 2026-08-02:** v67.0 is still the highest published REST API version — Winter '27 / v68.0 has not shipped yet. Verified against the [Versions resource doc](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_versions.htm), which **is** readable by plain HTTP fetchers, unlike the `help.salesforce.com` release-notes page (issue https://github.com/Shanksg/clawskills/issues/12). Use the versions doc for automated freshness checks and the release notes only for delta review in a browser.
+> **⚠️ Checked 2026-10-14 — Winter '27 (v68.0) reviewed, examples stay on v67.0 until rollout completes:** the [Winter '27 API release notes](https://help.salesforce.com/s/articleView?id=release-notes.rn_api.htm&release=264&type=5) confirm v68.0 and list **no breaking changes to the sObject REST or Bulk API 2.0 calls in this doc**. The rollout is not finished: Salesforce's Trust status API (`https://api.status.salesforce.com/v1/maintenances`, filter `name=Winter '27 Major Release`) shows the largest wave scheduled for **2026-10-17**, and orgs not yet upgraded cannot call `/v68.0/`. So examples keep `/v67.0/`, which works everywhere; once `GET /services/data/` on your org lists 68.0, switching is a find-and-replace. Other v68.0 items relevant to integrations:
+> - **`latest` version alias:** `/services/data/latest/...` routes to the newest version your org supports. Don't use it in production — it moves under you three times a year, the same reason this doc pins a number.
+> - **Instanced URLs:** API traffic to instanced URLs (e.g. `na123.salesforce.com`) **stops in sandboxes in Winter '27**; production enforcement was postponed again, to **Spring '27**. Always call your My Domain URL (`https://<MyDomainName>.my.salesforce.com`).
+> - **Suspicious-activity protection:** if Salesforce detects suspicious API data access it may terminate the session or freeze the integration user and email the admin. Treat a `401 INVALID_SESSION_ID` as "re-authenticate once"; if that fails, stop and alert — a frozen user needs an admin.
+> - SOAP `login()` needs the *Use Any API Auth* permission from 2026-12-01 and retires for API versions 31.0–64.0 in Summer '27; Platform API versions 31.0–40.0 are being retired. Neither affects this doc, which is REST-only on v67.0.
 >
-> **⚠️ Announced for Winter '27:** enforcement of the API traffic URL requirement (first introduced in Summer '25, repeatedly postponed) lands in Winter '27. If you still call org URLs that are not the My Domain / enhanced-domain form, fix that before v68.0. Separately, SOAP `login()` retires for API versions 31.0–64.0 in Summer '27 — not used by this doc, which is REST-only.
+> developer.salesforce.com now returns `403` to non-browser fetchers (the versions doc moved to https://developer.salesforce.com/docs/platform/api-rest/guide/resources-versions.html); the help.salesforce.com release notes render in headless Chrome (`--headless=new --dump-dom`). See issue https://github.com/Shanksg/clawskills/issues/12.
 >
-> **Sources:** [REST API versions](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_versions.htm) · [Summer '26 API release notes](https://help.salesforce.com/s/articleView?id=release-notes.rn_api.htm&release=262&type=5) (JS-rendered; open in a real browser)
+> **Sources:** [REST API versions](https://developer.salesforce.com/docs/platform/api-rest/guide/resources-versions.html) · [Winter '27 API release notes](https://help.salesforce.com/s/articleView?id=release-notes.rn_api.htm&release=264&type=5) (JS-rendered; open in a browser or headless Chrome)
 
 ---
 

package/skills/servicenow/skill.md

@@ -1,15 +1,17 @@
 # ServiceNow Skill
 
-> **Last validated:** 2026-08-02 | **API:** ServiceNow REST Table API + Attachment API | **Current release:** Australia (Early Availability March 12, 2026) — re-confirmed against servicenow.com/docs on 2026-08-02
+> **Last validated:** 2026-10-14 | **API:** ServiceNow REST Table API + Attachment API | **Current release:** Brazil (Early Availability September 24, 2026) — confirmed against servicenow.com/docs on 2026-10-14
 > **Base URL:** `https://{instance-name}.service-now.com/api/now/`
 > **Assumed product:** ITSM (Incident, Problem, Change, Request). All APIs are available on other ServiceNow apps using the same Table API pattern.
 >
-> **Release history:** Xanadu (2024) → Yokohama (March 2025) → Zurich (2025) → **Australia** (Early Availability March 12, 2026, current). The Table API and Attachment API request/response formats are unchanged across all of these — recipes in this doc work on any of them.
+> **Release history:** Xanadu (2024) → Yokohama (March 2025) → Zurich (2025) → Australia (Early Availability March 12, 2026) → **Brazil** (Early Availability September 24, 2026, current). The Table API and Attachment API request/response formats are unchanged across all of these — recipes in this doc work on any of them.
 >
 > **⚠️ Updated 2026-08-02:** this doc previously tracked Yokohama, two releases behind. Doc links now point at the `australia-*` bundles. What Australia adds that matters for integrations:
 > - **Attachment attribute endpoints** — `GET`/`DELETE /now/attachment/{sys_id}/attributes` and `GET`/`DELETE /now/attachment/{sys_id}/attributes/{key}` for reading and managing attachment metadata.
 > - **CopyDynamicSchemaAPI** — programmatic copying of schema configurations.
 >
+> **⚠️ Changed 2026-09-24:** Brazil reached Early Availability. Doc links now point at the Brazil docs. The Brazil API release notes list no changes to the Table, Attachment, or Import Set APIs or to OAuth — recipes are unchanged. New REST APIs in Brazil (Developer Sandbox Management, Stream Connect Schema Registry, Sales Cart) are outside this doc's ITSM scope.
+>
 > Instance versions lag the family release; check **System Diagnostics → Stats** on your instance rather than assuming it runs the newest family.
 
 ---
@@ -529,15 +531,15 @@ ServiceNow uses optimistic locking internally. If two concurrent PATCH requests
 
 ## Sources
 
-- ServiceNow Table API (Australia): https://www.servicenow.com/docs/bundle/australia-api-reference/page/integrate/inbound-rest/concept/c_TableAPI.html
-- Australia API Release Notes: https://www.servicenow.com/docs/bundle/australia-release-notes/page/release-notes/now-platform-app-engine/api-rn.html
+- ServiceNow Table API (Brazil): https://www.servicenow.com/docs/r/brazil/api-reference/rest-apis/c_TableAPI.html
+- Brazil API Release Notes: https://www.servicenow.com/docs/r/brazil/release-notes/api-rn-static.html
 - New REST APIs by release (Yokohama-era overview, still useful background): https://www.servicenow.com/community/developer-blog/yokohama-integration-landscape-new-web-service-rest-apis/ba-p/3166555
-- Australia Release Notes: https://www.servicenow.com/docs/bundle/australia-release-notes/page/release-notes/family-release-notes.html
+- Brazil Release Notes: https://www.servicenow.com/docs/r/brazil/release-notes/family-release-notes.html
 - Attachment API: https://developer.servicenow.com/dev.do#!/reference/api/australia/rest/c_AttachmentAPI
 - OAuth 2.0 setup: https://developer.servicenow.com/dev.do#!/guides/australia/now-platform/tpb-oauth/c_OAuth2AuthenticationWithSNOW
 - Encoded Query Strings: https://developer.servicenow.com/dev.do#!/guides/australia/now-platform/tpb-ui/c_EncodedQueryStrings
 - Import Sets: https://developer.servicenow.com/dev.do#!/reference/api/australia/rest/c_ImportSetAPI
 - Outbound REST: https://developer.servicenow.com/dev.do#!/learn/learning-plans/australia/new_to_servicenow/app_store_learnv2_rest_australia_outbound_rest_integrations
 - Business Rules: https://developer.servicenow.com/dev.do#!/guides/australia/now-platform/tpb-glide/c_BusinessRulesAPI
-- Flow Designer: https://docs.servicenow.com/bundle/australia-build-workflows/page/administer/flow-designer/concept/flow-designer.html
+- Flow Designer: https://www.servicenow.com/docs/r/brazil/build-workflows/workflow-studio/workflow-studio-flows-subflows-and-actions-landing.html
 - API Rate Limits best practices: https://developer.servicenow.com/dev.do#!/guides/australia/now-platform/tpb-rest/c_RESTAPIBestPractices

package/skills/slack/skill.md

@@ -1,6 +1,6 @@
 # Slack Skill
 
-> **Last validated:** 2026-08-02 | **API:** Slack Web API (no versioned URL path)
+> **Last validated:** 2026-10-14 | **API:** Slack Web API (no versioned URL path)
 > **REST base URL:** `https://slack.com/api/`
 > **Assumed product:** Slack (cloud). Slack Enterprise Grid adds org-level APIs but the core methods are identical.
 >
@@ -9,6 +9,7 @@
 > - **System notifications now come from the "Slack" user (`USLACK`), not Slackbot** (2026-06-17). Any handler that filters or routes on Slackbot's user ID must be updated.
 > - **Optional OAuth scopes** (2026-03-16): app manifests support `bot_optional` and `user_optional` to mark scopes as optional at install time.
 > - **`assistant.threads.setStatus`** accepts `chat:write` as well as `assistant:write` (2026-03-05); `assistant:write` is being phased out.
+> - **Agent sessions replace `assistant.threads.*`** (2026-08-20): `agents.sessions.setStatus` replaces `assistant.threads.setStatus` (bot token, `chat:write`; `status` is one of `active`, `processing`, `suspended`, `closed`) and `agents.sessions.rename` replaces `assistant.threads.setTitle`. Existing `assistant.threads` calls keep working through a compatibility bridge for now; migrate new code to `agents.sessions.*`. New event: `agent_session_stopped` (user stopped your agent).
 > - **Node SDK v8 / Bolt for JS v5** (2026-07-14/15) require Node.js 20+, moved from axios to native `fetch`, and removed Workflow Steps from Apps. This doc's examples are HTTP-level and unaffected, but pinned SDK versions in your own code are not.
 >
 > **Docs moved:** `api.slack.com` now redirects to `docs.slack.dev`. The Web API endpoints themselves are unchanged.

package/skills/stripe/skill.md

@@ -1,9 +1,17 @@
 # Stripe Skill
 
-> **Last validated:** 2026-08-02 | **API version:** `2026-07-29.dahlia` (latest stable)
+> **Last validated:** 2026-10-14 | **API version:** `2026-09-30.endive` (latest stable)
 > **REST base URL:** `https://api.stripe.com/v1/`
 > **Assumed product:** Stripe Payments + Billing. Stripe Connect (multi-account platform) is covered in the Auth and Recipes sections.
 >
+> **⚠️ Changed 2026-09-30:** Stripe opened the **Endive** release train (`2026-09-30.endive`), succeeding Dahlia (last Dahlia version: `2026-08-26.dahlia`, additive only). Breaking changes in `2026-09-30.endive` that affect server-side integrations ([changelog](https://docs.stripe.com/changelog/endive)):
+> - **`payment_method_types` is no longer writable** on PaymentIntent create/update/confirm, SetupIntent create/update, or Checkout Session create — passing it returns `400` `payment_method_types_no_longer_supported`. Use dynamic payment methods (`automatic_payment_methods[enabled]=true`, as the recipes below already do), optionally with `excluded_payment_method_types`, or `allowed_payment_method_types` for an explicit list. The field remains read-only on the object.
+> - **`billing_cycle_anchor`** on subscription update/resume and `invoices/create_preview` now takes an object: `billing_cycle_anchor[type]=now` instead of `billing_cycle_anchor=now`.
+> - **Connect:** the generic fraud rejection reason is replaced by specific fraud reasons, platform-initiated rejections are distinguished from Stripe's, and errors are returned for eventually-due requirements — treat these as open enums.
+> - The rest (Financial Connections `countries` → `country`, PayTo field removals, SEPA billing-address enforcement, BLIK decline codes, Reserve enums, Stripe.js payment request button deprecation) don't touch the REST calls in this doc.
+>
+> Also new (non-breaking): subscriptions can be paused on demand (`POST /v1/subscriptions/{id}/pause`, flexible billing mode only) — `paused` status is no longer only a trial-end outcome; check `status_details`.
+>
 > **⚠️ Changed 2026-03-25:** Stripe opened the **Dahlia** release train (`2026-03-25.dahlia`), succeeding Clover. Only the first version in a train carries breaking changes; later Dahlia versions (`2026-04-22`, `2026-05-27`, `2026-06-24`, `2026-07-29`) are additive. Breaking changes in `2026-03-25.dahlia` that affect server-side integrations:
 > - **Connect / Capabilities API:** risk requirements added to capability objects — code that enumerates requirement types must tolerate the new entries.
 > - **Subscriptions:** a new `retention_policy` cancellation reason can now appear on `cancellation_details.reason`. Treat the reason field as an open enum.
@@ -11,7 +19,7 @@
 > - **Issuing:** the Visa card reference ID is now optional on token card references.
 > - The remaining breaking changes are in Stripe.js / Elements (renamed `initCheckout()` → `initCheckoutElements()`, `initEmbeddedCheckout()` → `createEmbeddedCheckoutPage()`, `elements.update()` now returns a Promise) and affect browser code, not the REST calls in this doc.
 >
-> `2026-02-25.clover` still works — Stripe supports old versions indefinitely for existing accounts — but examples below pin `2026-07-29.dahlia`.
+> Older versions (`2026-07-29.dahlia`, `2026-02-25.clover`) still work — Stripe supports old versions indefinitely for existing accounts — but examples below pin `2026-09-30.endive`.
 
 ---
 
@@ -93,7 +101,7 @@ requires_payment_method → requires_confirmation → requires_action → proces
 | `incomplete_expired` | Initial 23-hour window expired without payment |
 | `past_due` | Latest renewal invoice failed; automatic retries in progress |
 | `unpaid` | Retries exhausted; subscription remains but no more attempts |
-| `paused` | Trial ended without a default payment method |
+| `paused` | Trial ended without a default payment method, or paused on demand via `/pause` (see `status_details`) |
 | `canceled` | Terminal; cannot be reactivated |
 
 ### Amounts and currencies
@@ -145,7 +153,7 @@ Always pin the API version explicitly to avoid unexpected behaviour when Stripe
 ```bash
 curl https://api.stripe.com/v1/payment_intents \
   -u "sk_test_...:" \
-  -H "Stripe-Version: 2026-07-29.dahlia" \
+  -H "Stripe-Version: 2026-09-30.endive" \
   -d amount=2000 \
   -d currency=usd
 ```

package/skills/zendesk/skill.md

@@ -1,6 +1,6 @@
 # Zendesk Skill
 
-> **Last validated:** 2026-08-02 | **API:** Zendesk Support REST API v2
+> **Last validated:** 2026-10-14 | **API:** Zendesk Support REST API v2
 > **Base URL:** `https://{subdomain}.zendesk.com/api/v2/`
 >
 > **⚠️ Breaking changes since 2024:**
@@ -19,6 +19,10 @@
 > - **AI Agents API (deprecation 2026-07-01, announced 2026-05-19):** the legacy `*.ultimate.ai` base URL is retired — use `{subdomain}.zendesk.com/ai-agents/api`.
 > - **Jira integration (2026-06-24):** Zendesk is delisting Jira Integration V2 and restoring the original version. Relevant to the [Zendesk → Jira bug escalation playbook](../../playbooks/zendesk-jira-bug-escalation.md), which uses the two products' REST APIs directly and is therefore unaffected by the marketplace app change.
 >
+> **Checked 2026-10-14:**
+> - **⚠️ Changed 2026-08-26: `POST /api/v2/oauth/tokens` (Create Token) deprecated.** The reference now marks it as no longer available. Use Create Token for Grant Type (`POST /oauth/tokens`, the token endpoint listed under OAuth 2.0 below) instead. This doc's OAuth flow already uses that endpoint.
+> - **Help Center Templating API v1–v3 end-of-life (starts 2026-09-14):** this affects Help Center themes only, not the Support endpoints in this doc.
+>
 > **Source:** https://developer.zendesk.com/api-reference/changelog/changelog/
 
 ## What this skill enables