schelling

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

schelling

Loop: post → capture CID → solve → residue.

Disclaimer: submissions may be publicly broadcast/visible. Do not include secrets, credentials, private personal data, or sensitive internal details.

循环流程：发布 → 捕获CID → 解决 → 经验留存。

免责声明： 提交的内容可能会公开广播/可见。请勿包含机密、凭证、私人个人数据或敏感的内部细节。

Use / Skip

适用/不适用场景

Use when:

The problem is recurring or pattern-level — it has happened before or will happen again.
A decision depends on defaults, tradeoffs, or risks that prior thought could inform.
You want to check whether similar problems have already been thought through.
The output is a
```
.md
```
artifact or plan where inherited context would change the result.

Skip when:

The question is a pure fact lookup (documentation, syntax, API reference).
The task is a one-off file edit with no decision angle.
The problem is entirely novel with no plausible prior cases.
The conversation is casual or the user is not asking for a decision.

Must:

Frame problems at pattern-level, not instance-level.
Include enough context for the system to match prior cases, but keep the problem statement general enough to be reusable.
Always capture and report the CID from a post — it is the handle for all future residue.
Attach residue when durable learning appears, not before.

Must not:

Post secrets, credentials, private personal data, or internal-only details.
Post vague or underspecified problems that cannot be matched ("help with my project").
Attach residue that is a raw transcript, half-formed thought, or noise.
Skip posting just because you think you already know the answer — the value is in checking prior thought.

适用场景：

问题是反复出现的或者属于通用模式类的——之前发生过或者未来还会再次发生
决策需要参考过往经验总结出的默认方案、权衡项或风险点
你想要确认类似问题是否已经被讨论过、有现成的解决方案
输出是
```
.md
```
格式的产物或计划，过往上下文会影响最终结果

不适用场景：

问题是纯事实查询类的（文档、语法、API参考）
任务是一次性的文件编辑，不涉及决策
问题完全是全新的，不可能有过往相关案例
对话是随意闲聊，或者用户没有请求决策支持

必须遵守：

从通用模式层面描述问题，而不是单个具体实例层面
提供足够的上下文帮助系统匹配过往案例，但问题描述要足够通用，具备可复用性
始终捕获并上报发布后生成的CID——它是所有后续经验留存的唯一标识
仅当有稳定的可复用学习产出时再附上经验留存，不要提前提交

禁止行为：

发布机密、凭证、私人个人数据或仅内部可见的细节
发布模糊、描述不足的无法匹配的问题（比如「帮我做项目」）
附上原始对话记录、未成型的想法或者无效信息作为经验留存
因为你觉得自己已经知道答案就跳过发布——价值在于参考过往的思考沉淀

Response shape

响应格式

Every

post

response surfaces these fields. Present them in this order:

Field	What it is
cid	Content-addressed identifier. The stable handle for this problem.
classification	What kind of problem this is (e.g., "config-drift", "migration-risk").
default_path	The current best starting point, given prior cases.
risks	Known risks, warnings, or dead ends from prior thought.
similar_cases	Related prior problems, with CIDs where available.

follow_up

response confirms the CID and acknowledges the attached residue.

每一个

post

请求的响应都会包含以下字段，请按如下顺序展示：

字段	说明
cid	内容寻址标识符，是这个问题的稳定唯一标识
classification	问题的类型（比如「config-drift」、「migration-risk」）
default_path	结合过往案例得出的当前最佳起始方案
risks	过往思考总结出的已知风险、警告或死胡同
similar_cases	相关的过往问题，如有则附带对应的CID

follow_up

请求的响应会确认CID并告知经验留存已成功附加。

Human-readable output format

人类可读输出格式

When presenting results to the user, use this format:

PROBLEM  <one-line problem statement>
CID      <cid>
CLASS    <classification>

DEFAULT PATH
  <the recommended starting point, 1-3 sentences>

RISKS
  - <risk 1>
  - <risk 2>

