Where each thing lives.每样东西放在哪。
| Layer层 | Where存放 | Loads何时加载 | What goes here放什么 |
|---|---|---|---|
| Always-on常驻 | base/conduct.md → ~/.claude/CLAUDE.md | every turn每轮 | Neutral universal rules — signing conventions, honesty and verification discipline, permissions, secret handling, style.通用中性规则 —— 署名规矩、诚实与查证纪律、权限、secret 处理、风格。 |
| On-demand skill按需 skill | skills/<name>/ (symlinked)（软链） | only when its trigger matches触发词命中才载入 | Domain methods and procedures — the body is platform-agnostic, values sit in params/<platform>.md.领域方法和流程 —— 正文跟平台无关，具体值放在 params/<platform>.md。 |
| Org-shared组织共享 | base/<org>-common.md | @import in a project CLAUDE.md项目 CLAUDE.md 里 @import | Conventions shared across products — commit rules, build environment, path rules.跨产品共享的约定 —— 提交规范、编译环境、路径规矩。 |
| Project state项目状态 | <project>/CLAUDE.md | when you work in that directory在该目录下工作时 | Current task and key paths, plus an @import of the org-shared layer.当前任务、关键路径，再 @import 组织共享层。 |
The one hard rule:唯一的硬规则： an always-on behavioural constraint must never become an on-demand skill. A skill needs a trigger; a rule like “never add a certain signature” or “output style” has to apply every turn and has no trigger — as a skill it would quietly fail to load on most turns. 每轮都要生效的行为约束，绝不能做成按需 skill。skill 要靠触发词才载入；像「禁止某类署名」「输出风格」这种每轮都要生效、又没有触发场景的规则，做成 skill 后大多数轮次都不会载入，而且不会有任何报错。
Three deploy.sh modes.deploy.sh 的三种用法。
# 1) deploy skills: symlink from the data repo into ~/.claude/skills (one source, no drift)部署 skills：从数据仓软链进 ~/.claude/skills（只有一份源，不会两边不一致）
bin/deploy.sh --link <data-repo>
# 2) generate the always-on file: base/conduct.md → ~/.claude/CLAUDE.md (backs up the old one)生成全局常驻文件：base/conduct.md → ~/.claude/CLAUDE.md（自动备份旧的）
bin/deploy.sh --gen-claudemd <data-repo>
# 3) import the org-shared layer into a project (idempotent; --import takes any shared file)让某个项目导入组织共享层（重复执行无副作用；--import 可传任意共享文件）
bin/deploy.sh --add-import <project>/CLAUDE.md --import <data-repo>/base/<org>-common.mdThe tool hardcodes none of your filenames — everything is a parameter.工具不写死你的任何文件名，全部走参数。
Clone two repos, deploy, done.克隆两个仓，装回来，就好了。
- a
Clone the tool and your data拉工具仓和数据仓
git clone <this-tool-repo> git clone <your-private-skills-data-repo> # keep it private if it holds real values含真实值就保持私有 - b
Symlink skills, regenerate the always-on file软链 skills，生成全局常驻文件
whetstone/bin/deploy.sh --link <data-repo> whetstone/bin/deploy.sh --gen-claudemd <data-repo> - c
Per project: import the org-shared layer每个项目：导入组织共享层
whetstone/bin/deploy.sh --add-import <project>/CLAUDE.md \ --import <data-repo>/base/<org>-common.md - d
First session per project每个项目的第一次会话
Approve the one-time “external import” prompt. Paths differ per machine; every command takes them as arguments.点一次「外部导入」的批准框。每台机器路径不同，所有命令都按参数传路径。
Four things that bite.四个坑。
@import doesn't save context@import 不省上下文
It loads in full at launch. Its value is one source and tidy organisation, not fewer tokens. What really stays out until needed is an on-demand skill — so keep heavy content in skills, not imports.它在启动时全量载入。它的价值是只有一份源、组织清楚，而不是省 token。真正「不触发就不载入」的是按需 skill —— 所以重内容放 skill，别用 import。
Keep always-on neutral and sparse常驻层保持中性、稀疏
That is what keeps false positives down — not any trick to route around a classifier.这才是减少误报的办法，而不是靠什么技巧绕开分类器。
Real values → private repo真实值放私有仓
If the data repo carries internal paths, org names or platform parameters, make it private. The tool repo stays generic and public.数据仓里有内部路径、组织名或平台参数，就设成私有。工具仓保持通用、公开。
Multi-root projects多根目录的项目
Code and notes on different mounts? Put a CLAUDE.md at each root; the thin one only @imports the main one.代码和笔记在不同挂载点？每个根目录放一个 CLAUDE.md，薄的那个只 @import 主文件。