@acedatacloud/skills 2026.726.3 → 2026.726.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@acedatacloud/skills",
-  "version": "2026.726.3",
+  "version": "2026.726.5",
   "description": "Agent Skills for AceDataCloud AI services — music, image, video generation, LLM chat, web search. Compatible with Claude Code, GitHub Copilot, Gemini CLI, OpenAI Codex, and 30+ AI coding agents.",
   "keywords": [
     "agent-skills",

package/skills/google-ads/SKILL.md

@@ -5,8 +5,8 @@ when_to_use: |
   Trigger when the user wants Google Ads reporting — list accessible
   customers, campaign / ad-group / keyword performance, spend and
   conversions. Read via GAQL. Needs the OAuth token PLUS a platform
-  developer token and a login-customer-id; if those env vars are
-  absent the connector isn't fully provisioned yet — tell the user.
+  developer token; if the developer token is absent the connector
+  isn't fully provisioned yet — tell the user.
 connections: [google/ads]
 allowed_tools: [Bash]
 license: Apache-2.0
@@ -15,26 +15,31 @@ metadata:
   version: "1.0"
 ---
 
-Query the **Google Ads API** via `curl + jq`. Three credentials are needed:
+Query the **Google Ads API** via `curl + jq`. Two credentials plus one context
+header:
 
 - `$GOOGLE_ADS_TOKEN` — the user's OAuth bearer (`adwords` scope) →
   `Authorization: Bearer $GOOGLE_ADS_TOKEN`
 - `$GOOGLE_ADS_DEVELOPER_TOKEN` — the platform's developer token (injected
   server-side) → header `developer-token: $GOOGLE_ADS_DEVELOPER_TOKEN`
-- `login-customer-id` — the manager (MCC) id under which calls are made; use the
-  target customer id, or `$GOOGLE_ADS_LOGIN_CUSTOMER_ID` if set (digits only, no
-  dashes).
+- `login-customer-id` — **only for manager (MCC) scoped calls**: the manager id
+  the request runs under, or `$GOOGLE_ADS_LOGIN_CUSTOMER_ID` if set (digits
+  only, no dashes). Not needed by `customers:listAccessibleCustomers`.
 
 > **API version:** the base is `https://googleads.googleapis.com/<vNN>`. Google
-> ships a new `vNN` every ~4 months and retires old ones — set `VER` to the
-> **current** supported version (check developers.google.com/google-ads/api
-> release notes); the example uses `v18`.
+> ships a new `vNN` every ~4 months and retires old ones, so a hardcoded version
+> eventually stops working. The example uses `v25` (supported as of 2026-07). If
+> **every** call 404s, the version is unavailable — either retired or not yet
+> released. Probe `customers:listAccessibleCustomers`: a supported version
+> answers 401/200, an unavailable one 404. Step **down** one version at a time
+> from the example, and check Google's supported-versions table before assuming
+> a newer `vNN` exists.
 
 If `$GOOGLE_ADS_DEVELOPER_TOKEN` is empty, the connector isn't fully provisioned —
 say so rather than calling the API (it would 401/DEVELOPER_TOKEN_NOT_APPROVED).
 
 ```bash
-VER="v18"; BASE="https://googleads.googleapis.com/$VER"
+VER="v25"; BASE="https://googleads.googleapis.com/$VER"
 AUTH="Authorization: Bearer $GOOGLE_ADS_TOKEN"; DEV="developer-token: $GOOGLE_ADS_DEVELOPER_TOKEN"
 # Customers the OAuth user can access (ids are returned as customers/<id>)
 curl -sS -H "$AUTH" -H "$DEV" "$BASE/customers:listAccessibleCustomers" | jq '.resourceNames'
@@ -44,7 +49,10 @@ curl -sS -H "$AUTH" -H "$DEV" "$BASE/customers:listAccessibleCustomers" | jq '.r
 
 ```bash
 CID="1234567890"   # target customer id, digits only
