TMEET Scenario Skills

将本项目作为三个腾讯会议场景 Skill 的统一入口。保持 tmeet CLI -> Python 数据采集 -> 数据文件 -> LLM Analysis -> 输入绑定检查 -> LLM Polish -> report.md 的固定链路。

先选择场景

选择场景后，读取对应的子 Skill：

• 会后复盘：meeting-review/SKILL.md
• 会议记忆：meeting-memory/SKILL.md
• 执行审阅：meeting-auditor/SKILL.md

环境要求

在项目根目录执行所有示例。要求：

• Windows、macOS 或 Linux；路径示例以当前 Windows 工作区为主。
• Python 3.10 或更高版本。脚本只使用 Python 标准库。
• Node.js 与 npm 仅在安装 tmeet CLI 时需要。
• tmeet 命令必须位于 PATH，且支持 upstream/tmeet-skill-1.0.6/ 记录的命令和参数。
• 用户必须已完成腾讯会议 OAuth 登录。
• 当前用户必须能写入项目的 runtime/ 目录。
• 文件与终端优先使用 UTF-8。

先执行环境预检：

cd ..\tmeet-scenario-skills
python --version
tmeet --help
tmeet auth status

若缺少 tmeet，由用户在终端安装：

npm install -g @tencentcloud/tmeet@latest

若尚未登录，由用户按上游规范在终端完成交互式授权：

tmeet auth login --no-browser

打开命令输出的完整授权 URL 并完成授权。采集脚本和 Analysis LLM 都不得自动执行登录，也不得输出 AccessToken 或 RefreshToken。

规范来源与读取顺序

将以下文件作为固定规范：

