用途：维护 docs/decisions.md，按时间顺序记录项目重大决策，形成“为什么这样选”的永久记录。范围仅限高层架构、设计与产品决策，尤其是涉及取舍的选择。判断标准是：半年后的人是否需要知道这个选择的原因才能理解项目形态；若不需要则不记录。
主要能力：识别并记录决策，包括决策内容、背景、备选方案、关键取舍与最终理由；按复杂度调整详细程度（简单为标题加一两句，复杂则含背景、备选、取舍与理由）；在 docs/ 不存在时创建目录，在 docs/decisions.md 不存在时以“# Project Decisions”标题创建，存在则读取并追加到文件末尾，保持空行分隔与格式一致；记录后向用户简要确认。
使用方式：可在检测到重大架构选择时主动建议记录，例如选择数据库、框架、核心架构模式或长期设计方向，并等待用户确认；也可在用户明确要求“记录这个决策”“加入决策日志”“添加到 decisions.md”时记录。条目格式为“## YYYY-MM-DD: [决策标题]”，使用当天日期，按从旧到新追加。
适用场景：数据库选型（如 SQLite 与 PostgreSQL）、主要框架或库选择、单体与微服务、渲染方式、同步与异步等核心模式，以及约束未来工作的基础设计选择。
限制：不记录依赖升级与版本锁定、单个功能的实现细节、命名与文件布局、可在单个 PR 内无感回退的选择、代码评审评论级别的内容，以及伪装成决策的进度说明。正常功能构建通常应产生零条记录。不修改旧条目；若旧决策被重新讨论或更改，应作为新条目记录。避免重复条目。标题以 Bump、Pin、Fix、Ship ... partial 开头或以 (post-review refinement) 结尾的，几乎不是决策。存疑时宁可不记。