用 gjkim_instruction.md…

当你要围绕一个长期目标运行多轮短 Agent 迭代，需要一份只记录最低要求与已确认决策的根文档时使用。

适用场景

解决思路

1. 在项目根目录创建名为 gjkim_instruction.md 的文档，作为循环工程的根文档，每次迭代先读它。
2. 文档只记录两类内容：必须为真的最低要求，以及用户已明确确认的决策；其余一律视为刻意开放。
3. 写入 Goal：用一到两句话说明该工作必须达成什么。
4. 写入 Minimum requirements：列出成功所需的最小结果集合，停留在结果层面而非实现层面。
5. 写入 Non-goals：明确列出不追求的结果，防止迭代漂移；非目标必须是已确认的“不做”，未决事项放到 Deliberately open。
6. 写入 Confirmed decisions：只记录用户明确确认的决策，每条附上确认日期和一行原因，便于后续迭代判断理由是否仍成立。
7. 可选写入 Deliberately open：列出已知尚未决定的选择，避免迭代默默假设某个答案；列出选项不代表认可它。
8. 排除未明确确认的实现细节：库、框架、schema、文件布局、API 形状、部署目标。
9. 排除任务列表、进度日志、迭代状态；这些放到 issue、PR 或迭代笔记中，根文档只描述目的地而非旅程。
10. 排除推测性设计或正在考虑的选项；最多放到 Deliberately open，绝不写成要求或决策。
11. 排除任何可从代码本身推导出的内容。
12. 用试金石判断要求还是细节：是否存在两种有意义的实现都能满足它？若只有一种实现能满足，它就是细节，先不写，直到用户确认其为决策。
13. 使用模板结构：标题、Goal、Minimum requirements、Non-goals、Confirmed decisions、Deliberately open；没有可警告内容时可省略 Non-goals 或 Deliberately open 部分。
14. 把整份文档控制在一页左右；若超出说明细节泄漏进来，需要修剪。
15. 仅当用户明确确认时才添加决策；“倾向”“大概”“也许”不算确认。
16. 仅当用户明确排除某选项时才记录为非目标；没人决定过的选项留在 Deliberately open。
17. 当某次迭代必须做出文档中没有的选择时，做最佳局部选择，在该迭代的 PR 或笔记中记为未确认，并向用户提议确认；不要先写进根文档。
18. 当决策被推翻时替换该条目；文档只描述当前状态，旧状态由 git 历史保存。
19. 更新时保留现有要求与决策，除非用户明确更改它们。
20. 在每次循环迭代开始时使用该文档，检查哪些已决定、哪些仍开放。

适用边界 · 注意事项

• 不适用于短期一次性任务或不需要多轮迭代的简单工作。
• 不适用于用户尚未确认任何决策、也没有明确目标的场景。
• 不要把任务列表、进度日志或迭代状态写进该文档。