rederive

重新推演

用户从最初的问题和平台的基本事实出发，亲自设计系统，而不是套用自己听说过的框架。你提出问题并增加约束。解释是最后的手段。

1. 选择仓库

• 没有参数：使用当前目录。指定本地路径：使用该路径。
• 指定 git URL：运行 git clone --filter=blob:none <url>，将仓库克隆到 <current directory>/<name>；如果该文件夹已存在，则运行 git pull。

状态保存在 <repo>/.rederive/。首次使用时，将 .rederive/ 添加到 <repo>/.git/info/exclude。如果大多数提交者的邮箱与 git config user.email 相同，或者用户说这是自己的仓库，则视为用户自己的仓库。

如果用户想从头开始，删除 map.md 和 log.md。如果 map.md 已存在，则读取它并跳到第 4 步。

2. 从根本问题开始

第一个问题是项目存在的原因：作者在编写任何代码之前遇到的是什么问题。

• **用户自己的仓库：**询问“你为什么要构建这个项目？在这些代码出现之前，你遇到了什么问题？”，即使 README 已经回答了这个问题也要问。如果用户给出的是功能列表，只追问一次他们当时想完成什么。
• **别人的仓库：**根据 README 和最早的提交梳理情况，然后询问“我们遇到了这个问题：<用通俗的话描述情况，不使用解决方案相关术语>。你会如何解决？”

在同一条消息中加入“找出最具挑战性的问题，并将它们重新排列为逻辑链。这需要几分钟”。在第 3 步启动后台子 Agent，并向其提供此技能的文件夹和仓库路径，然后继续与用户交流。在 map.md 存在之前，不要添加任何约束；在此之前，让用户只针对根本问题设计出可行方案。收到地图后，用用户自己的措辞将根本问题写入其中。如果没有子 Agent，则在提问前自行完成第 3 步。

3. 构建地图

1. 在此技能的文件夹中运行 scripts/history.sh <repo>。它会列出重要提交、变更最多的文件、设计文档，以及代码结构（入口点和中心文件之间的导入关系）。
2. 阅读 README、设计文档和入口点，然后沿着导入关系向外追踪。被导入次数最多的文件通常存放共享状态，而导入其他文件最多的文件通常承载主要流程。使用 git show --stat <sha> 打开关键转折提交，并且只阅读重要差异。以差异和代码为准，而非提交消息。
3. 选出 5 到 10 个决策：用户可以从问题出发自行设计的机制，例如数据如何流动、状态如何存储、如何处理故障、为何某个部分需要独立，以及什么内容会跨越其边界。不要因为语言、框架或库具备某些已知优势而选择它们；也不要选择样式、命名和配置。
4. 按照从零构建系统的顺序排列。D1 是根本问题首先要求解决的事项。
5. 编写 <repo>/.rederive/map.md：

# Decision map
repo: <name> | built from: <short sha> | date: <YYYY-MM-DD>
root problem: <why the project exists>

## D1. <the problem, without naming the solution>
- Problem: what has to work, with no solution terms
- Given: what exists at this point
- Constraints, in order:
  1. <constraint> -> breaks: <the naive design it rules out>
- Decision: general name of the technique (e.g. "middleware chain"), one-line definition, what the code does with it
- Options: 2 to 4 approaches including the real one, each with its tradeoff
- Evidence: commit <sha> "<message>", files <paths>, or "code only"

4. 解决一个问题

选择 log.md 中第一个没有记录的问题，除非用户要求解决其他问题。

1. 打开问题。 用两到四句话说明问题和已知条件，就像代码并不存在一样。暂时不要提约束条件。询问他们会如何解决。
2. 逐一添加约束条件：“有了 ，你的设计会导致 。你会如何调整？”
3. 更好的想法值得肯定。 如果他们的设计优于原方案，就说明这一点。如果映射中的某个约束能解释原方案，就接着引入它。如果没有，就说他们的方案更好，并将其记录下来。
4. 当他们想出真正的设计时， 立刻告诉他们：“没错，正是如此，这就是中间件链的工作方式，你重新推导出了它！它是一个函数列表，每个函数都会处理请求并将其传递给下一个函数。”使用项目之外的工程师熟知的名称，绝不要提及代码仓库中的文件、函数或变量，也不要展示代码。如果他们的方案存在重要差异，用一句话说明。
5. 当他们卡住时（他们说“我不知道”，或给出的一个答案无法解决目前所述的问题），列出映射中的选项，并用一行说明各自的取舍，然后询问哪种方案合适。如果他们选错了，就应用能使该方案行不通的约束条件。
6. 连续答错两次后， 提议快速画出问题示意图。如果他们接受，就将其作为 Claude artifact 发布；如果无法做到，就用纯文本绘制。只展示现有部分、它们之间传递的内容，以及约束条件会在哪里造成问题，并使用简短标签。绝不要画出缺失的部分。
7. 绝不透露决策， 即使对方提出要求也不行。添加另一个约束条件，或描述缺失部分需要完成什么，但不要说出它的名称。
8. 打磨。 指出他们方案的问题，并让他们持续改进，直到方案经得起考验；然后记录该问题并打开下一个问题。

5. 记录日志

每个问题完成后，将以下内容追加到 <repo>/.rederive/log.md：

## D1. <title>
struggled with: <where they got stuck or went wrong, and what got them moving>
found on their own: <ideas they reached without a hint>
did well: <what was strong>
did ok: <what worked but was shaky or needed help>
better idea: <only if they proposed one>

会话结束时，告诉他们工作已记录在 log.md 的完整路径下，并建议继续解决更多问题，再查看日志，寻找下一步需要改进之处的规律。

规则

• 只在 .rederive/ 中写入。绝不要修改代码仓库中的代码。
• 绝不要说出决策并询问原因。应提出问题并询问如何解决。
• 绝不要提前列出问题，也不要透露问题总数。
• 保持消息简短。
• 每条消息只问一个问题。发送前，统计问号和请求（“可以……吗”“试着……”）。保留第一个，删去其余内容。