Summary
/understand-knowledge's deterministic parser (parse-knowledge-base.py) extracts links only via [[wikilink]] syntax (WIKILINK_RE). A wiki that follows the Karpathy three-layer pattern in every other respect — has index.md, multiple cross-linked .md files, schema file — but uses CommonMark [label](page.md) links instead of [[ ]] gets detected as karpathy and then produces zero deterministic edges.
This is common for wikis rendered on GitHub/GitLab, since those renderers do not support [[wikilinks]], so authors use standard markdown links.
Steps to reproduce
A minimal wiki:
index.md # "## Topic" then - [Alpha](pages/alpha.md) - [Beta](pages/beta.md)
pages/alpha.md # body: "relates to [Beta](beta.md)"
pages/beta.md
Run the parser:
python3 parse-knowledge-base.py <dir>
Expected: alpha → beta related edge, and alpha/beta categorized under "Topic".
Actual: ... 0 wikilinks (0 unresolved), edges: 0, and the index category has 0 articles.
The skill still "succeeds," so the degradation is silent — the LLM-analysis phase then has to invent the entire link structure from prose, producing a noisy, unreliable graph instead of the real one.
Root cause
extract_wikilinks / parse_index only scan WIKILINK_RE.
resolve_wikilink resolves by filename stem, not by relative path, so [label](path.md) targets are never matched even if extracted.
Relationship to existing issues
This case — a Karpathy-format wiki that uses CommonMark links — is covered by neither.
Proposed fix
Within the existing Karpathy code path, additionally extract [label](page.md) links and resolve them by normalised relative path, alongside the existing [[ ]] handling (fully backward-compatible). Same treatment for index.md category links. PR incoming.
Environment
understand-anything 2.7.x, skills/understand-knowledge/parse-knowledge-base.py
- Python 3.13
Summary
/understand-knowledge's deterministic parser (parse-knowledge-base.py) extracts links only via[[wikilink]]syntax (WIKILINK_RE). A wiki that follows the Karpathy three-layer pattern in every other respect — hasindex.md, multiple cross-linked.mdfiles, schema file — but uses CommonMark[label](page.md)links instead of[[ ]]gets detected askarpathyand then produces zero deterministic edges.This is common for wikis rendered on GitHub/GitLab, since those renderers do not support
[[wikilinks]], so authors use standard markdown links.Steps to reproduce
A minimal wiki:
Run the parser:
Expected:
alpha → betarelated edge, andalpha/betacategorized under "Topic".Actual:
... 0 wikilinks (0 unresolved),edges: 0, and the index category has 0 articles.The skill still "succeeds," so the degradation is silent — the LLM-analysis phase then has to invent the entire link structure from prose, producing a noisy, unreliable graph instead of the real one.
Root cause
extract_wikilinks/parse_indexonly scanWIKILINK_RE.resolve_wikilinkresolves by filename stem, not by relative path, so[label](path.md)targets are never matched even if extracted.Relationship to existing issues
[[wikilink]]path resolution (title-caseIndex.md, repo-root prefixes) — still wikilink-only.[](path.md)parsing but as a separatedoctrineformat detected only whenindex.mdis absent, and states "Karpathy detection takes precedence." A wiki that hasindex.mdand uses markdown links is therefore still routed to the Karpathy path and still yields 0 edges.This case — a Karpathy-format wiki that uses CommonMark links — is covered by neither.
Proposed fix
Within the existing Karpathy code path, additionally extract
[label](page.md)links and resolve them by normalised relative path, alongside the existing[[ ]]handling (fully backward-compatible). Same treatment forindex.mdcategory links. PR incoming.Environment
understand-anything2.7.x,skills/understand-knowledge/parse-knowledge-base.py