@acedatacloud/skills 2026.621.5 → 2026.621.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@acedatacloud/skills",
-  "version": "2026.621.5",
+  "version": "2026.621.7",
   "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/{cn-blog → zhihu}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: cn-blog
-description: Read and publish on Chinese content platforms with the user's own login cookies (BYOC) — list their published articles with vote/comment stats, inspect one article, and publish a new article. Use when the user mentions 知乎 / Zhihu, "我的知乎文章", reading their article stats (点赞/评论), or publishing/发文 to Zhihu.
+name: zhihu
+description: Read and publish on Zhihu (知乎) with the user's own login cookies (BYOC) — list their published articles with vote/comment stats, inspect one article, and publish a new article. Use when the user mentions 知乎 / Zhihu, "我的知乎文章", reading their article stats (点赞/评论), or publishing/发文 to Zhihu.
 when_to_use: |
   Trigger for anything on the user's Zhihu (知乎) account driven by their own
   login cookie: show who they are, list their published articles with
@@ -15,7 +15,7 @@ metadata:
   version: "1.0"
 ---
 
-# cn-blog — Zhihu via your own cookies
+# zhihu — read & publish on Zhihu via your own cookies
 
 Drives the user's **real** Zhihu account through the same web APIs the site's
 own editor uses, authenticated by the login cookie they captured with the ACE
@@ -93,5 +93,6 @@ python3 $BLOG publish --title "标题" --content-file article.html --confirm
   acts on the user's own account with their own captured cookie; the user owns
   that risk. Never use it to scrape other people's content at scale.
 - **Never print `ZHIHU_COOKIES`** — it is full account access.
-- **Scope today**: Zhihu only. 掘金 / CSDN connectors exist in the vault and are
-  planned next; this skill will grow a `--platform` switch for them.
+- **Scope**: Zhihu only. Other Chinese platforms (掘金 / CSDN / …) ship as their
+  own per-platform skills (e.g. `csdn`, `juejin`), each with its own connector —
+  not a `--platform` switch here.

package/skills/{cn-blog → zhihu}/scripts/blog.py

