图 3-1两段式装载
图 3-1 · 从磁盘到上下文的三段。每往右一步，进入上下文的文字才变多。
图 3-2三道闸门，和上游把它们各自开到多大
图 3-2 · 实测依据：50 份 SKILL.md 的 frontmatter 键计数（disable-model-invocation 命中 49 份，缺的那份是 setup-pstack）。这两个键是 Cursor 的技能元数据约定，同仓库其他官方插件也在用；pstack 自己没有解释它们的语义。
3-3这一层最值得学的东西
不是机制，是写法。pstack 把"什么时候该用我"写进 description，而且写得很具体：
摘要写法
列触发词，不列功能
interrogate 的摘要里直接写了 "challenge this"、"find blind spots"、"tear this apart"——把用户可能说的话抄进索引。
摘要写法
声明和宿主的冲突
Cursor 自带一个 babysit 技能，触发词撞车。根文件里专门写"任何 PR 状态请求走剧本，不走宿主那个"。冲突是提前设计掉的。
代价
显式即门槛
闸门 B 关掉以后，"agent 主动想到用某个技能"这件事不会发生。全部靠人记得住命令，或靠 poteto-mode 替你去点。
代价
摘要也要花钱
50 条摘要常驻上下文。技能装到几百个时，这一层自己会变成瓶颈。
本层的检验问题：既然 49 个技能都不许模型自己触发，description 为什么还要写得那么讲究？
答：它服务两批读者——人（在命令列表里挑）和 poteto-mode（读摘要决定这一步派谁）。
下一层 H04 进入 pstack 的根文件，看它怎么做这个决定。