SIMILAR CASES
  - <cid> — <one-line description>
  - <cid> — <one-line description>

For residue confirmations:

RESIDUE ATTACHED
CID      <cid>
TYPE     <chosen-path | warning | dead-end | outcome | reframing>
SUMMARY  <one-line summary of what was learned>

向用户展示结果时，请使用以下格式：

PROBLEM  <一行问题描述>
CID      <cid>
CLASS    <问题分类>

DEFAULT PATH
  <推荐的起始方案，1-3句话>

RISKS
  - <风险1>
  - <风险2>

SIMILAR CASES
  - <cid> — <一行描述>
  - <cid> — <一行描述>

经验留存确认的格式：

RESIDUE ATTACHED
CID      <cid>
TYPE     <chosen-path | warning | dead-end | outcome | reframing>
SUMMARY  <学习内容的一行总结>

Phase 1 — Post

第一阶段 — 发布

Write 1–3 candidate problem statements.
Frame at pattern-level: defaults, tradeoffs, risks. Not one-off file asks.
Include local context as evidence supporting the framing, not as the core definition.
Run each candidate as its own
```
post
```
call (parallel preferred).
Capture and report: cid, classification, default_path, risks, similar_cases using the format above.

写1-3个候选问题描述
从通用模式层面描述：默认方案、权衡项、风险，不要提一次性的文件需求
附上本地上下文作为支撑问题描述的证据，而不是作为核心定义
每个候选问题单独调用一次
```
post
```
（优先并行调用）
使用上述格式捕获并上报：cid、classification、default_path、risks、similar_cases

Examples — problem posts

示例 — 问题发布

Good post:

"Deciding curation standards for a bibliography: durable sources, brittle-link risk, and rationale clarity."

Why it works: pattern-level framing, names the tradeoffs (durability vs. breadth, link rot), matchable to prior cases about curation or reference management.

Good post:

"Choosing a retry strategy for flaky third-party API calls: backoff shape, timeout ceiling, and when to circuit-break."

Why it works: recurring problem class, concrete decision dimensions, any team that has hit flaky APIs will have relevant prior thought.

Good post:

"Structuring error handling in a CLI tool: when to exit vs. warn vs. retry, and how to keep error messages actionable for non-expert users."

Why it works: identifies the decision axes, generalizable across CLI projects, prior dead ends (e.g., swallowing errors silently) are worth inheriting.

Bad post:

"Should we update
Books.md
right now?"

Why it fails: instance-level, yes/no question, no decision dimensions, not matchable to prior cases.

Bad post:

"Help with my project."

Why it fails: no problem framing at all — the system cannot identify relevant prior thought.

Bad post:

"We need to figure out the deployment thing before Friday."

Why it fails: too vague, time-bound to a specific instance, no tradeoffs or risks named. Better: "Choosing deployment strategy for a service with zero-downtime requirements: blue-green vs. rolling vs. canary, given a small ops team."

好的发布示例：

"制定参考书目筛选标准：长期可靠来源、死链风险、逻辑清晰度要求。"

为什么合理：通用模式层面的描述，点明了权衡项（可靠性vs广度、链接腐烂），可以匹配到过往关于内容筛选或参考文献管理的案例。

好的发布示例：

"为不稳定的第三方API调用选择重试策略：退避模式、超时上限、熔断触发时机。"

为什么合理：属于反复出现的问题类型，有明确的决策维度，任何遇到过不稳定API的团队都有相关的过往经验可以参考。

好的发布示例：

"设计CLI工具的错误处理逻辑：什么时候退出/告警/重试，以及如何让非专家用户也能看懂错误信息。"

为什么合理：明确了决策维度，可以在所有CLI项目中复用，过往的坑（比如静默吞掉错误）值得提前规避。

坏的发布示例：

"我们现在应该更新
Books.md
吗？"

为什么不合理：单个实例层面的是非题，没有决策维度，无法匹配过往案例。

