wiki-tools

Wiki Tools

Use this skill to scaffold, tune, validate, and evaluate Pi local wiki extension packages.

Reference: generalized wiki quality improvements.

Quality target

Aim for 90-95/100 confidence before considering a generated wiki complete. Confidence must come from observed tool behavior against realistic prompts, not just successful file generation.

Score every generated wiki on:

• Accuracy: corpus path/file types/format are correct; titles/headings match source; top search results include canonical pages; extracts answer the prompt with valid local citations.
• Effectiveness: setup/status/missing-docs behavior is clear; prompt routing is specific; diagnostics and safety language fit the domain; workflow is repeatable.
• Token output: search/read/extract outputs are bounded; exact-section extracts are preferred for final answers; omitted/truncated output is visible.

If any category is below 90/100, keep tuning or explicitly document why confidence remains lower.

Required workflow

1. Inspect available templates with list_wiki_templates or /wiki-templates when the template name is unclear.
2. Profile the corpus before or immediately after creation:
   • canonical docs path
   • repo/source URL
   • source format: markdown, asciidoc, or html
   • indexed file extensions
   • include/partial/generated-page behavior
   • broad corpus/domain terms that may need downweighting or stopwording
   • domain query expansions and aliases
3. Use create_wiki or /wiki-create for new local wiki packages. Prefer /wiki-create for interactive creation because it previews inferred values, confirms creation, validates, and can queue an agent tuning/review pass.
4. Tune generated package files before declaring success:
   • index.ts: CONFIG.format, CONFIG.fileExtensions, prompt detection, query expansions, stopwords/downweights, parser assumptions, cache/schema behavior.
   • For every created wiki, derive CONFIG.searchStopwords and CONFIG.termWeights from that wiki's own corpus/profile and simulation results. Keep generic language stopwords minimal, downweight only broad domain terms that demonstrably over-rank noisy pages, and do not reuse another wiki's terms without evidence.
   • skills/*/SKILL.md: precise source priority, compact search, search/sections/extract workflow, diagnostics, safety warnings, token discipline.
   • README.md and references/*: corpus profile, limitations, smoke-test findings, evaluation summary.
5. Use validate_wiki or /wiki-validate after creation or manual edits.
6. Run practical package checks when feasible:

   npm install --package-lock-only --ignore-scripts
   npm pack --dry-run
   bun build index.ts --target=node --outfile=/tmp/<pkg>-index-check.js
   

7. Run the generated smoke-test command/tool when docs are available to check title, heading, and link fidelity.
8. Evaluate with at least five realistic simulations across difficulty levels:
   • novice setup question
   • beginner configuration question
   • intermediate troubleshooting/API question
   • advanced system/architecture question
   • expert edge case or developer workflow
9. For each simulation, record top search results, selected page, section list size, extract size, matched sections, omitted/truncated state, and accuracy/effectiveness/token-output scores.
10. Prefer this answer workflow for generated wiki skills:

search -> sections -> exact section extract -> final answer with local citation

Query extraction is useful for exploration but can over-select sections on large pages. 11. Use update_wiki or /wiki-update only when the user wants to refresh scaffolded files from the template. Avoid overwriting customized files unless explicitly requested or the dry-run shows safe changes.