@@ -1,6 +1,6 @@
 #!/usr/bin/env python3
 """
-cn-blog — read & publish on Chinese content platforms with the user's own
+zhihu — read & publish on Zhihu (知乎) with the user's own
 login cookies (BYOC). Standard-library only (urllib), no third-party deps,
 so it runs in the bare sandbox without an image change.
 
@@ -319,7 +319,7 @@ COMMANDS = {
 
 
 def main() -> None:
-    p = argparse.ArgumentParser(prog="blog.py", description="cn-blog cookie CLI")
+    p = argparse.ArgumentParser(prog="blog.py", description="zhihu cookie CLI")
     p.add_argument("--platform", default="zhihu", choices=["zhihu"],
                    help="content platform (only zhihu is implemented today)")
     sub = p.add_subparsers(dest="command", required=True)

package/skills/cloudflare/SKILL.md

@@ -1,75 +0,0 @@
----
-name: cloudflare
-description: Manage Cloudflare zones, DNS records, cache purge and Workers via the API v4. Use when the user mentions Cloudflare, a DNS record on a Cloudflare-hosted domain, purging / clearing the CDN cache, a zone's settings, WAF / firewall rules, or listing Workers.
-when_to_use: |
-  Trigger when the user wants to list Cloudflare zones, read or change
-  DNS records, purge the cache, inspect Workers, or review firewall
-  rules. The connector stores a scoped Cloudflare API token; confirm
-  before any write (DNS create/update/delete, cache purge) and prefer
-  the smallest-blast-radius action.
-connections: [cloudflare]
-allowed_tools: [Bash]
-license: Apache-2.0
-metadata:
-  author: acedatacloud
-  version: "1.0"
----
-
-Call the **Cloudflare API v4** with `curl + jq`. The user's **scoped** token is
-in `$CLOUDFLARE_API_TOKEN` (optionally `$CLOUDFLARE_ACCOUNT_ID` /
-`$CLOUDFLARE_ZONE_ID`); every call needs `Authorization: Bearer
-$CLOUDFLARE_API_TOKEN`. Base URL: `https://api.cloudflare.com/client/v4`.
-
-Every response has `{"success": bool, "errors": [...], "result": ...}`. On
-`success:false` show `.errors` verbatim. `403`/`9109` means the token lacks the
-permission for that resource → the user must re-mint the token with the right
-scope (zone DNS edit, cache purge, etc.).
-
-```bash
-AUTH=(-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN")
-API="https://api.cloudflare.com/client/v4"
-# Zones the token can see
-curl -sS "${AUTH[@]}" "$API/zones" | jq '.result[] | {id, name, status, plan: .plan.name}'
-```
-
-## DNS records
-
-```bash
-ZONE="${CLOUDFLARE_ZONE_ID:?set or pick from the zones list}"
-# List (filter with ?type=A&name=foo.example.com)
-curl -sS "${AUTH[@]}" "$API/zones/$ZONE/dns_records?per_page=100" \
-  | jq '.result[] | {id, type, name, content, proxied, ttl}'
-
-# Create (confirm first)
-curl -sS -X POST "${AUTH[@]}" -H "Content-Type: application/json" \
-  -d '{"type":"CNAME","name":"www","content":"example.com","proxied":true}' \
-  "$API/zones/$ZONE/dns_records" | jq '.success, .result.id'
-
-# Update PATCH /dns_records/{id} ; delete DELETE /dns_records/{id}
-```
-
-## Purge cache (confirm first)
-
-```bash
-# Targeted purge by URL (preferred); use {"purge_everything":true} only if asked
-curl -sS -X POST "${AUTH[@]}" -H "Content-Type: application/json" \
-  -d '{"files":["https://example.com/path"]}' \
-  "$API/zones/$ZONE/purge_cache" | jq '.success'
-```
-
-## Workers & firewall
-
-```bash
-ACCT="${CLOUDFLARE_ACCOUNT_ID:?needed for account-scoped resources}"
-curl -sS "${AUTH[@]}" "$API/accounts/$ACCT/workers/scripts" | jq '.result[] | {id, modified_on}'
-# Firewall / WAF custom rules live under /zones/$ZONE/firewall/rules and rulesets.
-```
-
-## Gotchas
-
-- Insist on a **scoped API token**, never the legacy Global API Key (the connect
-  form's help says so) — a Global Key can do anything on the account.
-- `proxied:true` = orange-cloud (CDN/WAF on); `false` = DNS-only. Changing it can
-  break TLS/origin expectations — confirm intent.
-- Account-scoped calls (Workers, some analytics) need `$CLOUDFLARE_ACCOUNT_ID`;
-  zone-scoped calls need a zone id (pick from `/zones` if env unset).

package/skills/sentry/SKILL.md

@@ -1,80 +0,0 @@
----
-name: sentry
-description: Monitor errors, issues, releases and projects in Sentry via the REST API v0. Use when the user mentions Sentry, error tracking, an unresolved issue, a stack trace / crash, error rate, a release, or wants to triage / resolve / assign issues across their Sentry projects.
-when_to_use: |
-  Trigger when the user wants to list or search Sentry issues, read a
-  crash's latest event + stack trace, list projects or releases, or
-  resolve / assign an issue. The connector stores a Sentry auth token
-  with the granted org scope — confirm before any write (resolve /
-  assign / delete), and prefer read-only triage first.
-connections: [sentry]
-allowed_tools: [Bash]
-license: Apache-2.0
-metadata:
-  author: acedatacloud
-  version: "1.0"
----
-
-Call the **Sentry REST API v0** with `curl + jq`. The user's auth token is in
-`$SENTRY_AUTH_TOKEN` and their org slug in `$SENTRY_ORG_SLUG`; every call needs
-`Authorization: Bearer $SENTRY_AUTH_TOKEN`. Base URL: `https://sentry.io/api/0`
-(SaaS). For a self-hosted Sentry the user supplies `$SENTRY_BASE_URL` — use it
-instead when set.
-
-Errors come back as JSON with a `detail` field — show it verbatim. `401` means
-the token is invalid → the user must re-connect Sentry. `403` means the token
-lacks the scope for that action (e.g. write) → ask them to re-connect with a
-broader token.
-
-Always confirm the org + list projects first:
-
-```bash
-BASE="${SENTRY_BASE_URL:-https://sentry.io/api/0}"
-curl -sS -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-  "$BASE/organizations/$SENTRY_ORG_SLUG/projects/" \
-  | jq '.[] | {slug, name, platform}'
-```
-
-## Search & read issues
-
-```bash
-# Unresolved issues for a project, most frequent first.
-curl -sS -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-  "$BASE/projects/$SENTRY_ORG_SLUG/PROJECT_SLUG/issues/?query=is:unresolved&sort=freq" \
-  | jq '.[] | {id, shortId, title, count, userCount, lastSeen}'
-
-# A single issue + its latest event (stack trace, tags, breadcrumbs).
-curl -sS -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-  "$BASE/issues/ISSUE_ID/" | jq '{shortId, title, status, count, firstSeen, lastSeen}'
-curl -sS -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-  "$BASE/issues/ISSUE_ID/events/latest/" \
-  | jq '{message, culprit, entries: [.entries[] | .type]}'
-```
-
-`query=` uses Sentry's search syntax: `is:unresolved`, `is:assigned`,
-`environment:production`, `release:1.2.3`, free-text, etc.
-
-## Releases
-
-```bash
-curl -sS -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-  "$BASE/organizations/$SENTRY_ORG_SLUG/releases/?per_page=20" \
-  | jq '.[] | {version, dateCreated, newGroups, projects: [.projects[].slug]}'
-```
-
-## Triage (writes — confirm first)
-
-```bash
-# Resolve (or set status: unresolved | ignored). Assign with assignedTo (username/email).
-curl -sS -X PUT -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-  -H "Content-Type: application/json" -d '{"status":"resolved"}' \
-  "$BASE/issues/ISSUE_ID/" | jq '{shortId, status}'
-```
-
-## Gotchas
-
-- **Pagination** is `Link` header cursor-based (`per_page` max 100). For "all
-  issues" follow the `rel="next"; results="true"` cursor.
-- **Org/project slugs**, not numeric ids, in the issue-search URL; the issue
-  detail/triage routes take the numeric/short issue id.
-- Don't dump tokens or PII from event payloads back to the user unprompted.