vault-health-batch

Name: vault-health-batch
Author: pssah4

215stars23forks

How to install vault-health-batch?

pssah4/vault-operator/vault-health-batch

$npx -y skills add pssah4/vault-operator --skill vault-health-batch

Installs into the current project.

Summary

Autonomous batch mode for Vault Health findings. Works through orphans, missing backlinks, and tags in batches without asking on every fix.

Files · 1

View on GitHub

SKILL.md

1	# Vault Health Batch Mode
2
3	You work through Vault Health findings AUTONOMOUSLY in batches.
4	Ask the user ONLY at real decision points, NOT on every single fix.
5	All changes are reversible via the undo bar (checkpoints are created automatically).
6
7	## Phase 1: TRIAGE
8
9	1. Call `vault_health_check`
10	2. Read the findings and group them by type
11	3. Give the user a short overview (3-5 lines):
12	```
13	Vault Health: X findings
14	- N orphaned notes (M of them with context)
15	- N missing backlinks
16	- N broken links
17	- N inconsistent tags
18	- N weak clusters
19
20	I will start with the mechanical fixes (backlinks, tags).
21	For broken links and isolated orphans I will ask you.
22	```
23	4. Start Phase 2 IMMEDIATELY -- do NOT wait for confirmation
24
25	## Phase 2: BATCH FIX
26
27	Work through the types in this order.
28
29	### 2a: Missing backlinks + orphans with context (ONE TOOL CALL)
30
31	These are mechanical fixes: entities that are referenced but do not link back.
32
33	Steps:
34	1. Call `vault_health_check` with `action: "fix_backlinks"`
35	2. The tool fixes ALL missing backlinks in one batch (pure code, 0 LLM cost)
36	3. Show the user the result: "X entities updated, Y backlinks added"
37
38	NO read_file, NO update_frontmatter, NO sub-agent. ONE tool call does everything.
39
40	### 2c: Inconsistent tags (AUTONOMOUS)
41
42	Tags that differ only in upper/lower case.
43
44	Steps:
45	1. Pick the more frequent variant
46	2. Change all occurrences of the rarer variant via `update_frontmatter`
47	3. NO questions
48
49	### 2d: Broken links (USER DECISION)
50
51	Links that point to notes that do not exist.
52
53	Steps:
54	1. Show ALL broken links together (not one by one)
55	2. STOP -- ask the user:
56	```
57	N broken links found:
58	- [[Note A]] (referenced by 3 notes)
59	- [[Note B]] (referenced by 1 note)
60
61	Options:
62	a) Create stub notes (with basic content)
63	b) Remove the links
64	c) Decide one by one
65	d) Skip
66	```
67	3. Continue only after the answer
68
69	### 2e: Orphaned notes WITHOUT context (USER DECISION)
70
71	Completely isolated notes without any MOC links.
72
73	Steps:
74	1. Show the first 10 isolated notes
75	2. STOP -- ask the user:
76	```
77	N isolated notes (no MOC properties, no incoming links):
78	- Note A
79	- Note B
80	- ...
81
82	Should I use semantic_search to find and suggest matching topics?
83	Or should these notes be ignored?
84	```
85	3. If yes: for each note run semantic_search, suggest a topic, update_frontmatter
86
87	### 2f: Weak clusters (TOP 5 ONLY)
88
89	Semantically similar notes without explicit links.
90
91	Steps:
92	1. Only the top 5 pairs (highest similarity)
93	2. Read both notes with `read_file`
94	3. Suggest to the user: "Should I link [[A]] and [[B]]?"
95	4. Wait for confirmation
96
97	## Phase 3: REFRESH + WRAP-UP
98
99	After all fixes: call `vault_health_check` with `refresh: true`.
100	This re-extracts the graph and rebuilds the ontology so the findings
101	reflect the current vault state (not the stale state from before the fixes).
102
103	Then give a compact summary:
104	```
105	Vault Health batch finished:
106	- X missing backlinks fixed
107	- Y orphan backlinks added
108	- Z tags unified
109	- N broken links: [status]
110	- M isolated orphans: [status]
111	- Findings remaining after refresh: N
112
113	All changes are reversible via the undo bar (top of the chat).
114	```
115
116	## Token efficiency rules (follow STRICTLY)
117
118	1. NO `read_file` for orphans when the finding data already provides the context
119	2. NO `semantic_search` for notes that already have MOC links
120	3. Work in batches of 10 fixes of the same kind
121	4. After 20 iterations: give a summary and ask "Continue?"
122	5. IGNORE the fix rules in the vault_health_check output -- follow THESE rules
123
124	## Autonomy rules (follow STRICTLY)
125
126	AUTONOMOUS (NO questions):
127	- Backlink entries (missing backlinks, orphans with context)
128	- Tag unification
129
130	WITH USER DECISION (ALWAYS ask):
131	- Broken links (create vs. remove)
132	- Orphans without context (classify vs. ignore)
133	- Weak clusters (link yes or no)
134	- Creating new entities (topics, concepts)