-curl -sS -H "$AUTH" -H "$DEV" -H "login-customer-id: ${GOOGLE_ADS_LOGIN_CUSTOMER_ID:-$CID}" \
+# Manager (MCC) access → send login-customer-id; direct access → drop the header.
+# Array, not a plain string: the header value contains a space and would split.
+LOGIN=(); [ -n "$GOOGLE_ADS_LOGIN_CUSTOMER_ID" ] && LOGIN=(-H "login-customer-id: $GOOGLE_ADS_LOGIN_CUSTOMER_ID")
+curl -sS -H "$AUTH" -H "$DEV" "${LOGIN[@]}" \
   -H "Content-Type: application/json" -d '{
   "query":"SELECT campaign.name, metrics.cost_micros, metrics.clicks, metrics.conversions FROM campaign WHERE segments.date DURING LAST_30_DAYS ORDER BY metrics.cost_micros DESC"
 }' "$BASE/customers/$CID/googleAds:searchStream" \
@@ -56,8 +64,14 @@ GAQL resources: `campaign`, `ad_group`, `ad_group_criterion` (keywords),
 
 ## Gotchas
 
-- **Three headers, not one.** Missing `developer-token` or `login-customer-id`
-  is the #1 cause of 401/403 here.
+- **A 404 on *every* endpoint points at `VER`, not at credentials** — the
+  version is retired or unreleased. A 404 on a *single* call is about that call:
+  a missing resource (bad customer id) or a wrong path. Sanity-check the version
+  with `customers:listAccessibleCustomers` before debugging auth.
+- **Two credentials plus a context header.** `developer-token` is required on
+  every call; `login-customer-id` is only needed when acting under a manager
+  (MCC) account — `customers:listAccessibleCustomers` works without it. Omitting
+  it on a manager-scoped call is the #1 cause of 401/403 here.
 - Customer ids are **digits only** in URLs/headers (strip the dashes from
   `123-456-7890`).
 - `searchStream` returns an array of chunks each with `.results[]` — flatten with

package/skills/wordpress/SKILL.md

@@ -9,11 +9,11 @@ when_to_use: |
   This skill is for self-hosted WordPress (Application Password auth),
   not WordPress.com.
 connections: [wordpress]
-allowed_tools: [Bash]
+allowed_tools: [Bash, publish_artifact]
 license: Apache-2.0
 metadata:
   author: acedatacloud
-  version: "1.0"
+  version: "1.1"
 ---
 
 Drive the **WordPress REST API** (`/wp-json/wp/v2`) with `curl + jq`.
@@ -36,27 +36,54 @@ API="$SITE/wp-json/wp/v2"
 WP=(curl -sS --fail-with-body -u "$WORDPRESS_USERNAME:$WORDPRESS_APP_PASSWORD")
 ```
 
+> **Don't add `-L`/`--location` to these calls.** A redirect usually means the
+> site URL is wrong. curl strips the `Authorization` header when a redirect
+> crosses host or scheme (e.g. `http`→`https`, apex→`www`) — exactly the cases
+> that occur here — so the followed request runs **unauthenticated** and can
+> return the site's HTML page with HTTP 200: it looks like success but wrote
+> nothing. Fix the URL instead (see the `/wp-json` gotcha below).
+
+
 Errors come back as `{"code": "...", "message": "...", "data": {"status": 401}}` —
 show `message` verbatim. Common codes:
 
 | HTTP | Meaning | What to tell the user |
 |------|---------|-----------------------|
 | 401 | `incorrect_password` / bad Basic auth | Application Password wrong or revoked → regenerate it and reconnect the WordPress connector |
+| 401 | `rest_not_logged_in` on a plain-`http://` site | Application Passwords are disabled without HTTPS → the user must enable HTTPS |
 | 403 | `rest_cannot_create` / insufficient role | The user's role can't publish; needs Author/Editor/Admin, or Application Passwords are disabled on the site |
 | 404 | `rest_no_route` | REST API disabled or a security plugin blocks `/wp-json` → the user must re-enable it |
 | 400 | `rest_invalid_param` | Bad field (e.g. unknown category id) → fix and retry |
