Use when a query or conversation against the LLM-Wiki produces a durable synthesis worth keeping — a multi-source comparison/connection, or a standard concept the wiki lacks. Proposes filing it back as a new or updated wiki page and writes ONLY on the user's confirmation. Skip one-off lookups and navigation.

2026-06-285

wiki-lint

kangig94/obsidian-para-zk

Use only when the user explicitly asks to lint or health-check the LLM-Wiki. Never run it as part of ingest or normal wiki work.

2026-06-285

codex-setup

kangig94/obsidian-para-zk

Install or refresh PARA-ZK Codex custom agents from the plugin's bundled Claude-style agent definitions. Use when a Codex user wants PARA-ZK workflows such as wiki-ingest to spawn named agents like wiki-weaver, or after installing/upgrading the PARA-ZK plugin in Codex.

2026-06-225

tier-review

kangig94/obsidian-para-zk

Use after implementation to run tier-classified review agents and produce a consolidated verdict.

2026-06-065

name	wiki-retopology
description	Use when reorganizing the existing PARA-ZK LLM-Wiki domain topology.

Wiki Retopology

Plan and execute the deterministic topology part of an existing LLM-Wiki refactor: domains, page homes, same-domain names, source-domain index membership, and cross-domain links. This skill may run approved refile-llm-wiki and same-domain rename-llm-wiki commands before handoff, and after a refile it must remove the moved page from the old/source domain index. It does not ingest new canonical sources and it does not rewrite page prose by default. Source-backed body or hub synthesis is handed off to wiki-ingest after the approved topology moves are already in place.

Context

LLM-Wiki pages are LLM-owned derived synthesis under LLM-Wiki/. A domain is a page's file-tree home and hub context; cross-domain relationships live in links. Therefore:

Use domain indexes as the topology map. In large vaults, rank index pairs first and then read the returned indexes directly; do not use concept-page similarity as a ranking signal.
If the user names or suspects a cross-domain relation, read those indexes directly even if a ranking command would not surface them.
A page can be strongly related to another domain without moving there.
A cross-domain link is normal and is not itself evidence for a domain merge.
A domain move is structural and deterministic: use para-zk:refile-llm-wiki.
After a domain move, the old/source domain index must stop listing the moved page as a member.
A prose rewrite, hub synthesis, or source re-evaluation belongs to wiki-ingest.

Default posture: plan first, then apply approved deterministic structure, then hand off. Apply only when the user explicitly asks to apply, or after they approve the proposed plan.

Argument Routing

Argument	Routing
`scope=all` (default)	Use global index-pair candidates, then read the returned hubs and enough pages to plan.
`scope=domain domain=<domain>`	Use focused candidates and the returned index graph for that domain, then read the returned hubs and enough pages to plan.
`scope=pages titles=<json-or-comma-list>`	Read the listed pages' domain hubs and use focused candidates when neighboring domains matter.
`apply=true`	After plan presentation/approval, apply deterministic moves/renames before handoff.

Reject domain without scope=domain; reject titles without scope=pages; reject both together. Do not ask the user to resolve invalid arguments; stop with the concrete routing error.

Execution

