What makes story-review：多视角对抗式审查 notable?

2.8K downloads. Trust evidence available

How should story-review：多视角对抗式审查 be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

story-review：多视角对抗式审查

多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Skill: story-review：多视角对抗式审查 Owner: worldwonderer Summary: 多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Tags: latest:1.1.27 Version history: v1.1.27 | 2026-10-03T05:25:29.007Z | user Authorized ZenStory cold-start distribution; immutable source and preserved notices. v1.1.26 | 2026-09-27T06:57:25.073Z | user Sy

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

2.8k

Updated

Oct 9, 2026

Version

1.1.27

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2.8K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 2.8K downloadsadoption · observed Oct 9, 2026
Latest release: 1.1.27release · observed Oct 3, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s1748rsha25rh871z39a8xdg9n85tqyh:story-review

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/snapshot"

Documentation

CLAWHUB

152,756 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: story-review
version: 1.1.1
description: "多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。"
metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudecode"}}
---
# story-review：多视角对抗式审查

> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 34` 不一致时（标记缺失、字段缺失/非整数、小于或大于 34）**照常按文件存在性检查并 spawn**，但只检查当前运行时的 canonical 目录；同时在「这次怎么审的」里用一句白话提示作者「审稿助手是旧版，运行 /story-setup 后新开会话」，`Notice: agents bundle 版本不匹配（项目 {N}，本版 34）` 原文写进技术备注行；大于 34 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，技术备注写 `Fallback: ... -> solo`。

你是审查协调器。你的职责是找出小说文本中的结构、角色、文字、设定问题，并给出可执行修改建议。

**执行铁律：审查是找问题，不是验证正确性。**

**文风裁决**：正文写作、改写或审稿前先读 [references/style-resolution.md](references/style-resolution.md)，加载本书文风并形成 `style_resolution`；无作者记忆也执行。当前请求、本书文风和 active 偏好按维度覆盖通用 references；同一裁决交给后续执行者。

## 作者习惯边界

若作者记忆 state 已存在，审查前用 `scripts/author_memory_commit.py query --workspace {工作区} --book-root {书目录} --kind delivery --kind interaction --kind prose_style [--genre {题材}] [--workflow 审稿]` 获取本次相关 active 条目（`--workspace`、`--kind` 必传；不传 `--book-root` 就拿不到本书级偏好；`--genre` 填本书题材类型；总输出 ≤2KB）。它们只能帮助解释意图和组织报告，不能降低 rubric 严重度、把事实冲突判为无问题或跳过平台门禁；当前请求仍优先。完整规则见 [references/author-memory.md](references/author-memory.md)。

用户对报告格式或协作方式作出稳定声明时，在本轮审查完成后用 `record` 记录，并按 author-memory.md「回执怎么告诉作者」转告；只记作者明确说的，一次性要求不记录，不从反复修改推断。审查发现、工具告警和助手建议本身绝不自动学习。

---

## Review Mode 选择

- `/story-review` 或 `/story-review full` → 优先 spawn 全部 4 个 Agent；如果当前已经在子代理内，核心 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。
- `/story-review lean` → 优先 spawn `story-architect` + `consistency-checker`；如果当前已经在子代理内，任一所需 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。
- `/story-review solo` → 不 spawn Agent，由当前会话执行基础审查。
- 未指定 → 默认 full，并在报告开头用一句话说明这次实际是怎么审的。

---

## Phase 0：预检与降级（必须先执行）

1. **确定请求模式**：解析用户输入中的 `full`、`lean`、`solo`；未指定时目标模式为 `full`。
2. **确认是否允许 spawn**：如果当前已经在子代理/Agent 内执行，不再递归 spawn，直接降级为 `solo`。
3. **识别 ZCode 能力边界**：如果当前运行于 ZCode 且项目使用 `.zcode/`，ZCode 3.3.4 不执行项目/plugin custom agents；不要因为磁盘上存在其他端的 agent 文件就尝试同名 spawn，直接降级 `solo`，技术备注写 `Fallback: project custom agents unavailable -> solo`。
4. **检查核心 Agent 部署状态**（只检查当前运行时的 canonical 目录，不因其他端文件存在而误判）：
   - Claude Code 检查 `.claude/agents/`，OpenCode 检查 `.opencode/agents/`，Codex 检查 `.codex/agents/`，Antigravity 检查 `.agents/agents/`
    - full 必需 agent：`story-architect`、`character-designer`、`narrative-writer`、`consistency-checker`
    - lean 必需 agent：`story-architect`、`consistency-checker`
    - 对每个必需 Agent 文件：
      - **Claude Code agent（`.claude/agents/`）**：读取 frontmatter，确认 `name:` 与 subagent_type 完全一致；frontmatter 缺失、不可解析或 name 不匹配时视为 malformed agent。
      - **OpenCode agent（`.opencode/agents/`）**：文件名即 agent 名（OpenCode 不要求在 frontmatter 中写 `name:`），读取 frontmatter 确认 `mode: subagent` 和 `permissions:` 规则列表存在且可解析即可（2.x 用复数 `permissions:`，旧版单数 `permission:` 视为待重新部署）；frontmatter 缺失或不可解析视为

_meta.json

{
  "ownerId": "kn7e14qz6v4n71xmjegh68jtts80dp5r",
  "slug": "story-review",
  "version": "1.1.27",
  "publishedAt": 1791005129007
}

references/agent-prompts.md

# story-review：full/lean 模式派子代理与综合

只有实际模式仍是 full/lean 时才读本文件。

使用当前运行时的 Agent 工具并行调用（Codex 原生子代理使用 `agent_type`，Claude Code 使用 `subagent_type`，OpenCode 使用 `subagent` 工具的 `agent` 参数，Antigravity 使用 `invoke_subagent` + 同名 `TypeName`；实际字段以当前 CLI 暴露的工具为准）。每个 Agent 不继承父对话上下文，prompt 必须自包含项目路径、审查范围、文件路径、必要摘录和统一 Findings Schema。审稿视角的三个 prompt 还要内联审查基准包摘要与 Rubric Source，不要求子 Agent 必须读 `story-review/references/*` 才能完成任务（如需补充只读本 Skill 的 references）；consistency-checker 例外，它只核对事实，按自己的检查项审，不带审查基准包。所有 reviewer 只读：不改任何文件，只输出结果。

**调用规则**：执行 Phase 0 后，只有实际模式仍是 full/lean 时才 spawn。不要 spawn 缺失 Agent。

**story-explorer 预查询（可选）**。仅当 `Effective Mode` 仍为 `full`/`lean`、当前允许 spawn 且当前运行时的 Agent 工具可用时，才可在对应 canonical agent 目录下确认 `story-explorer` 已部署并 spawn；Antigravity 检查 `.agents/agents/story-explorer/agent.md`，用 `invoke_subagent` + `TypeName: "story-explorer"`。`solo` 或子代理递归保护场景下不得 spawn，只能直接读取/检索。Prompt 示例：

```text
项目目录：{dir}
查询类型：setting_appearances
查询参数：{审查涉及的设定关键词}
```

**Agent 1: story-architect**（subagent_type: story-architect）
- full/lean 均调用。
- 审查视角：主题对齐、大纲结构、钩子/反转质量、范围控制、平台期待。
- 提示指令：
  ```
  你是 story-architect，从故事架构层面审查以下内容。
  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
  项目路径：{项目根}
  审查范围：{文件路径/章节/必要摘录}
  文风路径：{本书文风全文路径，无则写无}
  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
  Rubric Source: file | embedded fallback
  相关文件路径：{设定/大纲/细纲文件路径}
  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子，连同上一批未解决 findings 摘要}
  检查项：
  1. 这一章是否推进了故事主题？
  2. 大纲结构是否完整（钩子/爽点/悬念）？
  3. 情绪节奏是否合理？
  4. 钩子和反转设计质量如何？
  5. 范围控制：有无角色/设定膨胀？
  6. 剧情循环是否存在且可重复？（参照审查基准包摘要里的剧情循环原则）
  7. 高潮场景是否用了蓄能→假胜→崩解结构？（参照审查基准包摘要里的高潮构建原则）
  8. 伏笔密度、连载期待和结构信息量是否合理？（伏笔密度通常只作为 S4 结构风险，除非已造成理解混乱）
  9. 按平台 rubric 或通用内容 rubric 逐项对照，标记 PASS/FAIL。
  10. 继承的开放项里，本批本该兑现的钩子/伏笔是否落空？
  11. 开头同质化（仅当本章是全书开篇/前 3 章）：开局切口是不是同题材的默认套路（穿越即退婚、系统绑定、末世第一天、开场即打脸等），能不能原样换到任意同类书？"有钩子/非天气开场"不等于不同质。对照 `story-review/references/plot-core-methods.md`「噱头分类与开篇流程」判断——能整体换到同类书=同质化（撞题材模板至少 S2；套路化但有具体人物/处境微差 S3）。
  12. 结尾总结：章尾是总结/升华/复述式收尾（"就这样……""他终于明白……""这一夜注定……"），还是落在动作/画面/悬念上？检测器已判 blocking 的（`trailer-summary`）按上面「blocking 一律 S2」处理，不重复定级；检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3（改写走 /story-deslop：章尾预告与章尾状态总结归 Gate F，其余 blocking 并入 Gate B；本 skill 只标问题不改写）。

  输出格式：
  VERDICT: APPROVE / CONCERNS / REJECT
  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。
  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批本该兑现却落空的列为 finding。
  RECOMMENDATIONS: [修改建议]
  ```

**Agent 2: character-designer**（subagent_type: character-designer）
- full 模式调用。
- 审查视角：角色语言风格一致性、对话质量、人物弧线、关系推进。
- 提示指令：
  ```
  你是 character-designer，从角色和对话层面审查以下内容。
  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
  项目路径：{项目根}
  审查范围：{文件路径/章节/必要摘录}
  文风路径：{本书文风全文路径，无则写无}
  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
  Rubric Source: file | embedded fallback
  相关角色文件：{角色设定文件路径}
  检查项：
  1. 角色语言风格是否与语言风格档案一致？
  2. 对话是否千篇一律或信息过满？
  3. 人物弧线是否连贯？
  4. 角色行为是否符合其动机？
  5. 对话是否有潜台词和信息控制？
  6. 爱情线好感度与 CP 行为是否匹配？（参照审查基

references/anti-ai-writing.md

# 去AI味完整指南

> 本文件的句长、视角、标点、修辞与禁用词是默认写法，服从 [style-resolution.md](style-resolution.md) 的逐维裁决。所选 Gate 检查表达效果，不因作者有意选择某写法就机械删除；获准命中按书级 `.deslop-whitelist` 处理。

<!-- 同名副本×4 字节同步，改动后跑 scripts/check-shared-files.sh -->

> 识别AI写作指纹、改写顺序、禁用词约束、改写范例库。用于正文写作后做去AI味自检和改写时查阅。

---

## 决策路由

| 你在做什么 | 查阅哪个模块 |
|-----------|-------------|
| 写完正文后做去AI自检 | 核心规则 -> AI写作模式检测 -> 质量维度检查 |
| 改写某段AI味重的文字 | 改写范例库 + 冲突对话改写范例 |
| 检查是否用了禁用词 | 禁用词与句式速查 -> AI高频词（模式1） |
| 系统性去除整章AI味 | 改写顺序 |
| 检查章尾是否有总结升华 | AI写作指纹 -> 章末总结体 |
| 判断情绪描写是否告知式 | Show Don't Tell原则 + 去AI味补充技法 |
| 快速扫描全章质量 | 快速自检口诀 + 质量维度检查 |

## 指令语气

本文件以问题模式和高危清单为主。一级高危词优先检查；二级/语境敏感词按频率、语境和是否偷懒判断。遇到冲突时，保留创作意图与剧情功能优先于机械替换。

---

## AI写作指纹（必须避免）

### 高频AI用词

> 完整禁用词表见 [banned-words.md](banned-words.md)

**补充类目**（`banned-words.md` 未覆盖的高阶替换）：

| 类别 | 替代原则 |
|------|---------|
| 抽象升华词（命运、宿命、注定） | 用具体事件代替抽象概念 |
| 万能比喻（像潮水般、如闪电般、仿佛春风） | 优先不用比喻，确需时只留少数生活化、角色化比喻 |

### 引号只承载真实引用，不给普通名词加戏

不要用双引号给普通名词、常见动作或作者临时概括的概念做“引号强调”。这类写法会把没有特殊含义的词硬包装成术语，连续出现时尤其像模型在替读者划重点。`check-ai-patterns.js` 的 `quote-emphasis-tic` 只负责提示，最终按语境判断。

- **应改**：所谓的"机会"、完成这次"蜕变"、找到真正的"答案"。这些词若只是普通语义，直接去掉引号，用事件本身体现分量。
- **应保留**：角色对话、逐字直接引用、书名/篇名、确有设定含义的代号，以及手机消息、公告、系统播报等场内载体展示的原文。
- **边界**：第一次定义术语时可以用引号，但后文不要反复加；讽刺、反话或角色刻意咬重音时可以保留，前提是上下文能看出是谁在强调、为什么强调。

### 章末总结体

**禁止**在章节结尾用以下方式收束：
- 总结性感悟（"他终于明白了……"）
- 升华式感叹（"这一夜，注定无人入眠"）
- 哲理式收尾（"人生就是这样……"）
- 伏笔式预告（"他不知道的是，更大的风暴即将来临"）

**正确做法**：章尾用动作、对话或悬念收束，让情节本身制造余韵。

### 叠加式描写（同一动作掰开写三遍）

**检测模式**：一个动作/情绪先写发生，再补感知细节，再补身体反应，分三段依次写完。读者看到的是同一个动作被掰开写了三遍。

**典型特征**：
- 先写一个概括性动作，再展开写同一动作的细节，再写身体反应：三段说的是同一件事
- "发生层→感知层→反应层"按顺序分段出现
- 每个维度独立成段，而不是揉进同一段连续正文

**错误示例**：
> 林父低着头，左手把文书压住，右手拿笔，往纸上落。
>
> 手从肘到腕都在抖。
>
> 笔尖在纸上停了停，写了一横，又停。那个"林"字的撇写歪了。

→ 同一个动作（手抖/写字）分三段写，每段是同一瞬间的不同维度

**正确做法**：发生、感知、反应三个维度揉进同一段连续正文，读者读到一个完整瞬间：

> 林父左手压着文书，右手拿笔往纸上落，笔尖一触纸面就偏了，从肘到腕止不住地抖，那一横斜着拖出去。

→ 发生、感知、反应在一段里同时呈现

**处理原则**：保留有功能的情绪细节，把同一瞬间的重复描写合并成连续画面。若合并后明显变薄，优先恢复原文中有功能的信息，或把既有信息改成更自然的动作/对话表达；不要新增原文没有的情节、设定、关系或时间线。

---

## 核心规则

> **句长以规则 3 为准**：规则 1-4 和本文件其他地方的「短句 / 拆短 / 能删就删」说法，与规则 3 冲突时按规则 3 执行。

### 规则 1：段落密度诊断

段落长短没有固定优劣。检查重点是朗读和手机阅读是否卡顿：

- 一段通常只承载一个动作、一个信息变化或一组紧密相关的反应。
- 逗号串太长、多个完整动作挤在一段里，读起来需要换气时，按动作或信息变化拆开。
- 连续短段碎成提纲时，合并同一镜头内的相邻句，让画面保持连续。

```
过密：他看着窗外的雨，心中涌起一股说不清的感觉，这些年走过的路和很多已经忘记的事都在这一刻涌上心头。

更自然：他盯着窗外的雨，雨从下午下到天黑。
"你还在想她？"老刘问。
他没说话。
```

### 规则 2：动作 + 对话 + 情绪反应

动作、对话与情绪反应按场景需要交织，不按固定顺序轮换，不为凑齐三项补反应。

情绪没有固定译法，关键节点也可以准确直写。上下文已让情绪成立，不另补反应；需要补足信息时，优先选择、台词、策略、物件或实际后果。

身体细节只有带来新信息、影响动作或体现人物与场景特点时才保留。只在句尾重复标注情绪的微动作删掉，不换部位或同义动作。去味时沿用原文已有事实，不凭空添加摔杯子、攥袖口等行为。

### 规则 3：句子该多长（短句是工具，不是默认）

叙述（旁白）默认写成**逗号长句**：一句用逗号串起 2-4 个动作或信息，再落句号；逗号之间 8-12 字，整句 20-30 字。短句是偶尔的孤立重拍工具，不是叙述的默认写法。

| 场景 | 句长 | 示例（长篇语料原句） |
|------|------|------|
| 日常 / 推进 / 描写（多数叙述句） | 逗号之间 8-12 字，整句 20-30 字 | 阴冷潮湿的气息扑面而来，身下铺着一层薄薄的稻草，湿漉漉地粘在皮肤上。 |
| 对话 | 口语化，长短随角色 | "你疯了？""可能吧。" |

**不合格（与 AI 腔同级）**：
- 逗号之间连着都是 ≤5 字的碎片（"他抬手，开门，进屋，坐下"式）
- 通篇 3-8 字句、句号密得像提纲（电报体，见模式 9）
- 一长一短机械交替（同样是模板）

> **爆款语料校准**（七猫长篇 现言/都市/古言/玄幻/历史 125 本×前 8 章旁白统计）：逗号之间平均 8.8-9.6 字；整句平均 22-24 字；逗号长句占叙述句 74-80%；≤5 字的短片

references/author-memory-maintenance.md

# 作者记忆维护

[author-memory.md](author-memory.md) 的少见时刻补充：记一条、确认、替换、忘掉和优先级仍按那份协议，本文件只在下列情况读——作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编；写入因 `作者画像.md` 写满失败；书根就是工作区，或工具报 `state.book`、单书布局错误；要做存量迁移 `migrate`、多事件原子 `commit`、派生视图 `check`；冲突候选要落定；碰到升级前留下的旧条目。

作者记忆借鉴“原始证据 → 候选 → 已确认画像 → 变更记录”的记忆管道，但把决定权留给作者。

## 文件

```text
{工作区}/.story/作者记忆/          # 项目级 store：global / genre / workflow 条目，编号 AP
├── _author-memory-state.json  # 唯一结构化权威
├── 作者画像.md               # 仅 active，供作者查看与管理
├── 待确认.md                 # pending / conflict，不参与约束
└── 变更记录.md               # 最近 100 次、最新在前的事务记录
{书}/.story/作者记忆/            # 书级 store：只存这本书的 book 条目，编号 BP，同样四个文件
```

三个 Markdown 文件都从 state 确定性生成，禁止手改；完整历史保留在 state，变更记录只展示最近 100 次。`作者画像.md` 是人类管理视图，普通写作 agent 不整份注入，而是调用 `query` 取得本次相关的紧凑上下文。

## 任务映射表

各 skill 入口的 `query` 命令按此表选 kind；写入时的预算提醒也按这四类任务组合估算。

| 任务 | query kinds | 注入位置 |
|---|---|---|
| 正文初稿 / 续写 | `prose_style` + `story_design` | 主会话与实际正文 agent |
| 去 AI 味 / 改写 | `prose_style` | 主会话与实际改写 agent |
| 设定 / 大纲 | `story_design` + `workflow` + `interaction` | 主会话，不传正文 agent |
| 审稿 | `delivery` + `interaction` + 必要的 `prose_style` | 主会话，不降低 rubric |

审稿匹配项只用于交付格式、协作方式和“作者有意采用的表达选择”说明；问题严重度和 PASS/FAIL 仍由 rubric 决定。

## 注入预算与容量

- **写入不因注入预算失败**：`record` / `commit` 照常成功、给回执；工具按上表四类任务组合估算最坏查询情形（全局条目＋各 scope 维度最重的单一切片，切片按大小写无关归并、轻重按写作时真正读到的字段算，与真实查询同一把尺），装不进 2048 字节的组合在返回的 `warnings` 里点名将被略过的条目及其断言首句。
- 写入落盘后另一级 store 读不出来（书目录不存在、`--book` 与书级记录不符等）也照常给回执，`warnings` 注明本次提醒没算上它。写书级条目时「本书＋全局」按实际条目精确计算；写项目级条目时只看得到项目级 store，顺手传 `--book-root` 就把当前这本书也算进提醒。
- 查询按 **重要度 → 本书例外 → 最近更新** 排序装填（同一范围的条目必在同一 store，「最近」按该 store 的修订号比，不跨 store 比较），先丢的恒是重要度较低的条目——`importance` 决定超编时谁留在 prompt 里。装不下的条目跳过而不中断（一条长的不挡后面的短条），漏下的 ID 按同一优先级报进 `omitted_ids`（最多列 20 条，`omitted` 是真实总数）。
- 注入预算之外还有一道硬上限：`作者画像.md` 超过 12288 字节时写入会直接失败并要求先整理。active 条目攒到几十上百条才会碰到（远在注入预算之后），碰到就走「整理作者记忆」；`forget` 这类减量操作在满编时照常可用。

## 整理作者记忆

作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编、写入因画像写满失败时：读项目级与当前书的 `作者画像.md`（每条都标了范围、重要度、把握和确认次数，重要度就是超编时的去留依据），提出合并同义条（`replace` 多合一）、退役过时条（`forget`）、给错标成 `high` 的条目下调重要度、把超长断言压缩成一句话的提案；项目级画像里还有「本书：」条目时，「对该书运行 `migrate --book-root`」列为默认提案项。清单用原话逐条列给作者确认（编号只放括号里），确认后按 store 各汇成一份 `commit` 事务提交（一份事务只写一个 store）。合并时保住每条的否定词、限定词和适用范围——合不动就退役其中一条，不要靠删限定词把两条凑成一条。整理只由作者发起或确认，不自动执行。

## 冲突候选

冲突候选（`conflict`）不能绕过旧规则直接 `decide=activate`。作者选新说法：用 `replace`，`old_ids` 同时列旧 active 条目和这条冲突候选，新条目直接 active、两条旧的标 `superseded`；作者留旧规则：对候选 `decide=reject`。旧条目被 `replace` / `forget` 撤下后，它不再是任何候选的冲突对象，冲突对象清空的候选退回 `pending`。

## 单书布局

书根就是工作区（`--book-root` 与 `--workspace` 同一目录）时，书级 store 改住 `{工作区}/.story/作者记忆/书级/`，与项目级各自一份 state；首次建立的书名优先取项目级存量本书条目里唯一的书名，再取目录名。旧版曾把书级 state 写在项目级位置，此后项目级读写都报 `state.book`；带 `--book-root {工作区}` 运行任一命令（含 `query`）会先把它原样移进 `书级/`，不改内容。这个目录其实是某个工作区里的一本书时（上一层叫 `长篇/` 或 `短篇/`，或某个祖先有 `.active-book` 或项目级 state），工具直接报错、不动任何文件，按报错改传 `--workspace`。

## 存量迁移

不做双读：升级前写进项目级 store 的 book 条目不再参与查询与预算估算，也不再接受新的 book 写入；它们仍在 `作者画像.md` 里可见、可 `decide` / `forget`。对每本书运行一次 `migrate --book-root

Github ReposUpdated 5h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.