Junyi vault
育儿先育己，让 AI 学会你。写给创业者父母的家庭成长 Skills，把你的真实经验和判断标准，交给一个长期服务这个家庭的 Agent。
npx -y skills add junyifei/junyi-skills --skill junyi-vaultAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
搭建、维护和诊断采用“域—类—档”模型的个人知识库：从零设计最小目录骨架，把笔记、蒸馏素材、复盘和资料归入现有结构，或只读审计已经混乱的 Obsidian/Markdown 文件库并提出迁移方案。用于“搭知识库”“初始化 Obsidian”“这条笔记放哪”“批量归档”“整理混乱知识库”“合并 vault-builder 和 vault-filer”等任务。任何创建、移动、覆盖或批量写入都必须先预览并取得明确确认。
SKILL.md
5.5 KB, as published. Nobody here has run it
君一知识库
「君一」是方法来源，不是服务对象。 本 Skill 处理的是使用者自己的知识库。
用一个入口处理知识库的三个状态：没有结构时搭建，有稳定结构时归档，结构混乱时先诊断。不要把“重新整理”理解成获得了擅自移动或覆盖使用者文件的授权。
先判断状态
-
确认知识库根目录。路径不明确时先定位，不根据文件夹名猜测。
-
只读扫描现有结构；可运行：
python3 scripts/scan_vault.py <知识库根目录> -
路由到一种模式：
- 搭建模式：目标目录不存在或基本为空，使用者要从零建立结构。
- 归档模式：已有可理解的结构，使用者要放入一条或一批新内容。
- 诊断模式：存在重复分类、层级过深、大量散落文件或使用者明确说知识库很乱。
-
如果状态不明确，展示扫描证据和建议模式，让使用者确认；不要用“可能是空库”直接创建。
不可违反的规则
- 任何创建目录、写入文件、移动、重命名、合并或覆盖之前，先展示完整计划和目标路径。
- 新增“域”或“类”必须获得使用者确认；归类不确定时给出 2–3 个候选和差异，不瞎猜。
- 默认不覆盖现有文件。批量操作默认 dry-run；只有使用者确认计划后才使用
--apply。 - 诊断模式默认只读。迁移计划与迁移动作分开，不能在同一步完成。
- 不删除原文，不把有力量的原话切碎，不根据标题编造正文结构。
- 先读取现有命名、frontmatter、索引和隐私习惯；现有稳定约定优先于本 Skill 的默认模板。
- 私密内容不因为进入知识库就自动获得公开授权。记录来源、授权和隐私级别。
- 不让符号链接、绝对路径或
..路径逃出知识库根目录。
核心模型
- 域：长期负责或持续关心的生活/工作范围，通常 3–6 个。
- 类：域内稳定出现、检索时会主动寻找的内容类型，通常每域 2–5 个。
- 档：具体笔记、记录、案例、素材或产物。
域和类是检索承诺，不是装饰。能通过搜索、标签或索引解决的问题，不急着新增文件夹。新库默认只预建“域/类”两层；已有库不强制改成两层。
搭建模式
读取 build-mode.md 并执行：
-
了解使用者要管理的内容、最常见检索问题、五个高频使用场景、隐私边界和现有工具。
-
选择最接近的起手模型，再按真实内容收敛为 3–6 个域、每域 2–5 个类。
-
展示“域—类”清单、每个类收什么/不收什么，以及三个示例归档。
-
使用者确认后生成操作 manifest，先 dry-run：
python3 scripts/apply_manifest.py plan.json --root <目标目录> -
使用者明确确认本次计划后再执行：
python3 scripts/apply_manifest.py plan.json --root <目标目录> --apply -
重新扫描，确认目录、根索引和使用说明存在且未覆盖原文件。
归档模式
读取 file-mode.md 和 schema-decision.md：
- 扫描现有域、类和命名约定。
- 判断内容的“主要未来用途”，再选择域和类；主题相似但用途不同的内容不强行放一起。
- 给出置信度与依据。低置信度必须询问；现有分类都不合适时提出一个最小新增方案并等待确认。
- 选择强、半或无 schema；保留来源、原话和必要上下文。
- 展示目标路径、文件名、frontmatter、内容结构和冲突处理方式。
- 确认后通过 manifest 写入；默认同名冲突报错，可在使用者确认后改用安全后缀。覆盖必须单独明确授权。
- 回执写清写到哪里、为何归到这里、是否新增分类、是否保留待确认项。
诊断模式
读取 audit-mode.md：
- 只读扫描目录深度、根目录散落文件、重复/近义分类、空目录和命名漂移。
- 通过抽样内容确认用途，不能只看文件名批量判定。
- 输出“保留、合并候选、改名候选、待观察、不能自动处理”五类清单。
- 提供可逆迁移顺序和回滚点；使用者确认前不生成 apply manifest。
- 每一批迁移单独预览、确认、执行和验收，不进行一次性大搬家。
完成前验收
- 重新运行
scan_vault.py，结构与已确认计划一致。 - manifest 中每个路径都在根目录内；没有未说明冲突和失败项。
- 新文件可用 UTF-8 读取、无 U+FFFD 乱码、frontmatter 合法。
- 没有覆盖、删除、移动计划之外的使用者文件。
- 归档内容仍能追溯来源；引用、时间和人物没有被改写。
- 新增分类都能回答“以后什么内容会继续放进来”，否则撤回新增。
只有使用者明确要求时，才继续把新结构接入其他 Agent、自动化任务或云端系统。