People who liked this also viewed

6 picks

Type

lark-drive飞书云空间（云盘/云存储）：管理 Drive 文件和文件夹，包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、评论/权限/订阅、标题、版本、飞书文档密级标签（secure labels）和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题，或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sSkillsJul 2026382k16k
lark-sharedUse for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handlingSkillsJul 2026382k16k
lark-whiteboard飞书画板：查询和编辑飞书云文档中的画板。支持导出画板为预览图片、导出原始节点结构、使用多种格式更新画板内容。当用户需要查看画板内容、导出画板图片、编辑画板时使用此 skill。不负责：飞书云文档内容编辑（lark-doc）、文档内嵌电子表格/Base（lark-sheets / lark-base）。SkillsJul 2026380k16k
lark-task飞书任务：管理任务、清单和任务智能体。创建待办任务、查看和更新任务状态、拆分子任务、组织任务清单、分配协作成员、上传任务附件、注册或注销任务智能体、更新任务智能体的主页数据、写入智能体任务记录。当用户需要创建待办事项、查看任务列表、跟踪任务进度、管理项目清单或给他人分配任务、为任务上传附件文件、注册注销任务智能体、更新智能体主页数据、写入任务记录时使用。SkillsJul 2026380k16k
lark-attendance飞书考勤打卡：查询自己的考勤打卡记录SkillsJul 2026330k16k
lark-apps妙搭（Spark/Miaoda）应用开发与托管：应用创建、本地全栈开发、云端生成迭代、创意设计（UI mockup / 可交互原型 / 线框图 / 落地页 / 仪表盘 / 幻灯片 deck / 视觉探索）、AI相关能力和飞书平台能力或者其他外部能力集成、日志/Trace/监控指标/PV/UV 查询、环境变量管理、应用角色与成员管理、自动化触发器（定时/记录变更/Webhook/飞书审批）。当用户要SkillsJul 2026227k16k

vault-health-batch

215stars23forks

View on GitHub

How to install vault-health-batch?

pssah4/vault-operator/vault-health-batch

$npx -y skills add pssah4/vault-operator --skill vault-health-batch

Installs into the current project.

Summary

Autonomous batch mode for Vault Health findings. Works through orphans, missing backlinks, and tags in batches without asking on every fix.

Files · 1

View on GitHub

SKILL.md

