customize：画像与守则的修改入口

目的

研究画像不是一次访谈就终身有效的：换课题、换学校、换目标期刊、合规政策更新，都需要改画像。本技能提供受控的修改通道——画像与 guardrails 只能经由本技能（或 cold-start-interview 的整体重谈）修改，其他 skill 不得顺手改 CLAUDE.md。集中入口的意义在于：每次修改都留痕、都告知影响面。

前置检查

1. 读取插件根目录 CLAUDE.md 全文，定位用户想改的部分：画像七小节，还是 Shared guardrails 八条，还是两者。
2. 用户描述模糊时（"帮我改一下设置"），先展示画像当前各节的一句话摘要，让用户指认要改哪节。
3. 区分修改性质：画像修改（用户自身信息变化，低风险）与 guardrails 修改（行为基线变化，影响所有 skill，需谨慎）。后者按第 3 节的加严流程处理。
4. 画像整体空白（多数小节为 [填空]）时，直接引导 cold-start-interview，不用本技能逐节补——访谈比零散修补的成本更低、结构更完整。
5. 确认没有进行中的写入冲突：本技能运行期间不并行改 CLAUDE.md；若上一次 customize 留下了未确认的草稿差异，先向用户确认继续还是放弃。

0 · 预览模式

用户说"先让我看看改完什么样、先别写"时进入预览模式：

1. 照常整理新文草稿并出示"原文 → 新文"差异；
2. 不写回 CLAUDE.md，不登记 provenance；
3. 明确告知"当前只是预览，文件未变"；用户随后确认时再走正式写回流程；
4. 预览内容不暂存到磁盘——下次会话用户重新提出即可，避免"幽灵草稿"与正式内容混淆。

1 · 画像修改流程

1. 读现状：把目标小节的当前内容原样展示给用户。
2. 确认修改点：用户说改什么就改什么；用户的口语化描述（"我现在主要投英文刊了"）由助手整理成散文草稿，与画像其余部分风格一致（连贯自然段，不是 YAML）。
3. 出示差异：把"原文 → 新文"并排展示，逐处确认。用户没提的部分一字不动。
4. 写回：用编辑工具只替换目标小节内容；画像其他小节、guardrails、术语表、附录一律不碰。
5. 留痕：provenance-record 登记本次修改，note 写明"画像更新：<小节名>，原因：<用户给的原因>"。

2 · 修改后的影响告知

写回完成后，必须明确告知用户哪些 skill 的行为会变化。对照表：

没有受影响的 skill 也要明说（"本次修改不影响任何自动化行为"），让用户对影响面有确定预期。

3 · guardrails 修改流程（加严）

guardrails 是全插件的行为基线，改它等于给所有 skill 换操作系统。流程比画像修改多三步：

1. 逐条确认：用户要改哪一条，就把该条原文完整展示，确认"你要改的是这条，改成这样"；不打包、不批量。
2. 影响推演：向用户说明该条被哪些 skill 引用（检索 CLAUDE.md 与各 SKILL.md 中的 "guardrail 第 N 条" 引用），修改会放松还是收紧这些位置的行为。放松类修改（如删除"危险操作先确认"中的某项）需要用户明确二次确认。
3. 一致性检查：新条文与其余七条不冲突；冲突时展示冲突点，请用户裁决，不自行调和。
4. 写回与留痕：同画像流程，note 中额外记录"guardrail 第 N 条修改，影响 <skill 列表>"。
5. 禁止项：来源标注词汇表（第 1 条）允许增补标签，不允许删除或重定义已有标签——下游产物已经按旧词表写就，改词表会让历史产物失义。用户坚持时，说明后果并拒绝执行，建议以增补方式表达需求。

guardrails 修改示例：

用户：危险操作确认太烦了，批量下载那条去掉。 助手：第 8 条原文的"联网批量下载"一项要求先确认再执行。引用该条的位置：research-lifecycle 的 experiment 阶段、日常文献追踪流程。去掉后，这些位置将不再就批量下载征求你的同意——数据源风控（封 IP、封账号）的风险由你自行承担。确认去掉吗？ 用户：确认。 助手：（写回、登记）已修改。补充说明：日常文献检索不受影响，只有"批量抓取全文"这类动作不再事前确认。想恢复时随时说"customize 加回批量下载确认"。

