obsidian-markdown, obsidian-cli: a frontmatter alias does not resolve a bare wikilink

A bare [[Some Alias]] comes back (unresolved) from Obsidian's own resolver, while the piped form [[Real Name|Some Alias]] pointing at the same file resolves. So a hand-written wikilink whose text is only an alias is a broken link, even when a note in the vault carries that text in its aliases. What hides it: accepting an alias from the link suggester inserts the piped form, which resolves — so the failure only shows up when the link is typed by hand, which is what an agent does.

Neither skill says anything false today. Both leave out the load-bearing negative, and obsidian-cli omits the one command that measures it.

Verified on Obsidian 1.13.7 (installer 1.12.7), macOS 26.2 (25C56), skills at 8ccef29.

Repro

Target note carries the alias:

---
aliases:
  - ProbeAliasZeta
---
Target note.

Linking note uses the bare alias, the piped form, and a target that does not exist:

[[ProbeAliasZeta]]

[[Alias Probe Target|ProbeAliasZeta]]

[[Alias Probe Missing qqzzxx0997]]

$ obsidian properties path="99 Inbox/Alias Probe Target.md"
aliases:
  - ProbeAliasZeta

$ obsidian links path="99 Inbox/Alias Probe Linker.md"
99 Inbox/Alias Probe Target.md
Alias Probe Missing qqzzxx0997 (unresolved)
ProbeAliasZeta (unresolved)

Line 1 is the piped form resolving. Line 2 is the target that does not exist. Line 3 is the bare alias, carrying the same verdict as the target that does not exist. properties confirms the alias is indexed, so this is not a stale cache.

file= behaves the same way:

$ obsidian read file="ProbeAliasZeta"
Error: File "ProbeAliasZeta" not found.

$ obsidian read file="Alias Probe Target"
---
type: note
...

obsidian-markdown

The properties section reads:

Default properties: tags (searchable labels), aliases (alternative note names for link suggestions), cssclasses (CSS classes for styling).

and references/PROPERTIES.md:

• aliases - Alternative names for the note (used in link suggestions)

Both are accurate. But "alternative note names" is the natural reading for a link target, and the Internal Links block lists [[Note Name|Display Text]] as custom display text — without saying it is the required form when the display text is an alias.

Suggested, after the Internal Links code block:

A bare [[Alias]] does not resolve, even when a note carries that alias. aliases feeds the link suggester, which inserts the piped form — write [[Note Name|Alias]].

obsidian-cli

The File targeting section reads:

• file=<name> — resolves like a wikilink (name only, no path or extension needed)

That is exactly right, and it is the reason file=<alias> fails: a bare wikilink does not resolve an alias either. Worth making explicit, because "resolves like a wikilink" reads as "resolves the way the suggester offers".

Suggested, under File targeting:

file= does not resolve aliases. Address a note by its filename, or by path=.

Separately, the links command is absent from the skill, and it is the only instrument for link brokenness: it suffixes every unresolved target with the literal (unresolved), as above. backlinks is documented and links is not, which leaves an agent checking its own links by reading the target's frontmatter instead — which is exactly what produces the wrong answer here.

Suggested, under Common patterns:

obsidian links path="folder/note.md"   # link targets; unresolved ones are suffixed (unresolved)

obsidian-markdown's workflow asks the author to "Verify the note renders correctly in Obsidian's reading view", which an agent cannot do. links is the runnable form of that check.

Related, not duplicates

• #141 flags the same file= sentence for a different failure, base commands needing the extension.
• #90 adds links and unresolved to the command listing, without the (unresolved) semantics or anything about aliases.

Happy to send a PR for any of this.