业务智能体每次都从零推理，同一件事做一千次就付一千次的钱，结果还是概率性的；用 AI 更快写出的软件，业务含义仍然写死在代码里，交付即冻结。Livepowers 是一套装进 Claude Code、Codex、Cursor 的工作方法，让智能体先复用已固化的能力，没有才去探索并留下证据，把成功路径固化成经测试的代码，一切成果过独立验收——越用越熟练。
交付即冻结；每次变化都要重新解释需求、改写实现。用 AI 更快地生成这种软件，只是穿新鞋走老路。
同一件事做一千次就付一千次推理的钱，结果还是概率性的；没有证据，没有积累，产品不会变熟练。
高频、可验证、稳定的事固化为 System 1（代码 / CLI / SQL，CPU，便宜、确定）；新问题交给 System 2（Agent + 大模型）探索并留证据；固化失效就去固化。System 2 占比随时间下降，能力库随时间增长。
一张图看完整个系统。上面是一个请求怎么走，中间是三块地基，下面是让产品越用越熟练的日夜循环；技能名用小字标在对应位置。
任何请求先看有没有现成的做法：有就直接用，几乎不花钱、结果确定；没有才让"探索者"（智能体 + 大模型）去想办法——先说清要什么，只在业务地图范围内摸索，做完要过质检。每一步都留下工作日志；走不通就到预算止损，换人接手，而不是无限重试。
业务地图回答"业务里有什么、怎么算、谁能做"，写在代码外面，可以确认和改版；工具箱装的是反复成功后做成"按钮"的能力，每个带测试和责任人；操作手册是 18 个技能，规定什么时候做什么，会话一开始就自动翻开。
白天探索留日志；夜里翻日志，把反复成功的做法先算值不值、再写测试和草稿，顺便查旧工具还灵不灵；早晨人看晨报逐个决定，通过的放进工具箱。于是明天的请求更多走"找到了"——这就是"越用越熟练"。四道护栏贯穿全程：质检、写操作安全、账本、现场交付的资产回流。
写在 using-livepowers 里，会话启动时由钩子注入。它们是强制流程，不是建议。
先检查技能。只要有 1% 的可能适用，就先读。
先 System 1，后 System 2。命中已固化的能力就直接执行，不再重新推理。
没有证据的探索等于没发生。每次探索后都要运行 lp evidence add。
不在本体之外操作。缺对象或口径时提本体变更，不要用一段脚本把缺口盖过去。
写操作必须过安全门禁。八项检查：状态前提、权限、事务、幂等、并发、审批、审计、补偿。
生成者不评审自己。以真实回执为准，不认 Agent 的自我声明。
没有基线的价值不算价值。承诺业务结果之前，先登记基线。
按工作循环分组。每个技能是一个含 SKILL.md 的文件夹，符合 Agent Skills 开放标准。标 NEW 的是 v1.0 新增的。
七条铁律、路由表、三层架构落点（本体 / 工具 / 技能）、标准工作循环和反模式。
两种起步：存量改造（先扫描摸清现有系统）和新建再造（从预置本体出发）。只读扫描，生成环境指纹和本体草稿，夜间检测漂移。
一次只问一个问题；先判断变化落在哪一层（界面 / 参数 / 功能 / 本体 / 会话）；用户不确定的说法记为假设；写出带业务不变量和验收样例的规格。
四个状态：候选 → 已校验 → 已确认 → 已发布。每次变更写明来源、适用范围、生效时间，以及历史结果要不要重算。大小调整走两条通道。
先把请求规范成意图，再查注册表：命中就执行，未命中才进入探索。同时定义了四种去固化信号。
先定轮次和预算，超限自动止损。探索只在本体范围内进行，写操作只预演，结果要用样例核对，并留下别人能接手的产物和证据。
F-V-S-R 门禁和盈亏平衡 → 先写测试 → 确定性实现 → 组装能力包 → 独立验收 → 注册。新能力在产品内上线，不必整版升级。
每个工具一张工具卡、带决策点的业务剧本、硬约束；弱模型跑 10 次成功率要 ≥95%。换模型就重跑基准，模型升级后不再需要的约束就去掉。
四道门依次是：形式检查、契约测试、独立对抗审查、人工采纳。以回执为准，不认声明；派工、执行、验证、采纳、运营五种职责分开。
先仿真后执行；八项检查各配对应测试；审批后重新校验；超时先查状态再决定是否重试；写清存量系统能保证到什么程度。
止损后先冻结、交付诊断包；七类主因只选一个（规格不清 / 本体缺口 / 环境漂移 / 能力失效 / 预算太低 / 工具故障 / 不该做）；换人重开、重定规格或关闭，接管成本入账。
强模型规划、便宜模型执行；按模型能稳定运行的时长切段；交接时写实际终态并指定独立检查者；用 DAG 拆任务、设止损和熔断，统一填作业契约。
看 System 2 占比的变化趋势，挑出固化候选，复核已有能力（失败、闲置、久未复验、换了模型），跑金丝雀评测，生成晨报。
按信任域分级；协调消息和大块内容分两条线；所有 Agent 共用一个任务标识和契约版本；哈希链防篡改，支持回放和审计。
五类底座资产；先白盒、再契约、后证据闭环；同时选一个降本场景和一个增收场景；现场成果过四道门进资产库，并统计回流率；FDE 考核看两项指标。
价值闸门：可量化、可归因、可复现、可经营。先登记基线，再算单位验收任务成本（失败的成本也计入）、首次价值交付时间，以及增量价值 ΔV = B × u。
岗位 = 角色 + 职责 + 智能体团队 + 本体 + 技能 + 工具 + 权限 + KPI + 升级路径 + 人在回路。每项任务标明归属，并算清岗位的经济账。
先看 Agent 在没有技能时如何失败，再写最小的技能去纠正它。description 只写触发条件，写完用结构测试检查。
每个场景写清触发 → 走哪些技能 → 产出。完整命令见 docs/scenarios.md。
注册表未命中，会话级小请求不建任务，直接在本体范围内探索，用已知数字核对，留证据。
评分 ≥5 且调用次数 > n*：夜间先写测试再写参数化 SQL，登记产物；早晨人工过四道门后注册。
lp registry find HIT，核对前置条件后按 entry 调用，几乎零 Token；证据里 S1 占比上升。
"有效跟进"是本体层变化；原子行动填八项检查与九项测试；先预演后执行；注册必须带测试。
只读扫描生成环境指纹和本体草稿，业务逐个确认对象、状态机、口径；选试点场景，登记基线。
指纹比对报漂移；相关能力退役回到 System 2；提本体 Delta 后用 --supersedes 固化新版本。
脚本止损；执行者冻结并交付诊断包；接管人归因只选一个主因；换人重开或重定规格；接管成本入账。
金丝雀记录与比较；Skill 类能力标记待复验；重跑基准后去掉不再需要的约束。
同一任务 id + 契约版本；消息经交换机，哈希链防篡改；审计点名"声称完成却无回执"。
任务归属 auto / agent / handoff / human；接管条件与 KPI；接管比例高就先固化再谈规模。
强模型拆 DAG，按便宜模型可稳定运行的时长切段；每段写作业契约、独立检查者与止损。
基线 → 测量 → 成本归集（含失败、返工、接管）→ 验收任务平均成本、首次价值交付时间、ΔV。
bash examples/walkthrough.sh 的真实输出：用一个虚构的商机数据库走完 扫描 → 基线 → MISS → 三轮探索 → 评分 → 看板 → 独立验收 → 注册 → HIT → 台账 → 漂移 → 晨报。
工作目录：<临时目录> 已初始化 .livepowers/（evidence.jsonl, registry.json, tasks.json, outcomes.jsonl, assets.json, reports/） --- 本体草稿（节选） # 本体草稿（scan_sqlite.py 自动生成）——须业务确认后才能晋升为 ontology.yaml source: sqlite:demo.sqlite ontology_version: 0.1.0-draft objects: - name: activities description: "" # TODO(需业务确认) 业务含义 identity: ['id'] row_count: 0 attributes: - {name: id, type: INTEGER, nullable: true} - {name: opportunity_id, type: INTEGER, nullable: true} - {name: kind, type: TEXT, nullable: true} - {name: created_at, type: TEXT, nullable: true} # 候选时间字段：事件时间还是快照时间？ 已登记基线 stale-opps/逾期重点商机数 = 40.0 MISS —— 未命中已固化能力 → 转 System 2 探索（记得记录证据） （MISS → System 2） t_8a03132e: 待澄清 → 规格确认 t_8a03132e: 规格确认 → 探索 t_8a03132e: 探索 → 探索 t_8a03132e: 探索 → 探索 固化候选（按 调用次数 × 可验证度 排序）： - transfer stale opportunity: S2 3 次, 成功率 100%, 可验证 100%, 均成本 0.8000 （写操作：需 oltp-action-safety） F-V-S-R 评分: 10.0/10 分项 {'F': 2, 'V': 2, 'S': 2, 'R': 1} System 2 有效单次成本 c2' = 2.2500（含失败重试与人工兜底） 盈亏平衡调用次数 n* = 11.1；预计 6 个月内调用 180 次 建议: 固化 提示: 写操作——固化前必须完成 oltp-action-safety 八项检查测试 t_8a03132e: 探索 → 待验证 t_8a03132e: 待验证 → 已注册 已注册 cap_转交逾期商机 v1.0.0 HIT —— 命中已固化能力 → 走 System 1 执行： [3] cap_转交逾期商机 v1.0.0 (cli) entry: crm opp transfer-stale --days {days} [写操作] ok ok ### 场景 stale-opps - 逾期重点商机数: 基线 40.0 → 目标 10.0；当前 22.0（Δ -18，-45.0%） - 归集成本 2.40（inference 2.40） - 通过验收任务 1，未通过 0；验收任务平均成本 = 2.40 - 首次价值交付时间：0.0 天（自范围确认至首个生产任务被采纳） 环境漂移： - customers: 新增列 industry - opportunities.stage: 状态出现新取值 ['on_hold']（状态机须更新） --- 晨报：.livepowers/reports/morning-2026-10-07.md # 晨间报告 · 2026-10-07 …（晨报：待验收产物 · 固化候选 · 金丝雀 · 能力复核 · 看板 · 台账 · 需要人决定的事）
技能之间如何衔接：白天探索，夜间固化，早晨验收。
| 时段 | 发生什么 | 用到的技能 / 命令 |
|---|---|---|
| 白天 | 能复用的直接走 System 1。不能复用的先建任务、设好轮次和预算，再由 Agent 探索；结果经样例核对、过验收门后交付，并留下证据。写操作先预演，确认后再执行。 | system1-first · explore-with-evidence · acceptance-gates · oltp-action-safetylp registry find · lp task · lp evidence add |
| 傍晚 | 把长程任务拆成 DAG，按模型能稳定运行的时长切段，填好作业契约和交接契约，设止损条件。 | night-loop-planning · lp job validate |
| 夜间 | 长程任务运行。固化评审生成草稿和测试；扫描环境漂移；复核已有能力；跑金丝雀评测。Agent 间的协作全程经交换机记录。 | nightly-crystallization-review · crystallize-to-system1 · env-scan-ontology · auditable-agent-commslp candidates · lp score · lp registry review |
| 早晨 | 读晨报。人工采纳后注册（生成者和采纳人必须不同），不通过的写明原因。处理复核项和转入异常接管的任务，更新结果台账。 | /lp-morning · lp report · lp registry add / retire / verify · lp outcome |
lp task 把看板规则写成了代码，不只是写在文档里。
不是所有探索都值得固化。lp score 同时给出评分和盈亏平衡调用次数 n*；建议固化时退出码为 0，否则为 3。
| 维度 | 含义 | 取值 |
|---|---|---|
| F 频率 | 每月预计调用次数 | <4 → 0；4–19 → 1；≥20 → 2 |
| V 可验证 | 结果能否被样例 / 断言自动核对 | 0 / 1 / 2；V=0 一票否决 |
| S 稳定 | 口径、输入结构、接口是否稳定 | 0 / 1 / 2 |
| R 风险 | 是否写生产状态 | 写操作收益最大，但须过八项检查 |
| 合成分 = F×2 + V×1.5 + S + R（满分 10）；≥5 且预计调用次数 > n* 才建议固化 | ||
n* = (K + M) / (c2′ − c1)
c2′ = c2 / p + (1 − p)·h / p
K 是固化成本，M 是维护成本，c1 / c2 是单次执行成本，p 是 System 2 的成功率，h 是失败后人工兜底的成本。成功率越低，固化越划算。夜间空闲算力可以摊薄 K；口径常变会抬高 M。
v1.0 把"算不算完成"和"值不值"也变成了可检查的流程。
| 门 | 发现什么 | 由谁 |
|---|---|---|
| 1 形式检查 | 结构、类型、必填字段、本体版本 | 机器 |
| 2 契约测试 | 验收样例、业务不变量、八项检查 | 机器 |
| 3 独立对抗审查 | 遗漏的前提、口径偏差、越权和异常路径 | 与生成者分离的审查者，用保留测试集 |
| 4 人工采纳 | 业务意义、未被覆盖的风险 | 有权的业务责任人 |
| 台账指标 | 定义 |
|---|---|
| 验收任务平均成本 | 全部归集成本（含失败、返工、接管）÷ 通过验收的任务数 |
| 首次价值交付时间 | 从范围确认到首个生产任务被采纳 |
| 增量价值 | ΔV = 业务基数 B × 提升率 u |
| 资产回流率 | 进入参考库的现场成果 ÷ 现场成果总数 |
纯 Python 3.9+ 标准库，不用安装任何依赖。数据全部落在项目的 .livepowers/ 下，建议纳入 git。
lp init lp registry find "帮我看一下各地区的周收入" # HIT → exit 0；MISS → exit 2 lp task new --title "逾期商机移交" --max-loops 5 --budget 20 lp task move t_xxx explore --by agent-a --reason "假设：按最近有效跟进计" --cost 0.8 lp evidence add --intent "transfer stale opportunity" --system S2 --outcome success --cost 0.8 --verifiable --task t_xxx lp score --freq 30 --verifiable 2 --stability 2 --writes-state --c2 0.8 --c1 0.001 --K 20 --M 5 --p 0.8 --h 5 # → F-V-S-R 10.0/10；c2' = 2.25；n* = 11.1；6 个月预计 180 次 → 建议: 固化 lp task move t_xxx registered --by reviewer-b --reason "四道门通过" --evidence acceptance.md lp registry add --name "转交逾期商机" --kind cli --intents "transfer stale opportunity,转交逾期商机" \ --entry "crm opp transfer-stale" --writes-state --tests "pytest tests/" --generated-by agent-a --accepted-by reviewer-b lp outcome baseline --scenario stale-opps --metric "逾期商机数" --value 40 --target 10 lp asset gate as_xxx abstractable --by reviewer # 依次 versioned / evaluated / reusable lp registry review --current-model model-b # 连续失败 / 闲置 / 久未复验 / 换模型 lp report # .livepowers/reports/morning-日期.md
# 中转模式：所有 Agent 间消息经交换机，append-only + 哈希链 python agent_switch.py serve --port 7070 --log .livepowers/comms.jsonl python agent_switch.py send --from supervisor --to executor --type task --body "实现 issue #12" \ --trace t1 --task t_9f2c --contract spec-12@1.1 # 旁路模式：不中转，框架插件在收发时落盘；大块内容只传引用 python agent_switch.py sidecar-log --from executor --to reviewer --type result --body "完成" --ref git:feat/x@a1b2 python agent_switch.py replay --trace t1 --speed 1 python agent_switch.py verify # 日志被改动会报"哈希链断裂" python agent_switch.py audit # 被拒消息 / 未闭合 trace / 声称完成却无回执
# 只读扫描 → 本体草稿 + 环境指纹（敏感字段只记名称，不抽样） python scan_sqlite.py crm.sqlite --fingerprint fp-1.json > .livepowers/ontology.draft.yaml # relations: # - {from: opportunities.customer_id, to: customers.id, evidence: foreign_key} # - {from: opportunities.owner_id, to: owners.id, evidence: name_inferred} # 推断，须确认 # 夜间漂移检测 python scan_sqlite.py --diff fp-1.json fp-2.json # 有漂移 exit 5 # - customers: 新增列 industry # - opportunities.stage: 状态出现新取值 ['on_hold']（状态机须更新）
# 一键安装技能（默认装到 ~/.claude/skills） npx livepowers install # 其他客户端：--target codex | cursor | agents npx livepowers install --target cursor # 装到当前项目；codex 会同时合并 AGENTS.md 入口说明 npx livepowers install --target codex --project # 全局安装后可直接用 lp 命令（需要 Python 3.9+） npm i -g livepowers && lp --version # 查看 / 卸载 livepowers list livepowers uninstall --target codex --project
/plugin marketplace add zhanglunet/livepowers /plugin install livepowers@livepowers-marketplace # 自带 SessionStart 钩子，自动注入 using-livepowers # 命令：/lp-route /lp-nightly /lp-morning
git clone https://github.com/zhanglunet/livepowers # 个人 cp -r livepowers/skills/* ~/.claude/skills/ # 团队共享（随仓库走） cp -r livepowers/skills/* your-repo/.claude/skills/
# Codex：装到项目，并把入口说明合并进项目的 AGENTS.md（带标记，可卸载） npx livepowers install --target codex --project # 或作为插件：.codex-plugin/plugin.json # Cursor：个人技能目录 ~/.cursor/skills npx livepowers install --target cursor # 或作为插件：.cursor-plugin/plugin.json + hooks/hooks-cursor.json
# 每个技能单独打包为 zip，在设置的技能页逐个上传
bash livepowers/scripts/package-skills.sh
ls livepowers/dist/skills/借鉴了 Superpowers 的形式，解决的是不同的问题；两者可以同装。逐项对比、三种串联用法和 9 个同类产品的详细表见 docs/comparison.md。
| 维度 | obra/superpowers | Livepowers |
|---|---|---|
| 定位 | 软件开发方法论：让编码 Agent 像资深工程师一样工作 | 企业业务产品范式：让业务 Agent 在本体内工作，并越用越熟练 |
| 主流程 | brainstorming → worktree → writing-plans → 子 Agent 执行 → TDD → review | system1-first → 探索留证据 → 验收门 → 夜间固化评审 → TDD 固化 → 能力包注册 → 复核 / 去固化 |
| 世界模型 | 代码仓库 | 本体（描述面 + 运行面），带环境感知、漂移检测和版本化演进 |
| 固化物 | 人工从对话中提炼的 markdown 技能 | 带测试、版本和元数据的确定性代码 / CLI / SQL，组装成能力包；生成者 ≠ 采纳人由脚本强制 |
| 异常与夜间 | 遇阻即停，交给人 | 止损 → 异常接管技能；夜间固化评审、金丝雀、晨报、早晨人工采纳 |
| 成本与价值 | 未涉及 | F-V-S-R、盈亏平衡 n*、S2 占比趋势、结果台账、资产回流率 |
| 写操作安全 | 通用 code review | 先仿真后执行；八项检查与对应测试 |
| 多 Agent | 子 Agent 执行，逐任务审查 | 派工 / 执行 / 验证 / 采纳 / 运营五种职责分离；可审计交换机、回放、信任域分级 |
| 共同点 | 技能是强制工作流；会话启动时注入入口技能；TDD；生成与评审分离；澄清时一次只问一个问题；用压力测试来写技能。两者可以同时安装：Livepowers 负责"做什么、要不要固化、算不算完成"，Superpowers 负责"固化代码怎么写好"。 | |
和其他同类产品比，Livepowers 最像谁、独有什么：
| 产品 | 定位 | 最像的点 | Livepowers 独有 / 缺失 |
|---|---|---|---|
| Agent Skills 标准 · anthropics/skills | 开放技能格式与官方示例库 | Livepowers 完全遵循该格式 | 独有整套业务方法论与运行时；缺触发率自动评测 |
| GitHub spec-kit | 规格驱动开发 | constitution ≈ 铁律 + 不变量；converge ≈ 验收门 | 独有 System 1 路由、固化经济学、夜间循环；缺任务 ID 产物链 |
| BMAD-METHOD | 角色化 Agile 框架 | 多角色 ≈ 数字岗位 + 职责分离 | 独有本体、固化、台账；缺 PRD / Story 模板体系 |
| Agent OS | 提取代码规范注入 Agent | 从环境提取标准 ≈ 环境扫描 | 扫的是业务语义而非代码风格 |
| claude-flow / Ruflo | 多 Agent 编排平台 | 从成功轨迹学习 + 路由 ≈ System 1 优先 | 固化物是可测试代码，有人工采纳门；缺向量检索 |
| Palantir AIP / Ontology | 商业企业平台 | Agent + Ontology 公式；行动审批审计 | 开源、零依赖、可装进任意 Agent；缺本体运行时 |
| Devin Playbooks | 可复用流程 prompt | Playbook ≈ 工具卡 + 剧本 | 固化物是代码而非 prompt；缺从会话自动生成 |
| Voyager 式自增长技能库 | 自动蒸馏技能 | 探索留证据 → 固化 | 独有 n*、生成者 ≠ 采纳人、去固化；缺 hook 自动采集 |
| skills.sh · Cursor rules | 分发渠道 | npx 安装对应这些渠道 | 未上架 skills.sh；不生成 .mdc |
能，而且建议同装。Livepowers 决定"做什么、要不要固化、算不算完成"，Superpowers 决定"固化代码怎么写好"。两者的入口技能都在会话启动时注入，互不覆盖；固化流水线里 Livepowers 挑候选并验收，Superpowers 的 brainstorming → writing-plans → TDD 负责实现。
能。npx livepowers install --target cursor | codex | agents 装到对应客户端的技能目录；任何支持 Agent Skills 标准的客户端都能读 skills/*/SKILL.md。区别是只有 Claude Code 插件自带 SessionStart 钩子自动注入入口技能，其他客户端靠技能描述触发，Codex 可以把入口说明合并进项目的 AGENTS.md（安装器会做）。
lp 命令在哪里？npm i -g livepowers 后直接用（需要 Python 3.9+）；Claude Code 插件里是 python3 ${CLAUDE_PLUGIN_ROOT}/scripts/lp.py，钩子会告诉 Agent 路径；仅复制技能的用户给仓库脚本起个别名。lp --help 列出全部子命令。
全部在项目的 .livepowers/ 下（证据、注册表、看板、台账、金丝雀、晨报、夜间产物），建议纳入 git——它就是产品"变熟练"的记录。本仓库自己的 .gitignore 忽略它只是因为仓库不是业务项目，不要照抄。
不必。用 env-scan-ontology 扫出的草稿本体（版本 0.1.0-draft）就能走通第一个任务，规格里引用草稿对象名，等业务确认后升版。但铁律 4 不变：缺对象、缺口径时提本体变更，不要用脚本掩盖。
不会，这正是它要解决的问题。完成与否由验收条件决定：看板拒绝执行者把任务迁到已注册，注册要求生成者 ≠ 采纳人，夜间产物清单拒绝自我验收，交换机审计会点名"声称完成却无回执"的消息。
Claude Code 插件自带 PostToolUse / Stop 钩子：lp registry find 命中后每次调用该能力都自动记一条 S1 证据（失败也记，能力置信度随之升降）；未命中而本轮结束前没有 lp evidence add，钩子补记一条 partial 的 S2 证据，晨报单列"自动采集待确认"。显式记录仍然优先——它有可验证标记、成本和说明；自动记录只是兜底，LP_HOOK_CAPTURE=0 可关闭。
可验证度 V=0 一票否决；候选要 3 次成功且被样例核对过；固化物必须带测试；写操作缺测试拒绝注册；早晨由人采纳；运行期连续失败、口径变化、环境漂移、换模型都会触发复核或去固化。自动固化并不可靠，所以夜间产出的永远是"草稿 + 测试证据"，最终决定权在人。
用同义词表解决：lp intents alias "weekly revenue by region" "各地区周收入" 登记后，这个别名记的证据自动归到规范名，lp registry find 也按整组同义词匹配。夜间 lp intents suggest 会列出"长得像"的意图对让人确认——只建议，不自动合并，合错口径比多探索一次代价高。
scan_sqlite.py 是示例：按同样的输出结构（对象、属性、外键、状态取值抽样、指纹）查你数据库的 information_schema 即可，其余流程不变。欢迎提 PR 补其他数据库的扫描器。
选一个有代表性的分析场景，启用 using-livepowers、system1-first、explore-with-evidence、outcome-ledger。先登记基线、记录证据，统一意图的命名。
把关键口径写进本体和规格。开启 acceptance-gates 和夜间评审，每天早晨人工采纳，观察 System 2 占比的曲线。
扩展到写操作场景和长程任务，多 Agent 协作接入交换机。现场交付统一走 fde-delivery，把资产回流率纳入评价。
做了什么、为什么、放弃了什么。全文见 docs/devlog.md；版本条目见 CHANGELOG。
lp intents alias / list / suggest。别名落盘为规范名、历史证据读取时归并、路由按整组同义词匹配，同一件事不再因为换了说法而重复探索。取舍：只建议不自动合并；不引入向量检索，保持零依赖和可审计。registry add --supersedes；新增 takeover-handling 技能、lp pending 夜间产物清单、lp canary 金丝雀；入口技能写清三种安装方式下脚本与模板的位置；网站加场景、demo、对比、FAQ、开发日志与反馈入口。推迟：hook 自动采集证据、意图同义词表、触发率自动评测。npx livepowers install 装进 Claude Code / Cursor / Codex，lp 命令随包安装；官网上线。这个项目靠使用反馈迭代。用了之后哪里别扭、不清楚、Agent 绕过了规则、想要什么场景，都请告诉我们。
想动手？路线图总览里每一项都是可独立领取的小项目（触发率评测、任务 ID、Cursor 规则、skills.sh、语义检索、数据库扫描器……）。场景交流与落地经验请到 Discussions。提 PR 前先读 writing-livepowers-skills，并运行 python -m unittest discover -s tests -v。