用途：这是一套行为约定，适用于作者本机的购物与分类信息自动化仓库家族（olx-polite-mcp 及其同类仓库），这些仓库只存在于作者机器上。它与 mcp-server-shipping（同一批仓库的开发循环与分发机制）以及机器上常驻的通用指令文件不同，后者承载真正通用的约定；本约定针对特定领域，即对用户本人已登录的实时个人账户执行自动化。安装到其他环境时约定仍可阅读，但仓库名属于作者本人。
主要能力与用法： 一、首次真实变更操作前先确认。在一个会话中，对用户实时、个人、已登录账户执行第一个真实变更型浏览器操作（例如真实的加入购物车点击，而非只读操作）之前，应停下来通过 AskUserQuestion 询问，而不是直接执行，即使该操作范围窄、成本低、可撤销。询问时应表述为一次性的限定范围测试（说明将运行什么，以及适用时事后会撤销/回滚），而不是泛泛的权限请求。一旦获批并确认了形态/行为，同一会话中后续同类操作无需再次确认。理由：该仓库家族本就把结账/个人账户操作视为比普通读取风险高得多的类别，各仓库自身的边界文档也如此说明（例如“结账永不自动化”、不解决 CAPTCHA）。对真实账户的首次真实变更测试属于同一类别，即使具体动作很小。 二、批量交互式逐项决策，不要让用户输入列表。当工作流需要用户做出若干小的独立决策时（例如“这 8 件商品各要多少”），应使用 AskUserQuestion 分批询问，每批约 4 项，并把推荐默认值预填为第一个选项；不要给出一个大列表让用户在一次回复中把所有答案打出来。理由：Freshful 补货流程会话中的明确反馈是，让用户逐项交互式回答体验更好，一次性输入大量结构化内容会破坏体验。应用方式：仅对无法这样分解的决策，或项目多到分批不再轻量时，才保留单次自由文本询问；此时应考虑重构流程本身（例如把“可能到期的物品”与“很少触碰的物品”拆开，而不是平铺批量处理）。 三、在实现之前或同时把探索/研究结论写入 PLAN.md。当研究/探索阶段（实时 CDP 探索、API 探测、DOM 检查）得出改变或确认计划的结论时，应先把它们作为独立章节写入仓库的 PLAN.md，并匹配该文档现有的叙述风格，然后再写实际实现代码，或与实现同时进行。不要只把结论留在对话里就直接写代码。理由：这是明确指示，且符合该仓库家族既有模式，其中 PLAN.md（单一整体文件，该家族早于 plan-docs 技能所记录的 plans/YYYY-MM-DD-topic.md 约定，尚未迁移）是架构为何如此的持久记录，代码注释会回指它而非重新解释。应用方式：在这些仓库中完成任何实时探索/研究后，先更新 PLAN.md 的相关章节（标记已解决的开放问题、添加带日期的结论章节、重述/扩展结论涉及的边界决策），再进入实现；即使当轮用户未明确要求写文档，也应将其视为默认顺序。
限制：资料未提供该约定的安装命令、平台支持范围、收费或价格信息；其适用对象限于作者自有的上述仓库家族，其他环境仅可阅读参考。