+| 500 | `rest_upload_sideload_error` | `wp-content/uploads` isn't writable by the web server → the user must fix directory permissions |
+
+> **`content` is HTML, not Markdown.** Raw Markdown renders literally. `pandoc` is
+> **not installed** — convert with Python's `markdown` package (preinstalled in the
+> sandbox). If the import ever fails, `pip install markdown` first, then:
+>
+> ```bash
+> HTML=$(python3 -c "
+> import sys, markdown
+> print(markdown.markdown(sys.stdin.read(), extensions=['fenced_code','tables']))
+> " <<'MD'
+> ## 标题
+>
+> 正文 **粗体**
+> MD
+> )
+> ```
 
-> **`content` is HTML, not Markdown.** Convert Markdown to HTML first
-> (`pandoc -f markdown -t html`, or a simple converter). Raw Markdown renders literally.
 
 ## Step 0 — verify the connection first
 
 ```bash
-"${WP[@]}" "$API/users/me" | jq '{id, name, slug, roles: (.roles // [])}'
+"${WP[@]}" "$API/users/me?context=edit" | jq '{id, name, slug, roles}'
 ```
 
-A 200 with your user object confirms the site URL, username, and Application
-Password all work. If this fails, stop and surface the error — don't attempt writes.
+`context=edit` is required — without it WP omits `roles`/`capabilities` entirely,
+so you cannot tell whether the account may publish. A 200 with `roles` containing
+`administrator`, `editor` or `author` confirms the site URL, username, Application
+Password **and** publish permission. If this fails, stop and surface the error —
+don't attempt writes.
 
 ## Publish or draft a post
 
@@ -87,6 +114,62 @@ jq -n --arg t "标题" --arg c "<p>正文</p>" --arg e "一句话摘要" \
 - Update a post: `POST $API/posts/<id>` with any subset of fields (WP REST uses
   POST, not PUT, for updates).
 - Delete (trash) a post: `"${WP[@]}" -X DELETE "$API/posts/<id>"`.
+- Schedule a post: `{"status":"future","date_gmt":"2030-01-01T00:00:00"}` (UTC,
+  no trailing `Z`).
+
+## SEO fields that actually matter
+
+WordPress core emits `<link rel="canonical">` on its own but ships **no meta
+description tag at all** — that only appears if the site runs an SEO plugin
+(Yoast, Rank Math, SEOPress) or a theme that renders one. Those consume the
+post's `excerpt`, so setting `excerpt` is what makes a good description possible;
+it does nothing on a bare core install. For an SEO post always set:
+
+| Field | Why |
+|---|---|
+| `slug` | The permalink. Set it explicitly to a short ASCII keyword phrase — otherwise a CJK title becomes a percent-encoded URL. |
+| `excerpt` | Source for the SEO plugin's meta description and for list-page summaries. One sentence. |
+| `categories` / `tags` | Internal linking + topic clustering. |
+| `featured_media` | Social/OG card image. |
+| media `alt_text` | Image SEO + accessibility. Set it on the media object (below). |
+
+
+```bash
+jq -n --arg s "claude-api-guide" --argjson c 3 --argjson m 9 \
+  '{title:"如何稳定调用 Claude API：完整对接指南",
+    slug:$s,
+    content:"<h2>小标题</h2><p>正文</p>",
+    excerpt:"一句话摘要，用于 meta description。",
+    status:"publish", categories:[$c], featured_media:$m}' \
+| "${WP[@]}" -X POST "$API/posts" -H "Content-Type: application/json" -d @- \
+| jq '{id, status, slug, link}'
+```
+
+## Before publishing: check for a duplicate
+
+**WordPress will NOT reject a duplicate slug — it silently appends `-2`,** so an
+unattended/scheduled run that reposts the same article creates an endless trail of
+near-identical URLs that compete with each other in search. Always pre-check:
+
+```bash
+SLUG="claude-api-guide"
+# Fail CLOSED at BOTH steps: a failed request, or a 200 that isn't a JSON array
+# (HTML from a redirect/permalink issue, or an error object), must abort — never
+# fall through and create the duplicate this check exists to prevent.
+if ! LOOKUP=$("${WP[@]}" "$API/posts?slug=$SLUG&status=publish,draft,future&_fields=id,link"); then
+  echo "duplicate check failed (request error) — aborting" >&2; exit 1
+fi
+if ! EXISTING=$(printf '%s' "$LOOKUP" | jq -er 'if type=="array" then (.[0].id // "") else error("not a JSON array") end'); then
+  echo "duplicate check failed (unexpected response) — aborting" >&2; exit 1
+fi
+if [ -n "$EXISTING" ]; then
+  echo "already exists as post $EXISTING — update it instead of creating a new one"
+  # update:  "${WP[@]}" -X POST "$API/posts/$EXISTING" ...
+fi
+```
+
+Prefer **updating** the existing post over creating a near-duplicate. This matters
+most in Scheduled Tasks, where nobody is watching the output.
 
 ## List / read posts
 