Orient: Run optsidian para-zk:conventions ONCE first for this task, then optsidian para-zk:describe and optsidian para-zk:describe type=llm-wiki. Confirm the surface exposes para-zk:wiki-domains, para-zk:wiki-retopology-candidates, para-zk:list, para-zk:read-llm-wiki, para-zk:refile-llm-wiki, para-zk:rename-llm-wiki, and para-zk:update-llm-wiki. If the vault is unavailable, stop with the CLI error; do not read vault files directly.
Inventory:
- Read domains: optsidian para-zk:wiki-domains limit=all.
- Read the roster: optsidian para-zk:list type=llm-wiki limit=all.
- For scope=all, get global index-pair candidates: optsidian para-zk:wiki-retopology-candidates limit=<k>. Each candidate includes a score and the shortest index-to-index connection within depth=2 by default.
- For scope=domain, get focused candidates: optsidian para-zk:wiki-retopology-candidates domain="<domain>" limit=<k>; it also returns an undirected index graph neighborhood with depth=2 by default.
- Read the <domain>/index bodies for domains in the returned candidate pairs, plus any explicitly user-named domains.
- For a small vault or an explicitly exhaustive pass, reading every domain index is acceptable.
- Read individual concept pages only when the hub is insufficient to classify a move, merge, or link. Prefer bounded reads; this is a topology pass, not a full re-synthesis pass.
Diagnose topology:
- Domain split: a domain is an umbrella with several stable lineages/problem areas that each can sustain a useful hub and multiple pages.
- Domain merge: two domains are synonyms/near-synonyms, or their hubs describe the same problem area with no durable distinction.
- Refile: a concept page's best home is a different existing or planned domain, while the concept itself remains the same page.
- Same-domain rename: the concept name is unclear but the domain home is correct.
- Cross-domain link: two domains remain distinct but their hubs/pages should point to each other so the wiki reads as one graph.
- Handoff to ingest: page or hub prose needs source-backed synthesis, citations, or a body rewrite. Do not do that inside this skill; route it to wiki-ingest.
Plan: Produce a compact text plan with concrete titles and one-line rationales. Include only sections that have entries: summary, domain moves, domain splits, domain merges, same-domain renames, source-index prunes, cross-domain links, wiki-ingest handoff, and manual decisions.

Keep the plan ordered: merges before moves into the merged domain; domain creation before moves into the new domain; deterministic moves/renames and source-index prunes before every wiki-ingest handoff.
Apply approved deterministic topology before handoff:
- Domain move: optsidian para-zk:refile-llm-wiki title="<current>" domain="<target>".
- Same-domain rename: optsidian para-zk:rename-llm-wiki title="<current>" new_title="<current-domain>/<new-concept>".
- After each successful refile, read the old/source <domain>/index fresh and remove the moved page's member section or standalone child entry. Obsidian may have rewritten the stale link to the new path; remove the membership block anyway.
- Choose the smallest coherent removal range yourself: a dedicated section for the moved page, a standalone bullet/list item, or a short local paragraph whose only purpose is to register that page as an old-domain member. Then use update-llm-wiki key=body op=replace match=<chosen range> with="" by=<model-id> for the source-index prune.
- If several reasonable removal ranges exist, pick the smallest one that leaves the old index grammatical enough to read. Report the range you removed.
- Do not refile <domain>/index hubs.
- If a target path exists, stop and surface the conflict; do not invent suffixes.
- After each successful move/rename, update the handoff packet to use the final title/path, not the old topology. If a move fails, stop before handoff.
Hand off synthesis to wiki-ingest against the final topology:
- For source-backed pages: invoke wiki-ingest mode=re-ingest source_path=<path> or source_paths=<json> with the applied retopology context.
- For hub-only topology rewrites with no source read needed, present a hub_updates handoff: desired children/groups, cross-domain links, and rationale. This skill should not compose large hub prose itself.
- If no canonical source is tied to the rewrite, say so explicitly and ask before doing any direct update-llm-wiki write.
Report:
- What was read: domains, hubs, and any concept pages.
- The proposed plan and what remains manual.
- If applied: every refile/rename command run, every source-index prune, and the result path.
- The exact wiki-ingest handoff packet for source-backed rewrites and hub updates.

Guardrails

Never use raw file moves or direct vault file edits.
Never treat cross-domain links as a reason to collapse domains by default.
Never mint a new domain without a one-sentence rationale and expected child concepts.
Never leave near-synonym domains unmentioned if they are discovered.
Never let a page exist in two domains; one concept = one page across the wiki.
Never leave a refiled page as a child/member section in the old/source index.
Never bulk-rewrite bodies or hubs without an explicit user approval and a handoff plan.

Decision Examples

Split a large domain: language-models contains several dense clusters such as scaling laws, alignment, retrieval-augmented generation, and agents. If each cluster has multiple child concepts and needs its own useful hub, plan new domains, refile the relevant pages, and prune their old-domain index memberships.
Merge near-synonym domains: RL and reinforcement-learning cover the same problem area. Pick the canonical domain, refile pages into it, and prune the old domain's index memberships.
Link instead of merge: language-models/transformer-architecture strongly informs scaling-laws/chinchilla, but the former is model architecture and the latter is scaling methodology. Keep domains distinct and plan cross-domain links rather than a merge.