4 · 写回纪律

1. 一次只改一处：一次 customize 运行只修改一个目标（某画像小节或某条 guardrail）；用户一次提多处修改时逐项走完流程，不合并成一次大改——逐项确认才能逐项留痕。
2. 原样保留其他内容：CLAUDE.md 中未被用户指认的部分一字不动，包括空行与注释格式；不顺手"优化措辞"。
3. 写回失败不硬来：文件被占用或内容在此期间变化时，停止并报告，请用户处理后重试；不基于过期副本强行覆盖。
4. 修改即留痕：每次正式写回都登记 provenance，paths 为 CLAUDE.md，note 写明改了哪节、原因；预览模式不写回也不登记。

5 · 批量体检模式

用户说"帮我看看配置有没有过时"时：

1. 逐节展示画像，标注每节的最后修改时间（从 provenance.jsonl 推）；超过一年的节建议重新确认；
2. 对照 metadata 中的 last_reviewed 提示复核；
3. 检查画像内部一致性（如"写作语言：英文"与"目标期刊全部是中文刊"的矛盾）；
4. 输出体检清单，用户指认要改的项，回到第 1 节流程。

6 · 何时用 customize，何时重谈画像

两条通道的分工：

• customize：局部变化。换了一个目标期刊、新增一个合规要求、数据源权限变了一个——改一节以内，用本技能。
• cold-start-interview --redo：整体变化。换领域、换单位、从学生变成独立 PI——七节里要动四五节，重谈比逐节修补更干净，旧画像通过 provenance 留痕可追。
• 判断标准给用户一句话："要动的地方超过三节就建议 --redo。"

7 · 常见修改场景速查

8 · 修改示例对话

用户：改一下画像，我现在投稿主要用 APA 了。 助手：当前「引用格式」一节写的是"GB/T 7714—2015 顺序编码制；英文投稿跟目标期刊要求"。 我打算改成："默认使用 APA 第 7 版；学位论文等学校有明确要求的场景仍用 GB/T 7714—2015 顺序编码制。"——学位论文那条保留，对吗？ 用户：对，学校要求不变。 助手：（写回、登记 provenance）已完成。行为变化：review-writing 生成参考文献默认走 APA 第 7 版；citation-verify 的格式核验基准同步切换。进行中的项目 正在 writing 阶段，如需要可按新格式 revise 一次。

输出模板

## 修改完成

- 修改位置：CLAUDE.md「<小节名>」
- 修改摘要：<一句话>
- 留痕：已登记 .openscience/provenance.jsonl

行为变化提醒：
- <skill 名>：将 <具体变化>
- …

如这次变化应该更早生效（例如影响进行中的项目），
建议对相应阶段运行 stage-gate revise。

本技能不做什么

• 不做首次画像生成：空白画像走 cold-start-interview；本技能假设画像已存在。
• 不改 SKILL.md 正文：发现 skill 正文与 CLAUDE.md 冲突时，以 CLAUDE.md 为准并报告该冲突，由插件维护者修正文；本技能只改 CLAUDE.md。
• 不执行"看看效果再决定"的试探性修改：每次写回都是正式修改并留痕；用户想预览就先出示差异不写入。
• 不修改 reviewer-protocol 的契约字段：那是跨插件约定，改动需要所有引用方同步，超出本技能范围。
• 不评判用户的新配置（如新目标期刊是否"够格"），只负责准确落实与影响告知。
• 不替其他 skill 改配置：各 skill 自身的设置项由它们自己维护，本技能只管包根 CLAUDE.md 中的画像与 guardrails。

收尾与下一步

• 修改完成后提醒：进行中的项目（stage.yaml 存在且非 rejected）是否受本次修改影响；受影响时建议用户对当前阶段 revise 以应用新配置。
• 数据源权限变化（如毕业失去机构订阅）后，额外建议重跑 literature 阶段的检索以评估覆盖度变化。
• 画像复核周期建议：每学期或每年跑一次第 5 节的批量体检，特别是在毕业、换单位、开新课题这些节点之后。
• 修改频繁时（连续几次 customize 都动同一节），建议停下来想一想：是画像写法太细需要精简，还是研究本身在转向、值得一次 --redo 重谈。
• 结束语固定一句："以后画像或规则再变，直接说'改一下画像'或'customize'即可。"