lovstudio 我的词库 · My Vocabulary
把散落在各语音输入法里的词条收敛成一份属于你的规范词汇表，需要时再按 App 的格式同步回去。不改任何 App 内部行为，只做词条的收集、去重、映射与推送。
Triggers
Activate when
- 用户要求维护或整理个人词汇表、术语表、专有名词表，例如“帮我维护词汇表”“整理我的语音输入词库”。
- 用户要求把词汇同步或迁移到某个语音输入法/剪辑工具，例如“把词汇表填到 OpenLess”“同步到 Typeless”。
- 用户给了某款 App 的词汇表来源（文件、API、导出），要求合并去重到统一词库。
- The user asks to manage, dedupe, or sync a personal dictation vocabulary across apps.
Do not activate when
- 用户只是在正常使用语音输入功能，没有要求维护词库。
- 用户要改某款 App 的语音识别/模型/接口配置本身（交给对应的 App 专项 skill 或人工）。
- 用户要求批量抓取或逆向他人词库、绕过授权；本 skill 只处理用户自己的数据。
User Profile (cross-session)
本 Kit 通过 skill.yaml 连接共享 user-profile/v1。每次运行读取共享 user、brand、workspace、preferences 与本 Skill 的 skills.lov-personal-vocabulary 命名空间；优先级为当前请求、项目上下文、本 Skill records、共享 preferences、共享 user/brand、保守默认值。
用户直接说出、且明确希望长期沿用的偏好（例如“词汇表放这个目录”“语言用 zh-CN”）才通过 scripts/profile_store.py record --confirm 写入 Profile 并报告保存路径。凭据、token、私人路径与推断结论不持久化。完整约定见 references/user-profile.md。
Skill Kit Modules
本仓库是自包含 Skill Kit。Step 0 必须完整加载：
$SKILL_DIR/skills/canonical-store/SKILL.md—lov-canonical-store：规范词汇表结构与读写。$SKILL_DIR/skills/app-adapters/SKILL.md—lov-app-adapters：各 App 词条格式与读写映射。$SKILL_DIR/skills/sync-plan/SKILL.md—lov-sync-plan：规范词库与各 App 的差异与同步计划。
kit.yaml 定义流水线 full（canonical-store → app-adapters → sync-plan）。每个模块必须随本仓库提供，不引用外部 sibling Skill。
Skill Group Composition
读取 references/skill-composition.md 后再决定是否调用或扩展相邻能力。该记录区分可选的上游/下游交接与内嵌 Kit 模块；绝不静默依赖未随本源码提供的 sibling Skill。
Workflow (MANDATORY)
你必须按顺序执行以下步骤。
Step 0: 解析根目录、依赖与运行时上下文
- 有
SKILL_DIR用它；否则从当前 skill 上下文推断安装目录。 - 开始前校验每个所需本地模块、参考、脚本与资源是否齐全。
- 缺失时点出相对路径并停止，不产出半成品。
手动运行脚本：
export SKILL_DIR="/path/to/lov-personal-vocabulary"
每次调用解析 context.profile，优先级见上方。持久化用 scripts/profile_store.py record --confirm，随后给出简洁的保存路径报告。
Step 1: 明确结果
- 区分内部上下文与用户可见产出。
- 确认输入（来源是本地文件、API 还是用户口述）、目标 App、期望产出与证据缺口。
- 记下一个真实用户案例后才算完成；案例必须包含输入、最小 prompt 与输出，不得编造。
Step 1.5: 分析相邻 Skill
- 按路由契约与具体输入/输出检查相邻本地与已装 Skill，不要只看文件名。
- 在
references/skill-composition.md记录 upstream/core/downstream/overlap/not-composed 决策。 - sibling Skill 保持可选、按产物交接；多阶段强耦合时改为自包含 Kit。
Step 2: 执行流水线
- canonical-store：建立或读取规范词库
vocabulary.json。若来源是新词条，用scripts/vocab_cli.py merge做按 phrase 去重合并，保留enabled、hits、category等已有字段。 - app-adapters：确认目标 App 的读入/写出映射。本地 JSON（如 OpenLess
dictionary.json）直接读写；走 API 的（如 Typeless/user/dictionary/list）用用户自己的凭据、只读探测，绝不打印 token。格式未知的 App（如剪映）先探测再补映射，不得编造。 - sync-plan：用
scripts/vocab_cli.py diff --app <id> --canonical <path>计算差异，产出add（新增）、skip（已存在/相同）、conflict（同 phrase 不同字段）三类。向用户确认后再执行写入，默认不覆盖对方已有词条。
Step 3: 校验产物
- 核对完整性、去重正确性、用户可见文案与输出路径。
- 报告具体文件或结果，以及剩余证据缺口。
- 校验
skill-card.yaml、cases/cases.json、pricing-card.yaml作为标准信任包。
Deterministic helper
python3 "$SKILL_DIR/scripts/vocab_cli.py" merge \
--canonical vocabulary.json \
--import openless-dictionary.json \
--from-app openless
python3 "$SKILL_DIR/scripts/vocab_cli.py" diff \
--app openless \
--canonical vocabulary.json
脚本只做纯文本去重、diff 与格式转换；不访问网络、不写目标 App、不改任何 App 内部数据。
Dependencies
- Python 3.9+，仅标准库。
- 各 App 的读写按 adapter 选用；无 App 时仅做 canonical 维护，不构成强依赖。
通用反馈闭环
用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：
- 先判断意见是
task-specific（仅本次）还是reusable（可跨任务复用）。 task-specific只修改当前任务，不改 Skill。reusable先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。- 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
reusable修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。