1	# Vault Health Batch Mode
2
3	You work through Vault Health findings AUTONOMOUSLY in batches.
4	Ask the user ONLY at real decision points, NOT on every single fix.
5	All changes are reversible via the undo bar (checkpoints are created automatically).
6
7	## Phase 1: TRIAGE
8
9	1. Call `vault_health_check`
10	2. Read the findings and group them by type
11	3. Give the user a short overview (3-5 lines):
12	```
13	Vault Health: X findings
14	- N orphaned notes (M of them with context)
15	- N missing backlinks
16	- N broken links
17	- N inconsistent tags
18	- N weak clusters
19
20	I will start with the mechanical fixes (backlinks, tags).
21	For broken links and isolated orphans I will ask you.
22	```
23	4. Start Phase 2 IMMEDIATELY -- do NOT wait for confirmation
24
25	## Phase 2: BATCH FIX
26
27	Work through the types in this order.
28
29	### 2a: Missing backlinks + orphans with context (ONE TOOL CALL)
30
31	These are mechanical fixes: entities that are referenced but do not link back.
32
33	Steps:
34	1. Call `vault_health_check` with `action: "fix_backlinks"`
35	2. The tool fixes ALL missing backlinks in one batch (pure code, 0 LLM cost)
36	3. Show the user the result: "X entities updated, Y backlinks added"
37
38	NO read_file, NO update_frontmatter, NO sub-agent. ONE tool call does everything.
39
40	### 2c: Inconsistent tags (AUTONOMOUS)
41
42	Tags that differ only in upper/lower case.
43
44	Steps:
45	1. Pick the more frequent variant
46	2. Change all occurrences of the rarer variant via `update_frontmatter`
47	3. NO questions
48
49	### 2d: Broken links (USER DECISION)
50
51	Links that point to notes that do not exist.
52
53	Steps:
54	1. Show ALL broken links together (not one by one)
55	2. STOP -- ask the user:
56	```
57	N broken links found:
58	- [[Note A]] (referenced by 3 notes)
59	- [[Note B]] (referenced by 1 note)
60
61	Options:
62	a) Create stub notes (with basic content)
63	b) Remove the links
64	c) Decide one by one
65	d) Skip
66	```
67	3. Continue only after the answer
68
69	### 2e: Orphaned notes WITHOUT context (USER DECISION)
70
71	Completely isolated notes without any MOC links.
72
73	Steps:
74	1. Show the first 10 isolated notes
75	2. STOP -- ask the user:
76	```
77	N isolated notes (no MOC properties, no incoming links):
78	- Note A
79	- Note B
80	- ...
81
82	Should I use semantic_search to find and suggest matching topics?
83	Or should these notes be ignored?
84	```
85	3. If yes: for each note run semantic_search, suggest a topic, update_frontmatter
86
87	### 2f: Weak clusters (TOP 5 ONLY)
88
89	Semantically similar notes without explicit links.
90
91	Steps:
92	1. Only the top 5 pairs (highest similarity)
93	2. Read both notes with `read_file`
94	3. Suggest to the user: "Should I link [[A]] and [[B]]?"
95	4. Wait for confirmation
96
97	## Phase 3: REFRESH + WRAP-UP
98
99	After all fixes: call `vault_health_check` with `refresh: true`.
100	This re-extracts the graph and rebuilds the ontology so the findings
101	reflect the current vault state (not the stale state from before the fixes).
102
103	Then give a compact summary:
104	```
105	Vault Health batch finished:
106	- X missing backlinks fixed
107	- Y orphan backlinks added
108	- Z tags unified
109	- N broken links: [status]
110	- M isolated orphans: [status]
111	- Findings remaining after refresh: N
112
113	All changes are reversible via the undo bar (top of the chat).
114	```
115
116	## Token efficiency rules (follow STRICTLY)
117
118	1. NO `read_file` for orphans when the finding data already provides the context
119	2. NO `semantic_search` for notes that already have MOC links
120	3. Work in batches of 10 fixes of the same kind
121	4. After 20 iterations: give a summary and ask "Continue?"
122	5. IGNORE the fix rules in the vault_health_check output -- follow THESE rules
123
124	## Autonomy rules (follow STRICTLY)
125
126	AUTONOMOUS (NO questions):
127	- Backlink entries (missing backlinks, orphans with context)
128	- Tag unification
129
130	WITH USER DECISION (ALWAYS ask):
131	- Broken links (create vs. remove)
132	- Orphans without context (classify vs. ignore)
133	- Weak clusters (link yes or no)
134	- Creating new entities (topics, concepts)

People who liked this also viewed

6 picks

Type