Use when Obsidian vault notes have poor, generic, or uninformative filenames and need clear, descriptive names. Trigger phrases - "rename notes", "fix note names", "clean up filenames", "give notes better names". Also trigger for single notes - "rename this note", "give this a better name". Trigger when the user mentions "Untitled notes", "unnamed notes", or notes that are hard to find by name.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add neckarshore-skills/obsidian-vault-autopilot --skill note-rename --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Note Rename?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/neckarshore-skills-note-rename)More formats (shields.io, HTML) on the badges page.
---
name: note-rename
status: stable
description: Use when Obsidian vault notes have poor, generic, or uninformative filenames and need clear, descriptive names. Trigger phrases - "rename notes", "fix note names", "clean up filenames", "give notes better names". Also trigger for single notes - "rename this note", "give this a better name". Trigger when the user mentions "Untitled notes", "unnamed notes", or notes that are hard to find by name.
---
# Note Rename
Give poorly named vault notes clear, descriptive filenames. Rename and fix backlinks. No sorting, no restructuring.
## Principle: Core + Nahbereich + Report
- **Core:** Rename uninformative filenames, update backlinks across vault
- **Nahbereich:** Trash accidental notes via soft-delete (see rule below and `references/trash-concept.md`). Minimal YAML syntax repairs when already editing frontmatter. Syntactic fixes only — never add or change field values (that is property-enrich's job). Allowed repairs:
- `*` → `-` in tag lists
- Remove duplicate `---` separators
- Convert inline tags `[X]` to block format
- Remove junk text before opening `---` (e.g. dictation artifacts like `Thx ---` → `---`)
- Fix quoted keys with embedded colon: `"type:"` → `type` (the colon belongs to YAML syntax, not the key name)
- Fill missing YAML `created` from the Source Hierarchy (filename date > Git first-commit > filesystem birthtime) before evaluating cooldown. See `docs/metadata-requirements.md`. This prevents birthtime corruption on subsequent skill runs.
- **Execution precedence:** the quoted-key and duplicate-`---` repairs above are governed by Step 4a's sanity-check routing — apply them via `references/yaml-edits.md` recipe (f), which resolves duplicate-key collisions (identical → silent dedup; divergent → ABORT: skip + Class-A finding, no rename). Never hand-apply a key fix in a way that bypasses the recipe (f) Step 3 collision check.
- **Report:** Renames, backlink updates, findings for other skills
## Parameters
| Parameter | Default | Description |
|-----------|---------|-------------|
| `cooldown_days` | 3 | Skip notes created within the last N days. Grace period so the user can review recent captures before automation touches them. **Date source:** YAML `created` field in frontmatter. If missing, the skill auto-enriches `created` from the Source Hierarchy (filename date > Git first-commit > filesystem birthtime) before evaluating cooldown — see Nahbereich. Never use modification date. |
| `clone_cluster_skip` | true | When `true` (default), Step 4b SKIPs `created` enrichment for files whose only available date source is filesystem birthtime AND whose birthtime falls in a detected clone-cluster window. See `references/clone-cluster-detection.md`. The rename flow still runs (filename change applied), but the YAML `created` field is left absent (recoverable, not poisoned). Set to `false` to disable. |
| `scope` | inbox | Which folder to scan. `inbox` = inbox root only (default). `inbox-tree` = inbox folder including all subfolders (opt-in for bulk-mode, e.g. initial vault setup). `vault` = entire vault excluding root. `folder:<path>` = specific subfolder. User confirms before execution. |
## Scope Rules
- **Vault root is always excluded** unless the user explicitly asks to process root-level files. Root files are typically structural (OPS docs, config notes, plugin files) and rarely rename candidates.
- Folders starting with `_` are excluded from scanning (`_trash/`, `_secret/`, `_test-backup/`).
- Folders starting with `.` are excluded (`.trash/`, `.obsidian/`).
- Template folders (e.g. `00_Templates`) are excluded.
## Protected Files
Never rename or process these files (see `references/vault-autopilot-note.md`):
- `_vault-autopilot.md` in vault root
- Any file starting with `_` in vault root (reserved for plugin management)
## Rename Candidates
Rename notes with **uninformative** filenames: `Untitled`, `Unbenannt`, `New Note`, `Draft`, `Blank note`, `Note from iPhone`, `Quick Note`, URL-only names, hash-only names, obvious typos (95%+ clear intent).
**Never rename:** Already descriptive names.
**Daily Notes (`YYYY-MM-DD.md`):** Not automatically kept. Classify by content:
- **Empty or boilerplate-only** → Trash candidate (accidental note detection)
- **Has content (links, text, ideas)** → Rename candidate. Keep date prefix: `YYYY-MM-DD - Context - Detail`
- **Multi-topic (links from different platforms, mixed themes)** → TBD suffix. Flag for manual review.
**Web captures:** Apply prefix per `references/web-capture-detection.md`. Skip existing categorical prefixes.
**Unclear cases:** `[Original Name] - TBD`. When the original name contains a date, keep the date first: `YYYY-MM-DD - TBD`. The date must always lead for chronological sorting.
## Accidental Note Detection (Nahbereich)
Soft-delete to `_trash/` if ALL true: (1) generic filename, (2) no content beyond template boilerplate, (3) frontmatter has only generic tags and no real title. Add trash metadata per `references/trash-concept.md`. When in doubt → TBD prefix instead.
## Daily Note Detection (Nahbereich)
Notes matching the Daily Note pattern (`YYYY-MM-DD.md`) get special handling. They are NOT auto-kept — classify by content (see Rename Candidates above). Location handling:
**Detection rules:**
1. **Misplaced daily notes** — `YYYY-MM-DD.md` outside the vault's canonical Daily Notes folder → move there first, then classify for rename like any other note. Add skill-log with Daily action for the move.
2. **Hybrid names** (`YYYY-MM-DD Some Description.md`) — this is NOT a daily note. It is a regular note with a date prefix. Process as a rename candidate — the date prefix is informative context, not a daily note pattern.
3. **Future dates** — if the note has a `created` date in frontmatter, use it as the correct date and rename accordingly. If a note with the corrected date already exists, resolve via naming (e.g. add a suffix). If no `created` date is available, flag for manual review. Always log the date correction in the skill-log action: `Renamed from [original] (date corrected)`.
4. **Already in correct Daily Notes folder** — no move needed. Still classify for rename based on content.
5. **Nested Daily Notes folders** (e.g. `inbox/Daily Notes/YYYY-MM-DD.md`) — these are misplaced. The vault has ONE canonical Daily Notes folder. Move there, avoid duplicates.
## Corrupted File Detection (Nahbereich)
Detect files with multiple YAML frontmatter blocks (two or more `---`/`---` pairs). This happens when two notes get accidentally merged — typically an append error during sync or import. These files cannot be reliably processed.
**Action:** Rename with a descriptive corruption label (e.g. `YYYY-MM-DD - Korrupte Datei - Zwei Notizen verschmolzen`). Write skill-log. Do not attempt to split the file — that requires manual review by the user.
**Detection:** Count `---` pairs that enclose YAML-key-like content (at least one `key: value` line between the pair). Body-level `---` horizontal-rule separators without YAML content do NOT count. Precise heuristic: see `references/yaml-sanity.md` Pattern 2. Two genuine frontmatter blocks = corrupted.
## Sensitive Content Detection (Nahbereich)
Move to `_secret/` if the note contains sensitive data: recovery phrases, API keys, passwords, tokens, or other credentials stored as plaintext. These notes are a security risk and must not remain in the vault unprotected. Add trash metadata with `trash_source: note-rename` and the original path. The `_secret/` folder signals to the user that these files need manual review and secure handling — not just deletion.
## Naming Rules
1. Capture **core topic** — scannable at a glance
2. **Dash separator:** `Topic - Detail` for two-level names
3. No filler words ("Note about", "Draft of")
4. Match content language
5. Max ~70 characters
**Clusters:** If 3+ notes share a topic, suggest a common prefix before renaming.
## Context Segment
When renaming notes that have a date prefix, use a three-part name: `YYYY-MM-DD - Context - Detail`.
The **Context** segment answers: "What gives the reader the fastest orientation?" It can be:
- A **platform** (Instagram, YouTube, ChatGPT, Perplexity, Grok, GitHub, Reddit, LinkedIn)
- A **project** (the project or product name the note relates to)
- A **life area** (Family, Finance, Career, Health)
- An **activity** (Research, Interview, Meeting, Review)
**Platform detection** (when primary content is a link or capture):
| URL Pattern | Context Segment |
|---|---|
| `instagram.com` | Instagram |
| `youtube.com`, `youtu.be` | YouTube |
| `perplexity.ai` | Perplexity |
| `chatgpt.com` | ChatGPT |
| `grok.com` | Grok |
| `linkedin.com` | LinkedIn |
| `github.com` | GitHub |
| `reddit.com` | Reddit |
| Other recognizable domain | Domain name (capitalized) |
See also `references/web-capture-detection.md` for social platform detection rules.
**Multiple links, same platform:** One context segment. E.g. 3 Instagram links → still just "Instagram".
**Multiple links, different platforms:** Use the dominant platform as context, or `Research` if no platform dominates.
**No links (pure text):** Use project, life area, or activity as context.
## Multi-Topic Rules
When a note covers multiple unrelated topics, join them with `&` in the Detail segment:
| # | Topic Count | Platforms | Rule |
|---|-------------|-----------|------|
| 1 | 1-2 | any | All topics in the name with `&` |
| 2 | 3-4 | any | All topics in the name with `&` if it stays readable and under ~70 characters. Skill decides. |
| 3 | 5-6 | one dominant | All topics as keywords with `&`. One keyword per topic — enough to find the note later. |
| 4 | 5+ | multiple | `YYYY-MM-DD - Mixed Content - Mixed Topics.md`. Too chaotic for a meaningful name. |
| 5 | 7+ | any | `YYYY-MM-DD - Mixed Content - Mixed Topics.md`. Topic Override — content this fragmented cannot produce a meaningful name regardless of platform dominance. |
Examples:
- 2 topics: `2025-12-03 - Instagram - HR Interview Tipps & SaaS.md`
- 3 topics: `2025-12-04 - Instagram - SaaS & Dev Tools & Karpathy LLM.md`
- 5-6 topics, one platform: `2025-12-11 - Instagram - Product & Interview & Claude & AI Cases & Cursor.md`
- 5+ topics, multiple platforms: `2025-12-08 - Mixed Content - Mixed Topics.md`
- 7+ topics, one platform: `2026-01-08 - Mixed Content - Mixed Topics.md` (Topic Override — 7 topics, 93% Instagram, still too fragmented)
## Pre-flight
Before **every** invocation of this skill — including resumed sessions and re-triggers within the same conversation:
1. **Always (every OS):** Run [`references/clone-preflight.md`](../../references/clone-preflight.md). It detects clone-induced birthtime clusters and emits a WARN before any date-derivation runs. Cross-platform — applies on macOS, Linux, and Windows. WARN-flow only; skill execution continues.
2. **On Windows additionally:** Follow [`references/windows-preflight.md`](../../references/windows-preflight.md) end-to-end (registry check, trailing-dot folder detection, Windows-aware file-enumeration pattern). The enumeration pattern in Step 6 of that preflight applies to every subsequent file-listing call this skill makes — `Scan` (step 2 below) and `Check backlinks` (step 6 below) included. On macOS or Linux, this preflight is a no-op.
Run the checks freshly each time. Do not assume a previous turn's pass result still holds — registry state, folder topology, and birthtime clustering can change between invocations and previous results are not authoritative.
## Workflow
1. **Discover vault** — resolve `${OBSIDIAN_VAULT_PATH}`. Default scope: inbox root. Confirm with user.
2. **Scan** — list `.md` files.
3. **Nahbereich** — detect and trash accidental notes (soft-delete to `_trash/`). Move misplaced Daily Notes to the Daily Notes folder. Log each.
4. **Classify** — read title, tags, first ~30 lines (skip template boilerplate). For each note:
- **4a. Repair corrupted quoted-key variants first (Nahbereich, sanity-check).** Call `references/yaml-sanity.md`. Verdict-routing per `references/yaml-sanity.md` § "Per-skill policy":
- `BROKEN_KEYS_INSIDE_COLON` (shape β — F26 inside-colon): normalize via `references/yaml-edits.md` recipe (f) — handles ALL quoted-key patterns, not just `"created:"`/`"modified:"` (broadened from v0.1.0/v0.1.2 hardcoded list). After normalization, resolve duplicate-key collisions per recipe (f) Step 3 (identical → silent dedup; divergent → ABORT, see next bullet). Re-call sanity-check (idempotent fixpoint) — verdict must now be `OK`, `OK_QUOTED`, or `OK_NO_FRONTMATTER`.
- `DUPLICATE_KEYS_IDENTICAL_VALUES` (v0.1.4 W4): repair via recipe (f) silent dedup, then re-run sanity-check.
- `DUPLICATE_KEYS_DIVERGENT_VALUES` (v0.1.4 W4 — F7 family): **skip the file** + log Class-A finding "duplicate-key-divergent-values". Do NOT rename — user may legitimately need to merge values first; rename would obscure the underlying ambiguity. Route to user.
- `MULTIPLE_FRONTMATTER_BLOCKS`: use existing Corrupted File Detection (rename file with corruption-label).
- `OK_QUOTED`: proceed normally.
- `OK` / `OK_NO_FRONTMATTER`: proceed normally.
YAML edits MUST follow `references/yaml-edits.md` (recipes b + f). Without this normalization a strict YAML parser cannot read the author-intended date, falls back to the Source Hierarchy → filesystem birthtime (often fresh on cloned vaults), and the cooldown evaluation in 4c silently skips legitimate candidates. Classification regex accepts both plain and standard-quoted forms. Historical bugs: repo issue #4 (2026-04-27) for `created`/`modified`; F26 cross-skill cluster (2026-04-28) generalized the inside-colon pattern; F7 (GR-3 Cell 1, 2026-05-01) generalized duplicate-key resolution beyond first-wins-silent (v0.1.4 W4).
- **4b. After 4a, if YAML `created` is still missing:** derive the value via Source Hierarchy Prio 1-3 first (filename > git, with German-date normalization in Prio 1 per `references/german-date-normalization.md`). If Prio 1-3 yields a value, write it to frontmatter (Nahbereich) and record the source. If Prio 1-3 yields no value, apply the **clone-cluster gate** per `references/clone-cluster-detection.md`: detect the vault-wide cluster window once per skill invocation, then invoke recipe (a) `is_birthtime_in_clone_cluster_window`. If recipe (a) returns 0 (in cluster) AND recipe (b) `has_alternate_date_source` returns 1 (no alt source), SKIP `created` enrichment for this note — do not write the field, log the file as Class-C "clone-cluster birthtime, no alt source" in the per-skill findings file, and store the current filesystem birthtime only for later restoration (rename-flow proceeds, but `created` stays absent). Otherwise (no cluster declared, or recipe (a) returns 1 = not in cluster), fall through to Prio 4 (filesystem birthtime) — write `created` from `stat -f %SB` / `stat -c %W`. Behavior gated by config `clone_cluster_skip` (default `true`); when `false`, the gate is a no-op and Prio 4 fires unconditionally.
- **4c. Apply cooldown** (per `cooldown_days` parameter) using the now-trustworthy `created` value. Cooldown-skipped notes are reported in the Skipped section of the report (not silently dropped) — see `references/report-format-note-rename.md`.
- **4d. Mark** as: rename, keep, or TBD.
5. **Detect clusters** — 3+ candidates on same topic → prepare prefix suggestion.
6. **Check backlinks** — find all `[[Old Name]]` references across vault.
7. **Preview and confirm** — show the preview table (see `references/report-format-note-rename.md` for format and bilingual templates). Match the language the user is speaking. Include a rationale section below the table explaining non-trivial decisions. **Do not execute until the user explicitly confirms.**
8. **Execute** — rename files, update all `[[Old Name]]` and `[[Old Name|` references.
9. **Skill Log** — for every processed note (renamed, reviewed, or trashed), write the skill log. See `references/skill-log.md` for the full spec. YAML tag-list edits and skill-log callout edits MUST follow `references/yaml-edits.md` (recipes d + e). **After writing tag/callout, restore filesystem birthtime** from the YAML `created` value read during classification. Use `touch -t` (see `references/skill-log.md` § Birthtime Preservation). After auto-enrich in step 4, YAML `created` is almost always available. Restore birthtime from it. In the rare case that auto-enrich found no source (no filename date, no Git, no readable birthtime), restore from the pre-write filesystem birthtime captured in step 4.
**Tag (idempotent):**
- Check if `VaultAutopilot` already exists in the `tags` list in YAML frontmatter.
- If missing: add it. If present: do nothing. Never duplicate.
- If no `tags` field exists: create one with `VaultAutopilot` as the first entry.
**Callout (append-only):**
- Check if `> [!info] Vault Autopilot` exists at the end of the note.
- If missing: create the full callout block:
```
> [!info] Vault Autopilot
>
> | Date | Skill | Action |
> |------|-------|--------|
> | YYYY-MM-DD | note-rename | [action] |
```
- If present: append only a new `> | YYYY-MM-DD | note-rename | [action] |` row to the existing table. Never create a second callout.
- Ensure one blank line separates the callout from the preceding content.
**Action types:**
- Renamed: `Renamed from [old filename without .md]`
- Reviewed (name was already good): `Reviewed — name already descriptive`
- Trashed (Nahbereich): `Trashed — accidental note (soft-delete to _trash/)`
- Secret (Nahbereich): `Secret — sensitive content (moved to _secret/)`
- Daily (Nahbereich): `Daily — moved to Daily Notes folder`
10. **Write findings file** — for any non-trivial Findings (Class A/B/C/D as defined in `references/findings-file.md`), append a section to `<VAULT>/_vault-autopilot/findings/<YYYY-MM-DD>-note-rename.md`. Create the folder chain if missing. Never edit prior findings — append-only ledger.
11. **Report and log** — write summary, append to `logs/run-history.md`.
## Report Format
See `references/report-format-note-rename.md` for the full preview table format (bilingual), report template, and action types for skill log.
## Quality Check
- [ ] Renamed files exist at new paths
- [ ] All backlinks updated (no broken `[[]]`)
- [ ] No Daily Notes renamed
- [ ] User confirmed before execution
- [ ] Every processed file has `VaultAutopilot` tag in frontmatter (exactly once)
- [ ] Every processed file has skill log callout at the end
- [ ] Reviewed notes have "Reviewed" action, not "Renamed"
- [ ] Re-renamed notes have multiple callout rows, not multiple callouts
- [ ] Sanity-check called Step 4a per `references/yaml-sanity.md` (broadened from hardcoded `"created:"`/`"modified:"` to all quoted-keys)
- [ ] Quoted-key broken-key variants (shape β — inside-colon) normalized via recipe (f); standard quoted-keys (shape α) pass through as `OK_QUOTED`
- [ ] Duplicate-key divergent-value collisions (F7 family) skip + Class-A finding; file is NOT renamed — user merges manually first (v0.1.4 W4)
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!