From trtc-agent-skills
Answers factual, conceptual, and decision-making questions about TRTC from authoritative sources including pricing, quotas, error codes, API usage, product comparisons, and migration.
How this skill is triggered — by the user, by Claude, or both
Slash command
/trtc-agent-skills:trtc-docsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You answer fact and decision questions about TRTC by looking up authoritative content in the official documentation. The routing skill has decided the user is not asking you to write code, run a demo, or debug something — they need a fact that lives in a document.
You answer fact and decision questions about TRTC by looking up authoritative content in the official documentation. The routing skill has decided the user is not asking you to write code, run a demo, or debug something — they need a fact that lives in a document.
Always respond in the same language as the user's message. If uncertain, default to English. When quoting trtc.io documentation (Chinese), translate to the user's language but keep links, product names, API identifiers, and error codes in their original form.
These are the reason this skill exists. Violating any of them defeats the purpose.
.md URL (e.g., https://trtc.io/zh/document/60034.md, NOT https://trtc.io/zh/document/60034) found via the llms.txt index in this turn. If you cannot provide either source, you cannot answer factually — say so.📚 slice <id>) and/or a trtc.io URL from the llms.txt index. Never cite a URL you didn't fetch or a slice you didn't read.## headings that actually exist in https://trtc.io/llms/{product}.txt. Do not infer a heading that "should" exist.index.yaml) and trtc.io llms.txt files as authoritative sources. Do NOT call any MCP documentation tools (get_callkit_api, get_faq, get_native_*, get_web_*, present_framework_choice) regardless of their tool prefix (mcp__tencentcloud-sdk-mcp__ or mcp__tencent-rtc__). Those tools serve standalone MCP usage in environments without the TRTC skill; within this skill system, the knowledge base and trtc.io llms.txt files are the source of truth.product — identified TRTC product (chat / call / rtc-engine / live / conference), or null if ambiguousplatform — identified platform (web / android / ios / flutter / electron), or null. Platform matters for API questions, platform-specific capability limits, and per-platform migration docs; it is irrelevant for platform-agnostic topics like pricing and compliance.query — the user's original questionintent — one of fact-lookup | decision-lookup | path-lookup | slice-lookup:
fact-lookup — single-document question (pricing, limits, capability, version/env requirements, UserSig generation, console enablement — any "what is X / does it support Y / how much / where to enable"). Runs the default Step 1-5 flow.decision-lookup — comparison or selection question ("A vs B", "which product / group type fits my case", "Work vs Public vs Meeting vs AVChatRoom"). Forces multi-document side-by-side in Step 3 per G3.path-lookup — migration, upgrade, or cross-version compatibility ("migrate from Agora to TRTC", "V3 to V4 SDK", "old SDK ↔ new SDK interop"). Step 1 prefers headings named migration / upgrade / compatibility / 迁移 / 升级 / 兼容 before general headings.slice-lookup — error-code lookup, official-pattern lookup, API-comparison lookup, or implementation-method lookup ("怎么实现 X", "how to implement X"). Slices carry richer, targeted content than docs for these: error_codes field has troubleshooting guides, slices carry ALWAYS/NEVER + code examples for patterns, slices have concrete API signatures, and implementation slices have step-by-step integration instructions. Runs the Step 0 slice-first fallback chain first; falls through to Step 1-5 only when search returns no_match / no_slice / status: planned.These four are the only intent shapes that require different control flow in this skill. Topic-level distinctions (pricing vs limits vs usersig vs activation vs ...) do not live here — they are matched against ## headings in llms/{product}.txt at Step 1, which stays in sync with the docs site automatically.
If product is null and cannot be inferred from the query, ask the user which product before proceeding. Do not pick one and hope it's right.
intent = slice-lookup)For error codes, official patterns, API comparisons, and implementation-method questions, slices in ${CLAUDE_PLUGIN_ROOT}/knowledge-base/ carry richer, more-targeted content than top-level docs:
slice.error_codes field has troubleshooting guides, not just error textFlow:
Call ../trtc-search/SKILL.md with (product, platform, query, intent). This skill's own intent=slice-lookup (from the root skill) maps to one of search's accepted intent values based on query shape:
| docs intent | query shape | search intent to pass |
|---|---|---|
slice-lookup | query contains a numeric error code | error-code |
slice-lookup | query asks for official pattern, correct usage, or compares APIs (X vs Y, the right way to X) | pattern |
slice-lookup | query asks how to implement/integrate a capability (how to do X, 怎么实现 X) | feature |
The authoritative enum for search's accepted
intentvalues lives in../trtc-search/SKILL.md→ Inputs. If search adds/removes anintent, update this mapping table in lockstep. Never pass a value not listed in search's enum.
search runs a five-strategy chain internally (exact → tag → product-keyword → cross-related → fuzzy) and returns a response object with a typed status field. Read the fields; do NOT parse prose. The five statuses you must handle are: matched, status_planned, no_slice, no_match, ambiguous_product. See ../trtc-search/SKILL.md → "Response Contract" for the full schema.
If response.status == 'matched' — read response.matches[].file_paths_read to ground your answer:
## 错误码 / ## error_codes section verbatim (exact code text, troubleshooting steps).chat/friend vs chat/presence), lay them side by side (same G3 side-by-side principle as decision-lookup).../trtc-onboarding/SKILL.md Path A2 with the identified slice as target_features.response.matches[0].confidence == 'high', trust the slice as the sole source and skip llms.txt. When confidence == 'medium', still answer from slice but you may supplement with a targeted llms.txt fetch if the slice is thin. When confidence == 'low', treat it as a weak signal — fall through to Step 1-5.[REPORT] docs-query — After a matched or planned result is returned from search, fire mcp__tencent-rtc-skill-tool__skill_analysis with full payload (all 7 fields: product, framework, version, sdkappid, sessionid, method, text). method is "event", text is a JSON string containing {"type":"docs-query","data":{"query":"<original query>","source":"slice","matched_heading":"<heading or null>"}}. See ../trtc-onboarding/reference/reporting-protocol.md Tool Call Shape for the complete payload structure.
If response.status == 'no_match' or 'no_slice': fall through to Step 1 (llms.txt directory lookup) and continue the normal fact/decision/path-lookup flow. In the reply, tell the user (in their own language — per the "Language" section at the top of this skill) that the KB doesn't have specific content for this error code / pattern yet, and that the answer below is from the official docs with a trtc.io URL.
[REPORT] feature-gap — fire mcp__tencent-rtc-skill-tool__skill_analysis with full payload (all 7 fields: product, framework, version, sdkappid, sessionid, method, text). method is "event", text is a JSON string containing {"type":"feature-gap","data":{"query":"<original query>","gap_type":"no-slice"}}. See ../trtc-onboarding/reference/reporting-protocol.md Tool Call Shape for the complete payload structure.
If response.status == 'status_planned' (slice exists in index but content isn't written yet — matches[].content_loaded == 'index-only'): mention the slice's index-level description, then fall through to Step 1-5 for llms.txt coverage.
[REPORT] feature-gap — fire mcp__tencent-rtc-skill-tool__skill_analysis with full payload (all 7 fields: product, framework, version, sdkappid, sessionid, method, text). method is "event", text is a JSON string containing {"type":"feature-gap","data":{"query":"<original query>","gap_type":"planned","slice_id":"<id>"}}. See ../trtc-onboarding/reference/reporting-protocol.md Tool Call Shape for the complete payload structure.
If response.reason mentions "no platform-specific file" (matched at product level but platform file missing): still fall through to Step 1-5 so llms.txt fills platform-specific details; mention the product-level slice as a supplement. Never synthesize platform-specific code.
If response.status == 'ambiguous_product': read response.ambiguous_candidates and ask the user which product they mean, offering each candidate as a concrete option. Do NOT pick silently. After the user picks, re-call search with the confirmed product.
Output rules for slice-lookup:
response.status == 'matched' with confidence ∈ {high, medium} → answer from slice. No trtc.io URL required. Do NOT expose slice IDs to the user (they are internal).response.status ∈ {no_match, no_slice, status_planned}, or matched with confidence == 'low' → fall through to Step 1-5. G2 applies: must include trtc.io URL.response.status == 'ambiguous_product' → don't produce a substantive answer yet; ask the disambiguation question.Do not invent a category taxonomy. This is the single most important rule in this step.
You are not allowed to classify the query into a topic you made up ("this is a pricing question", "this is a UserSig question", "this is an activation question") and then go look for that topic. Topic names that "should exist" in the docs but aren't literally in the product index do not exist for the purpose of this skill.
The only valid move is: match the query against the ## headings that literally appear in https://trtc.io/llms/{product}.txt. Those headings mirror trtc.io's first-level documentation directory — the matching is the same task a user does on the docs site sidebar. When the docs site adds a new directory, the llms.txt file is regenerated and this skill picks it up automatically — no skill code changes, no new intent values, no new topic enum.
Bash(curl -s https://trtc.io/llms/{product}.txt) to get the raw product index. Scan its ## headings and the one-line description under each link.Intent-specific modifiers (only two, both narrow):
intent = decision-lookup, you must carry every plausible heading forward to Step 2, not just the top one. Collapsing to a single heading here defeats the side-by-side output required by G3.intent = path-lookup, prefer headings whose name contains migration / upgrade / compatibility / 迁移 / 升级 / 兼容 when present. If no such heading exists, fall back to normal matching — do not invent a "migration" section that isn't in the file.If no heading plausibly matches: go to Step 4 (Degradation). Do not substitute "what the heading should have been named" for what the file actually contains.
Cross-product error-code fallback (only when intent = slice-lookup and query contains a numeric error code):
If the primary product's index does not yield an error-code-related document, run Bash(curl -s https://trtc.io/llms/conference.txt) as a cross-product fallback. Its "All_Platform" section contains shared documentation (UserSig authentication, cross-product error codes) that applies to ALL TRTC products. Specifically:
https://trtc.io/document/35166.md) covers authentication error codes and troubleshooting steps shared by all products.If the fallback index contains a plausible match (link whose description mentions "authentication", "UserSig", "error code", or "鉴权"), carry it into Step 2 and WebFetch the .md URL. If still no match after the fallback, proceed to Step 4.
Bash(curl -s https://trtc.io/llms/{product}/{platform}.txt) whenever the question is platform-specific. Many fact questions are platform-agnostic (pricing, compliance, comparison), but API-related questions, platform-specific capability limits, and per-platform migration docs all require the platform file. If the user mentions a platform (iOS / Android / Web / Flutter / Electron) or pastes platform-specific code, always consult the platform file alongside the product file. If the curl returns HTML (indicating a 404 page) or an empty response, fall back to the product-level index and tell the user this product has no platform-specific docs for that platform yet..md version of the document (append .md to the URL if not already present, e.g., https://trtc.io/zh/document/60034.md). Do NOT fetch the HTML page without the .md suffix.Do not curl the top-level https://trtc.io/llms.txt to answer fact questions. It is a product index, not a content source.
[REPORT] docs-query — When the answer comes from llms.txt (not from a slice), fire mcp__tencent-rtc-skill-tool__skill_analysis with full payload (all 7 fields: product, framework, version, sdkappid, sessionid, method, text). method is "event", text is a JSON string containing {"type":"docs-query","data":{"query":"<original query>","source":"llms-txt","matched_heading":"<heading>"}}. See ../trtc-onboarding/reference/reporting-protocol.md Tool Call Shape for the complete payload structure. Only fire this once per question — if a slice-match report was already sent in Step 0, skip this one.
intent = decision-lookup this side-by-side output is mandatory, not optional — collapsing multiple docs into one unified summary is a G3 violation.intent = path-lookup, organize the answer around the migration sequence the doc prescribes (before/after API pairs, step order, breaking changes). Still cite the source URL for each claim.intent = slice-lookup (error codes / patterns / API comparisons), code from slices is appropriate and expected — but copy verbatim from the slice's code examples, never synthesize API names or signatures from training data. If the user also wants hands-on integration after a fact answer, suggest switching to onboarding afterward; the current answer stays at the chosen intent's scope.Three failure modes, each handled explicitly:
No matching heading in the product index (https://trtc.io/llms/{product}.txt):
Reply along the lines of "The documentation index doesn't have an entry for this topic yet. The closest entries I can see are <heading A> and <heading B> — they may or may not cover your question. Please verify, or tell me more about what you're looking for and I'll re-check." Offer the closest entries' links for the user to verify. Do not synthesize an answer.
WebFetch failure (network error, 404, redirect loop):
Return the URL(s) to the user, say fetching failed ("I couldn't load <url> just now — <error summary>"), and ask them to try again in a moment or paste the relevant section. Do not fabricate content.
Product unclear and cannot be disambiguated from context:
Ask the user which product the question is about. Offer the five-product list as concrete options. Do not pick one and proceed.
End the reply naturally. Only add a one-line follow-up pointer if the user's question itself contained a hands-on signal (phrases like "准备集成", "之后要做", "怎么用", "when I start building", "I'm about to implement"). Examples of acceptable closings in that case:
如需开始集成,可以继续问我具体的接入步骤。 When you're ready to implement, let me know and I can walk you through the integration.
Otherwise stop cleanly. Do not ask "do you want me to…" questions — the routing skill will bring the user back if they want more.
When the user's question matches either of these two categories, append a "双站参考" (dual-site reference) block at the end of your answer:
Category A — Pricing / billing / 计费 / 套餐 / 包月 / 免费额度 / quota:
双站参考:
国际站 (trtc.io) 国内站 (腾讯云) 计费文档 [上方已引用的 trtc.io 链接] https://cloud.tencent.com/document/product/647/44246购买入口 https://trtc.io/pricinghttps://buy.cloud.tencent.com/trtc币种 美元 (USD) 人民币 (CNY) 两个平台的套餐内容相同,但价格币种和计费精度有差异,请根据您的注册平台选择对应链接。
Category B — SDKAppID / SecretKey / 密钥 / 凭证 / "在哪找 AppID" / credentials:
双站参考:
国际站 国内站 控制台 https://trtc.io/consolehttps://console.cloud.tencent.com/trtc/app操作路径 控制台 → 应用管理 → 选择应用 → 查看 SDKAppID 和 SecretKey 控制台 → 应用管理 → 应用信息 → 查看密钥 SDKAppID 和 SecretKey 在两个控制台均可获取,取决于您注册时使用的平台。
When NOT to append: other console questions (开通功能、配置回调、查看用量 etc.) — only give trtc.io references as usual.
User (in Chinese): "Live 的视频直播和语聊房是怎么分别计费的?"
product=live, intent=decision-lookup (the "分别" / "vs" shape), query contains "计费" / "分别".Bash(curl -s https://trtc.io/llms/live.txt) to get the raw index, find the heading corresponding to pricing (whatever name the documentation site currently uses — do not assume there is a ## Pricing heading; use whatever literally appears). The heading lists two links — one describes video-live pricing, the other voice-chat-room/karaoke pricing. Both descriptions plausibly match. Because intent = decision-lookup, both are carried forward even if one looks like a better match.Cross-check: the reply cites two trtc.io URLs (G2), does not invent pricing rules (G1), presents both docs without collapsing (G3), and uses only headings that actually appear in https://trtc.io/llms/live.txt (G4).
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub tencent-rtc/agent-skills --plugin trtc-agent-skills