| name | setup-wiki |
| description | USER-INVOKED ONLY (via /setup-wiki). One-time setup for the LLM Code Wiki plugin: picks a wiki data root, scaffolds it from the plugin's template, records the root in ~/.llm-code-wiki, then customizes Purpose, the scope tag, and the repo registry. Do NOT run this automatically or as part of any other task — only when the user explicitly types /setup-wiki. |
| disable-model-invocation | true |
Set up your wiki (one-time)
Run only when the user invokes /setup-wiki. The wiki and deep-research skills ship with
this plugin and are already installed globally; what's missing is the wiki data — the knowledge
base itself. This wizard scaffolds that data at a location the user picks, records where it lives so
every skill can find it, and customizes it. Be friendly and brief; do the mechanical work yourself
and ask the user only what you genuinely cannot infer. Work through the steps in order.
Throughout, $WIKI_ROOT is the absolute path to the user's wiki data. The plugin's bundled files
live at ${CLAUDE_PLUGIN_ROOT} (Claude Code sets this for you).
0. Choose the wiki data root
The pointer file ~/.llm-code-wiki records the wiki's location. First check whether the wiki is
already set up:
cat ~/.llm-code-wiki 2>/dev/null
- If it prints a path and that directory has a filled-in
constitution.md, the wiki is already
set up — confirm with the user before changing anything (they may just want to re-run a later
step, e.g. add repos or enable validation).
- Otherwise, ask the user where the wiki data should live. Suggest a default like
~/llm-code-wiki (a standalone folder they'll manage as its own git repo). Set $WIKI_ROOT to
the confirmed absolute path.
1. Scaffold the wiki + record its location
Copy the plugin's template skeleton into $WIKI_ROOT and write the pointer file:
WIKI_ROOT="$HOME/llm-code-wiki"
mkdir -p "$WIKI_ROOT"
cp -R "${CLAUDE_PLUGIN_ROOT}/template/." "$WIKI_ROOT"/
printf '%s\n' "$WIKI_ROOT" > ~/.llm-code-wiki
Confirm $WIKI_ROOT now contains constitution.md, repos.md, scripts/, and wiki/, and that
cat ~/.llm-code-wiki prints the root. Everything below operates on files under $WIKI_ROOT.
2. Verify hashing on this OS
Detect the platform and smoke-test the matching script so staleness detection works here.
macOS / Linux (bash):
chmod +x "$WIKI_ROOT/scripts/hash.sh"
echo "hello" > /tmp/_wiki_t.txt
H=$("$WIKI_ROOT/scripts/hash.sh" /tmp/_wiki_t.txt)
"$WIKI_ROOT/scripts/hash.sh" /tmp/_wiki_t.txt "$H"
echo "changed" > /tmp/_wiki_t.txt
"$WIKI_ROOT/scripts/hash.sh" /tmp/_wiki_t.txt "$H"
rm /tmp/_wiki_t.txt
"$WIKI_ROOT/scripts/hash.sh" /tmp/_wiki_t.txt "$H"
Windows (PowerShell):
"hello" | Out-File -Encoding utf8 $env:TEMP\_wiki_t.txt
$H = & "$WIKI_ROOT\scripts\hash.ps1" -File $env:TEMP\_wiki_t.txt # prints a hash
& "$WIKI_ROOT\scripts\hash.ps1" -File $env:TEMP\_wiki_t.txt -Recorded $H # FRESH
"changed" | Out-File -Encoding utf8 $env:TEMP\_wiki_t.txt
& "$WIKI_ROOT\scripts\hash.ps1" -File $env:TEMP\_wiki_t.txt -Recorded $H # STALE
Remove-Item $env:TEMP\_wiki_t.txt
& "$WIKI_ROOT\scripts\hash.ps1" -File $env:TEMP\_wiki_t.txt -Recorded $H # MISSING
Report the four verdicts (hash / FRESH / STALE / MISSING). If the tool is missing:
- Linux without
sha256sum/shasum → tell the user to install coreutils.
- Windows →
Get-FileHash ships with PowerShell 4+; if missing, update PowerShell.
3. Define the Purpose
Ask the user, in one or two questions: What is this knowledge base about — its center of
gravity? (e.g. "our payments platform, with competitor repo X as reference," or "the Linux
kernel networking stack"). Then rewrite the ## Purpose & scope section of
$WIKI_ROOT/constitution.md, replacing the <!-- CUSTOMIZE --> placeholder with a pointed
one-paragraph description.
4. Set the scope: tag
Ask whether their knowledge splits into distinct "worlds" worth tagging. Offer common shapes:
ours/theirs, v1/v2, frontend/backend, or none (single world). Update the
### The scope: tag section of $WIKI_ROOT/constitution.md to list the chosen values (or note that
scope: is unused and may be omitted from frontmatter).
5. Fill the repo registry
Help the user populate $WIKI_ROOT/repos.md. Offer to scan for git repos to suggest rows — scan
near $WIKI_ROOT and/or the directory the user invoked /setup-wiki from:
for d in "$WIKI_ROOT"/../*/ "$WIKI_ROOT"/../*/*/; do [ -d "$d/.git" ] && echo "$(basename "$d") -> $d"; done
For each repo the user wants to track, add a row: name | scope | path | notes. Paths are
relative to $WIKI_ROOT (where repos.md lives), e.g. ../some-repo. Remove the example rows.
Confirm the table with the user.
6. Enable validation (optional — requires Python 3)
$WIKI_ROOT/scripts/validate.py enforces the frontmatter schema, source freshness (re-hashing),
and index presence. If the user doesn't want it, skip this step — the files lie dormant and are safe
to delete.
If they do want it:
- Confirm Python 3 is available:
command -v python3. If absent, tell the user to install it or
skip this step.
- Smoke-test it on the fresh vault and confirm it passes:
python3 "$WIKI_ROOT/scripts/validate.py"
- Activate the local pre-commit hook (run from inside the wiki repo, after
git init in step 7):
cd "$WIKI_ROOT" && chmod +x scripts/hooks/pre-commit && git config core.hooksPath scripts/hooks
- A CI workflow ships at
$WIKI_ROOT/.github/workflows/validate.yml (runs
python3 scripts/validate.py --no-repo-hash, since CI can't see sibling code repos). Keep it if
pushing to GitHub Actions; delete it otherwise.
7. Tidy up (offer, don't force)
Ask whether to:
8. Done
Summarize what changed. The wiki and deep-research skills are already active (installed with the
plugin) and resolve the wiki via ~/.llm-code-wiki — no restart needed. Reassure the user there are
no commands to memorize: just ask in plain English from any repo. Give examples: "scan / read
<repo>" to map a repo, ask any question to research, "save this" to keep a session insight, "check
the wiki" to health-check for out-of-date pages. Suggest opening $WIKI_ROOT/wiki/ as an Obsidian
vault. Remind them: to track a new source repo later, add it to $WIKI_ROOT/repos.md.