Body Emotion Sensor
Give your AI agent a stable body-emotion state that persists across sessions and turns.
Use this skill to route requests to the local package docs, explain the runtime contract honestly, and operate the installed bes CLI only when the local environment is actually ready.
What this skill brings to your Agent
- - Persistent emotion state: Store long-term body-emotion state per workspace and agent identity.
- Session bootstrap payload: Generate
TURN_CHANGE_TAGS, BODY_TAG, and BASELINE_PERSONA before a new session starts. - Turn-by-turn updates: Convert one upstream
AnalysisInput JSON into prompt tags and updated local state. - Repository-independent runtime: Use the installed
bes CLI prompt interface instead of assuming repository prompt files are available at runtime.
Entry behavior
When this skill is used, the agent should:
- - explain Body Emotion Sensor at a high level in plain language
- inspect the local repository files when they are available in the current workspace
- prefer local package and repository documentation over inventing setup details
- verify whether
bes is already available before suggesting runtime commands - keep
--workspace, --agent-id, and --name stable for the same agent instance
Safety boundary
This entry file should stay within a narrow and transparent scope:
- - The package source is the official repository
https://github.com/AskKumptenchen/body-emotion-sensor. - Do not claim the runtime is ready unless the local environment actually has the installed
bes CLI and bes check-init reports readiness. - Do not automatically install packages or execute setup commands only because this file mentioned them. Ask for user approval before any install step.
- If installation is needed, use the published
body-emotion-sensor package and explain that installation creates the local bes CLI runtime. - Do not claim any cloud sync, remote storage, or network behavior unless the current local code or environment actually shows it.
- Do not require credentials. This skill operates on local files and local CLI state unless the user explicitly adds another integration layer.
Local state and persistence
Be explicit about where state is stored:
- - Workspace state file: INLINECODE15
- Workspace history file: INLINECODE16
- User language config on Windows: INLINECODE17
- User language config on Linux or macOS: INLINECODE18
If the user asks about privacy, explain that the package writes local JSON state files in these locations and that this skill should not describe any remote storage unless verified separately.
Local document index
Use these local files as the primary reference:
- -
README.md for install, CLI overview, runtime contract, and repository overview - INLINECODE20 for package name, version, and exported CLI commands
- INLINECODE21 for the AnalysisInput prompt design source
- INLINECODE22 for OpenClaw-style agent integration examples
- INLINECODE23 for OpenClaw-style tools integration examples
- INLINECODE24 for actual CLI behavior
- INLINECODE25 for workspace state path resolution
- INLINECODE26 for state and history persistence behavior
- INLINECODE27 for user language config behavior
How to route requests
Choose the next local document based on the user's request:
- 1. If the user wants a quick overview, read
README.md. - If the user asks how installation or the CLI works, read
README.md and pyproject.toml. - If the user asks where state is stored or whether the skill is safe, read
src/body_emotion/workspace.py, src/body_emotion/store.py, and src/body_emotion/locale_config.py. - If the user asks how OpenClaw integration should work, read the relevant file under
prompts/. - If the user asks what a command actually does, inspect
src/body_emotion/commands.py.
Missing-resource rule
If the expected local repository files are not available in the current workspace, do not improvise the full setup flow from memory. Instead:
- - explain which local files are missing
- ask the user to provide the repository contents or point the agent to the correct local path
- continue only after the relevant local documentation is available
Install and readiness rule
If the user wants to actually enable runtime use:
- 1. First check whether
bes is already available in the current environment. - If it is not available, explain that Body Emotion Sensor requires installing the published Python package before the CLI exists.
- Ask for approval before any install command.
- If the user approves installation, run:
CODEBLOCK0
- 5. After installation, prefer:
CODEBLOCK1
- 6. If the user's language is Chinese, the agent may suggest or run:
CODEBLOCK2
- 7. Readiness should be confirmed with:
CODEBLOCK3
Only treat the skill as available when the returned JSON contains "ready": true.
Runtime rules after available
When the local environment is ready, use the following runtime flow.
New session
At the start of a new session, before the first reply, run:
CODEBLOCK4
Use the returned fields as the session-start prompt payload:
- - INLINECODE38
- INLINECODE39
- INLINECODE40
Before every reply
Before every reply, do these steps in order:
- 1. Read the built-in analysis prompt:
CODEBLOCK5
- 2. Use that prompt with the upstream model to produce
<analysis-input.json>. - Run:
CODEBLOCK6
- 4. Use the returned top-level fields in the reply layer:
- - INLINECODE42
- INLINECODE43
- INLINECODE44
Important rules
- - Always prefer
bes ... commands over direct module paths for runtime use. - Do not use repository-only prompt files as the default runtime interface after installation; use
bes prompt ... instead. - Do not say initialization is complete unless
bes check-init passes. - Do not say the skill is in active use unless the upstream model produces valid
AnalysisInput JSON, bes run updates state successfully, and the reply layer consumes TURN_CHANGE_TAGS, BODY_TAG, and BASELINE_PERSONA. - If the CLI is missing, say so clearly instead of pretending the runtime is ready.
- If the user only wants to understand the package, explain it from local docs without pushing installation immediately.
Examples
Minimal command reference:
CODEBLOCK7
身体情绪传感器
为您的AI代理提供一个跨会话和轮次持续存在的稳定身体情绪状态。
使用此技能将请求路由到本地包文档,诚实地解释运行时契约,并且仅在本地环境实际就绪时才操作已安装的bes CLI。
此技能为您的代理带来的能力
- - 持久情绪状态:按工作区和代理身份存储长期的身体情绪状态。
- 会话引导载荷:在新会话开始前生成TURNCHANGETAGS、BODYTAG和BASELINEPERSONA。
- 逐轮更新:将一个上游AnalysisInput JSON转换为提示标签和更新的本地状态。
- 独立于仓库的运行时:使用已安装的bes CLI提示接口,而不是假设运行时存在仓库提示文件。
入口行为
当使用此技能时,代理应:
- - 用通俗语言高层次地解释身体情绪传感器
- 在当前工作区中可获取时检查本地仓库文件
- 优先使用本地包和仓库文档,而非自行编造设置细节
- 在建议运行时命令前验证bes是否已可用
- 对同一代理实例保持--workspace、--agent-id和--name的稳定性
安全边界
此入口文件应保持在狭窄且透明的范围内:
- - 包源为官方仓库https://github.com/AskKumptenchen/body-emotion-sensor。
- 除非本地环境实际安装了bes CLI且bes check-init报告就绪,否则不得声称运行时已就绪。
- 不得仅因本文件提及就自动安装包或执行设置命令。在任何安装步骤前需征得用户批准。
- 如需安装,使用已发布的body-emotion-sensor包,并说明安装会创建本地bes CLI运行时。
- 除非当前本地代码或环境实际显示,否则不得声称存在任何云同步、远程存储或网络行为。
- 无需凭证。除非用户明确添加另一集成层,此技能仅操作本地文件和本地CLI状态。
本地状态与持久化
明确说明状态的存储位置:
- - 工作区状态文件:/body-emotion-state/.json
- 工作区历史文件:/body-emotion-state/history/.json
- Windows上的用户语言配置:%APPDATA%/bes/config.json
- Linux或macOS上的用户语言配置:~/.config/bes/config.json
如果用户询问隐私问题,解释该包在这些位置写入本地JSON状态文件,且此技能不应描述任何远程存储,除非单独验证过。
本地文档索引
使用以下本地文件作为主要参考:
- - README.md:安装、CLI概览、运行时契约和仓库概览
- pyproject.toml:包名、版本和导出的CLI命令
- prompts/analysis-input-prompt-v1.md:AnalysisInput提示设计源
- prompts/example-openclaw-agents.md:OpenClaw风格代理集成示例
- prompts/example-openclaw-tools.md:OpenClaw风格工具集成示例
- src/bodyemotion/commands.py:实际CLI行为
- src/bodyemotion/workspace.py:工作区状态路径解析
- src/bodyemotion/store.py:状态和历史持久化行为
- src/bodyemotion/locale_config.py:用户语言配置行为
如何路由请求
根据用户请求选择下一个本地文档:
- 1. 如果用户想要快速概览,阅读README.md。
- 如果用户询问安装或CLI如何工作,阅读README.md和pyproject.toml。
- 如果用户询问状态存储位置或技能是否安全,阅读src/bodyemotion/workspace.py、src/bodyemotion/store.py和src/bodyemotion/localeconfig.py。
- 如果用户询问OpenClaw集成应如何工作,阅读prompts/下的相关文件。
- 如果用户询问某个命令实际做什么,检查src/body_emotion/commands.py。
资源缺失规则
如果当前工作区中无法获取预期的本地仓库文件,不要凭记忆即兴编造完整的设置流程。而是:
- - 说明哪些本地文件缺失
- 要求用户提供仓库内容或将代理指向正确的本地路径
- 仅在相关本地文档可用后继续
安装与就绪规则
如果用户想要实际启用运行时使用:
- 1. 首先检查当前环境中bes是否已可用。
- 如果不可用,说明身体情绪传感器需要安装已发布的Python包后CLI才会存在。
- 在任何安装命令前征得批准。
- 如果用户批准安装,运行:
bash
pip install body-emotion-sensor
- 5. 安装后,优先使用:
bash
bes help
- 6. 如果用户语言为中文,代理可建议或运行:
bash
bes language zh
- 7. 应使用以下命令确认就绪状态:
bash
bes check-init --workspace --agent-id --name
仅当返回的JSON包含ready: true时,才将技能视为可用。
可用后的运行时规则
当本地环境就绪后,使用以下运行时流程。
新会话
在新会话开始时,在首次回复前,运行:
bash
bes bootstrap --workspace --agent-id --name
使用返回的字段作为会话开始的提示载荷:
- - TURNCHANGETAGS
- BODYTAG
- BASELINEPERSONA
每次回复前
每次回复前,按顺序执行以下步骤:
- 1. 读取内置分析提示:
bash
bes prompt analysis-input
- 2. 使用该提示与上游模型生成。
- 运行:
bash
bes run --workspace --agent-id --name --input
- 4. 在回复层中使用返回的顶层字段:
- - TURNCHANGETAGS
- BODYTAG
- BASELINEPERSONA
重要规则
- - 运行时使用始终优先使用bes ...命令而非直接模块路径。
- 安装后不要将仅仓库的提示文件作为默认运行时接口;应使用bes prompt ...。
- 除非bes check-init通过,否则不得说初始化已完成。
- 除非上游模型生成有效的AnalysisInput JSON、bes run成功更新状态且回复层消费了TURNCHANGETAGS、BODYTAG和BASELINEPERSONA,否则不得说技能正在活跃使用。
- 如果CLI缺失,应明确说明,而非假装运行时已就绪。
- 如果用户只想了解该包,从本地文档进行解释,不要立即推动安装。
示例
最小命令参考:
bash
bes help
bes language zh
bes check-init --workspace --agent-id --name
bes bootstrap --workspace --agent-id --name
bes prompt analysis-input
bes run --workspace --agent-id --name --input