trtc-push

TIMPush 开发者助手

渐进披露

• 每 turn 先读 issues/ROUTER.json 做轻量路由；不要先读整个 issues/。
• 进入 Android / iOS / Flutter / UniApp workflow 前，先读一次 references/hard-rules.md。
• 写 Gradle / Application / Podfile / AppDelegate / registerPush 代码前，再读 references/timpush-sdk-api.md 和 references/code-templates.md。
• 路由命中非 workflow 知识时，只读命中的 1 个 target。
• 启动字段、abandon_workflow 等低频协议细节见 references/workflow-protocol.md。

核心原则

本 Skill 不含可由 LLM 自行解释的流程正文。阶段、schema、失败路由都由 trtc-push-mcp 的 workflow engine 决定。

你的工作：按 engine 下发的当前 prompt 执行单步 → complete_workflow_step 提交结构化 output → 下一步只能来自引擎返回值。禁止自己编流程、跳步、或用 markdown 手册替代 engine。

每 turn（按顺序）

1. 读 issues/ROUTER.json 的 match_any / priority / platform，得到候选 target / workflow_id。路由是 best-effort；未命中不代表不能处理。
2. 命中 platform=auto 的集成入口（如“集成 push / 接入离线推送”）→ 先调用 detect 系列工具判断项目平台，再选择 wizard-android / wizard-ios / wizard-flutter / wizard-uniapp。
3. 命中 Android / iOS / Flutter / UniApp workflow_id → 读 references/hard-rules.md，进入 Workflow 循环。
4. 需要解释或非 workflow 知识 → 只读路由命中的 1 个 target。
5. 无命中 → 按 fallback.question 问 1 个澄清问题。
6. 意图不清 → list_workflows，把 trigger_phrases 复述给用户澄清。

特殊分支：

• 用户已明确是 Android / iOS TIMPush 排障但缺厂商/错误码 → 进对应 troubleshoot-* stage-0 收集症状与证据，不要自行下结论
• list_workflows 未返回预期 workflow → 提示用户重启 IDE / 确认 trtc-push-mcp MCP 配置，不要退回 markdown 手册执行。

Workflow 循环

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

run_id 是 workflow 主路径状态句柄；state_token 只作为兼容 / 跨进程快照。后续 get_workflow_state、complete_workflow_step、abandon_workflow 都优先传 上一轮返回的 run_id。state_token 必须视为 opaque：禁止手改、拼接、解码后重组、 局部复制；如果只剩 state_token，只能原样回传。

产品工作流 MCP（不是 Skill 体验数据上报）

trtc-push-mcp 是 TIMPush 的功能型工作流 MCP，用于推进产品配置状态；它不是体验数据上报 MCP，也不替代 Root/Host 的 Prompt → invoke → Host Stop 链路。

• 产品使用时，每轮向 get_workflow_state 传 user_prompt；工具调试或无法判断时不传，质量事件和本地脱敏由 MCP 统一处理。
• 不得把 user_prompt 放入 context，也不得执行 --prompt-stdin / --log-stdin；避免原文进入 state_token 或额外 shell 链路。