Problem
The --wiki flag is documented in the usage section but Step 6 of the skill only handles
--obsidian and HTML. There is no wiki generation step.
This creates two related failure modes:
-
Pipeline ordering bug: Anyone who uses --wiki does so outside the documented flow —
typically after Step 9, at which point .graphify_labels.json has already been deleted.
to_wiki() receives None for community_labels and silently falls back to
[[Community 0]], [[Community 1]], etc., discarding the labels set in Step 5.
-
Post-pipeline wiki regeneration is impossible: Even if a user ran the full pipeline
correctly (without --wiki), they cannot regenerate the wiki later with correct labels.
Community labels are ephemeral — deleted in Step 9 — and not persisted anywhere.
graph.json stores integer community IDs per node but not the human-readable names.
Expected behavior
Wiki generation should run in Step 6 (before Step 9 cleanup), with access to
.graphify_labels.json. The --wiki flag should remain opt-in, consistent with
--obsidian, --svg, and other optional outputs.
Two solution paths
Path A — Fix the skill only:
Add a wiki generation block to Step 6, between the HTML block and Step 7, that reads
.graphify_labels.json before Step 9 deletes it. Simple, minimal change.
Path B — Fix the root cause:
Persist community labels to graphify-out/labels.json as a first-class output artifact
in Step 5 (alongside graph.json and GRAPH_REPORT.md). This also enables:
- Post-pipeline wiki regeneration at any time
--update and --cluster-only reruns that can reuse existing labels without
re-running the full labeling step
Note: this is separate from #228 (wikilink format issue in wiki.py) which concerns
the library output format. This issue is about the skill's pipeline ordering and label
persistence.
Problem
The
--wikiflag is documented in the usage section but Step 6 of the skill only handles--obsidianand HTML. There is no wiki generation step.This creates two related failure modes:
Pipeline ordering bug: Anyone who uses
--wikidoes so outside the documented flow —typically after Step 9, at which point
.graphify_labels.jsonhas already been deleted.to_wiki()receivesNoneforcommunity_labelsand silently falls back to[[Community 0]],[[Community 1]], etc., discarding the labels set in Step 5.Post-pipeline wiki regeneration is impossible: Even if a user ran the full pipeline
correctly (without
--wiki), they cannot regenerate the wiki later with correct labels.Community labels are ephemeral — deleted in Step 9 — and not persisted anywhere.
graph.jsonstores integer community IDs per node but not the human-readable names.Expected behavior
Wiki generation should run in Step 6 (before Step 9 cleanup), with access to
.graphify_labels.json. The--wikiflag should remain opt-in, consistent with--obsidian,--svg, and other optional outputs.Two solution paths
Path A — Fix the skill only:
Add a wiki generation block to Step 6, between the HTML block and Step 7, that reads
.graphify_labels.jsonbefore Step 9 deletes it. Simple, minimal change.Path B — Fix the root cause:
Persist community labels to
graphify-out/labels.jsonas a first-class output artifactin Step 5 (alongside
graph.jsonandGRAPH_REPORT.md). This also enables:--updateand--cluster-onlyreruns that can reuse existing labels withoutre-running the full labeling step
Note: this is separate from #228 (wikilink format issue in
wiki.py) which concernsthe library output format. This issue is about the skill's pipeline ordering and label
persistence.