1. 读取本文件，选择场景并确认统一流程。
2. 读取 PROJECT_RULES.md，确认不可突破的安全与数据边界。
3. 读取目标场景的 SKILL.md、prompts/analyze.md 和 prompts/polish.md。
4. 仅在需要确认 CLI 命令、参数或分页规则时，读取 upstream/tmeet-skill-1.0.6/SKILL.md 及相应 references/*.md。

不得凭模型记忆发明 tmeet 命令。不得修改 upstream/ 中的任何文件。

固定安全边界

• 只允许 Python 采集脚本调用 tmeet；Analysis 和 Polish 不得直接调用 CLI。
• 自动链路只允许读取类命令，不得创建、更新、取消会议，不得变更受邀者，不得执行会控、登出或提交录制权限申请。
• 使用 subprocess.run(..., shell=False)，分别捕获 stdout、stderr 和 returncode。
• 查询命令优先使用 --compact；当精简响应缺少后续必需字段时才重新请求完整响应。
• 分页只使用 --page-token 与 --page-size。读取上一页 data.next_page_token 并原样传递；不得构造、递增或猜测 token。
• 先将 CLI JSON 写入当前 run，再生成 manifest，再开始 Analysis。
• 不得使用 mock、fixture、旧 run、网络搜索或模型长期记忆补足缺失事实。
• 权限不足时保留已合法取得的数据，将 run 标为 PARTIAL 并记录机器可读原因；不得自动申请权限。
• 对外引用会议时使用 meeting_code、主题和时间，不得主动展示内部会议、录制、文件或 trace 标识。

允许的自动只读能力以 shared/scripts/cli_utils.py 中的白名单和上游文档交集为准，包括：

auth status
meeting get
meeting list-ended
meeting invitees-list
record list
record address
record smart-minutes
record transcript-get
record transcript-paragraphs
record transcript-search
report participants
report waiting-room-log

第一步：采集真实 CLI 数据

会后复盘

优先按会议号采集：

python meeting-review/scripts/collect_data.py `
  --meeting-code "123456789"

按时间与主题筛选候选：

python meeting-review/scripts/collect_data.py `
  --start "2026-07-01T00:00:00+08:00" `
  --end "2026-07-22T23:59:59+08:00" `
  --query "季度复盘" `
  --max-pages 10

如果候选不是唯一会议，脚本写入 candidate_meetings.json、返回 BLOCKED，且不更新 latest_run.json。要求用户确认 meeting_code 后重新采集，不得自动选择最相似候选。

会议记忆

python meeting-memory/scripts/collect_data.py `
  --start "2026-07-01T00:00:00+08:00" `
  --end "2026-07-22T23:59:59+08:00" `
  --query "季度目标" `
  --max-meetings 30 `
  --max-pages 10

仅在确有必要且数据量可控时获取相关完整转写：

python meeting-memory/scripts/collect_data.py `
  --start "2026-07-01T00:00:00+08:00" `
  --end "2026-07-22T23:59:59+08:00" `
  --query "季度目标" `
  --include-transcripts

时间必须是包含时区的 ISO 8601，且 end 必须晚于 start。不要无边界抓取全部历史会议。

会议执行审阅

python meeting-auditor/scripts/collect_data.py `
  --meeting-code "123456789"

也可使用与 meeting-review 相同的 --start、--end、--query 和 --max-pages 候选筛选参数。

如需把运行数据写入其他位置，给任一采集器传入：

--runtime-root <directory>

第二步：定位当前 run

先固定本次采集实际使用的 RUNTIME_ROOT。未传 --runtime-root 时，RUNTIME_ROOT=<PROJECT_ROOT>/runtime；传入自定义目录时，采集、Analysis、Validator 和 Polish 必须始终使用同一个绝对路径。

成功或部分成功采集后，只读取：

LATEST_RUN_FILE=<RUNTIME_ROOT>/<skill>/latest_run.json

从该文件取得 run_id 和 run_dir，解析并校验：

RUN_DIR=<RUNTIME_ROOT>/<skill>/runs/<run_id>/
├── input/
├── input_manifest.json
└── .internal/

run_dir 必须位于同一 RUNTIME_ROOT、同一 Skill 的 runs/ 下并与 run_id 一致，否则停止。只使用该指针指定的 run；不得扫描 runs/ 猜测最新目录，也不得把旧 analysis.md 与新输入混合。

路径与产物归类

执行材料与运行产物必须分离；不得在 prompts/、scripts/、子 Skill 根目录或项目根目录写入 analysis.md、report.md 或 .internal/。同一批次的输入、中间结果、内部校验和最终报告统一归档在同一个 RUN_DIR，避免跨批次混用。

采集器状态与退出码：

不要把 PARTIAL 解释为报告质量通过。

第三步：执行 Analysis

读取目标场景的 prompts/analyze.md 作为指令，并且只读取当前 RUN_DIR 的：

<RUN_DIR>/input/
<RUN_DIR>/input_manifest.json

默认使用简体中文完成 Analysis；命令名、文件名、JSON 字段名和内部状态常量保持原始英文形式。

只写入：

<RUN_DIR>/analysis.md
<RUN_DIR>/.internal/llm_input_receipt.json

receipt 必须从本次实际收到的 manifest 原样复制字段：

{
  "schema_version": "1.0",
  "skill": "<meeting-review|meeting-memory|meeting-auditor>",
  "run_id": "<copy from input_manifest.json>",
  "bundle_sha256": "<copy from input_manifest.json>"
}

不要自行计算 receipt 中的 hash。不要把 receipt、hash 或 run 标识写入 analysis.md。

始终区分：

• 明确记录 / Explicit：数据直接记录的内容。
• 分析归纳 / Inferred：基于数据的合理归纳，不得冒充会议明确决定。
• 未明确 / Unknown：当前数据不足以判断。

不要把 Smart Minutes 当作完整逐字转写，不要把受邀者当作实际参会者，不要把等候室记录当作实际参会。

第四步：执行输入绑定检查

从项目根目录运行，并传入与采集阶段完全相同的 RUNTIME_ROOT：

python shared/scripts/verify_llm_input.py `
  --skill meeting-review `
  --runtime-root runtime

将 --skill 替换为当前场景。Validator 会：

1. 读取最新 run 指针。
2. 重新读取 manifest 声明的所有输入文件。
3. 检查文件集合、文件大小和 SHA256。
4. 重新计算 bundle hash。
5. 检查 receipt 的 skill、run 和 bundle 是否绑定最新输入。
6. 写入 .internal/input_binding_verification.json。

Validator 返回 0 表示 PASS，返回 1 表示 FAIL。它只证明输入批次绑定一致，不证明会议事实、分析结论或报告质量正确。

验证失败时停止，不得生成 report.md，不得修改旧 manifest 或 receipt 来强行通过；重新执行当前 run 的 Analysis。

验证通过后，将 Validator 已验证的精确 RUN_DIR 直接交给 Polish。不要在 Polish 阶段重新读取 latest_run.json，以免批量执行时指针已切换到另一个 run。

第五步：生成最终报告

仅在 Validator 返回 PASS 后读取目标场景的 prompts/polish.md，并将已验证的精确 RUN_DIR 作为运行上下文。唯一业务输入是 <RUN_DIR>/analysis.md，唯一输出是 <RUN_DIR>/report.md。

默认使用简体中文生成最终业务报告，使表达符合腾讯会议中文用户的阅读习惯。

Polish 只允许：

• 调整结构和标题层级。
• 删除重复。
• 改善语言与可读性。
• 将现有分析整理为正式报告。

Polish 不得：

• 重新调用 CLI 或进行新的事实分析。
• 增加、推翻或补全结论。
• 编造负责人、时间、决策、风险或参会情况。
• 把“未明确”改写为确定答案。

最终 report.md 禁止包含 SHA256、bundle hash、run 标识、receipt、Validator 状态、PASS/FAIL、trace 标识及内部会议/录制/文件 ID。最终用户只看到业务报告。

常见问题

完成检查

交付报告前确认：

• 使用了正确的场景 Skill。
• 数据来自真实 tmeet CLI，且当前 run 已落盘。
• 没有调用写操作或自动权限申请。
• Analysis 只读取当前 run 的 input/ 与 manifest。
• 执行材料与运行产物不在同一目录，且所有运行产物均归入当前 RUN_DIR。
• receipt 与 Analysis 同时生成且没有进入业务分析正文。
• Validator 返回 PASS。
• Polish 使用 Validator 已验证的精确 RUN_DIR，没有重新解析 latest 指针。
• Polish 没有增加新事实。
• report.md 没有内部技术字段或内部 ID。

有关架构、使用者快速开始和文档索引，读取 README.md；有关不可变项目约束，读取 PROJECT_RULES.md。