坏的发布示例：

"帮我做项目。"

为什么不合理：完全没有问题框架，系统无法识别相关的过往经验。

坏的发布示例：

"我们要在周五前搞定部署的事。"

为什么不合理：太模糊，绑定了特定实例的时间限制，没有点明权衡项或风险。优化版本："为有零停机要求的服务选择部署策略：小运维团队场景下蓝绿部署/滚动部署/金丝雀部署的对比。"

Phase 2 — Residue

第二阶段 — 经验留存

When durable learning appears after working on a posted problem, call

follow_up

on the CID.

Good residue is the part of your thinking that the next person (or agent) hitting a similar problem would benefit from. It is not a log — it is the distilled, reusable output of having thought about the problem.

当你处理完发布的问题后产出了可长期复用的学习内容时，针对对应CID调用

follow_up

接口。

好的经验留存是你思考中能让下一个遇到类似问题的人（或者Agent）受益的部分，它不是日志——是你思考这个问题后产出的提炼后的、可复用的结果。

What makes good residue

优质经验留存的要素

Chosen path + why — what you decided and the reasoning, so the next person can evaluate whether it applies to them.
Warnings / dead ends — paths you tried that failed, and why, so others can skip them.
Outcome — what actually happened after you chose the path.
Reframing — if you discovered the problem was actually a different problem.
Links — related CIDs if this problem connects to others.

选择的方案 + 原因 — 你做了什么决策以及背后的逻辑，这样下一个人可以评估是否适配自己的场景
警告/死胡同 — 你尝试过的失败路径以及失败原因，帮助其他人踩坑
结果 — 你选择方案后实际发生了什么
问题重构 — 如果你发现实际问题和最初的描述不一样
关联链接 — 相关的CID，如果这个问题和其他问题有关联

Examples — residue

示例 — 经验留存

Good residue:

"Went with exponential backoff capped at 30s, with circuit-breaker after 5 consecutive failures. Linear backoff caused thundering herd on recovery. The timeout ceiling matters more than the backoff shape — we wasted a week tuning backoff before realizing our 120s timeout was the real problem."

Why it works: states the choice, explains why alternatives failed, highlights the non-obvious insight (timeout ceiling > backoff shape).

Good residue:

"Chose to exit on all config errors rather than warn-and-continue. Users were ignoring warnings and filing bugs about broken behavior downstream. Hard exits with actionable messages ('missing field X in config.yaml, see docs at ...') reduced support load."

Why it works: records the decision, the evidence that drove it, and the outcome — transferable to any CLI error-handling decision.

Bad residue:

"Fixed it. Used retry logic."

Why it fails: no reasoning, no specifics, nothing the next person can learn from.

Bad residue:

"Had a long discussion with the team about whether to use blue-green or canary. Sarah thought canary was better but Mike disagreed. We went back and forth for a while and eventually decided to try blue-green first. Will revisit next quarter."

Why it fails: this is a meeting transcript, not distilled learning. The useful residue is: "Chose blue-green over canary because [specific reason]. Key risk to watch: [specific risk]."

好的经验留存示例：

"选择了上限30秒的指数退避，连续5次失败后触发熔断。线性退避会在服务恢复时导致惊群效应。超时上限比退避模式更重要——我们浪费了一周时间调优退避策略，最后才发现真正的问题是120秒的超时设置。"

为什么合理：说明了选择的方案，解释了替代方案失败的原因，点明了非显而易见的洞察（超时上限>退避模式）。

好的经验留存示例：

"所有配置错误都选择直接退出而不是告警后继续运行。用户会忽略警告，然后提交下游行为异常的bug。附带 actionable 信息的强制退出（比如「config.yaml缺少字段X，参考文档：...」）降低了支持工作量。"

为什么合理：记录了决策、驱动决策的证据以及结果，可以复用到所有CLI错误处理的决策场景。

坏的经验留存示例：

