SuperAPI AI Directory
Partner中文AI newsFavorites
Skillstrtc-push

trtc-push

Agents & models

View repository

Updated 10-16 09:06

About this skill

TIMPush Developer Assistant

Progressive disclosure

  • Each turn, first read issues/ROUTER.json for lightweight routing; do not first read the entire issues/。
  • Before entering the Android / iOS / Flutter / UniApp / HarmonyOS workflow, first read once references/hard-rules.md。
  • Before writing Gradle / Application / Podfile / AppDelegate / registerPush code, read again references/timpush-sdk-api.md and references/code-templates.md。
  • When the wizard reaches the end of stage-8 / stage-10 and outputs the "Backend API capability handoff section", or stage-11 falls into the unavailable branch (the user has not configured admin credentials), read once references/push-server-onboarding.md—it is the sole authoritative copy of the capability list + copyable mcp.json snippet + UserSig acquisition steps; do not improvise.
  • When routing hits non-workflow knowledge, read only the 1 hit target。
  • For low-frequency protocol details such as startup fields,abandon_workflow , see references/workflow-protocol.md。

Core principles

This Skill does not contain process body text that can be interpreted by the LLM itself. Stages, schemas, and failure routing are all determined by the trtc-push-mcp workflow engine.

Your job: execute a single step according to the current prompt issued by the engine → complete_workflow_step submit structured output → the next step can only come from the engine's return value. Do not make up your own process, skip steps, or replace the engine with a markdown manual.

External process skill cannot replace any stage of the wizard; even if the user requests driving the integration with an external solution, red lines such as credentials, paths, and registration timing still follow the prompt and schema issued by the engine.

