{"id":"0b3f5da0-ff86-4130-8f15-cad674cb791c","entityType":"agent","slug":"clawhub-thenerdforge-obsidian-vault-curator","name":"Obsidian Vault Curator","canonicalUrl":"https://www.xpersona.co/agent/clawhub-thenerdforge-obsidian-vault-curator","canonicalPath":"/agent/clawhub-thenerdforge-obsidian-vault-curator","generatedAt":"2026-10-11T15:16:15.399Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:51:16.422Z","emptyReason":null},"description":"Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classif...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s174xf840fv9gsykcep648d75d83qqy6:obsidian-vault-curator","sourceUrl":"https://clawhub.ai/thenerdforge/obsidian-vault-curator","homepage":"https://clawhub.ai/thenerdforge/skills/obsidian-vault-curator","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/thenerdforge/obsidian-vault-curator","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/thenerdforge/skills/obsidian-vault-curator","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Obsidian Vault Curator technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:51:16.422Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:51:16.422Z","emptyReason":null},"stars":null,"forks":null,"downloads":1062,"packageName":null,"latestVersion":"1.1.0","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:51:16.360Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T12:51:16.422Z","lastCrawledAt":"2026-10-11T12:51:16.360Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T12:51:16.360Z","lastVerifiedAt":null,"highlights":[{"version":"1.1.0","createdAt":"2026-05-19T20:09:26.671Z","changelog":"Major prompt-engineering and safety hardening release for large Obsidian/Markdown vault curation workflows. Added: - New read-only roles: duplicate-cluster-agent, sensitive-content-agent, and threshold-based structural-move-planner. - Concrete subagent packet examples for every named role. - Glossary for sensitive content, operational data, heterogeneous slices, folder roots, canonical changes, and affected backlinks. - Sensitive-content precedence rule. - Topic and confidence rules, plus topic slug validation. Changed: - Multi-note and heterogeneous vault work now defaults to inventory-first read-only subagent passes. - Main agent remains the only writer; subagents are strictly read-only and never write, even with user approval. - Read-only subagent slices are capped at 200 notes; write slices are capped at 3-10 related notes. - Output shapes are centralized in references/output-format.md. - Migration planning now requires reviewer pass for every note in the slice. - Link-verifier and sensitive-content-agent now have explicit slice caps and split rules. Fixed: - Removed writer-subagent loophole. - Removed ambiguous unverified terminology from script output. - Clarified that pending verification is not a frontmatter status. - Reduced ambiguity between sensitive content and operational data. - Tightened stop conditions, human-review gates, and anti-hallucination guardrails. Reviewed through multiple Claude Code prompt-engineering audits. Final regression review verdict: publish-ready.","fileCount":14,"zipByteSize":28267},{"version":"1.0.2","createdAt":"2026-05-19T17:18:45.761Z","changelog":"Strengthened subagent delegation rules; added inventory-first delegation for multi-note work; tightened bounded-slice workflow and output-shape handling; no global subagent model or delegationMode config added.","fileCount":12,"zipByteSize":18482},{"version":"1.0.1","createdAt":"2026-05-13T22:23:30.907Z","changelog":"Subagent policy in SKILL.md refined with bounded read-only slice rules and clearer escalation/return-shape guardrails.","fileCount":12,"zipByteSize":18127},{"version":"1.0.0","createdAt":"2026-05-12T15:46:48.492Z","changelog":"Initial public release. Cautious Obsidian vault curation with inventory, frontmatter validation, link checks, migration planning, and conservative write-slice rules.","fileCount":12,"zipByteSize":17757}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s174xf840fv9gsykcep648d75d83qqy6:obsidian-vault-curator","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s174xf840fv9gsykcep648d75d83qqy6:obsidian-vault-curator` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/thenerdforge/obsidian-vault-curator before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T15:16:15.394Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-thenerdforge-obsidian-vault-curator/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:51:16.422Z","emptyReason":null},"readme":"Skill: Obsidian Vault Curator\n\nOwner: thenerdforge\n\nSummary: Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classif...\n\nTags: latest:1.1.0\n\nVersion history:\n\nv1.1.0 | 2026-05-19T20:09:26.671Z | user\n\nMajor prompt-engineering and safety hardening release for large Obsidian/Markdown vault curation workflows.\n\nAdded:\n- New read-only roles: duplicate-cluster-agent, sensitive-content-agent, and threshold-based structural-move-planner.\n- Concrete subagent packet examples for every named role.\n- Glossary for sensitive content, operational data, heterogeneous slices, folder roots, canonical changes, and affected backlinks.\n- Sensitive-content precedence rule.\n- Topic and confidence rules, plus topic slug validation.\n\nChanged:\n- Multi-note and heterogeneous vault work now defaults to inventory-first read-only subagent passes.\n- Main agent remains the only writer; subagents are strictly read-only and never write, even with user approval.\n- Read-only subagent slices are capped at 200 notes; write slices are capped at 3-10 related notes.\n- Output shapes are centralized in references/output-format.md.\n- Migration planning now requires reviewer pass for every note in the slice.\n- Link-verifier and sensitive-content-agent now have explicit slice caps and split rules.\n\nFixed:\n- Removed writer-subagent loophole.\n- Removed ambiguous unverified terminology from script output.\n- Clarified that pending verification is not a frontmatter status.\n- Reduced ambiguity between sensitive content and operational data.\n- Tightened stop conditions, human-review gates, and anti-hallucination guardrails.\n\nReviewed through multiple Claude Code prompt-engineering audits. Final regression review verdict: publish-ready.\n\nv1.0.2 | 2026-05-19T17:18:45.761Z | user\n\nStrengthened subagent delegation rules; added inventory-first delegation for multi-note work; tightened bounded-slice workflow and output-shape handling; no global subagent model or delegationMode config added.\n\nv1.0.1 | 2026-05-13T22:23:30.907Z | user\n\nSubagent policy in SKILL.md refined with bounded read-only slice rules and clearer escalation/return-shape guardrails.\n\nv1.0.0 | 2026-05-12T15:46:48.492Z | user\n\nInitial public release. Cautious Obsidian vault curation with inventory, frontmatter validation, link checks, migration planning, and conservative write-slice rules.\n\nArchive index:\n\nArchive v1.1.0: 14 files, 28267 bytes\n\nFiles: references/bases-views.md (1368b), references/classification-rubric.md (3524b), references/output-format.md (2528b), references/status-schema.md (2832b), references/subagent-packets.md (9092b), references/subagents.md (15374b), references/workflow.md (4340b), scripts/check_links.py (2451b), scripts/generate_migration_plan.py (3434b), scripts/inventory_slice.py (5590b), scripts/validate_frontmatter.py (4281b), skill-card.md (2474b), SKILL.md (10629b), _meta.json (141b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: obsidian-vault-curator\ndescription: Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classify notes, define canonical reference pages, separate current vs historical vs future-state material, design review dashboards or Bases views, or plan safe cleanup and migration without losing historical context. This skill requires installed Python 3 on PATH.\nmetadata:\n  openclaw:\n    emoji: \"🗂️\"\n    requires:\n      bins: [\"python3\"]\n    install:\n      - id: brew-python\n        kind: brew\n        formula: python\n        bins: [\"python3\"]\n        label: \"Install Python 3 (brew)\"\n        os: [\"darwin\"]\n---\n\n# Obsidian Vault Curator\n\nBring structure to a messy Obsidian vault without flattening its history. Start with inventory. Then run separate read-only analysis passes. Then propose one small, reviewable write slice.\n\nFor multi-note work, use read-only subagents by default. Keep the main agent as the only writer. Use one bounded slice per subagent and separate passes for inventory, comparison, classification, verification, and sensitive-content review.\n\n## Runtime requirement\n\nThis skill declares `python3` on `PATH` as a host requirement.\n\n- The requirement is surfaced in metadata as `requires.bins: [\"python3\"]`.\n- On macOS, the metadata includes a Homebrew install hint.\n- On Linux, install Python 3 with your distro package manager, for example `sudo apt install python3`, then verify `python3 --version`.\n- On Windows, install Python from the official Python Install Manager or with `winget install Python.Python.3.14`, then open a new terminal and verify that `python3 --version` works. If only `python` works, add a `python3` alias or shim on `PATH` before using this skill.\n- The bundled helper scripts in `scripts/` use only the Python standard library.\n- No extra Python packages are required.\n- No exact minor version is currently pinned. The helpers were validated with Python 3.11+ and tested locally on macOS against Python `3.14.4`.\n- Windows support is documented, but the full workflow has not yet been live-validated on Windows.\n\n## Core rules\n\n- Default to read-only.\n- Use subagents by default for multi-note or heterogeneous work.\n- Keep inventory first, then read-only review, then writes.\n- Never delete notes unless the user explicitly asks.\n- Never rewrite more than one write slice at a time. A write slice must stay within 3-10 related notes. Multiple-slice content rewrites in one pass count as mass-rewrite and require explicit user approval.\n- Never run parallel write agents.\n- Treat findings of sensitive content (see `references/subagents.md` glossary) as hypotheses until the main agent verifies the exact note content.\n- Never rely on a global forced subagent model. Reuse the main-agent model when it fits; change model only when a specific role clearly benefits.\n- Prefer `superseded_by` over overwrite.\n- Preserve historical context.\n- Treat `doc_kind` and `status` as separate concerns.\n- Prefer controlled YAML frontmatter over ad-hoc tags for lifecycle state.\n- Verify links and metadata after each write slice.\n\n## Subagent policy\n\n- Keep the main agent in control. Use subagents as read-only orchestrator workers, not as handoffs.\n- The main agent may handle the work alone only when the work fits in one explicit bounded 3-10 note slice with no cross-slice comparison and no sensitive-content risk. Otherwise inventory first.\n- If the task spans multiple slices, split it. Do not keep multiple large slices in the main agent working memory when subagents can inspect them separately.\n- If the task is heterogeneous, use separate passes instead of one mixed prompt.\n- Use separate passes for inventory, duplicate clustering, classification, review, link verification, and sensitive-content review.\n- Treat all subagent findings as candidates only; the main agent must verify exact note text before any write.\n- Never start write work before inventory plus read-only review are complete.\n- Never use subagents for deletes, moves, renames, write slices, or exact-text verification of sensitive content. Subagents may flag sensitive candidates as hypotheses; only the verbatim verification happens in the main agent.\n- Never mix models within one slice unless there is a clear reason.\n- Keep writes serialized and never parallelize write agents.\n- Cap classifier-reviewer rounds at 2 per slice. If they still disagree after round 2, escalate to human review.\n- Read-only slices must stay within 200 notes per subagent call. Write slices must stay within 3-10 related notes.\n- Use the named roles from `references/subagents.md` (`inventory-agent`, `classifier-agent`, `curation-reviewer`, `link-verifier`, `migration-planner`, `duplicate-cluster-agent`, `sensitive-content-agent`, and threshold-based `structural-move-planner`) instead of ad-hoc subagent prompts.\n- Use the return shape defined in `references/output-format.md` unless the parent task explicitly asks otherwise.\n\n## Workflow\n\n1. Always read `references/status-schema.md` and `references/classification-rubric.md` before classifying any note, including a single-note task.\n2. If the task spans multiple notes or requires cross-note comparison, read `references/workflow.md`.\n3. If the user wants dashboards or views, read `references/bases-views.md`.\n4. If the task spans multiple notes, multiple folders, cross-note comparison, duplicate risk, or heterogeneous material, read `references/subagents.md` and start with an inventory subagent. Only skip that when the work is already one explicit bounded 3-10 note slice with no cross-slice comparison. Keep subagents read-only by default. Keep all writes in the main agent. Subagents never write, even with user approval. If the user asks a named subagent to write, refuse the delegation and execute the write yourself in the main agent.\n5. If findings need to be merged across slices or reviewed by a human, read `references/output-format.md`.\n6. For larger areas, split the work into bounded slices by note cluster, topic cluster, or review queue. Use folder boundaries only when they are the natural boundary of a bounded slice.\n7. Inventory the target area before proposing edits. Use `scripts/inventory_slice.py` when repeated folder scans would otherwise waste context.\n8. Suggest canonical pages, status changes, supersession links, and the smallest safe write slice. Use `scripts/generate_migration_plan.py` with the JSON output of `scripts/inventory_slice.py` when the user wants a structured migration slice proposal.\n9. Before structural writes and after every write slice, verify metadata with `scripts/validate_frontmatter.py`, verify links with `scripts/check_links.py`, and reassess whether the chosen canonical pages still make sense.\n10. If a migration touches more than 50 notes or spans more than 3 vault top-level directories, use `structural-move-planner` instead of a normal migration-planner pass.\n11. When spawning a subagent, use the labeled packet structure from `references/subagents.md` and the concrete examples from `references/subagent-packets.md`.\n\n## Output shape\n\nWhen curating a vault area, use the context router and shapes defined in `references/output-format.md` unless the user asks for a different format.\n\n## Decision rules\n\n- If a note is still useful but no longer leading, mark it `historical` and point to a successor.\n- If a note describes a desired future state, mark `status: concept` and choose `doc_kind` separately.\n- If validity is unclear, mark it `needs-review` first instead of guessing.\n- If an old note may become useful again, prefer `reactivatable` over burying it.\n- If multiple notes cover the same topic, nominate one canonical page and propose the rest as supporting or historical pages.\n- If the vault already has a schema, adapt to it instead of forcing a new one.\n- If a subagent flags sensitive content (see `references/subagents.md` glossary), verify the exact text in the main agent before escalating or editing.\n\n## Safe operating mode\n\nUse small, reviewable steps:\n\n- classify before moving or merging\n- move before rewriting when structure is the real problem\n- create indexes and canonical pages before cleanup\n- keep historical pages reachable\n- ask before touching attachments, `.obsidian/`, or folder restructures that touch more than one folder or more than 10 notes\n\n## Built-in helpers (require installed `python3`)\n\nIf `python3` is unavailable, the bundled helper scripts cannot run. Continue with the manual workflow and do not pretend a helper script ran.\n\n- `scripts/inventory_slice.py` — scan one vault slice and summarize note counts, missing metadata, status/doc_kind coverage, title duplicates, exact-content duplicate clusters, and high-signal sensitive candidates that still require main-agent verification.\n- `scripts/validate_frontmatter.py` — verify the controlled frontmatter shape on one slice before or after edits.\n- `scripts/generate_migration_plan.py` — turn the JSON output of `scripts/inventory_slice.py` into a small, reviewable migration plan.\n- `scripts/check_links.py` — inspect wikilinks in one slice and flag unresolved targets before or after moves. Treat results as slice-local unless the checked slice includes every possible target note.\n\n## Large-section strategy\n\nWhen the user wants work on a broader vault area or any task involving multiple notes:\n\n1. keep one main agent as orchestrator\n2. split the area into bounded slices\n3. use read-only subagents for inventory, duplicate clustering, classification, contradiction checks, link review, and sensitive-content review, one bounded slice per subagent\n4. merge findings in the main agent\n5. execute one write slice at a time in the main agent\n\nPrefer this over giving one agent the whole vault context at once. If the area cannot be answered confidently from the current instructions and one bounded slice of material, inventory first, then fan out into separate slices.\n\n## References\n\n- `references/status-schema.md` — controlled fields, values, and examples\n- `references/classification-rubric.md` — note-by-note classification heuristics\n- `references/workflow.md` — end-to-end curation and migration flow\n- `references/bases-views.md` — suggested Bases views and review queues\n- `references/subagents.md` — safe delegation model for larger vault jobs\n- `references/subagent-packets.md` — concrete subagent packet examples for deterministic read-only delegation\n- `references/output-format.md` — standard subagent return shape, merge rules, and human-review gates\n\nFile v1.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7dzka1n2vjb8wgzt8v4xrych82ph5f\",\n  \"slug\": \"obsidian-vault-curator\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1779221366671\n}\n\nFile v1.1.0:references/bases-views.md\n\n# Bases and review views\n\nUse Bases or equivalent review lists as the control plane for curation.\n\nViews that group by `topic` depend on consistent topic slugs. Use the `topic` rule in `references/status-schema.md` before creating or changing topic-based views.\n\n## Recommended views\n\n### Vault Inbox\nShow notes missing `status` or `doc_kind`.\n\n### Needs Review\nShow notes where:\n\n- `status = needs-review`, or\n- `review_state = conflict`\n\n### Canonical Pages\nShow notes where:\n\n- `canonical = true`\n\ngroup by `topic`.\n\n### Historical but linked\nShow notes where:\n\n- `status = historical`\n- and the note still has meaningful inbound links\n\n### Concept / future state\nShow notes where:\n\n- `status = concept`\n\n### Reactivatable\nShow notes where:\n\n- `status = reactivatable`\n\n### Supersession gaps\nShow notes where:\n\n- `status = historical`\n- and `superseded_by` is empty\n\n### Stale current docs\nShow notes where:\n\n- `status = current`\n- and `last_verified` is older than 90 days or missing\n\n### Research not integrated\nShow notes where:\n\n- `doc_kind = research`\n- and no canonical page links to them\n\n## Practical guidance\n\n- Keep the first dashboard small and obvious.\n- Start with visibility, not automation.\n- Prefer a handful of high-signal views over a huge taxonomy.\n- If Bases is not available, propose manual indexes or search-driven lists as equivalent queues.\n\nFile v1.1.0:references/classification-rubric.md\n\n# Classification rubric\n\nClassify one note at a time. Prefer explicit uncertainty over confident mislabeling.\n\nSubagents that use this rubric return candidates only; the main agent verifies and applies.\nSee `references/status-schema.md` for the `confidence` rule when emitting per-note recommendations.\n\n## Step 1: Determine `doc_kind`\n\nAsk what the note is trying to be:\n\n- `reference` — source of truth, stable facts, config, paths, commands\n- `howto` — procedure to achieve a task\n- `explanation` — why something works, tradeoffs, reasoning\n- `tutorial` — guided learning sequence\n- `research` — collected findings, comparisons, external material\n- `adr` — a decision with context and consequences\n- `log` — diary, changelog, working notes, progress trail\n- `index` — hub page or navigation page\n- `concept` — target design or future plan\n\n## Step 2: Determine `status`\n\n### `current`\nUse when the note is still valid and should be trusted now.\nSignals:\n- verified paths, commands, hostnames, versions, or architecture\n- referenced by 2 or more inbound wikilinks from notes that are already `status: current`\n- clearly reflects the live environment\n\n### `historical`\nUse when the note is not current but still valuable.\nSignals:\n- documents a previous setup, migration path, or decision history\n- useful for recovery, comparison, or context\n- replaced by a newer page\n\n### `concept`\nUse when the note describes a desired future state.\nSignals:\n- signal words in the title or opening section, in German or English, such as Zielbild, Soll, Plan, Proposal, Vision, target state, draft, or future state\n- contains intended rather than verified state\n\n### `needs-review`\nUse when status is unclear.\nSignals:\n- mixed old and new facts\n- no verification date, or `last_verified` older than 90 days for a note claiming `status: current`\n- conflicts with better evidence\n- unclear whether the note is still active\n\n### `reactivatable`\nUse when the note is dormant but likely reusable.\nSignals:\n- currently inactive workflow or system\n- likely to return later\n- should stay discoverable without being treated as live\n\n## Canonical page test\n\nA note is a good canonical candidate when most of these are true:\n\n- it has the clearest scope for a topic\n- it is easier to update than the alternatives\n- it already attracts links or should attract them\n- it can safely point outward to detail pages\n- it is not mostly historical baggage\n\nIf no note qualifies, propose creating a small new index or reference page instead of forcing a bad canonical page.\n\n## Supersession rules\n\n- Do not erase old context when a new page replaces it.\n- Mark older pages with `superseded_by`.\n- Mark the new leading page with `supersedes`.\n- Prefer short transition notes over giant merge rewrites.\n\n## Conflict handling\n\nWhen two notes disagree:\n\n1. trust live evidence over prose\n2. trust the note with recent verification over the undated one\n3. downgrade uncertain notes to `needs-review`\n4. do not silently merge contradictions away\n5. if a note appears to contain sensitive content (see `references/subagents.md` glossary), flag it as a `needs-review` candidate until the main agent verifies the exact text\n\n## Smell list\n\nBe careful when a note contains:\n\n- old hostnames, paths, containers, or OS assumptions\n- ambiguous words like \"current\", \"latest\", \"new\" without a date\n- copied research without integration into a leading page\n- multiple unrelated topics in one note\n- operational instructions mixed with speculative design\n\nFile v1.1.0:references/output-format.md\n\n# Output and merge format\n\nUse one compact format so subagent findings are mergeable.\nThis file is the single source of truth for output shapes.\n\n## Context router\n\n| Context | Use this shape |\n|---|---|\n| Subagent reply | `Required five-section shape` |\n| Single-pass main-agent reply with no subagents | `Required five-section shape` |\n| Main-agent merged reply from two or more subagent slices | `Final main-agent summary shape` |\n\n## Required five-section shape\n\nReturn these sections in this order:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nKeep each section short and concrete.\nIf a section has nothing material, write `none`.\n\n## Preferred note-level fields\n\nWhen naming important notes, prefer this shape:\n\n- `Path or note name`\n- `doc_kind`\n- `status`\n- `canonical` yes/no when relevant\n- short reason\n- optional `confidence: low|medium|high`\n\nIf the bounded slice does not support a recommendation, write `insufficient evidence` and prefer `needs-review` over guessing.\n\n## Sensitive findings\n\nIf a subagent suspects sensitive content (see `references/subagents.md` glossary):\n\n- treat it as a hypothesis, not a confirmed finding\n- reference only the note path, field or section, pattern type, and redacted shape\n- do not quote the sensitive value\n- do not recommend edits as if the finding were confirmed\n- place the finding under `Risks and contradictions`\n- require main-agent verification against exact note text before escalation or editing\n\n## Merge rules for the main agent\n\nWhen merging child-slice results:\n\n1. prefer compact summaries over repeating every detail, but keep disagreements visible\n2. surface disagreements explicitly\n3. downgrade contested notes to `needs-review`\n4. separate confirmed facts from hypotheses\n5. separate structural actions from content rewrite actions\n6. keep unsupported claims out of the merged summary; use `insufficient evidence` where needed\n\n## Human-review gates\n\nEscalate to explicit human review before:\n\n- deleting notes\n- moves or renames affecting more than 10 notes or more than 1 vault top-level directory\n- editing notes after only inferred classification\n- acting on sensitive-content hypotheses\n- collapsing multiple competing pages into one canonical page without clear evidence\n- changing a canonical page with 3 or more affected backlinks\n\n## Final main-agent summary shape\n\nWhen reporting merged results back after a multi-slice pass, use the required five-section shape.\n\nFile v1.1.0:references/status-schema.md\n\n# Status schema\n\nUse a small controlled schema. Expand only when repeated real use shows a gap.\n\n## Core fields\n\n```yaml\nstatus: needs-review\ndoc_kind: reference\ntopic:\ncanonical: false\ncanonical_for: []\nsupersedes: []\nsuperseded_by: []\nlast_verified:\nreview_after:\nreview_state: unreviewed\nconfidence: low\n```\n\n## Allowed values\n\n### `status`\n\n- `current` — currently valid or leading\n- `historical` — no longer leading, but still worth keeping\n- `concept` — target state, proposal, idea, or design direction\n- `needs-review` — unclear, conflicting, or not yet checked\n- `reactivatable` — not active now, but likely worth reviving later\n\n### `doc_kind`\n\n- `reference`\n- `howto`\n- `explanation`\n- `tutorial`\n- `research`\n- `adr`\n- `log`\n- `index`\n- `concept`\n\nNote: `concept` exists in both lists on purpose. `status: concept` means the note describes a future state. `doc_kind: concept` describes its writing genre. They are independent.\n\n### `review_state`\n\n- `unreviewed`\n- `reviewed`\n- `conflict`\n- `migrate-plan-ready`\n- `migrated`\n\n### `confidence`\n\n- `low`\n- `medium`\n- `high`\n\n## Rules\n\n- Keep `status` separate from `doc_kind`.\n- When ambiguity matters in prose, name the field explicitly, for example `status: concept`.\n- Prefer one canonical page per topic cluster.\n- Use `superseded_by` on old pages and `supersedes` on the new leading page.\n- If you cannot justify `current`, use `needs-review` first.\n- If dates matter, write real dates instead of vague words like \"latest\".\n\n### `topic` rule\n\nUse one short kebab-case slug per topic cluster. Adopt the slug already used elsewhere in the vault when one exists. If no slug exists yet, leave the field blank rather than inventing one without main-agent confirmation.\n\n### `confidence` rule\n\nUse `low` when the evidence is one shallow signal or inference. Use `medium` when at least two independent signals agree. Use `high` only when the note's live state was directly verified within the current pass. Default to `low` under uncertainty.\n\n## Examples\n\n### Current reference page\n\n```yaml\nstatus: current\ndoc_kind: reference\ntopic: openclaw\ncanonical: true\ncanonical_for:\n  - OpenClaw Runtime\nlast_verified: 2026-05-11\nreview_state: reviewed\nconfidence: high\n```\n\n### Historical page preserved for context\n\n```yaml\nstatus: historical\ndoc_kind: howto\ntopic: openclaw\nsuperseded_by:\n  - \"[[OpenClaw Runtime & Konfiguration]]\"\nreview_state: reviewed\nconfidence: medium\n```\n\n### Future-state note\n\n```yaml\nstatus: concept\ndoc_kind: explanation\ntopic: yuna-public\nreview_state: unreviewed\nconfidence: medium\n```\n\n`status` and `doc_kind` are independent. A future-state note can also use `doc_kind: concept` when that is the best fit.\n\n### Unclear note waiting for triage\n\n```yaml\nstatus: needs-review\ndoc_kind: research\nreview_state: unreviewed\nconfidence: low\n```\n\nFile v1.1.0:references/subagent-packets.md\n\n# Subagent packet examples\n\nUse these examples when the main agent prepares a read-only subagent call.\n\nKeep the packet short.\nPass only the bounded slice, the minimum relevant rubric, and the exact constraints.\nUse the output shapes from `references/output-format.md`.\n\n## Packet template\n\n```text\nROLE:\n<exact role name>\n\nTASK:\n<one concrete read-only objective>\n\nBOUNDED SLICE:\n<exact folder, note set, or 3-10 note cluster>\n\nSOURCES:\n- <allowed file, summary, or rubric>\n\nCONSTRAINTS:\n- read-only\n- use only the bounded slice and listed sources\n- if evidence is insufficient, write `insufficient evidence`\n- prefer `needs-review` over guessing\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not infer outside the bounded slice\n- do not propose writes\n- do not quote sensitive values\n- stop when the bounded slice does not support a stable recommendation\n```\n\n## Example: `inventory-agent`\n\n```text\nROLE:\ninventory-agent\n\nTASK:\nMap the current state of this vault area before any deeper pass.\n\nBOUNDED SLICE:\nFolder `40 Skills & Automatisierung/Obsidian Curator`, capped at 200 notes.\n\nSOURCES:\n- note files inside the bounded slice\n- `references/status-schema.md`\n\nCONSTRAINTS:\n- read-only\n- do not classify note status beyond obvious missing metadata flags\n- do not compare content deeply; shallow duplicate detection only\n- do not propose writes\n- if evidence is insufficient, write `insufficient evidence`\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- use only the bounded slice\n- if a duplicate needs content comparison, route it as a candidate for `duplicate-cluster-agent`\n- if a note may contain sensitive content, flag it under `Risks and contradictions` as a sensitive-content hypothesis and prefer `status: needs-review`\n```\n\n## Example: `duplicate-cluster-agent`\n\n```text\nROLE:\nduplicate-cluster-agent\n\nTASK:\nCheck whether these 4 notes are near-duplicates, forks, drafts, or only topic-overlapping.\n\nBOUNDED SLICE:\nThese 4 notes only:\n- `X.md`\n- `Y.md`\n- `Z.md`\n- `W.md`\n\nSOURCES:\n- note bodies for the 4 notes\n- inventory summary that flagged them as duplicate candidates\n\nCONSTRAINTS:\n- read-only\n- compare content and structure, not filename alone\n- do not merge notes\n- do not propose `superseded_by`\n- if evidence is insufficient, write `insufficient evidence`\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not call notes duplicates from title similarity alone\n- do not infer one canonical note from path prestige alone\n- if overlap is weak, report `topic-overlap` or `coincidental-match`\n```\n\n## Example: `classifier-agent`\n\n```text\nROLE:\nclassifier-agent\n\nTASK:\nClassify this 5-note topic cluster and propose canonical candidates.\n\nBOUNDED SLICE:\nThese 5 notes only:\n- `A.md`\n- `B.md`\n- `C.md`\n- `D.md`\n- `E.md`\n\nSOURCES:\n- inventory summary for this slice\n- duplicate-cluster result if duplicate or overlap risk exists\n- `references/status-schema.md`\n- `references/classification-rubric.md`\n\nCONSTRAINTS:\n- read-only\n- use only these 5 notes plus the listed source files and summaries\n- do not rely on folder history outside the packet\n- if a note stays ambiguous, prefer `needs-review`\n- if evidence is insufficient, write `insufficient evidence`\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not propose deletions\n- do not force a canonical page when the slice does not support one\n- do not infer `historical` from age alone\n```\n\n## Example: `curation-reviewer`\n\n```text\nROLE:\ncuration-reviewer\n\nTASK:\nChallenge the classifier output for this same 5-note slice before any write planning.\n\nBOUNDED SLICE:\nThe same 5 notes reviewed by `classifier-agent`:\n- `A.md`\n- `B.md`\n- `C.md`\n- `D.md`\n- `E.md`\n\nSOURCES:\n- classifier-agent output for this exact slice\n- inventory summary for this exact slice\n- `references/status-schema.md`\n- `references/classification-rubric.md`\n\nCONSTRAINTS:\n- read-only\n- critique only\n- do not introduce final classifications as new truth\n- return per-note `pass`, `revise`, or `escalate-to-human`\n- if evidence is insufficient, write `insufficient evidence`\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- if classifier and reviewer still disagree after round 2, escalate to human review\n- if a contested note remains, keep it `needs-review`\n- do not propose writes\n```\n\n## Example: `link-verifier`\n\n```text\nROLE:\nlink-verifier\n\nTASK:\nCheck link and backlink risk for this proposed canonical-page update.\n\nBOUNDED SLICE:\nProposed write slice plus directly affected link targets:\n- `Canonical Page.md`\n- `Old Supporting Note.md`\n- `Topic Index.md`\n\nSOURCES:\n- proposed rename, move, canonical switch, supersession update, or index change\n- affected note paths\n- `scripts/check_links.py` output if available\n\nCONSTRAINTS:\n- read-only\n- report breakage only; never repair it\n- inspect wikilinks, backlinks, embedded transclusions, and Dataview/Bases query bodies\n- cap the bounded slice at 200 notes; if directly affected backlinks exceed 200, split the link-verifier pass by topic or by source folder\n- treat slice-local checks as slice-local, not vault-global proof\n- if affected backlinks are outside the inspected slice, return `insufficient evidence` and request a wider slice\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not modify links\n- do not approve a canonical change with 3 or more affected backlinks unless blast radius is clear\n- do not infer safe moves from shallow inventory alone\n```\n\n## Example: `migration-planner`\n\n```text\nROLE:\nmigration-planner\n\nTASK:\nPropose exactly one 3-10 note write slice based on completed read-only findings.\n\nBOUNDED SLICE:\nOne proposed write slice only:\n- `Note 1.md`\n- `Note 2.md`\n- `Note 3.md`\n\nSOURCES:\n- merged main-agent findings\n- inventory-agent output\n- classifier-agent output\n- curation-reviewer output with `pass`\n- sensitive-content-agent output when the slice includes content rewrite or operational data\n- link-verifier output when the slice changes a canonical page with 3 or more affected backlinks\n\nCONSTRAINTS:\n- read-only\n- plan only; do not create or modify files\n- no deletes\n- no parallel write plan\n- do not mix metadata, structural, and content-rewrite work in one slice\n- if any contested note remains, return `insufficient evidence` instead of a write plan\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not propose a write slice before inventory, classification, reviewer pass, and required verification passes are complete\n- do not propose a write slice unless curation-reviewer returned `pass` for every note in the slice\n- do not propose structural moves beyond one bounded slice\n- block deletion proposals unless the user explicitly approved deletion planning\n```\n\n## Example: `sensitive-content-agent`\n\n```text\nROLE:\nsensitive-content-agent\n\nTASK:\nReview this planned write slice for sensitive content.\n\nBOUNDED SLICE:\nThese 3 notes only:\n- `Ops Note 1.md`\n- `Ops Note 2.md`\n- `Migration Draft.md`\n\nSOURCES:\n- note files in the bounded slice\n- sensitive-content definition from `references/subagents.md` glossary\n\nCONSTRAINTS:\n- read-only\n- hypotheses only\n- cap the bounded slice at 200 notes; if the relevant area exceeds 200 notes, split into multiple sensitive-content-agent passes\n- redact suspect strings by default\n- never quote sensitive values verbatim\n- if evidence is insufficient, write `insufficient evidence`\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not recommend edits as if a finding were confirmed\n- place findings under `Risks and contradictions` as sensitive-content hypotheses\n- point only to note path, field or section, pattern type, and redacted shape\n```\n\n## Example: `structural-move-planner`\n\n```text\nROLE:\nstructural-move-planner\n\nTASK:\nPlan folder-level reorganization risk for a migration that crosses the structural threshold.\n\nBOUNDED SLICE:\nOne proposed structural migration that touches more than 50 notes or spans more than 3 vault top-level directories.\n\nSOURCES:\n- merged main-agent findings\n- inventory summaries for each affected folder root\n- link-verifier output or planned link-verifier scope\n- current folder-root map\n\nCONSTRAINTS:\n- read-only\n- plan only; do not create, rename, move, or delete files\n- do not replace `migration-planner` for normal 3-10 note write slices\n- compute blast radius for backlinks, Bases views, Dataview queries, embeds, and canonical redirections\n- if evidence is insufficient, write `insufficient evidence`\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not approve execution\n- do not propose parallel writes\n- if the migration is below threshold, return that `migration-planner` should handle it instead\n- block deletion proposals unless the user explicitly approved deletion planning\n```\n\nFile v1.1.0:references/subagents.md\n\n# Subagent model\n\nUse subagents to increase coverage and reduce context pressure.\n\nThe main agent stays in control and remains the sole writer.\nUse agent-as-tool / orchestrator-worker mode only.\nDo not use handoffs.\nSubagents never create, modify, rename, move, or delete files, even with user approval.\nDo not define a global forced model for all subagents; reuse the main model when it fits and change it only when a role clearly benefits.\n\n## Glossary\n\n- **Sensitive content**: any secrets, credentials, API tokens, private keys, PII, or internal-only identifiers. PII includes names, email addresses, phone numbers, physical addresses, and government IDs. Internal-only identifiers include live hostnames, IP addresses, service-account names, internal URLs, API endpoints, and deployment-specific IDs.\n- **Operational data**: anything that describes a live or recently-live system, including hostnames, paths, container names, configuration values, account names, API endpoints, deployment notes, and backup or restore details.\n- **Precedence rule**: any item that satisfies the `Sensitive content` definition is treated as sensitive content first, regardless of whether it also satisfies `Operational data`. `Operational data` is the broader bucket that triggers `sensitive-content-agent` review during migration; sensitive-content findings additionally require redaction and main-agent exact-text verification before any escalation or write.\n- **Heterogeneous slice**: a slice that matches any of these: spans more than one topic cluster; mixes more than two `doc_kind` values; mixes `current` and `historical` notes that may need different reviewers; mixes operational data with conceptual material. If a slice is heterogeneous, split it into separate single-aspect passes.\n- **Folder root**: a top-level directory of the vault; specifically, a direct child of the vault root.\n- **Canonical change**: any rename of a `canonical: true` note, move of a `canonical: true` note across folders, status flip of a `canonical: true` note away from `current`, setting `superseded_by` on a `canonical: true` note, or deleting a `canonical: true` note.\n- **Affected backlinks**: the count of wikilinks pointing at the canonical note, counted by `scripts/check_links.py` when available or by direct wikilink inspection when the script cannot run.\n\n## Context control principle\n\n- give each subagent one bounded slice only\n- read-only slices must stay within 200 notes per subagent call; if a folder or queue exceeds 200 notes, split it into multiple bounded slices and run separate `inventory-agent` passes\n- bounded slice defaults:\n  - `inventory-agent`: one parent folder, one topic queue, or one explicit note set, capped at 200 notes\n  - `duplicate-cluster-agent`: one candidate cluster or one 3-10 note comparison set\n  - `classifier-agent`: one 3-10 note topic cluster\n  - `curation-reviewer`: the same 3-10 note slice reviewed by `classifier-agent`\n  - `link-verifier`: one proposed write slice plus directly affected link targets, capped at 200 notes total per call. If directly affected backlinks exceed 200, split the `link-verifier` pass by topic or by source folder.\n  - `migration-planner`: one proposed 3-10 note write slice only\n  - `sensitive-content-agent`: one parent slice capped at 200 notes per call, or one planned 3-10 note write slice. If the relevant area exceeds 200 notes, split into multiple `sensitive-content-agent` passes.\n- split heterogeneous material into separate passes per the glossary definition\n- prefer folder, topic, or queue scoped slices over broad vault dumps\n- keep the main agent as the only place where cross-slice decisions are merged\n- if two slices might conflict, review them serially in the main agent\n- never let the main agent hold multiple large slices when subagents can inspect them separately\n- do not use facts outside the assigned bounded slice unless the main agent explicitly includes them in the packet\n- treat sensitive findings as provisional until the main agent reads the exact source note\n- never start write work before inventory plus read-only review are complete\n- if evidence is insufficient, say `insufficient evidence` and downgrade the note or slice to `needs-review` instead of guessing\n\n## Safe roles\n\nEach role's `Required content elements:` describes what must appear inside the shape from `references/output-format.md`. It never replaces that shape.\n\n### `inventory-agent`\nObjective: enumerate notes, folders, shallow duplicates, missing metadata, and structural clusters.\n\nUse this role when: the task spans more than one note, more than one folder, or any area that needs a first-pass map before deeper review.\n\nDo not use this role when: the task is already limited to one known note or one already-verified 3-10 note slice.\n\nRequired content elements: counts, folder map, missing-frontmatter lists, title-duplicate groups, shallow duplicate candidates, and \"needs deeper look\" referrals.\n\nTool and source guidance: read-only filesystem inspection only; use inventory heuristics and broad scanning before deeper passes.\n\nBoundaries: does not classify, does not compare content deeply, does not propose writes.\n\nFailure modes: over-counting near-duplicates from filename similarity; returning raw file lists instead of a distilled summary.\n\n### `duplicate-cluster-agent`\nObjective: find content-based near-duplicates and semantically overlapping notes that shallow inventory cannot see.\n\nUse this role when: `inventory-agent` reports duplicate candidates, multiple notes appear to cover the same topic, or the main agent sees draft/fork/overlap risk inside one 3-10 note slice.\n\nDo not skip this role when: duplicate or overlap risk exists and `classifier-agent` has not yet seen a duplicate-cluster result for the slice.\n\nDo not use this role when: the task is simple metadata completion, the notes are clearly unrelated, or shallow duplicate detection is already sufficient.\n\nRequired content elements: cluster groups with members, similarity rationale, cluster type (`near-duplicate`, `fork-of`, `draft-of`, `topic-overlap`, `coincidental-match`), and a canonical-candidate hypothesis.\n\nTool and source guidance: read only the bounded slice assigned by the main agent; compare body content and structure, not just filenames.\n\nBoundaries: no merging, no deletion, no writing, no `superseded_by` decisions.\n\nFailure modes: false positives from boilerplate/frontmatter, false negatives on conceptually similar but text-divergent notes.\n\n### `classifier-agent`\nObjective: propose `status`, `doc_kind`, `topic`, canonical candidates, and ambiguity flags for one bounded slice.\n\nUse this role when: inventory is complete and one 3-10 note slice now needs classification.\n\nDo not use this role when: inventory is still incomplete, duplicate/overlap risk has not been checked by `duplicate-cluster-agent`, sensitive exact-text verification is still pending, or the slice still mixes unrelated topics.\n\nRequired content elements: per-note recommendations with confidence and explicit uncertainty.\n\nTool and source guidance: use the inventory summary plus the classification rubric; stay within the bounded slice.\n\nBoundaries: suggests only, never writes, never resolves conflicts by force.\n\nFailure modes: conflating `status` and `doc_kind`; forcing a label on an ambiguous note instead of marking it `needs-review`.\n\n### `curation-reviewer`\nObjective: challenge classifier output, find contradictions, and surface counterexamples.\n\nUse this role when: `classifier-agent` has finished a slice and a read-only challenge pass is required before any structural or content write planning.\n\nDo not use this role when: no classifier output exists yet or the slice still needs inventory cleanup first.\n\nRequired content elements: per-note `pass` / `revise` / `escalate-to-human`.\n\nTool and source guidance: review the proposed classifications and canonical candidates for the same bounded slice.\n\nBoundaries: critique-only; do not introduce new classifications as final answers.\n\nFailure modes: reviewer-classifier collusion or shallow agreement that hides unresolved ambiguity.\n\n### `link-verifier`\nObjective: check wikilinks, backlinks, embedded transclusions, and Dataview/Bases query bodies before and after a write slice.\n\nUse this role when: a rename, move, canonical switch, supersession update, or index change is proposed or has just been applied.\n\nDo not use this role when: no link-affecting write is proposed and the task is classification-only.\n\nRequired content elements: pre/post diff, new orphans, broken links, and redirect or `superseded_by` suggestions.\n\nTool and source guidance: inspect only the affected slice and directly related link targets.\n\nBoundaries: reports breakage only; never repairs it.\n\nFailure modes: missing query bodies or treating slice-local checks as vault-global proof.\n\n### `migration-planner`\nObjective: propose the next write slice as a structured plan only.\n\nUse this role when all are true: (1) inventory is complete, (2) `classifier-agent` has run on this slice, (3) `curation-reviewer` returned `pass` for every note in the slice; if any note returned `revise` or `escalate-to-human`, drop that note from the slice or return `insufficient evidence` for the whole slice, (4) if the slice includes content rewrite or operational data, `sensitive-content-agent` has run, (5) if the slice changes a canonical page with 3 or more affected backlinks, `link-verifier` has run, and (6) the main agent is ready to choose one 3-10 note write slice.\n\nDo not use this role when: inventory is incomplete, reviewer disagreement is unresolved, any contested note remains in the slice, or the proposal would mix multiple write slices. If any contested note remains, return `insufficient evidence` instead of a write plan.\n\nRequired content elements: one proposed slice with operation list, predicted link impact, predicted Bases-view impact, and rollback notes.\n\nTool and source guidance: use merged read-only findings from the main agent.\n\nBoundaries: no files, no writes, no deletes, no parallel write plan, and no structural-move plan beyond one bounded slice.\n\nFailure modes: mixing metadata, structural, and content-rewrite work in one slice; proposing deletes by default.\n\n### `sensitive-content-agent`\nObjective: flag sensitive content as hypotheses.\n\nUse this role when: a parent slice needs a safety sweep, a planned write slice contains operational data, or any content rewrite is under consideration.\n\nDo not use this role when: the task is already blocked on explicit human review of known sensitive notes and no new slice is being evaluated.\n\nRequired content elements: per-finding location, pattern type, confidence, redacted shape, and recommended human-review action.\n\nTool and source guidance: read-only sweep of the bounded slice or the requested global area; redact suspect strings by default.\n\nBoundaries: hypotheses only; never quote suspect values verbatim; never propose deletes or rewrites.\n\nFailure modes: echoing sensitive material, alert fatigue, or missing paired credentials (a username found without its password, or a key ID without its secret).\n\n## Conditional roles\n\n### `structural-move-planner`\nObjective: plan folder-level reorganizations and cross-folder moves when a migration is unusually large or complex.\n\nUse this role when: one proposed migration touches more than 50 notes or spans more than 3 vault top-level directories.\n\nDo not use this role when: the work fits inside one normal 3-10 note write slice or stays within one vault top-level directory.\n\nRequired content elements: move plan with blast radius, backlinks, Bases-view impact, and canonical redirection notes.\n\nTool and source guidance: only use when the above threshold is met; otherwise keep this work inside `migration-planner`.\n\nBoundaries: read-only; no file changes; no direct execution.\n\nFailure modes: over-specializing small migrations or duplicating migration-planner output.\n\n## Required return shape\n\nUnless the parent task explicitly requests another format, return the relevant shape defined in `references/output-format.md`.\nKeep sections short and concrete. If a section has nothing material, write `none`.\n\n## Standard subagent prompt packet\n\nWhen the main agent invokes a subagent, use a packet with explicit section labels:\n\n- `ROLE:` exact role name\n- `TASK:` one concrete read-only objective\n- `BOUNDED SLICE:` exact folder, note set, or 3-10 note cluster\n- `SOURCES:` only the files, summaries, or rubrics the role may use\n- `CONSTRAINTS:` write prohibitions, uncertainty rules, and any role-specific limits\n- `OUTPUT:` the required shape from `references/output-format.md`\n- `STOP RULES:` when to return `insufficient evidence`, when to escalate, and what not to infer\n\nKeep the packet short.\nDo not paste broad vault history when a bounded slice plus the relevant rubric is enough.\nSee `references/subagent-packets.md` for concrete role examples.\n\n## Forbidden inferences\n\n- do not infer canonical status from filename alone\n- do not infer `historical` from age alone\n- do not infer `current` from folder placement alone\n- do not infer sensitive content from title alone\n- do not infer note equivalence from title similarity alone\n- do not infer safe structural moves from shallow inventory alone\n- do not infer cross-slice facts that were not included in the packet\n- do not replace uncertainty with a confident classification; use `needs-review` or `insufficient evidence`\n\n## Delegation pattern\n\n1. main agent defines the exact bounded slice\n2. main agent chooses the needed read-only role(s)\n3. one role inspects one slice\n4. if work is heterogeneous, use separate passes\n5. merge findings only in the main agent\n6. write one slice at a time in the main agent\n\nPrefer this over giving one agent the whole vault context at once.\nIf the area cannot be answered confidently from the current instructions and one bounded slice of material, inventory first, then fan out into separate slices.\n\n## Stop conditions and human-review gates\n\n- hard loop budget per slice = 2 classifier/reviewer rounds; if they still disagree after round 2, escalate to human\n- per-slice progress test; if a rerun changes no note classification, no canonical recommendation, and no risk evidence, stop\n- evidence threshold for writes; no write without inventory, classification, reviewer pass, and required verification passes\n- missing-info gate; if the rubric does not cover the case, stop and escalate\n- always block proposed deletes unless the user explicitly approves them\n- always block irreversible or structural writes until the required human-review gate is cleared\n- always stop for any slice that intersects a sensitive-content-agent hit until the main agent verifies the exact note text\n- always stop for canonical changes that affect 3 or more backlinks until link-verifier confirms the blast radius\n\n## Good use cases\n\n- large folder triage\n- duplicate detection\n- metadata gap detection\n- cross-checking classification confidence\n- broad-section triage with bounded child slices\n- reducing context load before a migration wave\n- flagging possible sensitive content for later main-agent verification\n\n## Bad use cases\n\n- parallel note rewrites\n- uncontrolled bulk frontmatter edits\n- whole-vault moves in one pass\n- autonomous cleanup without review gates\n\nFile v1.1.0:references/workflow.md\n\n# Workflow\n\nUse this workflow for non-trivial vault curation.\n\n## Phase 1: Inventory\n\n- define the exact folder, topic, or note set\n- list candidate notes\n- identify hubs, duplicates, and likely stale pages\n- note existing metadata patterns before proposing a new schema\n- when the area is heterogeneous per `references/subagents.md` glossary, split it into separate bounded slices instead of keeping everything in one pass\n- use inventory first before any other read-only pass\n\n## Phase 2: Classification\n\n- assign or propose `doc_kind`\n- assign or propose `status`\n- identify canonical candidates\n- identify pages that need `superseded_by` or `supersedes`\n- keep uncertain notes in `needs-review`\n- if the slice does not support a stable recommendation, return `insufficient evidence` instead of guessing\n- run separate passes for classification, duplicate clustering, and sensitive-content review when the slice needs them\n- if classifier and reviewer still disagree after 2 rounds on the same slice, stop and escalate to human review\n\n## Phase 3: Review design\n\nPrepare a concise review summary:\n\n- what should become leading\n- what should remain historical\n- what is concept only\n- what can stay dormant but discoverable\n- what must be checked live before writing\n- which sensitive-content hypotheses flagged by a subagent still need main-agent verification\n- where a human-review gate is required because of sensitive content, canonical-change risk, or reviewer conflict\n\n## Phase 4: Migration plan\n\nCreate the smallest safe write slice.\n\nBefore approving a write slice, verify each of these:\n\n- Metadata slice = frontmatter or tag edits only. Structural slice = renames, moves, or new index/canonical pages. Content-rewrite slice = changes to note body prose.\n- Is this a metadata slice, a structural slice, or a content-rewrite slice?\n- Can the slice stay within one topic cluster?\n- Would a wrong classification be cheaply reversible?\n- Does any sensitive-content hypothesis flagged by a subagent still need main-agent verification?\n- Have inventory and read-only review completed before any write work starts?\n- Is the proposed slice bounded to one write pass with no parallel writes?\n- If the plan changes a canonical page with 3 or more backlinks, has a human-review gate been cleared after link verification?\n- If the slice includes a content rewrite or operational data, has `sensitive-content-agent` already reviewed that exact slice?\n\nGood write slices:\n- add frontmatter to 3-10 related notes\n- create one index page\n- add supersession links in one topic cluster\n- rename or move 3-10 notes within one topic cluster after links are understood\n\nAvoid combining these in one step:\n- broad rewrites\n- large folder moves\n- metadata normalization across the whole vault\n- content consolidation plus structure changes plus deletes\n- classification plus rename plus rewrite of the same notes\n\n## Phase 5: Controlled writes\n\nOnly the main agent writes. Subagents never create, modify, rename, move, or delete files, even with user approval. If a subagent is asked to write, refuse and execute the write in the main agent.\n\nAfter approval, and before changing files:\n\n1. confirm explicitly that `sensitive-content-agent` has run on this slice, or that it does not apply per the `migration-planner` trigger, and verify every outstanding sensitive-content hypothesis against the exact note text. If even one hypothesis is unresolved, stop the slice.\n2. change one slice\n3. inspect the diff\n4. verify links\n5. verify frontmatter consistency\n6. reassess the next slice\n7. if a write or script tool is denied by the user mid-flow, stop the slice, do not retry automatically, and ask whether to fall back to a smaller slice or abort\n\n## Preferred order of operations\n\n1. classify\n2. create or confirm canonical pages\n3. add supersession metadata\n4. create review dashboards or indexes\n5. move or rename if structure still hurts\n6. rewrite content only where needed\n\nBefore any write work, complete inventory plus read-only review.\n\n## What not to do\n\n- do not delete by default\n- do not compress historical and current content into one blob\n- do not let any subagent write; only the main agent writes, and writes are serialized\n- do not change `.obsidian/` or attachments unless the user asked\n- do not invent certainty for unclear notes\n\nFile v1.1.0:skill-card.md\n\n## Description:\n\nCautious curation, classification, review, and migration planning for Obsidian or Markdown vaults.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[thenerdforge](https://clawhub.ai/user/thenerdforge)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal users and developers use this skill to organize Obsidian or Markdown vaults, classify notes, preserve historical context, design review views, and plan small, reviewable migrations.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Vault notes may contain secrets, PII, operational details, or internal-only identifiers.\n\nMitigation: Review proposed write slices before allowing edits, and verify sensitive-content hypotheses against exact note text before escalation or changes.\n\nRisk: Large restructures, deletes, or rewrites can lose historical context or break links.\n\nMitigation: Inventory first, keep write slices small, avoid deletes unless explicitly requested, and verify frontmatter and links after each write slice.\n\nRisk: Classification or canonical-page recommendations can be wrong when evidence is incomplete or notes conflict.\n\nMitigation: Treat subagent findings as candidates, prefer needs-review under uncertainty, and use human-review gates for contested or high-impact changes.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/thenerdforge/skills/obsidian-vault-curator)\n- [bases-views.md](references/bases-views.md)\n- [classification-rubric.md](references/classification-rubric.md)\n- [output-format.md](references/output-format.md)\n- [status-schema.md](references/status-schema.md)\n- [subagent-packets.md](references/subagent-packets.md)\n- [subagents.md](references/subagents.md)\n- [workflow.md](references/workflow.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown guidance with optional JSON, YAML frontmatter, and shell command snippets]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Uses compact five-section summaries for curation findings and merge reports.]\n\n## Skill Version(s):\n\n1.1.0 (source: ClawHub release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.2: 12 files, 18482 bytes\n\nFiles: references/bases-views.md (1204b), references/classification-rubric.md (3209b), references/output-format.md (1979b), references/status-schema.md (2320b), references/subagents.md (3746b), references/workflow.md (2702b), scripts/check_links.py (2451b), scripts/generate_migration_plan.py (3208b), scripts/inventory_slice.py (5560b), scripts/validate_frontmatter.py (4036b), SKILL.md (10218b), _meta.json (141b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: obsidian-vault-curator\ndescription: Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classify notes, define canonical reference pages, separate current vs historical vs future-state material, design review dashboards or Bases views, or plan safe cleanup and migration without losing historical context. This skill requires installed Python 3 on PATH.\nmetadata:\n  openclaw:\n    emoji: \"🗂️\"\n    requires:\n      bins: [\"python3\"]\n    install:\n      - id: brew-python\n        kind: brew\n        formula: python\n        bins: [\"python3\"]\n        label: \"Install Python 3 (brew)\"\n        os: [\"darwin\"]\n---\n\n# Obsidian Vault Curator\n\nBring structure to a messy Obsidian vault without flattening its history. Start with read-only analysis. Then propose one small, reviewable write slice.\n\nThis skill requires read-only subagents for analysis and inventory-first delegation for multi-note work. The workflow enforces one bounded slice per subagent.\n\n## Runtime requirement\n\nThis skill declares `python3` on `PATH` as a host requirement.\n\n- The requirement is surfaced in metadata as `requires.bins: [\"python3\"]`.\n- On macOS, the metadata includes a Homebrew install hint.\n- On Linux, install Python 3 with your distro package manager, for example `sudo apt install python3`, then verify `python3 --version`.\n- On Windows, install Python from the official Python Install Manager or with `winget install Python.Python.3.14`, then open a new terminal and verify that `python3 --version` works. If only `python` works, add a `python3` alias or shim on `PATH` before using this skill.\n- The bundled helper scripts in `scripts/` use only the Python standard library.\n- No extra Python packages are required.\n- No exact minor version is currently pinned. The helpers were validated with Python 3.11+ and tested locally on macOS against Python `3.14.4`.\n- Windows support is documented, but the full workflow has not yet been live-validated on Windows.\n\n## Core rules\n\n- Default to read-only.\n- Never delete notes unless the user explicitly asks.\n- Never rewrite more than one write slice at a time. A write slice should stay within 3-10 related notes. Multiple-slice content rewrites in one pass count as mass-rewrite and require explicit user approval.\n- Never run parallel write agents.\n- Treat findings of possible secrets, credentials, tokens, or live identifiers as hypotheses until the main agent verifies the exact note content.\n- Prefer `superseded_by` over overwrite.\n- Preserve historical context.\n- Treat `doc_kind` and `status` as separate concerns.\n- Prefer controlled YAML frontmatter over ad-hoc tags for lifecycle state.\n- Verify links and metadata after each write slice.\n\n## Subagent policy\n\n- Default subagent model: match the main agent model when possible.\n- Prefer `openai-codex/gpt-5.4-mini` for inventory, frontmatter checks, link checks, and small classification slices.\n- Escalate the whole job to a stronger model only when the slice is genuinely ambiguous, contradictory, or spans multiple clusters.\n- Use subagents by default.\n- Keep the work in the main agent only when the task can be completed confidently from the current instructions and one bounded slice of material.\n- If the task cannot be answered confidently from the current instructions and one bounded slice, spawn an `inventory-agent` first.\n- If the task requires inspecting more than one bounded slice, split it across read-only subagents.\n- If the task requires separate comparison, classification, or verification passes, delegate each pass to a subagent.\n- If the task is heterogeneous, do not try to keep all of it in the main agent context.\n- Never force the main agent to hold multiple large slices in working memory when subagents can inspect them separately.\n- Never start write work before inventory and read-only review are complete.\n- Do not use subagents for deletes, moves, renames, write slices, or exact-text verification of possibly sensitive material.\n- Treat subagent findings as candidates only; verify the exact note text in the main agent before any write.\n- Do not mix models within one slice unless there is a clear reason.\n- For broader areas, follow `references/subagents.md`: one bounded slice per subagent, read-only by default, and merge results only in the main agent.\n- Prefer the named roles from `references/subagents.md` (`inventory-agent`, `classifier-agent`, `curation-reviewer`, `link-verifier`, `migration-planner`) instead of ad-hoc subagent prompts.\n- Keep the required return shape from `references/subagents.md` unless the parent task explicitly asks otherwise.\n\n## Workflow\n\n1. Always read `references/status-schema.md` and `references/classification-rubric.md` before classifying any note, including a single-note task.\n2. If the task spans multiple notes or requires cross-note comparison, read `references/workflow.md`.\n3. If the user wants dashboards or views, read `references/bases-views.md`.\n4. If the task cannot be covered confidently by one bounded slice plus the current instructions, read `references/subagents.md` and start with an inventory subagent. Keep subagents read-only by default. Keep writes in the main agent unless the user has explicitly approved writes from one specific named subagent for this task.\n5. If findings need to be merged across slices or reviewed by a human, read `references/output-format.md`.\n6. For larger areas, split the work into bounded slices by note cluster, topic cluster, or review queue. Use folder boundaries only when they are the natural boundary of a bounded slice.\n7. Inventory the target area before proposing edits. Use `scripts/inventory_slice.py` when repeated folder scans would otherwise waste context.\n8. Suggest canonical pages, status changes, supersession links, and the smallest safe write slice. Use `scripts/generate_migration_plan.py` with the JSON output of `scripts/inventory_slice.py` when the user wants a structured migration slice proposal.\n9. Before structural writes and after every write slice, verify metadata with `scripts/validate_frontmatter.py`, verify links with `scripts/check_links.py`, and reassess whether the chosen canonical pages still make sense.\n\n## Output shape\n\nWhen curating a vault area, return these sections unless the user asks for a different format:\n\nUse this shape for a single-pass curation reply. Use the subagent shape from `references/output-format.md` when running as a subagent. Use the final main-agent summary shape from `references/output-format.md` only when merging results from multiple subagent slices in the main agent.\n\n1. `Current state` — what exists now, including ambiguity or conflicts.\n2. `Classification recommendations` — suggested `status`, `doc_kind`, and canonical candidates.\n3. `Risks and contradictions` — what could be damaged, misclassified, contradictory, or is still unverified.\n4. `Next write slice` — the smallest safe set of edits.\n5. `Verification` — what to check after changes.\n\n## Decision rules\n\n- If a note is still useful but no longer leading, mark it `historical` and point to a successor.\n- If a note describes a desired future state, mark `status: concept` and choose `doc_kind` separately.\n- If validity is unclear, mark it `needs-review` first instead of guessing.\n- If an old note may become useful again, prefer `reactivatable` over burying it.\n- If multiple notes cover the same topic, nominate one canonical page and propose the rest as supporting or historical pages.\n- If the vault already has a schema, adapt to it instead of forcing a new one.\n- If a subagent flags possible secrets, credentials, tokens, or live identifiers, verify the exact text in the main agent before escalating or editing.\n\n## Safe operating mode\n\nUse small, reviewable steps:\n\n- classify before moving or merging\n- move before rewriting when structure is the real problem\n- create indexes and canonical pages before cleanup\n- keep historical pages reachable\n- ask before touching attachments, `.obsidian/`, or folder restructures that touch more than one folder or more than 10 notes\n\n## Built-in helpers (require installed `python3`)\n\nIf `python3` is unavailable, the bundled helper scripts cannot run. Continue with the manual workflow and do not pretend a helper script ran.\n\n- `scripts/inventory_slice.py` — scan one vault slice and summarize note counts, missing metadata, status/doc_kind coverage, title duplicates, exact-content duplicate clusters, and high-signal sensitive candidates that still require main-agent verification.\n- `scripts/validate_frontmatter.py` — verify the controlled frontmatter shape on one slice before or after edits.\n- `scripts/generate_migration_plan.py` — turn the JSON output of `scripts/inventory_slice.py` into a small, reviewable migration plan.\n- `scripts/check_links.py` — inspect wikilinks in one slice and flag unresolved targets before or after moves. Treat results as slice-local unless the checked slice includes every possible target note.\n\n## Large-section strategy\n\nWhen the user wants work on a broader vault area or any task involving multiple notes:\n\n1. keep one main agent as orchestrator\n2. split the area into bounded slices\n3. use read-only subagents for inventory, classification, contradiction checks, and link review, one bounded slice per subagent\n4. merge findings in the main agent\n5. execute one write slice at a time in the main agent\n\nPrefer this over giving one agent the whole vault context at once. If the area cannot be answered confidently from the current instructions and one bounded slice of material, inventory first, then fan out into separate slices.\n\n## References\n\n- `references/status-schema.md` — controlled fields, values, and examples\n- `references/classification-rubric.md` — note-by-note classification heuristics\n- `references/workflow.md` — end-to-end curation and migration flow\n- `references/bases-views.md` — suggested Bases views and review queues\n- `references/subagents.md` — safe delegation model for larger vault jobs\n- `references/output-format.md` — standard subagent return shape, merge rules, and human-review gates\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn7dzka1n2vjb8wgzt8v4xrych82ph5f\",\n  \"slug\": \"obsidian-vault-curator\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1779211125761\n}\n\nFile v1.0.2:references/bases-views.md\n\n# Bases and review views\n\nUse Bases or equivalent review lists as the control plane for curation.\n\n## Recommended views\n\n### Vault Inbox\nShow notes missing `status` or `doc_kind`.\n\n### Needs Review\nShow notes where:\n\n- `status = needs-review`, or\n- `review_state = conflict`\n\n### Canonical Pages\nShow notes where:\n\n- `canonical = true`\n\ngroup by `topic`.\n\n### Historical but linked\nShow notes where:\n\n- `status = historical`\n- and the note still has meaningful inbound links\n\n### Concept / future state\nShow notes where:\n\n- `status = concept`\n\n### Reactivatable\nShow notes where:\n\n- `status = reactivatable`\n\n### Supersession gaps\nShow notes where:\n\n- `status = historical`\n- and `superseded_by` is empty\n\n### Stale current docs\nShow notes where:\n\n- `status = current`\n- and `last_verified` is older than 90 days or missing\n\n### Research not integrated\nShow notes where:\n\n- `doc_kind = research`\n- and no canonical page links to them\n\n## Practical guidance\n\n- Keep the first dashboard small and obvious.\n- Start with visibility, not automation.\n- Prefer a handful of high-signal views over a huge taxonomy.\n- If Bases is not available, propose manual indexes or search-driven lists as equivalent queues.\n\nFile v1.0.2:references/classification-rubric.md\n\n# Classification rubric\n\nClassify one note at a time. Prefer explicit uncertainty over confident mislabeling.\n\n## Step 1: Determine `doc_kind`\n\nAsk what the note is trying to be:\n\n- `reference` — source of truth, stable facts, config, paths, commands\n- `howto` — procedure to achieve a task\n- `explanation` — why something works, tradeoffs, reasoning\n- `tutorial` — guided learning sequence\n- `research` — collected findings, comparisons, external material\n- `adr` — a decision with context and consequences\n- `log` — diary, changelog, working notes, progress trail\n- `index` — hub page or navigation page\n- `concept` — target design or future plan\n\n## Step 2: Determine `status`\n\n### `current`\nUse when the note is still valid and should be trusted now.\nSignals:\n- verified paths, commands, hostnames, versions, or architecture\n- actively referenced from current hub pages\n- clearly reflects the live environment\n\n### `historical`\nUse when the note is not current but still valuable.\nSignals:\n- documents a previous setup, migration path, or decision history\n- useful for recovery, comparison, or context\n- replaced by a newer page\n\n### `concept`\nUse when the note describes a desired future state.\nSignals:\n- signal words in the title or opening section, in German or English, such as Zielbild, Soll, Plan, Proposal, Vision, target state, draft, or future state\n- contains intended rather than verified state\n\n### `needs-review`\nUse when status is unclear.\nSignals:\n- mixed old and new facts\n- no verification date\n- conflicts with better evidence\n- unclear whether the note is still active\n\n### `reactivatable`\nUse when the note is dormant but likely reusable.\nSignals:\n- currently inactive workflow or system\n- likely to return later\n- should stay discoverable without being treated as live\n\n## Canonical page test\n\nA note is a good canonical candidate when most of these are true:\n\n- it has the clearest scope for a topic\n- it is easier to update than the alternatives\n- it already attracts links or should attract them\n- it can safely point outward to detail pages\n- it is not mostly historical baggage\n\nIf no note qualifies, propose creating a small new index or reference page instead of forcing a bad canonical page.\n\n## Supersession rules\n\n- Do not erase old context when a new page replaces it.\n- Mark older pages with `superseded_by`.\n- Mark the new leading page with `supersedes`.\n- Prefer short transition notes over giant merge rewrites.\n\n## Conflict handling\n\nWhen two notes disagree:\n\n1. trust live evidence over prose\n2. trust the note with recent verification over the undated one\n3. downgrade uncertain notes to `needs-review`\n4. do not silently merge contradictions away\n5. if a note appears to contain possible secrets, credentials, tokens, or live identifiers, flag it as a `needs-review` candidate until the main agent verifies the exact text\n\n## Smell list\n\nBe careful when a note contains:\n\n- old hostnames, paths, containers, or OS assumptions\n- ambiguous words like \"current\", \"latest\", \"new\" without a date\n- copied research without integration into a leading page\n- multiple unrelated topics in one note\n- operational instructions mixed with speculative design\n\nFile v1.0.2:references/output-format.md\n\n# Output and merge format\n\nUse one compact format so subagent findings are mergeable.\n\nUse the required subagent sections below only for subagent replies. Use the SKILL.md output shape for a single-pass main-agent curation reply. Use the final main-agent summary shape below only when merging results from multiple subagent slices.\n\n## Required subagent sections\n\nReturn these sections in this order:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nKeep each section short and concrete.\n\n## Preferred note-level fields\n\nWhen naming important notes, prefer this shape:\n\n- `Path or note name`\n- `doc_kind`\n- `status`\n- `canonical` yes/no when relevant\n- short reason\n- optional `confidence: low|medium|high`\n\n## Sensitive findings\n\nIf a subagent suspects possible secrets, credentials, tokens, or live identifiers:\n\n- label it `unverified`\n- reference only the note path and field name; do not quote the sensitive value\n- do not recommend edits as if the finding were confirmed\n- require main-agent verification against exact note text\n\n## Merge rules for the main agent\n\nWhen merging child-slice results:\n\n1. prefer compact summaries over repeating every detail, but keep disagreements visible\n2. surface disagreements explicitly\n3. downgrade contested notes to `needs-review`\n4. separate confirmed facts from hypotheses\n5. separate structural actions from content rewrite actions\n\n## Human-review gates\n\nEscalate to explicit human review before:\n\n- deleting notes\n- broad moves or renames\n- editing notes after only inferred classification\n- acting on possible secrets or credentials\n- collapsing multiple competing pages into one canonical page without clear evidence\n\n## Final main-agent summary shape\n\nWhen reporting merged results back after a multi-slice pass, prefer:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nFile v1.0.2:references/status-schema.md\n\n# Status schema\n\nUse a small controlled schema. Expand only when repeated real use shows a gap.\n\n## Core fields\n\n```yaml\nstatus: needs-review\ndoc_kind: reference\ntopic:\ncanonical: false\ncanonical_for: []\nsupersedes: []\nsuperseded_by: []\nlast_verified:\nreview_after:\nreview_state: unreviewed\nconfidence: low\n```\n\n## Allowed values\n\n### `status`\n\n- `current` — currently valid or leading\n- `historical` — no longer leading, but still worth keeping\n- `concept` — target state, proposal, idea, or design direction\n- `needs-review` — unclear, conflicting, or not yet checked\n- `reactivatable` — not active now, but likely worth reviving later\n\n### `doc_kind`\n\n- `reference`\n- `howto`\n- `explanation`\n- `tutorial`\n- `research`\n- `adr`\n- `log`\n- `index`\n- `concept`\n\nNote: `concept` exists in both lists on purpose. `status: concept` means the note describes a future state. `doc_kind: concept` describes its writing genre. They are independent.\n\n### `review_state`\n\n- `unreviewed`\n- `reviewed`\n- `conflict`\n- `migrate-plan-ready`\n- `migrated`\n\n### `confidence`\n\n- `low`\n- `medium`\n- `high`\n\n## Rules\n\n- Keep `status` separate from `doc_kind`.\n- When ambiguity matters in prose, name the field explicitly, for example `status: concept`.\n- Prefer one canonical page per topic cluster.\n- Use `superseded_by` on old pages and `supersedes` on the new leading page.\n- If you cannot justify `current`, use `needs-review` first.\n- If dates matter, write real dates instead of vague words like \"latest\".\n\n## Examples\n\n### Current reference page\n\n```yaml\nstatus: current\ndoc_kind: reference\ntopic: openclaw\ncanonical: true\ncanonical_for:\n  - OpenClaw Runtime\nlast_verified: 2026-05-11\nreview_state: reviewed\nconfidence: high\n```\n\n### Historical page preserved for context\n\n```yaml\nstatus: historical\ndoc_kind: howto\ntopic: openclaw\nsuperseded_by:\n  - \"[[OpenClaw Runtime & Konfiguration]]\"\nreview_state: reviewed\nconfidence: medium\n```\n\n### Future-state note\n\n```yaml\nstatus: concept\ndoc_kind: explanation\ntopic: yuna-public\nreview_state: unreviewed\nconfidence: medium\n```\n\n`status` and `doc_kind` are independent. A future-state note can also use `doc_kind: concept` when that is the best fit.\n\n### Unclear note waiting for triage\n\n```yaml\nstatus: needs-review\ndoc_kind: research\nreview_state: unreviewed\nconfidence: low\n```\n\nFile v1.0.2:references/subagents.md\n\n# Subagent model\n\nUse subagents to increase coverage, not to spray writes across the vault.\n\nUse them mainly to reduce context pressure on larger vault sections.\n\nRead `output-format.md` when the results of multiple subagents will later be merged.\n\n## Context control principle\n\n- give each subagent one bounded slice only\n- prefer folder, topic, or queue scoped context over broad vault dumps\n- keep the main agent as the only place where cross-slice decisions are merged\n- if two slices might conflict, review them serially in the main agent\n- do not fork the whole parent transcript unless the task truly needs it\n- treat sensitive findings as provisional until the main agent reads the exact source note\n\n## Safe roles\n\n### `inventory-agent`\nRead-only. Enumerate notes, folders, duplicates, missing metadata, and likely clusters.\n\n### `classifier-agent`\nRead-only. Suggest `status`, `doc_kind`, canonical candidates, and ambiguity flags.\n\n### `curation-reviewer`\nRead-only. Challenge the proposed classification and look for contradictions.\n\n### `link-verifier`\nRead-only. Check wikilinks, backlinks, and likely breakage before or after moves.\n\n### `migration-planner`\nRead-only. Propose a write slice as a structured list of changes in the reply only. Do not create or modify files.\n\n## Required return shape\n\nUnless the parent task explicitly requests another format, return:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nIf confidence is mixed, say so explicitly note by note.\n\n## Recommended context packets\n\n### `inventory-agent`\n- target folder or note list\n- current hub page if one exists\n- status schema only\n\n### `classifier-agent`\n- inventory summary\n- note excerpts or a bounded note list\n- classification rubric only\n\n### `curation-reviewer`\n- proposed classifications\n- canonical candidates\n- contradictions or ambiguity list\n- possible sensitive findings labeled explicitly as `unverified`\n\n### `link-verifier`\n- affected note paths\n- rename or move proposal\n- no extra vault history unless links are ambiguous\n\n### `migration-planner`\n- merged findings from main agent\n- write-slice size limit\n- risk notes and review gates\n\n## Write policy\n\n- Keep writes in the main agent unless the user has explicitly approved writes from one specific named subagent for this task.\n- Never run multiple writing agents in parallel.\n- Never let subagents delete notes by default.\n- Treat renames and moves as write operations.\n- Never let a subagent-triggered secret warning cause edits by itself; the main agent must verify the exact note content first.\n\n## Delegation pattern\n\n1. main agent defines scope\n2. main agent cuts the scope into bounded slices\n3. read-only subagents inspect in parallel if helpful\n4. main agent merges findings\n5. main agent proposes a small write slice\n6. human reviews if needed\n7. main agent applies and verifies\n\n## Large-area pattern\n\nFor a broad area such as `40 Public Agent` or a whole topic tree:\n\n1. run inventory on the parent slice\n2. split into 3-8 child slices by topic or folder\n3. send only one child slice per subagent\n4. collect classifications and contradiction flags\n5. choose one child slice for actual writing\n6. verify before moving to the next slice\n\n## Good use cases\n\n- large folder triage\n- duplicate detection\n- metadata gap detection\n- cross-checking classification confidence\n- broad-section triage with bounded child slices\n- reducing context load before a migration wave\n- flagging possible sensitive content for later main-agent verification\n\n## Bad use cases\n\n- parallel note rewrites\n- uncontrolled bulk frontmatter edits\n- whole-vault moves in one pass\n- autonomous cleanup without review gates\n\nFile v1.0.2:references/workflow.md\n\n# Workflow\n\nUse this workflow for non-trivial vault curation.\n\n## Phase 1: Inventory\n\n- define the exact folder, topic, or note set\n- list candidate notes\n- identify hubs, duplicates, and likely stale pages\n- note existing metadata patterns before proposing a new schema\n\n## Phase 2: Classification\n\n- assign or propose `doc_kind`\n- assign or propose `status`\n- identify canonical candidates\n- identify pages that need `superseded_by` or `supersedes`\n- keep uncertain notes in `needs-review`\n\n## Phase 3: Review design\n\nPrepare a concise review summary:\n\n- what should become leading\n- what should remain historical\n- what is concept only\n- what can stay dormant but discoverable\n- what must be checked live before writing\n- which possible secrets, credentials, tokens, or live identifiers flagged by a subagent are still only hypotheses and need main-agent verification\n\n## Phase 4: Migration plan\n\nCreate the smallest safe write slice.\n\nBefore approving a write slice, verify each of these:\n\n- Metadata slice = frontmatter or tag edits only. Structural slice = renames, moves, or new index/canonical pages. Content-rewrite slice = changes to note body prose.\n- Is this a metadata slice, a structural slice, or a content-rewrite slice?\n- Can the slice stay within one topic cluster?\n- Would a wrong classification be cheaply reversible?\n- Does any possible secret, credential, token, or live identifier flagged by a subagent still need main-agent verification?\n\nGood write slices:\n- add frontmatter to 3-10 related notes\n- create one index page\n- add supersession links in one topic cluster\n- rename or move 3-10 notes within one topic cluster after links are understood\n\nAvoid combining these in one step:\n- broad rewrites\n- large folder moves\n- metadata normalization across the whole vault\n- content consolidation plus structure changes plus deletes\n- classification plus rename plus rewrite of the same notes\n\n## Phase 5: Controlled writes\n\nAfter approval, and before changing files:\n\n1. verify any claimed secrets, credentials, tokens, or live identifiers against the exact note text\n2. change one slice\n3. inspect the diff\n4. verify links\n5. verify frontmatter consistency\n6. reassess the next slice\n\n## Preferred order of operations\n\n1. classify\n2. create or confirm canonical pages\n3. add supersession metadata\n4. create review dashboards or indexes\n5. move or rename if structure still hurts\n6. rewrite content only where needed\n\n## What not to do\n\n- do not delete by default\n- do not compress historical and current content into one blob\n- do not let multiple agents write at once\n- do not change `.obsidian/` or attachments unless the user asked\n- do not invent certainty for unclear notes\n\nArchive v1.0.1: 12 files, 18127 bytes\n\nFiles: references/bases-views.md (1204b), references/classification-rubric.md (3209b), references/output-format.md (1979b), references/status-schema.md (2320b), references/subagents.md (3746b), references/workflow.md (2702b), scripts/check_links.py (2451b), scripts/generate_migration_plan.py (3208b), scripts/inventory_slice.py (5560b), scripts/validate_frontmatter.py (4036b), SKILL.md (8899b), _meta.json (141b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: obsidian-vault-curator\ndescription: Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classify notes, define canonical reference pages, separate current vs historical vs future-state material, design review dashboards or Bases views, or plan safe cleanup and migration without losing historical context. This skill requires installed Python 3 on PATH.\nmetadata:\n  openclaw:\n    emoji: \"🗂️\"\n    requires:\n      bins: [\"python3\"]\n    install:\n      - id: brew-python\n        kind: brew\n        formula: python\n        bins: [\"python3\"]\n        label: \"Install Python 3 (brew)\"\n        os: [\"darwin\"]\n---\n\n# Obsidian Vault Curator\n\nBring structure to a messy Obsidian vault without flattening its history. Start with read-only analysis. Then propose one small, reviewable write slice.\n\n## Runtime requirement\n\nThis skill declares `python3` on `PATH` as a host requirement.\n\n- The requirement is surfaced in metadata as `requires.bins: [\"python3\"]`.\n- On macOS, the metadata includes a Homebrew install hint.\n- On Linux, install Python 3 with your distro package manager, for example `sudo apt install python3`, then verify `python3 --version`.\n- On Windows, install Python from the official Python Install Manager or with `winget install Python.Python.3.14`, then open a new terminal and verify that `python3 --version` works. If only `python` works, add a `python3` alias or shim on `PATH` before using this skill.\n- The bundled helper scripts in `scripts/` use only the Python standard library.\n- No extra Python packages are required.\n- No exact minor version is currently pinned. The helpers were validated with Python 3.11+ and tested locally on macOS against Python `3.14.4`.\n- Windows support is documented, but the full workflow has not yet been live-validated on Windows.\n\n## Core rules\n\n- Default to read-only.\n- Never delete notes unless the user explicitly asks.\n- Never rewrite more than one write slice at a time. A write slice should stay within 3-10 related notes. Multiple-slice content rewrites in one pass count as mass-rewrite and require explicit user approval.\n- Never run parallel write agents.\n- Treat findings of possible secrets, credentials, tokens, or live identifiers as hypotheses until the main agent verifies the exact note content.\n- Prefer `superseded_by` over overwrite.\n- Preserve historical context.\n- Treat `doc_kind` and `status` as separate concerns.\n- Prefer controlled YAML frontmatter over ad-hoc tags for lifecycle state.\n- Verify links and metadata after each write slice.\n\n## Subagent policy\n\n- Default subagent model: match the main agent model when possible.\n- Prefer `openai-codex/gpt-5.4-mini` for inventory, frontmatter checks, link checks, and small classification slices.\n- Escalate the whole job to a stronger model only when the slice is genuinely ambiguous, contradictory, or spans multiple clusters.\n- Do not use subagents for deletes, moves, renames, write slices, or exact-text verification of possibly sensitive material.\n- Treat subagent findings as candidates only; verify the exact note text in the main agent before any write.\n- Do not mix models within one slice unless there is a clear reason.\n- For broader areas, follow `references/subagents.md`: one bounded slice per subagent, read-only by default, and merge results only in the main agent.\n- Prefer the named roles from `references/subagents.md` (`inventory-agent`, `classifier-agent`, `curation-reviewer`, `link-verifier`, `migration-planner`) instead of ad-hoc subagent prompts.\n- Keep the required return shape from `references/subagents.md` unless the parent task explicitly asks otherwise.\n\n## Workflow\n\n1. Always read `references/status-schema.md` and `references/classification-rubric.md` before classifying any note, including a single-note task.\n2. If the task touches more than a few notes or spans more than one folder, read `references/workflow.md`.\n3. If the user wants dashboards or views, read `references/bases-views.md`.\n4. If the target area is too large for one context-bounded pass, read `references/subagents.md`. Keep subagents read-only by default. Keep writes in the main agent unless the user has explicitly approved writes from one specific named subagent for this task.\n5. If findings need to be merged across slices or reviewed by a human, read `references/output-format.md`.\n6. For larger areas, split the work into context-bounded slices by folder, topic cluster, or review queue instead of loading the whole vault at once.\n7. Inventory the target area before proposing edits. Use `scripts/inventory_slice.py` when repeated folder scans would otherwise waste context.\n8. Suggest canonical pages, status changes, supersession links, and the smallest safe write slice. Use `scripts/generate_migration_plan.py` with the JSON output of `scripts/inventory_slice.py` when the user wants a structured migration slice proposal.\n9. Before structural writes and after every write slice, verify metadata with `scripts/validate_frontmatter.py`, verify links with `scripts/check_links.py`, and reassess whether the chosen canonical pages still make sense.\n\n## Output shape\n\nWhen curating a vault area, return these sections unless the user asks for a different format:\n\nUse this shape for a single-pass curation reply. Use the subagent shape from `references/output-format.md` when running as a subagent. Use the final main-agent summary shape from `references/output-format.md` only when merging results from multiple subagent slices.\n\n1. `Current state` — what exists now, including ambiguity or conflicts.\n2. `Classification recommendations` — suggested `status`, `doc_kind`, and canonical candidates.\n3. `Risks and contradictions` — what could be damaged, misclassified, contradictory, or is still unverified.\n4. `Next write slice` — the smallest safe set of edits.\n5. `Verification` — what to check after changes.\n\n## Decision rules\n\n- If a note is still useful but no longer leading, mark it `historical` and point to a successor.\n- If a note describes a desired future state, mark `status: concept` and choose `doc_kind` separately.\n- If validity is unclear, mark it `needs-review` first instead of guessing.\n- If an old note may become useful again, prefer `reactivatable` over burying it.\n- If multiple notes cover the same topic, nominate one canonical page and propose the rest as supporting or historical pages.\n- If the vault already has a schema, adapt to it instead of forcing a new one.\n- If a subagent flags possible secrets, credentials, tokens, or live identifiers, verify the exact text in the main agent before escalating or editing.\n\n## Safe operating mode\n\nUse small, reviewable steps:\n\n- classify before moving or merging\n- move before rewriting when structure is the real problem\n- create indexes and canonical pages before cleanup\n- keep historical pages reachable\n- ask before touching attachments, `.obsidian/`, or folder restructures that touch more than one folder or more than 10 notes\n\n## Built-in helpers (require installed `python3`)\n\nIf `python3` is unavailable, the bundled helper scripts cannot run. Continue with the manual workflow and do not pretend a helper script ran.\n\n- `scripts/inventory_slice.py` — scan one vault slice and summarize note counts, missing metadata, status/doc_kind coverage, title duplicates, exact-content duplicate clusters, and high-signal sensitive candidates that still require main-agent verification.\n- `scripts/validate_frontmatter.py` — verify the controlled frontmatter shape on one slice before or after edits.\n- `scripts/generate_migration_plan.py` — turn the JSON output of `scripts/inventory_slice.py` into a small, reviewable migration plan.\n- `scripts/check_links.py` — inspect wikilinks in one slice and flag unresolved targets before or after moves. Treat results as slice-local unless the checked slice includes every possible target note.\n\n## Large-section strategy\n\nWhen the user wants work on a broader vault area:\n\n1. keep one main agent as orchestrator\n2. split the area into bounded slices\n3. use read-only subagents for inventory, classification, contradiction checks, and link review\n4. merge findings in the main agent\n5. execute one write slice at a time in the main agent\n\nPrefer this over giving one agent the whole vault context at once.\n\n## References\n\n- `references/status-schema.md` — controlled fields, values, and examples\n- `references/classification-rubric.md` — note-by-note classification heuristics\n- `references/workflow.md` — end-to-end curation and migration flow\n- `references/bases-views.md` — suggested Bases views and review queues\n- `references/subagents.md` — safe delegation model for larger vault jobs\n- `references/output-format.md` — standard subagent return shape, merge rules, and human-review gates\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn7dzka1n2vjb8wgzt8v4xrych82ph5f\",\n  \"slug\": \"obsidian-vault-curator\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1778711010907\n}\n\nFile v1.0.1:references/bases-views.md\n\n# Bases and review views\n\nUse Bases or equivalent review lists as the control plane for curation.\n\n## Recommended views\n\n### Vault Inbox\nShow notes missing `status` or `doc_kind`.\n\n### Needs Review\nShow notes where:\n\n- `status = needs-review`, or\n- `review_state = conflict`\n\n### Canonical Pages\nShow notes where:\n\n- `canonical = true`\n\ngroup by `topic`.\n\n### Historical but linked\nShow notes where:\n\n- `status = historical`\n- and the note still has meaningful inbound links\n\n### Concept / future state\nShow notes where:\n\n- `status = concept`\n\n### Reactivatable\nShow notes where:\n\n- `status = reactivatable`\n\n### Supersession gaps\nShow notes where:\n\n- `status = historical`\n- and `superseded_by` is empty\n\n### Stale current docs\nShow notes where:\n\n- `status = current`\n- and `last_verified` is older than 90 days or missing\n\n### Research not integrated\nShow notes where:\n\n- `doc_kind = research`\n- and no canonical page links to them\n\n## Practical guidance\n\n- Keep the first dashboard small and obvious.\n- Start with visibility, not automation.\n- Prefer a handful of high-signal views over a huge taxonomy.\n- If Bases is not available, propose manual indexes or search-driven lists as equivalent queues.\n\nFile v1.0.1:references/classification-rubric.md\n\n# Classification rubric\n\nClassify one note at a time. Prefer explicit uncertainty over confident mislabeling.\n\n## Step 1: Determine `doc_kind`\n\nAsk what the note is trying to be:\n\n- `reference` — source of truth, stable facts, config, paths, commands\n- `howto` — procedure to achieve a task\n- `explanation` — why something works, tradeoffs, reasoning\n- `tutorial` — guided learning sequence\n- `research` — collected findings, comparisons, external material\n- `adr` — a decision with context and consequences\n- `log` — diary, changelog, working notes, progress trail\n- `index` — hub page or navigation page\n- `concept` — target design or future plan\n\n## Step 2: Determine `status`\n\n### `current`\nUse when the note is still valid and should be trusted now.\nSignals:\n- verified paths, commands, hostnames, versions, or architecture\n- actively referenced from current hub pages\n- clearly reflects the live environment\n\n### `historical`\nUse when the note is not current but still valuable.\nSignals:\n- documents a previous setup, migration path, or decision history\n- useful for recovery, comparison, or context\n- replaced by a newer page\n\n### `concept`\nUse when the note describes a desired future state.\nSignals:\n- signal words in the title or opening section, in German or English, such as Zielbild, Soll, Plan, Proposal, Vision, target state, draft, or future state\n- contains intended rather than verified state\n\n### `needs-review`\nUse when status is unclear.\nSignals:\n- mixed old and new facts\n- no verification date\n- conflicts with better evidence\n- unclear whether the note is still active\n\n### `reactivatable`\nUse when the note is dormant but likely reusable.\nSignals:\n- currently inactive workflow or system\n- likely to return later\n- should stay discoverable without being treated as live\n\n## Canonical page test\n\nA note is a good canonical candidate when most of these are true:\n\n- it has the clearest scope for a topic\n- it is easier to update than the alternatives\n- it already attracts links or should attract them\n- it can safely point outward to detail pages\n- it is not mostly historical baggage\n\nIf no note qualifies, propose creating a small new index or reference page instead of forcing a bad canonical page.\n\n## Supersession rules\n\n- Do not erase old context when a new page replaces it.\n- Mark older pages with `superseded_by`.\n- Mark the new leading page with `supersedes`.\n- Prefer short transition notes over giant merge rewrites.\n\n## Conflict handling\n\nWhen two notes disagree:\n\n1. trust live evidence over prose\n2. trust the note with recent verification over the undated one\n3. downgrade uncertain notes to `needs-review`\n4. do not silently merge contradictions away\n5. if a note appears to contain possible secrets, credentials, tokens, or live identifiers, flag it as a `needs-review` candidate until the main agent verifies the exact text\n\n## Smell list\n\nBe careful when a note contains:\n\n- old hostnames, paths, containers, or OS assumptions\n- ambiguous words like \"current\", \"latest\", \"new\" without a date\n- copied research without integration into a leading page\n- multiple unrelated topics in one note\n- operational instructions mixed with speculative design\n\nFile v1.0.1:references/output-format.md\n\n# Output and merge format\n\nUse one compact format so subagent findings are mergeable.\n\nUse the required subagent sections below only for subagent replies. Use the SKILL.md output shape for a single-pass main-agent curation reply. Use the final main-agent summary shape below only when merging results from multiple subagent slices.\n\n## Required subagent sections\n\nReturn these sections in this order:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nKeep each section short and concrete.\n\n## Preferred note-level fields\n\nWhen naming important notes, prefer this shape:\n\n- `Path or note name`\n- `doc_kind`\n- `status`\n- `canonical` yes/no when relevant\n- short reason\n- optional `confidence: low|medium|high`\n\n## Sensitive findings\n\nIf a subagent suspects possible secrets, credentials, tokens, or live identifiers:\n\n- label it `unverified`\n- reference only the note path and field name; do not quote the sensitive value\n- do not recommend edits as if the finding were confirmed\n- require main-agent verification against exact note text\n\n## Merge rules for the main agent\n\nWhen merging child-slice results:\n\n1. prefer compact summaries over repeating every detail, but keep disagreements visible\n2. surface disagreements explicitly\n3. downgrade contested notes to `needs-review`\n4. separate confirmed facts from hypotheses\n5. separate structural actions from content rewrite actions\n\n## Human-review gates\n\nEscalate to explicit human review before:\n\n- deleting notes\n- broad moves or renames\n- editing notes after only inferred classification\n- acting on possible secrets or credentials\n- collapsing multiple competing pages into one canonical page without clear evidence\n\n## Final main-agent summary shape\n\nWhen reporting merged results back after a multi-slice pass, prefer:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nFile v1.0.1:references/status-schema.md\n\n# Status schema\n\nUse a small controlled schema. Expand only when repeated real use shows a gap.\n\n## Core fields\n\n```yaml\nstatus: needs-review\ndoc_kind: reference\ntopic:\ncanonical: false\ncanonical_for: []\nsupersedes: []\nsuperseded_by: []\nlast_verified:\nreview_after:\nreview_state: unreviewed\nconfidence: low\n```\n\n## Allowed values\n\n### `status`\n\n- `current` — currently valid or leading\n- `historical` — no longer leading, but still worth keeping\n- `concept` — target state, proposal, idea, or design direction\n- `needs-review` — unclear, conflicting, or not yet checked\n- `reactivatable` — not active now, but likely worth reviving later\n\n### `doc_kind`\n\n- `reference`\n- `howto`\n- `explanation`\n- `tutorial`\n- `research`\n- `adr`\n- `log`\n- `index`\n- `concept`\n\nNote: `concept` exists in both lists on purpose. `status: concept` means the note describes a future state. `doc_kind: concept` describes its writing genre. They are independent.\n\n### `review_state`\n\n- `unreviewed`\n- `reviewed`\n- `conflict`\n- `migrate-plan-ready`\n- `migrated`\n\n### `confidence`\n\n- `low`\n- `medium`\n- `high`\n\n## Rules\n\n- Keep `status` separate from `doc_kind`.\n- When ambiguity matters in prose, name the field explicitly, for example `status: concept`.\n- Prefer one canonical page per topic cluster.\n- Use `superseded_by` on old pages and `supersedes` on the new leading page.\n- If you cannot justify `current`, use `needs-review` first.\n- If dates matter, write real dates instead of vague words like \"latest\".\n\n## Examples\n\n### Current reference page\n\n```yaml\nstatus: current\ndoc_kind: reference\ntopic: openclaw\ncanonical: true\ncanonical_for:\n  - OpenClaw Runtime\nlast_verified: 2026-05-11\nreview_state: reviewed\nconfidence: high\n```\n\n### Historical page preserved for context\n\n```yaml\nstatus: historical\ndoc_kind: howto\ntopic: openclaw\nsuperseded_by:\n  - \"[[OpenClaw Runtime & Konfiguration]]\"\nreview_state: reviewed\nconfidence: medium\n```\n\n### Future-state note\n\n```yaml\nstatus: concept\ndoc_kind: explanation\ntopic: yuna-public\nreview_state: unreviewed\nconfidence: medium\n```\n\n`status` and `doc_kind` are independent. A future-state note can also use `doc_kind: concept` when that is the best fit.\n\n### Unclear note waiting for triage\n\n```yaml\nstatus: needs-review\ndoc_kind: research\nreview_state: unreviewed\nconfidence: low\n```\n\nFile v1.0.1:references/subagents.md\n\n# Subagent model\n\nUse subagents to increase coverage, not to spray writes across the vault.\n\nUse them mainly to reduce context pressure on larger vault sections.\n\nRead `output-format.md` when the results of multiple subagents will later be merged.\n\n## Context control principle\n\n- give each subagent one bounded slice only\n- prefer folder, topic, or queue scoped context over broad vault dumps\n- keep the main agent as the only place where cross-slice decisions are merged\n- if two slices might conflict, review them serially in the main agent\n- do not fork the whole parent transcript unless the task truly needs it\n- treat sensitive findings as provisional until the main agent reads the exact source note\n\n## Safe roles\n\n### `inventory-agent`\nRead-only. Enumerate notes, folders, duplicates, missing metadata, and likely clusters.\n\n### `classifier-agent`\nRead-only. Suggest `status`, `doc_kind`, canonical candidates, and ambiguity flags.\n\n### `curation-reviewer`\nRead-only. Challenge the proposed classification and look for contradictions.\n\n### `link-verifier`\nRead-only. Check wikilinks, backlinks, and likely breakage before or after moves.\n\n### `migration-planner`\nRead-only. Propose a write slice as a structured list of changes in the reply only. Do not create or modify files.\n\n## Required return shape\n\nUnless the parent task explicitly requests another format, return:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nIf confidence is mixed, say so explicitly note by note.\n\n## Recommended context packets\n\n### `inventory-agent`\n- target folder or note list\n- current hub page if one exists\n- status schema only\n\n### `classifier-agent`\n- inventory summary\n- note excerpts or a bounded note list\n- classification rubric only\n\n### `curation-reviewer`\n- proposed classifications\n- canonical candidates\n- contradictions or ambiguity list\n- possible sensitive findings labeled explicitly as `unverified`\n\n### `link-verifier`\n- affected note paths\n- rename or move proposal\n- no extra vault history unless links are ambiguous\n\n### `migration-planner`\n- merged findings from main agent\n- write-slice size limit\n- risk notes and review gates\n\n## Write policy\n\n- Keep writes in the main agent unless the user has explicitly approved writes from one specific named subagent for this task.\n- Never run multiple writing agents in parallel.\n- Never let subagents delete notes by default.\n- Treat renames and moves as write operations.\n- Never let a subagent-triggered secret warning cause edits by itself; the main agent must verify the exact note content first.\n\n## Delegation pattern\n\n1. main agent defines scope\n2. main agent cuts the scope into bounded slices\n3. read-only subagents inspect in parallel if helpful\n4. main agent merges findings\n5. main agent proposes a small write slice\n6. human reviews if needed\n7. main agent applies and verifies\n\n## Large-area pattern\n\nFor a broad area such as `40 Public Agent` or a whole topic tree:\n\n1. run inventory on the parent slice\n2. split into 3-8 child slices by topic or folder\n3. send only one child slice per subagent\n4. collect classifications and contradiction flags\n5. choose one child slice for actual writing\n6. verify before moving to the next slice\n\n## Good use cases\n\n- large folder triage\n- duplicate detection\n- metadata gap detection\n- cross-checking classification confidence\n- broad-section triage with bounded child slices\n- reducing context load before a migration wave\n- flagging possible sensitive content for later main-agent verification\n\n## Bad use cases\n\n- parallel note rewrites\n- uncontrolled bulk frontmatter edits\n- whole-vault moves in one pass\n- autonomous cleanup without review gates\n\nFile v1.0.1:references/workflow.md\n\n# Workflow\n\nUse this workflow for non-trivial vault curation.\n\n## Phase 1: Inventory\n\n- define the exact folder, topic, or note set\n- list candidate notes\n- identify hubs, duplicates, and likely stale pages\n- note existing metadata patterns before proposing a new schema\n\n## Phase 2: Classification\n\n- assign or propose `doc_kind`\n- assign or propose `status`\n- identify canonical candidates\n- identify pages that need `superseded_by` or `supersedes`\n- keep uncertain notes in `needs-review`\n\n## Phase 3: Review design\n\nPrepare a concise review summary:\n\n- what should become leading\n- what should remain historical\n- what is concept only\n- what can stay dormant but discoverable\n- what must be checked live before writing\n- which possible secrets, credentials, tokens, or live identifiers flagged by a subagent are still only hypotheses and need main-agent verification\n\n## Phase 4: Migration plan\n\nCreate the smallest safe write slice.\n\nBefore approving a write slice, verify each of these:\n\n- Metadata slice = frontmatter or tag edits only. Structural slice = renames, moves, or new index/canonical pages. Content-rewrite slice = changes to note body prose.\n- Is this a metadata slice, a structural slice, or a content-rewrite slice?\n- Can the slice stay within one topic cluster?\n- Would a wrong classification be cheaply reversible?\n- Does any possible secret, credential, token, or live identifier flagged by a subagent still need main-agent verification?\n\nGood write slices:\n- add frontmatter to 3-10 related notes\n- create one index page\n- add supersession links in one topic cluster\n- rename or move 3-10 notes within one topic cluster after links are understood\n\nAvoid combining these in one step:\n- broad rewrites\n- large folder moves\n- metadata normalization across the whole vault\n- content consolidation plus structure changes plus deletes\n- classification plus rename plus rewrite of the same notes\n\n## Phase 5: Controlled writes\n\nAfter approval, and before changing files:\n\n1. verify any claimed secrets, credentials, tokens, or live identifiers against the exact note text\n2. change one slice\n3. inspect the diff\n4. verify links\n5. verify frontmatter consistency\n6. reassess the next slice\n\n## Preferred order of operations\n\n1. classify\n2. create or confirm canonical pages\n3. add supersession metadata\n4. create review dashboards or indexes\n5. move or rename if structure still hurts\n6. rewrite content only where needed\n\n## What not to do\n\n- do not delete by default\n- do not compress historical and current content into one blob\n- do not let multiple agents write at once\n- do not change `.obsidian/` or attachments unless the user asked\n- do not invent certainty for unclear notes\n\nArchive v1.0.0: 12 files, 17757 bytes\n\nFiles: references/bases-views.md (1204b), references/classification-rubric.md (3209b), references/output-format.md (1979b), references/status-schema.md (2320b), references/subagents.md (3746b), references/workflow.md (2702b), scripts/check_links.py (2451b), scripts/generate_migration_plan.py (3208b), scripts/inventory_slice.py (5560b), scripts/validate_frontmatter.py (4036b), SKILL.md (7801b), _meta.json (141b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: obsidian-vault-curator\ndescription: Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classify notes, define canonical reference pages, separate current vs historical vs future-state material, design review dashboards or Bases views, or plan safe cleanup and migration without losing historical context. This skill requires installed Python 3 on PATH.\nmetadata:\n  openclaw:\n    emoji: \"🗂️\"\n    requires:\n      bins: [\"python3\"]\n    install:\n      - id: brew-python\n        kind: brew\n        formula: python\n        bins: [\"python3\"]\n        label: \"Install Python 3 (brew)\"\n        os: [\"darwin\"]\n---\n\n# Obsidian Vault Curator\n\nBring structure to a messy Obsidian vault without flattening its history. Start with read-only analysis. Then propose one small, reviewable write slice.\n\n## Runtime requirement\n\nThis skill declares `python3` on `PATH` as a host requirement.\n\n- The requirement is surfaced in metadata as `requires.bins: [\"python3\"]`.\n- On macOS, the metadata includes a Homebrew install hint.\n- On Linux, install Python 3 with your distro package manager, for example `sudo apt install python3`, then verify `python3 --version`.\n- On Windows, install Python from the official Python Install Manager or with `winget install Python.Python.3.14`, then open a new terminal and verify that `python3 --version` works. If only `python` works, add a `python3` alias or shim on `PATH` before using this skill.\n- The bundled helper scripts in `scripts/` use only the Python standard library.\n- No extra Python packages are required.\n- No exact minor version is currently pinned. The helpers were validated with Python 3.11+ and tested locally on macOS against Python `3.14.4`.\n- Windows support is documented, but the full workflow has not yet been live-validated on Windows.\n\n## Core rules\n\n- Default to read-only.\n- Never delete notes unless the user explicitly asks.\n- Never rewrite more than one write slice at a time. A write slice should stay within 3-10 related notes. Multiple-slice content rewrites in one pass count as mass-rewrite and require explicit user approval.\n- Never run parallel write agents.\n- Treat findings of possible secrets, credentials, tokens, or live identifiers as hypotheses until the main agent verifies the exact note content.\n- Prefer `superseded_by` over overwrite.\n- Preserve historical context.\n- Treat `doc_kind` and `status` as separate concerns.\n- Prefer controlled YAML frontmatter over ad-hoc tags for lifecycle state.\n- Verify links and metadata after each write slice.\n\n## Workflow\n\n1. Always read `references/status-schema.md` and `references/classification-rubric.md` before classifying any note, including a single-note task.\n2. If the task touches more than a few notes or spans more than one folder, read `references/workflow.md`.\n3. If the user wants dashboards or views, read `references/bases-views.md`.\n4. If the target area is too large for one context-bounded pass, read `references/subagents.md`. Keep subagents read-only by default. Keep writes in the main agent unless the user has explicitly approved writes from one specific named subagent for this task.\n5. If findings need to be merged across slices or reviewed by a human, read `references/output-format.md`.\n6. For larger areas, split the work into context-bounded slices by folder, topic cluster, or review queue instead of loading the whole vault at once.\n7. Inventory the target area before proposing edits. Use `scripts/inventory_slice.py` when repeated folder scans would otherwise waste context.\n8. Suggest canonical pages, status changes, supersession links, and the smallest safe write slice. Use `scripts/generate_migration_plan.py` with the JSON output of `scripts/inventory_slice.py` when the user wants a structured migration slice proposal.\n9. Before structural writes and after every write slice, verify metadata with `scripts/validate_frontmatter.py`, verify links with `scripts/check_links.py`, and reassess whether the chosen canonical pages still make sense.\n\n## Output shape\n\nWhen curating a vault area, return these sections unless the user asks for a different format:\n\nUse this shape for a single-pass curation reply. Use the subagent shape from `references/output-format.md` when running as a subagent. Use the final main-agent summary shape from `references/output-format.md` only when merging results from multiple subagent slices.\n\n1. `Current state` — what exists now, including ambiguity or conflicts.\n2. `Classification recommendations` — suggested `status`, `doc_kind`, and canonical candidates.\n3. `Risks and contradictions` — what could be damaged, misclassified, contradictory, or is still unverified.\n4. `Next write slice` — the smallest safe set of edits.\n5. `Verification` — what to check after changes.\n\n## Decision rules\n\n- If a note is still useful but no longer leading, mark it `historical` and point to a successor.\n- If a note describes a desired future state, mark `status: concept` and choose `doc_kind` separately.\n- If validity is unclear, mark it `needs-review` first instead of guessing.\n- If an old note may become useful again, prefer `reactivatable` over burying it.\n- If multiple notes cover the same topic, nominate one canonical page and propose the rest as supporting or historical pages.\n- If the vault already has a schema, adapt to it instead of forcing a new one.\n- If a subagent flags possible secrets, credentials, tokens, or live identifiers, verify the exact text in the main agent before escalating or editing.\n\n## Safe operating mode\n\nUse small, reviewable steps:\n\n- classify before moving or merging\n- move before rewriting when structure is the real problem\n- create indexes and canonical pages before cleanup\n- keep historical pages reachable\n- ask before touching attachments, `.obsidian/`, or folder restructures that touch more than one folder or more than 10 notes\n\n## Built-in helpers (require installed `python3`)\n\nIf `python3` is unavailable, the bundled helper scripts cannot run. Continue with the manual workflow and do not pretend a helper script ran.\n\n- `scripts/inventory_slice.py` — scan one vault slice and summarize note counts, missing metadata, status/doc_kind coverage, title duplicates, exact-content duplicate clusters, and high-signal sensitive candidates that still require main-agent verification.\n- `scripts/validate_frontmatter.py` — verify the controlled frontmatter shape on one slice before or after edits.\n- `scripts/generate_migration_plan.py` — turn the JSON output of `scripts/inventory_slice.py` into a small, reviewable migration plan.\n- `scripts/check_links.py` — inspect wikilinks in one slice and flag unresolved targets before or after moves. Treat results as slice-local unless the checked slice includes every possible target note.\n\n## Large-section strategy\n\nWhen the user wants work on a broader vault area:\n\n1. keep one main agent as orchestrator\n2. split the area into bounded slices\n3. use read-only subagents for inventory, classification, contradiction checks, and link review\n4. merge findings in the main agent\n5. execute one write slice at a time in the main agent\n\nPrefer this over giving one agent the whole vault context at once.\n\n## References\n\n- `references/status-schema.md` — controlled fields, values, and examples\n- `references/classification-rubric.md` — note-by-note classification heuristics\n- `references/workflow.md` — end-to-end curation and migration flow\n- `references/bases-views.md` — suggested Bases views and review queues\n- `references/subagents.md` — safe delegation model for larger vault jobs\n- `references/output-format.md` — standard subagent return shape, merge rules, and human-review gates\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn7dzka1n2vjb8wgzt8v4xrych82ph5f\",\n  \"slug\": \"obsidian-vault-curator\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1778600808492\n}\n\nFile v1.0.0:references/bases-views.md\n\n# Bases and review views\n\nUse Bases or equivalent review lists as the control plane for curation.\n\n## Recommended views\n\n### Vault Inbox\nShow notes missing `status` or `doc_kind`.\n\n### Needs Review\nShow notes where:\n\n- `status = needs-review`, or\n- `review_state = conflict`\n\n### Canonical Pages\nShow notes where:\n\n- `canonical = true`\n\ngroup by `topic`.\n\n### Historical but linked\nShow notes where:\n\n- `status = historical`\n- and the note still has meaningful inbound links\n\n### Concept / future state\nShow notes where:\n\n- `status = concept`\n\n### Reactivatable\nShow notes where:\n\n- `status = reactivatable`\n\n### Supersession gaps\nShow notes where:\n\n- `status = historical`\n- and `superseded_by` is empty\n\n### Stale current docs\nShow notes where:\n\n- `status = current`\n- and `last_verified` is older than 90 days or missing\n\n### Research not integrated\nShow notes where:\n\n- `doc_kind = research`\n- and no canonical page links to them\n\n## Practical guidance\n\n- Keep the first dashboard small and obvious.\n- Start with visibility, not automation.\n- Prefer a handful of high-signal views over a huge taxonomy.\n- If Bases is not available, propose manual indexes or search-driven lists as equivalent queues.\n\nFile v1.0.0:references/classification-rubric.md\n\n# Classification rubric\n\nClassify one note at a time. Prefer explicit uncertainty over confident mislabeling.\n\n## Step 1: Determine `doc_kind`\n\nAsk what the note is trying to be:\n\n- `reference` — source of truth, stable facts, config, paths, commands\n- `howto` — procedure to achieve a task\n- `explanation` — why something works, tradeoffs, reasoning\n- `tutorial` — guided learning sequence\n- `research` — collected findings, comparisons, external material\n- `adr` — a decision with context and consequences\n- `log` — diary, changelog, working notes, progress trail\n- `index` — hub page or navigation page\n- `concept` — target design or future plan\n\n## Step 2: Determine `status`\n\n### `current`\nUse when the note is still valid and should be trusted now.\nSignals:\n- verified paths, commands, hostnames, versions, or architecture\n- actively referenced from current hub pages\n- clearly reflects the live environment\n\n### `historical`\nUse when the note is not current but still valuable.\nSignals:\n- documents a previous setup, migration path, or decision history\n- useful for recovery, comparison, or context\n- replaced by a newer page\n\n### `concept`\nUse when the note describes a desired future state.\nSignals:\n- signal words in the title or opening section, in German or English, such as Zielbild, Soll, Plan, Proposal, Vision, target state, draft, or future state\n- contains intended rather than verified state\n\n### `needs-review`\nUse when status is unclear.\nSignals:\n- mixed old and new facts\n- no verification date\n- conflicts with better evidence\n- unclear whether the note is still active\n\n### `reactivatable`\nUse when the note is dormant but likely reusable.\nSignals:\n- currently inactive workflow or system\n- likely to return later\n- should stay discoverable without being treated as live\n\n## Canonical page test\n\nA note is a good canonical candidate when most of these are true:\n\n- it has the clearest scope for a topic\n- it is easier to update than the alternatives\n- it already attracts links or should attract them\n- it can safely point outward to detail pages\n- it is not mostly historical baggage\n\nIf no note qualifies, propose creating a small new index or reference page instead of forcing a bad canonical page.\n\n## Supersession rules\n\n- Do not erase old context when a new page replaces it.\n- Mark older pages with `superseded_by`.\n- Mark the new leading page with `supersedes`.\n- Prefer short transition notes over giant merge rewrites.\n\n## Conflict handling\n\nWhen two notes disagree:\n\n1. trust live evidence over prose\n2. trust the note with recent verification over the undated one\n3. downgrade uncertain notes to `needs-review`\n4. do not silently merge contradictions away\n5. if a note appears to contain possible secrets, credentials, tokens, or live identifiers, flag it as a `needs-review` candidate until the main agent verifies the exact text\n\n## Smell list\n\nBe careful when a note contains:\n\n- old hostnames, paths, containers, or OS assumptions\n- ambiguous words like \"current\", \"latest\", \"new\" without a date\n- copied research without integration into a leading page\n- multiple unrelated topics in one note\n- operational instructions mixed with speculative design\n\nFile v1.0.0:references/output-format.md\n\n# Output and merge format\n\nUse one compact format so subagent findings are mergeable.\n\nUse the required subagent sections below only for subagent replies. Use the SKILL.md output shape for a single-pass main-agent curation reply. Use the final main-agent summary shape below only when merging results from multiple subagent slices.\n\n## Required subagent sections\n\nReturn these sections in this order:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nKeep each section short and concrete.\n\n## Preferred note-level fields\n\nWhen naming important notes, prefer this shape:\n\n- `Path or note name`\n- `doc_kind`\n- `status`\n- `canonical` yes/no when relevant\n- short reason\n- optional `confidence: low|medium|high`\n\n## Sensitive findings\n\nIf a subagent suspects possible secrets, credentials, tokens, or live identifiers:\n\n- label it `unverified`\n- reference only the note path and field name; do not quote the sensitive value\n- do not recommend edits as if the finding were confirmed\n- require main-agent verification against exact note text\n\n## Merge rules for the main agent\n\nWhen merging child-slice results:\n\n1. prefer compact summaries over repeating every detail, but keep disagreements visible\n2. surface disagreements explicitly\n3. downgrade contested notes to `needs-review`\n4. separate confirmed facts from hypotheses\n5. separate structural actions from content rewrite actions\n\n## Human-review gates\n\nEscalate to explicit human review before:\n\n- deleting notes\n- broad moves or renames\n- editing notes after only inferred classification\n- acting on possible secrets or credentials\n- collapsing multiple competing pages into one canonical page without clear evidence\n\n## Final main-agent summary shape\n\nWhen reporting merged results back after a multi-slice pass, prefer:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nFile v1.0.0:references/status-schema.md\n\n# Status schema\n\nUse a small controlled schema. Expand only when repeated real use shows a gap.\n\n## Core fields\n\n```yaml\nstatus: needs-review\ndoc_kind: reference\ntopic:\ncanonical: false\ncanonical_for: []\nsupersedes: []\nsuperseded_by: []\nlast_verified:\nreview_after:\nreview_state: unreviewed\nconfidence: low\n```\n\n## Allowed values\n\n### `status`\n\n- `current` — currently valid or leading\n- `historical` — no longer leading, but still worth keeping\n- `concept` — target state, proposal, idea, or design direction\n- `needs-review` — unclear, conflicting, or not yet checked\n- `reactivatable` — not active now, but likely worth reviving later\n\n### `doc_kind`\n\n- `reference`\n- `howto`\n- `explanation`\n- `tutorial`\n- `research`\n- `adr`\n- `log`\n- `index`\n- `concept`\n\nNote: `concept` exists in both lists on purpose. `status: concept` means the note describes a future state. `doc_kind: concept` describes its writing genre. They are independent.\n\n### `review_state`\n\n- `unreviewed`\n- `reviewed`\n- `conflict`\n- `migrate-plan-ready`\n- `migrated`\n\n### `confidence`\n\n- `low`\n- `medium`\n- `high`\n\n## Rules\n\n- Keep `status` separate from `doc_kind`.\n- When ambiguity matters in prose, name the field explicitly, for example `status: concept`.\n- Prefer one canonical page per topic cluster.\n- Use `superseded_by` on old pages and `supersedes` on the new leading page.\n- If you cannot justify `current`, use `needs-review` first.\n- If dates matter, write real dates instead of vague words like \"latest\".\n\n## Examples\n\n### Current reference page\n\n```yaml\nstatus: current\ndoc_kind: reference\ntopic: openclaw\ncanonical: true\ncanonical_for:\n  - OpenClaw Runtime\nlast_verified: 2026-05-11\nreview_state: reviewed\nconfidence: high\n```\n\n### Historical page preserved for context\n\n```yaml\nstatus: historical\ndoc_kind: howto\ntopic: openclaw\nsuperseded_by:\n  - \"[[OpenClaw Runtime & Konfiguration]]\"\nreview_state: reviewed\nconfidence: medium\n```\n\n### Future-state note\n\n```yaml\nstatus: concept\ndoc_kind: explanation\ntopic: yuna-public\nreview_state: unreviewed\nconfidence: medium\n```\n\n`status` and `doc_kind` are independent. A future-state note can also use `doc_kind: concept` when that is the best fit.\n\n### Unclear note waiting for triage\n\n```yaml\nstatus: needs-review\ndoc_kind: research\nreview_state: unreviewed\nconfidence: low\n```\n\nFile v1.0.0:references/subagents.md\n\n# Subagent model\n\nUse subagents to increase coverage, not to spray writes across the vault.\n\nUse them mainly to reduce context pressure on larger vault sections.\n\nRead `output-format.md` when the results of multiple subagents will later be merged.\n\n## Context control principle\n\n- give each subagent one bounded slice only\n- prefer folder, topic, or queue scoped context over broad vault dumps\n- keep the main agent as the only place where cross-slice decisions are merged\n- if two slices might conflict, review them serially in the main agent\n- do not fork the whole parent transcript unless the task truly needs it\n- treat sensitive findings as provisional until the main agent reads the exact source note\n\n## Safe roles\n\n### `inventory-agent`\nRead-only. Enumerate notes, folders, duplicates, missing metadata, and likely clusters.\n\n### `classifier-agent`\nRead-only. Suggest `status`, `doc_kind`, canonical candidates, and ambiguity flags.\n\n### `curation-reviewer`\nRead-only. Challenge the proposed classification and look for contradictions.\n\n### `link-verifier`\nRead-only. Check wikilinks, backlinks, and likely breakage before or after moves.\n\n### `migration-planner`\nRead-only. Propose a write slice as a structured list of changes in the reply only. Do not create or modify files.\n\n## Required return shape\n\nUnless the parent task explicitly requests another format, return:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nIf confidence is mixed, say so explicitly note by note.\n\n## Recommended context packets\n\n### `inventory-agent`\n- target folder or note list\n- current hub page if one exists\n- status schema only\n\n### `classifier-agent`\n- inventory summary\n- note excerpts or a bounded note list\n- classification rubric only\n\n### `curation-reviewer`\n- proposed classifications\n- canonical candidates\n- contradictions or ambiguity list\n- possible sensitive findings labeled explicitly as `unverified`\n\n### `link-verifier`\n- affected note paths\n- rename or move proposal\n- no extra vault history unless links are ambiguous\n\n### `migration-planner`\n- merged findings from main agent\n- write-slice size limit\n- risk notes and review gates\n\n## Write policy\n\n- Keep writes in the main agent unless the user has explicitly approved writes from one specific named subagent for this task.\n- Never run multiple writing agents in parallel.\n- Never let subagents delete notes by default.\n- Treat renames and moves as write operations.\n- Never let a subagent-triggered secret warning cause edits by itself; the main agent must verify the exact note content first.\n\n## Delegation pattern\n\n1. main agent defines scope\n2. main agent cuts the scope into bounded slices\n3. read-only subagents inspect in parallel if helpful\n4. main agent merges findings\n5. main agent proposes a small write slice\n6. human reviews if needed\n7. main agent applies and verifies\n\n## Large-area pattern\n\nFor a broad area such as `40 Public Agent` or a whole topic tree:\n\n1. run inventory on the parent slice\n2. split into 3-8 child slices by topic or folder\n3. send only one child slice per subagent\n4. collect classifications and contradiction flags\n5. choose one child slice for actual writing\n6. verify before moving to the next slice\n\n## Good use cases\n\n- large folder triage\n- duplicate detection\n- metadata gap detection\n- cross-checking classification confidence\n- broad-section triage with bounded child slices\n- reducing context load before a migration wave\n- flagging possible sensitive content for later main-agent verification\n\n## Bad use cases\n\n- parallel note rewrites\n- uncontrolled bulk frontmatter edits\n- whole-vault moves in one pass\n- autonomous cleanup without review gates\n\nFile v1.0.0:references/workflow.md\n\n# Workflow\n\nUse this workflow for non-trivial vault curation.\n\n## Phase 1: Inventory\n\n- define the exact folder, topic, or note set\n- list candidate notes\n- identify hubs, duplicates, and likely stale pages\n- note existing metadata patterns before proposing a new schema\n\n## Phase 2: Classification\n\n- assign or propose `doc_kind`\n- assign or propose `status`\n- identify canonical candidates\n- identify pages that need `superseded_by` or `supersedes`\n- keep uncertain notes in `needs-review`\n\n## Phase 3: Review design\n\nPrepare a concise review summary:\n\n- what should become leading\n- what should remain historical\n- what is concept only\n- what can stay dormant but discoverable\n- what must be checked live before writing\n- which possible secrets, credentials, tokens, or live identifiers flagged by a subagent are still only hypotheses and need main-agent verification\n\n## Phase 4: Migration plan\n\nCreate the smallest safe write slice.\n\nBefore approving a write slice, verify each of these:\n\n- Metadata slice = frontmatter or tag edits only. Structural slice = renames, moves, or new index/canonical pages. Content-rewrite slice = changes to note body prose.\n- Is this a metadata slice, a structural slice, or a content-rewrite slice?\n- Can the slice stay within one topic cluster?\n- Would a wrong classification be cheaply reversible?\n- Does any possible secret, credential, token, or live identifier flagged by a subagent still need main-agent verification?\n\nGood write slices:\n- add frontmatter to 3-10 related notes\n- create one index page\n- add supersession links in one topic cluster\n- rename or move 3-10 notes within one topic cluster after links are understood\n\nAvoid combining these in one step:\n- broad rewrites\n- large folder moves\n- metadata normalization across the whole vault\n- content consolidation plus structure changes plus deletes\n- classification plus rename plus rewrite of the same notes\n\n## Phase 5: Controlled writes\n\nAfter approval, and before changing files:\n\n1. verify any claimed secrets, credentials, tokens, or live identifiers against the exact note text\n2. change one slice\n3. inspect the diff\n4. verify links\n5. verify frontmatter consistency\n6. reassess the next slice\n\n## Preferred order of operations\n\n1. classify\n2. create or confirm canonical pages\n3. add supersession metadata\n4. create review dashboards or indexes\n5. move or rename if structure still hurts\n6. rewrite content only where needed\n\n## What not to do\n\n- do not delete by default\n- do not compress historical and current content into one blob\n- do not let multiple agents write at once\n- do not change `.obsidian/` or attachments unless the user asked\n- do not invent certainty for unclear notes","readmeExcerpt":"Skill: Obsidian Vault Curator Owner: thenerdforge Summary: Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classif... Tags: latest:1.1.0 Version history: v1.1.0 | 2026-05-19T20:09:26.671Z | user Major prompt-engineering and safety hardening release for large Obsidian/Markdown vault curation workflows. Added: - New re","codeSnippets":[],"executableExamples":[{"language":"yaml","snippet":"status: needs-review\ndoc_kind: reference\ntopic:\ncanonical: false\ncanonical_for: []\nsupersedes: []\nsuperseded_by: []\nlast_verified:\nreview_after:\nreview_state: unreviewed\nconfidence: low"},{"language":"yaml","snippet":"status: current\ndoc_kind: reference\ntopic: openclaw\ncanonical: true\ncanonical_for:\n  - OpenClaw Runtime\nlast_verified: 2026-05-11\nreview_state: reviewed\nconfidence: high"},{"language":"yaml","snippet":"status: historical\ndoc_kind: howto\ntopic: openclaw\nsuperseded_by:\n  - \"[[OpenClaw Runtime & Konfiguration]]\"\nreview_state: reviewed\nconfidence: medium"},{"language":"yaml","snippet":"status: concept\ndoc_kind: explanation\ntopic: yuna-public\nreview_state: unreviewed\nconfidence: medium"},{"language":"yaml","snippet":"status: needs-review\ndoc_kind: research\nreview_state: unreviewed\nconfidence: low"},{"language":"text","snippet":"ROLE:\n<exact role name>\n\nTASK:\n<one concrete read-only objective>\n\nBOUNDED SLICE:\n<exact folder, note set, or 3-10 note cluster>\n\nSOURCES:\n- <allowed file, summary, or rubric>\n\nCONSTRAINTS:\n- read-only\n- use only the bounded slice and listed sources\n- if evidence is insufficient, write `insufficient evidence`\n- prefer `needs-review` over guessing\n\nOUTPUT:\nReturn the required five-section shape from `references/output-format.md`.\n\nSTOP RULES:\n- do not infer outside the bounded slice\n- do not propose writes\n- do not quote sensitive values\n- stop when the bounded slice does not support a stable recommendation"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: obsidian-vault-curator\ndescription: Cautious curation, classification, review, and migration planning for Obsidian or Markdown vaults. Use when the user wants to organize a messy vault, classify notes, define canonical reference pages, separate current vs historical vs future-state material, design review dashboards or Bases views, or plan safe cleanup and migration without losing historical context. This skill requires installed Python 3 on PATH.\nmetadata:\n  openclaw:\n    emoji: \"🗂️\"\n    requires:\n      bins: [\"python3\"]\n    install:\n      - id: brew-python\n        kind: brew\n        formula: python\n        bins: [\"python3\"]\n        label: \"Install Python 3 (brew)\"\n        os: [\"darwin\"]\n---\n\n# Obsidian Vault Curator\n\nBring structure to a messy Obsidian vault without flattening its history. Start with inventory. Then run separate read-only analysis passes. Then propose one small, reviewable write slice.\n\nFor multi-note work, use read-only subagents by default. Keep the main agent as the only writer. Use one bounded slice per subagent and separate passes for inventory, comparison, classification, verification, and sensitive-content review.\n\n## Runtime requirement\n\nThis skill declares `python3` on `PATH` as a host requirement.\n\n- The requirement is surfaced in metadata as `requires.bins: [\"python3\"]`.\n- On macOS, the metadata includes a Homebrew install hint.\n- On Linux, install Python 3 with your distro package manager, for example `sudo apt install python3`, then verify `python3 --version`.\n- On Windows, install Python from the official Python Install Manager or with `winget install Python.Python.3.14`, then open a new terminal and verify that `python3 --version` works. If only `python` works, add a `python3` alias or shim on `PATH` before using this skill.\n- The bundled helper scripts in `scripts/` use only the Python standard library.\n- No extra Python packages are required.\n- No exact minor version is currently pinned. The helpers were validated with Python 3.11+ and tested locally on macOS against Python `3.14.4`.\n- Windows support is documented, but the full workflow has not yet been live-validated on Windows.\n\n## Core rules\n\n- Default to read-only.\n- Use subagents by default for multi-note or heterogeneous work.\n- Keep inventory first, then read-only review, then writes.\n- Never delete notes unless the user explicitly asks.\n- Never rewrite more than one write slice at a time. A write slice must stay within 3-10 related notes. Multiple-slice content rewrites in one pass count as mass-rewrite and require explicit user approval.\n- Never run parallel write agents.\n- Treat findings of sensitive content (see `references/subagents.md` glossary) as hypotheses until the main agent verifies the exact note content.\n- Never rely on a global forced subagent model. Reuse the main-agent model when it fits; change model only when a specific role clearly benefits.\n- Prefer `superseded_by` over overwrite.\n- Preserve historical context.\n- Treat `d"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7dzka1n2vjb8wgzt8v4xrych82ph5f\",\n  \"slug\": \"obsidian-vault-curator\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1779221366671\n}"},{"path":"references/bases-views.md","content":"# Bases and review views\n\nUse Bases or equivalent review lists as the control plane for curation.\n\nViews that group by `topic` depend on consistent topic slugs. Use the `topic` rule in `references/status-schema.md` before creating or changing topic-based views.\n\n## Recommended views\n\n### Vault Inbox\nShow notes missing `status` or `doc_kind`.\n\n### Needs Review\nShow notes where:\n\n- `status = needs-review`, or\n- `review_state = conflict`\n\n### Canonical Pages\nShow notes where:\n\n- `canonical = true`\n\ngroup by `topic`.\n\n### Historical but linked\nShow notes where:\n\n- `status = historical`\n- and the note still has meaningful inbound links\n\n### Concept / future state\nShow notes where:\n\n- `status = concept`\n\n### Reactivatable\nShow notes where:\n\n- `status = reactivatable`\n\n### Supersession gaps\nShow notes where:\n\n- `status = historical`\n- and `superseded_by` is empty\n\n### Stale current docs\nShow notes where:\n\n- `status = current`\n- and `last_verified` is older than 90 days or missing\n\n### Research not integrated\nShow notes where:\n\n- `doc_kind = research`\n- and no canonical page links to them\n\n## Practical guidance\n\n- Keep the first dashboard small and obvious.\n- Start with visibility, not automation.\n- Prefer a handful of high-signal views over a huge taxonomy.\n- If Bases is not available, propose manual indexes or search-driven lists as equivalent queues."},{"path":"references/classification-rubric.md","content":"# Classification rubric\n\nClassify one note at a time. Prefer explicit uncertainty over confident mislabeling.\n\nSubagents that use this rubric return candidates only; the main agent verifies and applies.\nSee `references/status-schema.md` for the `confidence` rule when emitting per-note recommendations.\n\n## Step 1: Determine `doc_kind`\n\nAsk what the note is trying to be:\n\n- `reference` — source of truth, stable facts, config, paths, commands\n- `howto` — procedure to achieve a task\n- `explanation` — why something works, tradeoffs, reasoning\n- `tutorial` — guided learning sequence\n- `research` — collected findings, comparisons, external material\n- `adr` — a decision with context and consequences\n- `log` — diary, changelog, working notes, progress trail\n- `index` — hub page or navigation page\n- `concept` — target design or future plan\n\n## Step 2: Determine `status`\n\n### `current`\nUse when the note is still valid and should be trusted now.\nSignals:\n- verified paths, commands, hostnames, versions, or architecture\n- referenced by 2 or more inbound wikilinks from notes that are already `status: current`\n- clearly reflects the live environment\n\n### `historical`\nUse when the note is not current but still valuable.\nSignals:\n- documents a previous setup, migration path, or decision history\n- useful for recovery, comparison, or context\n- replaced by a newer page\n\n### `concept`\nUse when the note describes a desired future state.\nSignals:\n- signal words in the title or opening section, in German or English, such as Zielbild, Soll, Plan, Proposal, Vision, target state, draft, or future state\n- contains intended rather than verified state\n\n### `needs-review`\nUse when status is unclear.\nSignals:\n- mixed old and new facts\n- no verification date, or `last_verified` older than 90 days for a note claiming `status: current`\n- conflicts with better evidence\n- unclear whether the note is still active\n\n### `reactivatable`\nUse when the note is dormant but likely reusable.\nSignals:\n- currently inactive workflow or system\n- likely to return later\n- should stay discoverable without being treated as live\n\n## Canonical page test\n\nA note is a good canonical candidate when most of these are true:\n\n- it has the clearest scope for a topic\n- it is easier to update than the alternatives\n- it already attracts links or should attract them\n- it can safely point outward to detail pages\n- it is not mostly historical baggage\n\nIf no note qualifies, propose creating a small new index or reference page instead of forcing a bad canonical page.\n\n## Supersession rules\n\n- Do not erase old context when a new page replaces it.\n- Mark older pages with `superseded_by`.\n- Mark the new leading page with `supersedes`.\n- Prefer short transition notes over giant merge rewrites.\n\n## Conflict handling\n\nWhen two notes disagree:\n\n1. trust live evidence over prose\n2. trust the note with recent verification over the undated one\n3. downgrade uncertain notes to `needs-review`\n4. do not silently merge contradiction"},{"path":"references/output-format.md","content":"# Output and merge format\n\nUse one compact format so subagent findings are mergeable.\nThis file is the single source of truth for output shapes.\n\n## Context router\n\n| Context | Use this shape |\n|---|---|\n| Subagent reply | `Required five-section shape` |\n| Single-pass main-agent reply with no subagents | `Required five-section shape` |\n| Main-agent merged reply from two or more subagent slices | `Final main-agent summary shape` |\n\n## Required five-section shape\n\nReturn these sections in this order:\n\n1. `Current state`\n2. `Classification recommendations`\n3. `Risks and contradictions`\n4. `Next write slice`\n5. `Verification`\n\nKeep each section short and concrete.\nIf a section has nothing material, write `none`.\n\n## Preferred note-level fields\n\nWhen naming important notes, prefer this shape:\n\n- `Path or note name`\n- `doc_kind`\n- `status`\n- `canonical` yes/no when relevant\n- short reason\n- optional `confidence: low|medium|high`\n\nIf the bounded slice does not support a recommendation, write `insufficient evidence` and prefer `needs-review` over guessing.\n\n## Sensitive findings\n\nIf a subagent suspects sensitive content (see `references/subagents.md` glossary):\n\n- treat it as a hypothesis, not a confirmed finding\n- reference only the note path, field or section, pattern type, and redacted shape\n- do not quote the sensitive value\n- do not recommend edits as if the finding were confirmed\n- place the finding under `Risks and contradictions`\n- require main-agent verification against exact note text before escalation or editing\n\n## Merge rules for the main agent\n\nWhen merging child-slice results:\n\n1. prefer compact summaries over repeating every detail, but keep disagreements visible\n2. surface disagreements explicitly\n3. downgrade contested notes to `needs-review`\n4. separate confirmed facts from hypotheses\n5. separate structural actions from content rewrite actions\n6. keep unsupported claims out of the merged summary; use `insufficient evidence` where needed\n\n## Human-review gates\n\nEscalate to explicit human review before:\n\n- deleting notes\n- moves or renames affecting more than 10 notes or more than 1 vault top-level directory\n- editing notes after only inferred classification\n- acting on sensitive-content hypotheses\n- collapsing multiple competing pages into one canonical page without clear evidence\n- changing a canonical page with 3 or more affected backlinks\n\n## Final main-agent summary shape\n\nWhen reporting merged results back after a multi-slice pass, use the required five-section shape."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2049,"uniquenessScore":43,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T12:51:16.422Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T12:51:16.422Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:16:15.399Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}