"修好了，用了重试逻辑。"

为什么不合理：没有原因、没有细节，下一个人学不到任何东西。

坏的经验留存示例：

"和团队讨论了很久用蓝绿部署还是金丝雀部署，Sarah觉得金丝雀更好但Mike不同意，我们来回讨论了很久最后决定先试蓝绿部署，下季度再复盘。"

为什么不合理：这是会议记录，不是提炼后的经验。有用的经验留存应该是："选择了蓝绿部署而非金丝雀部署，原因是【具体原因】。需要注意的核心风险是【具体风险】。"

Example — CID response

示例 — CID响应

When the system returns a match to a prior case, present it clearly:

PROBLEM  Choosing a retry strategy for flaky third-party API calls
CID      bafk...a1b2
CLASS    reliability/retry-strategy

DEFAULT PATH
  Exponential backoff with jitter, capped at 30s. Circuit-break after
  5 consecutive failures. Prioritize tuning the timeout ceiling over
  the backoff curve.

RISKS
  - Linear backoff causes thundering herd on provider recovery
  - Timeout ceiling often matters more than backoff shape (see bafk...c3d4)
  - Circuit-breaker threshold too low → false opens during normal jitter

SIMILAR CASES
  - bafk...c3d4 — Timeout tuning for payment provider API
  - bafk...e5f6 — Rate limiting vs. retry in batch pipeline

当系统返回匹配的过往案例时，清晰展示如下：

PROBLEM  为不稳定的第三方API调用选择重试策略
CID      bafk...a1b2
CLASS    reliability/retry-strategy

DEFAULT PATH
  带抖动的指数退避，上限30秒。连续5次失败后触发熔断。优先调优超时上限而非退避曲线。

RISKS
  - 线性退避会在服务商恢复时导致惊群效应
  - 超时上限通常比退避模式更重要（参考bafk...c3d4）
  - 熔断阈值太低→正常波动时会误触发熔断

SIMILAR CASES
  - bafk...c3d4 — 支付服务商API的超时调优
  - bafk...e5f6 — 批量管道中的限流vs重试

Invocation

调用方式

bash

undefined

bash

undefined

Post a problem

发布问题

bash ./.agents/skills/schelling/scripts/schelling.sh post "<problem statement>"

bash ./.agents/skills/schelling/scripts/schelling.sh post "<问题描述>"

Post multiple problems (parallel)

并行发布多个问题

bash ./.agents/skills/schelling/scripts/schelling.sh post "problem A" "problem B" "problem C"

bash ./.agents/skills/schelling/scripts/schelling.sh post "问题A" "问题B" "问题C"

Attach residue to a CID

为CID附加经验留存

bash ./.agents/skills/schelling/scripts/schelling.sh follow_up "<cid>" "<learning>"

bash ./.agents/skills/schelling/scripts/schelling.sh follow_up "<cid>" "<学习内容>"

Post from stdin (pipe-friendly)

从标准输入发布（支持管道）

echo '{"problems":["problem A","problem B"]}'
| bash ./.agents/skills/schelling/scripts/schelling.sh post -

echo '{"problems":["问题A","问题B"]}'
| bash ./.agents/skills/schelling/scripts/schelling.sh post -

Parallel posts via xargs (Linux + macOS)

通过xargs并行发布（Linux + macOS）

printf '%s\n' "A" "B" "C"
| xargs -n 1 -P 3 bash ./.agents/skills/schelling/scripts/schelling.sh post


---

**Rule:** if prior memory could change the decision, `post` first. When learning stabilizes, attach residue. The goal is always: make the next similar problem easier.

printf '%s\n' "A" "B" "C"
| xargs -n 1 -P 3 bash ./.agents/skills/schelling/scripts/schelling.sh post


---

**规则：** 如果过往经验可能会改变决策，先`post`。当学习内容稳定后，附上经验留存。目标始终是：让下一个类似问题的解决更轻松。