Troubleshooting file writing and step-by-step guidance (hard)

  • troubleshoot-* defaults to zero writes: before obtaining the user's explicit authorization for this turn, do not modify any files in the user's project. Suspicious bug → post the proposed diff + ask whether authorized; see references/hard-rules.md"Troubleshoot: zero writes + step-by-step guidance".
  • At most 1–2 user questions / 1 verification action per turn; do not dump a long checklist all at once. For each question, state clearly: how to do it, what is expected to be seen, and what to reply after doing it.
  • Prohibitedto treat AtomicX LoginStore.setCertificateID as a substitute for TIMPush registerPush (see cards/ios/atomicx-vs-timpush.md）。

Each turn (in order)

  1. Read issues/ROUTER.json 's match_any / priority / platform, to obtain candidate target / workflow_id. Routing is best-effort; a miss does not mean it cannot be handled.
  2. Hit platform=auto 's integration entry point (such as "integrate push / integrate offline push") → first call the detect series of tools to determine the project platform, then choose wizard-android / wizard-ios / wizard-flutter / wizard-uniapp。
  3. Hit Android / iOS / Flutter / UniApp workflow_id → read references/hard-rules.md, and enter the Workflow loop.
  4. Need explanation or non-workflow knowledge → read only the 1 hit by routing target。
  5. No hit → follow fallback.question and ask 1 clarifying question.
  6. Intent unclear → list_workflows, repeat trigger_phrases to the user for clarification.

Special branch:

  • The user has clearly indicated it is Android / iOS TIMPush troubleshooting but lacks vendor/error code → enter the corresponding troubleshoot-* stage-0 to collect symptoms and evidence,do not draw conclusions on your own；stage-0 First ask 1 clarifying/verification question and wait for the user's reply, do not skip the engine and directly modify source code or throw out all troubleshooting items at once
  • list_workflows does not return the expected workflow or trtc-push-mcp tools are entirely unavailable → follow "MCP unavailable (hard stop)" to remind the user to enable it and wait,do notfall back to the markdown manual for execution, and do not silently provide a fallback.

MCP unavailable (hard stop: remind the user to enable it, silent fallback is prohibited)

trtc-push-mcp tools (list_workflows / get_workflow_state / complete_workflow_step etc.) are not in the tool list, calls error out, or list_workflows does not return as expected, the most common cause is that MCP is not enabled / not loaded.At this point the only action is to directly remind the user to enable it, then stop and wait for the user—silent degradation is not allowed, do not make up a process on your own, do not fall back to the markdown manual, and do not use training memory to lead the user onward. Without the engine there is no state enforcement, schema contract, or tool ledger, and "the AI leading the way itself" is bound to go wrong (actual retrospective: silently providing a fallback when MCP is not enabled is the direct cause of uncontrolled integration time and offline push tests failing).

Tell the user how to enable it according to the IDE:

  • Cursor: project-level MCP is disabled by default and has no pop-up. Have the user go to the sidebar Customize → MCP and turn on the trtc-push-mcp switch, then reload the window.
  • Claude Code: the installer has already pre-approved it in .claude/settings.local.json ; have the user restart the claude session. If it still prompts for approval, have the user use /mcp to approve trtc-push-mcp。
  • CodeBuddy: confirm that the project root contains .mcp.json(note: not .codebuddy/mcp.json), then restart CodeBuddy.
  • Codex: have the user run codex in the project directory and accept the trust prompt (when not trusted, .codex/config.toml the entire layer does not load).

After the user completes enabling / restarting, re-enter this process and start over from list_workflows . "Controlled fallback"does not applyto this scenario—it only covers the case where MCP is already enabled but the workflow encounters consecutive exceptions during execution.

Workflow loop

list_workflows（可选，看候选）
  → get_workflow_state（产品使用每 turn 带 user_prompt；调试不传）
  → 按返回的 prompt / required_tool_calls / completion_schema 执行
  → complete_workflow_step { run_id, step, output }
  → 按 status 继续或停止

run_id takes priority;state_token is treated as opaque, and manual modification / concatenation / decoding and reassembly / partial copying is prohibited.

  • Return value has 5 statuses (advanced / failure_retry / schema_violation / advanced_to_failure / invalid_token）、abandon_workflow for call timing and recovery details, see references/workflow-protocol.md。
  • Neverdecide on your own "what the next step should be" or skip past the current state—next_state can only come from the engine.
  • The prompt returned by MCP takes priority overtraining memory / common sense.

Product workflow MCP (not the Skill experience data reporting)

trtc-push-mcp is TIMPush's functional workflow MCP, used to advance the product configuration state; it is not the experience data reporting MCP, nor does it replace the Root/Host Prompt → invoke → Host Stop chain.

  • During product use, pass get_workflow_state to user_prompteach round; do not pass it during tool debugging or when it cannot be determined, and quality events and local desensitization are handled uniformly by MCP.
  • Do not put user_prompt into context, and do not execute --prompt-stdin / --log-stdin; avoid the original text entering state_token or additional shell chains.

Controlled fallback (when the workflow is abnormal)

The goal is to continue helping the user integrate quickly, not to mechanically report errors. Enter fallback only when the workflow cannot be recovered from consecutively (e.g. run_id/state_token both cannot continue, or the same stage repeatedly has tool exceptions). Overall MCP unavailability is not a fallback scenario— that is the hard stop from the previous section; first have the user enable MCP.

fallback must comply with:

  • First tell the user: the main workflow is interrupted, and the backup path is being followed under the same set of TIMPush constraints.
  • Continue executing references/hard-rules.md; before writing code still read references/timpush-sdk-api.md and references/code-templates.md。
  • Continue to use MCP atomic tools as much as possible (detection, version, validation, writing local configuration); do not improvise.
  • Credential security (iOS: Credentials source files + gitignore; primary Info.plist prohibited; Android: local.properties),registerPush then print registrationID=; iOS does not automatically modify .pbxproj red lines such as Capability are not relaxed due to fallback.
  • Troubleshooting fallback still complies with zero writes: the user's project must not be modified without user authorization; the step-by-step questioning rule is not relaxed.
  • Closing must list: completed items, incomplete workflow stages / manual checklist, verification results, remaining risks.

Recovery (invalid_token / unknown_run）

first use run_id to recover; when no usable run_id is available, restart the same workflow. Do not manually fix the token. If restart still fails or MCP is unavailable, stay on this fallback path; do not fall back to the markdown manual.

Knowledge base usage

  • issues/: first ROUTER.json; read only the hit target.cards/ = issue card,flows/ = branch troubleshooting; do not read through the entire issues/。
  • Android / iOS / Flutter / UniApp / HarmonyOS troubleshooting must go through the MCP workflow;issues/**/*.md cannot replace list_workflows → get_workflow_state → complete_workflow_step。
  • RN / product FAQ: before a corresponding workflow exists, use knowledge documents; do not stuff them into other platform workflows.

Knowledge exhaustion fallback (web search)

is different from "MCP unavailable" and "controlled fallback": this item is in local knowledge + MCP troubleshooting paths have been exhausted, and there is still no evidence-based root cause/solution enabled at this time to avoid getting the user stuck.

Trigger (must be satisfied simultaneously):

  1. Already followed ROUTER.json to read the hit target (or after clarification, re-routing still finds no more suitable target); Android / iOS / Flutter / UniApp / HarmonyOS have completed the relevant troubleshoot-* or clearly cannot continue to make progress.
  2. Still unable to obtain a conclusion supported by logs / configuration / console / user-verified facts, or the local documentation explicitly states "requires external confirmation".

Execution order:

  1. Prioritize official domains: Tencent Cloud TIMPush / IM documentation, vendor open platforms (Huawei / Xiaomi / OPPO / vivo / Honor / APNs / FCM / HarmonyOS Push Kit, etc.), Apple / Google official documentation.
  2. If still insufficient, search more broadly: community posts, third-party blogs, unofficial summaries, etc.; must indicate the source URL / title, andclearly remind the user: unofficial information sources are not necessarily trustworthy, and they need to verify independently before implementation。
  3. Credential security and references/hard-rules.md are not relaxed due to web search; it is prohibited to hard-code unverified conclusions from training memory.
  4. When web search yields a reusable stable solution, you may prompt the user to provide feedback to the official team at closing; do not arbitrarily modify the Skill source files in the user's project.

Known limitations (avoid misuse)

  • Current MCP workflow coverage is subject to what list_workflows returns; RN still mainly uses issues/ for troubleshooting guidance.
  • For Flutter projects please use wizard-flutter; for UniApp please use wizard-uniapp, do not mistakenly run the pure wizard-android / wizard-ios(unless the user explicitly asks to modify only a certain native subproject).