New-media data-fetching capability pack: one DOUBAOYA_API_KEY connects to all live listings data on the platform.
Your (agent's) job is tounderstand what the user wants to do → pick the right capability → call it → explain the result in plain language。
Calls go through scripts/dby.mjs, don't assemble paths yourself (hardcoding will definitely 404;api describe first pull details to get execution.target then call).
How to call
$SKILL_DIR = this pack's directory (the directory given when the host loads this SKILL.md), always go through the CLI:node "$SKILL_DIR/scripts/dby.mjs" <组> <命令> [参数] [flags]. Non-TTY stdout is a single {ok,data|error} JSON; exit codes 0 success / 1 general error / 2 usage error / 3 business state / 4 auth / 5 network timeout (billed requests are never automatically retried) / 6 needs confirmation (--confirm to allow, the confirmation command given in the receipt can be replayed as-is). For parameters see node "$SKILL_DIR/scripts/dby.mjs" <组> <命令> --help。
commands by group name (this file is the full reference; each pack's SKILL.md lists only the ones it uses):
- api:list search describe invoke validate recommend
- write:prep topics review articles
- charter:profiles get put
- draft:create get version review-packet precheck submit comment list versions decide merge comments star link
- article:list get
- profile:list get create update delete wechat-history sample-add sample-list sample-rm
- doc:list get patch put revisions revision restore
- material:list get add rm
- insp:list add
- wechat:status render writing-spec topics review publish media-upload theme-list theme-get theme-add theme-update theme-rm
- task:list
- usage:summary balance logs log log-rm analytics
- banned:check
- Single commands: doctor retro upload whoami routes
🔴 First dby api describe then dby api invoke—always pull input parameters fresh,requestSchema/inputSchema are example values, not a JSON Schema; fill in according to the key names and value shapes; upstream silently returns empty or gives misleading errors for wrong input parameters, so if you can't get data first go back to describe and check again, don't rush to conclude "the API is down".
→ To string commands into your own workflow, read references/compose.md; to copy the skeleton and write your own SKILL.md, read references/user-skill-template.md。
0.5 Which capability should the user use? (choose by "what I want to do")
When the user doesn't specify a platform, default to WeChat Official Accounts.
This pack's territory: public data,engagement metrics(reads / likes / wow / comments), topic and account analysis— the area covered by Doubaoya's cloud capabilities. Writing body copy, formatting, checking banned words, and producing finished images are not here; each has its own dedicated pack.
The few materials others come to this pack to fetch when writing articles (provides data, does not write on their behalf):
api.gzh.hotArticle viral article samples on the same topic,api.gzh.cozeData viral titles and cover formulas in the same niche.
These are all data and references; they will not generate finished images.
🔴 Routing is handled by dby ; this pack only answers "which capability gives this number".
Don't decide for the user here which pack to go to next, and don't continue the writing delivery chain on your own—that's dby 's job.
This pack doesnot read, not copy, not restateits routing criteria, and doesn't even need to know the file names.
Look up posts by account: first api.gzh.searchUser to get the account ID, then api.gzh.workList(upstream only recognizes IDs, not Chinese nicknames).
"My own stuff" exception — ⛔ this capability has been retired: when the request points to the user'sowncontent (help me note this down / my notes /
what kind of person am I), it used to go through mera second brain,now it can't be called and there's no replacement——tell the user truthfully,
don't substitute public search(public search can't see their own notes). See references/retired.md。
→ Read when routing (which one to call / which route it takes)
references/capability-table.md, if you already know which one to call, don't read it.
Input parameters always go through describe fetched live; not a single field name is copied from that table.
The pitfalls of the full index and route selection are in dby-gateway/references/capability-index.md and routing-pitfalls.md(optional).
🔴 Compliance / prohibited words: entry requests always go through dby-banned-words(dedicated package, compares all three platforms at once and produces safe rewrites for all platforms).
tool.contentSafety.checkWords(multi-platform scope, detail endpoint /api/skills/content-safety-check) and
skill.wechat.prohibitedWord(official account scope,/api/skills/wechat-prohibited-word) are here merely as
endpoint indexes, for direct calls by the gateway layer; they are not routing targets of this entry.
🖼 For finished images go to dby-image(rebuilt in 2026-09 as the server-side image generation capability was restored). What this package provides is coverdata—the cover image URLs, titles and click counts of hit posts in the same niche, for you to distill the patterns yourself; it does not generate images.
❌ Iron rule for topic selection: do not use the user's account name / IP name as a keyword to search. The user's official account/account name (e.g. "菜籽油") iswho he is(niche/persona/audience), not a search term—searching it will only find literally same-named content. For general hot topics use the keyword-free
api.trend.hotSpotKeywordto fetch directly; IP names are only used for matching and filtering. "Without keywords" meanskeywords——the time window still has to be narrowed(see the first item in Gotchas). Cross-platform trend radar (skill.trend.radar)searches articles on three platforms by keyword, not rankings, keyword is required: when you already have a topic in handuse it, to see who writes about this word and how on Douyin / Xiaohongshu / official accounts respectively; when you have no topic and want it to come up with topics for youdon't use it—that kind of need goes through the aboveapi.trend.hotSpotKeyword。
What to do if it fails
How to handle each error code (noResult is not a failure, which ones can be retried and which must never be retried, 404 should go find another collection)
see dby-gateway/references/protocol.md item 6.
If you follow it and still can't get around it, or want to complain → you may mention using dby-feedback to write it up on the spot as feedback (optional, no need to mention it again).
Gotchas
→ After choosing the capability and before actually making the request, read references/gotchas.md;
come back and read it when you can't get data, or the results are clearly wrong. Remember the two most costly ones first:
Hot topic direct fetch (api.trend.hotSpotKeyword) must narrow the time window, otherwise what you get is the hot list from the week before last;
while api.trend.hotKeywords is exactly the opposite, with a time range it will always return 0 items—the time semantics of the two capabilities are reversed.
Delivery receipt (include one with every delivery)
Write the receipt along with the delivery, don't add it afterwards.
Before starting, state clearly which tier this delivery goes to,stop at whichever tier the goal stops at. This package ends once the data is delivered,
do not proceed to the next stop on your own—whether to go further is judged by dby . In particular, do not run dby-publish
just because it's "convenient"
(it writes into the user's own official account backend, a real side effect). If unsure, just ask.
Append at the end of the delivery, four lines, don't merge them:
查阅:<读了哪份路由 / 参考了哪张表>
执行:<真正调了哪些能力>
质检:<跑了哪些检查>
跳过:<发现了但没跑的> —— 原因:<为什么不该跑>
- "Executed" only records what was actually run; write the ones that ran but failed here and note the failure; do not move them into "Skipped" to gloss over them.
- "Skipped" lists only those that were "discovered but judged not worth running"; ones not discovered at all need not be listed. Those with side effects especially must not be omitted.
- 🔴 Only write quantities that can be proven. The conclusions in parentheses must refer back to something that actually exists in this real return.
(The prohibited-word check returns riskcategoriesarray, so "hit N categories" is provable; itdoes not returnlevel / score / list of hit words,
so "0 high-risk" and "low risk" are fabricated.) If unsure, return to
describeand take a look at the output parameter example.
Hard rules
- Never echo / print / log any part of the key—the prefix either.
- Only retrieve data through the public interface of
https://doubaoya.compublic interface data retrieval of; do not describe, guess, or expose the upstream data source / internal services to users. To users, the capability comes from "Doubaoya". - Fetch input parameters live, fetch paths live(use
describe/ let the script fetch them), do not assemble from memory or this document. - Write scripts using real data as the material, incorporate the real angles of hot topics / viral hits; do not write emptily detached from the data.
- Deliver with a receipt, four lines; under "Execution" write only what actually ran.
Next step
| After getting the data | where to go |
|---|---|
| Need to generate images / add images / edit images | dby-image(text-to-image / image-to-image / image editing; after generation, save to a local file) |
| Need to format the draft and save it to the official account draft box | dby-publish |
| Need to rewrite a viral hit into your own copy (no API calls, no key needed) | dby-rewrite |
| Need to establish a persona / extract brand facts | dby-charter |
| Hop-by-hop navigation (which step to take after finishing this one) | dby |
| Stuck at the protocol layer (complete explanation of routing / envelope / error codes) | dby-gateway |