沟通

ce-noslop

用途：改写、检查或起草散文，让它不带任何 AI 写作痕迹。初读就能读懂。保留原文所有事实。

3 种模式

默认选择：没有草稿 → author；命令式 → edit；提问 → detect。

7 项检查（逐句应用）

1. 机制 — 说的是它做什么/感觉如何，而不是用感受代替事实。
2. 可移植性 — 一句不动就能搬到另一个项目里的句子，就不携带本项目的任何事实。
3. 主体 — 原文说明了谁做这个动作时，要写出主语。
4. 一意一句 — 读者会不会要重读？会就拆。读一遍就懂的就保持。
5. 密度 — 一个手法说明不了问题。一段中累计 3+ 种不同模式，或同一模式跨段落重复出现 = 命中。
6. 结论先行 — 第一句是不是已经带出结果？
7. 读者 — 没看过这份文档的人能据此行动吗？必要时点明标识符、交代后果。

3 种语域

• 智能体对用户 — 怎么想就怎么写。未指定读者时的默认。
• 仓库 / 团队制品 — 中性，贴近上下文既有语气。不用第一人称，不带制品不需要的观点。
• 用户自己的文字 — 保留口吻；做最小有效编辑。只在拆分句子、补回主语这些保留用词的动作上停手。

硬边界

• 绝不触碰代码块、引文、frontmatter、链接目标、标识符，或调用方契约必需的标记（用户明确点名除外）。
• 绝不说“这是模型写的”（或其反面）。

参考（共 2 份、64 行）

• references/patterns.md（61）— 模式目录：夸大、模糊归因等
• references/terminology.md（3）— 术语替换规则

ce-promote

用途：为一个已发布功能起草发布/营销文案。只起草 — 绝不发布、推送、排期、提交或开 PR。 disable-model-invocation: true。

4 个阶段

1. 搞清楚发了什么 — gh PR 视图 + git diff stat + CHANGELOG 顶部 + git log。1–3 句面向用户的价值摘要（讲结果，不讲实现）。
2. 选渠道 — 默认 X 帖（或 thread）+ changelog 简讯。按改动伸缩，不强套模板。
3. 起草 — 检测 Spiral 状态；Path 0（一次性提示接入，可拒绝） → Path A（Spiral 已就绪） → Path B（经 ce-noslop 直接起草）。
4. 呈现 — 每条文案作为带标签的、可复制块。绝不发布。结尾： “drafts are yours to ship.”

Spiral 检测

which spiral + spiral auth status --json。返回 Authenticated: true → 就绪；找不到二进制 → 缺失；false → 未登录。

按渠道起草

• X — 第一行是钩子；1–3 行紧凑。只有多拍时才用 thread。
• Changelog — 一行陈述句；平实、不带宣传味。
• LinkedIn — 短段落：人的角度 + 是什么。比 X 稍温暖。
• Email — 主讲收益的标题 + 2–4 句正文 + 一个 CTA。
• 博客开头 — 一段铺垫问题 + 能力；深度内容留给正文。
• 演示脚本 — 3–6 句口语化节拍：钩子 / 问题 / 动作 / 收益。

参考（共 1 份、149 行）

• references/spiral-cli.md — Spiral CLI：检测、登录、品牌口吻起草

ce-proof

用途：在 Proof（协同编辑器）里发布、读取、评论、编辑 Markdown。以单向发布为主。

基础 URL 解析

配置中的 proof_api_base（本地优先） → PROOF_API_BASE 环境变量 → 默认 https://www.proofeditor.ai。非默认 = 自托管 → 需要 proof_api_key。

身份（固定不变）

• by = "ai:code-agent" + X-Agent-Id = "ai:code-agent"
• POST /presence 上 name = "Compound Engineering"

凭证

• accessToken — 日常 bearer（读取、编辑、上线、事件）。
• ownerSecret — 仅用于删除 + owner 级操作。认领时即失效；创建时两个都要拿到。

操作

• 读取：GET /api/agent/<slug>/v3/document
• 编辑：POST /api/agent/<slug>/v3/edit。评论 / 建议 / 回复 / 解决 / 正文修改都在 body 的 operations 中。选择最窄操作：散文用范围限定的 replace / insert / delete；跟踪改动用 suggest；只有整体替换请求才用 set_document。
• 删除：DELETE /api/documents/<slug>；未认领时需要 ownerSecret，认领后需要 owner 在 Every 上的会话。

错误

• TARGET_AMBIGUOUS — 锚点匹配 > 1；用 occurrence / before / after 消歧。绝不盲目重试。
• retryable: false — 修改请求本身。
• retryable: true + error.current — 重新解析目标，重试一次。
• 202 / PENDING / partial: true — 重新读 v3/document；只重试失败的操作。

硬规则

• 绝不在 Proof 文档里写密钥 / 凭证 / API key / 私人令牌 / 敏感 PII，除非用户明确同意。
• 发布交接后绝不自动删除。仅在用户要求删除，或明确是临时草稿时才删。
• 清空 Markdown 并不会抹掉评论标记。删除是唯一的隐私清理方式。
• 交给人时永远给带 token 的链接（tokenUrl），不要给裸 /d/<slug>。

参考（共 2 份、300 行）

• references/api.md（176）— 完整 Proof Web API 参考
• references/workflows.md（124）— Proof 工作流

ce-product-pulse

用途：对用量 / 性能 / 错误 / 待办做时间窗报告。disable-model-invocation: true。单页输出；保存到 <root>/pulse-reports/。

回看窗口

格式：24h / 7d / 30d，发布场景用 1h。尾部 +15 分钟缓冲（分析与追踪链路有摄入延迟）。

硬约束

• 全程只读。只把 pulse 配置写到 config.local.yaml 和报告文件。数据库连接必须只读。
• 报告中不包含 PII（不写用户邮箱 / 账号 ID / 消息内容）。
• 不内置阈值；不贴默认的“好/坏”标签；不告警。
• 单页输出（30–40 行）。
• 不替代发版日志或仪表盘。

阶段

配置键

pulse_product_name、pulse_lookback_default（默认 24h）、pulse_db_enabled（默认 false）。

参考（共 5 份、458 行）

• references/setup.md（43）— 首次运行配置
• references/config.md（20）— pulse 配置键 schema
• references/run.md（46）— 运行 pulse
• references/interview.md（260）— 首次运行访谈
• references/report-template.md（89）

跨技能边界