@@ -125,22 +208,40 @@ MEDIA_ID=$("${WP[@]}" -X POST "$API/media" \
   -H "Content-Type: image/png" \
   --data-binary @"$FILE" | jq -r '.id')
 echo "media id=$MEDIA_ID"
+
+# Set alt text (image SEO + accessibility) — a separate call on the media object.
+jq -n --arg a "Claude API 架构图" '{alt_text:$a}' \
+| "${WP[@]}" -X POST "$API/media/$MEDIA_ID" \
+    -H "Content-Type: application/json" -d @- | jq '{id, alt_text}'
+
 # Attach as the post's featured image:
 #   add  "featured_media": <MEDIA_ID>  to the post body.
 ```
 
 ## Gotchas
 
-- **HTTPS + Application Passwords are required.** On plain `http://`, WordPress
-  disables Application Passwords → every call 401s. Tell the user to enable HTTPS.
+- **HTTPS is effectively required for Application Passwords.** WP gates them on
+  `wp_is_application_passwords_available()`, which is false on a plain-`http://`
+  production site → authenticated calls fail with `rest_not_logged_in` (401). (The
+  gate is filterable and is bypassed when `WP_ENVIRONMENT_TYPE` is `local`, so a
+  dev box may still work — but any real site the user connects must serve HTTPS.)
+- **`$WORDPRESS_SITE_URL` must exactly match the site's configured address.** If
+  it differs (missing/extra `www`, `http` vs `https`), WP answers `/wp-json/...`
+  with a **301** to the canonical host. Fix the stored site URL in the connector
+  rather than papering over it with `-L`.
+
 - **A security plugin / host may block `/wp-json`** (Wordfence, "disable REST
   API" plugins, some managed hosts). Symptom: 404 `rest_no_route` or an HTML
   login page instead of JSON. The user must allow REST API access.
+- **Pretty permalinks may be off.** If `/wp-json/wp/v2/...` returns the site's
+  HTML instead of JSON, the site is on plain permalinks — use the always-available
+  query form instead: `$SITE/?rest_route=/wp/v2/posts`.
 - **The Application Password contains spaces** (e.g. `abcd efgh ijkl mnop`).
   Keep them — `curl -u` handles the spaces fine; don't strip them.
 - **Never publish silently.** Even if the user says "post it", prefer creating a
   draft and returning the `wp-admin` edit link unless they explicitly asked to
-  go live.
+  go live. (In an unattended Scheduled Task the user has pre-authorized the run,
+  so publishing directly is expected there — but still run the duplicate check.)
 
 
 ## Record the output