Wiki Tools

Wiki Tools

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

Reference: [generalized wiki quality improvements](references/generalized-wiki-quality-improvements.md).

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

1. 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.
2. 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.

1. Use validate_wiki or /wiki-validate after creation or manual edits.
2. Run practical package checks when feasible:

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

1. Run the generated smoke-test command/tool when docs are available to check title, heading, and link fidelity.
2. 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

1. 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.
2. Prefer this answer workflow for generated wiki skills:

``txt search -> sections -> exact section extract -> final answer with local citation `` Query extraction is useful for exploration but can over-select sections on large pages.

1. 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.

User commands

• /wiki-templates
• /wiki-create [--repo-url URL] [--target-dir DIR] [--doc-format markdown|asciidoc|html] [--dry-run] [--overwrite] [--yes] [--agent-review] [--no-agent-review]
• /wiki-update --target-dir DIR [--overwrite] [--apply]
• /wiki-validate

The create/update commands also accept a JSON object after the command. If the first argument is a repository URL, infer repoUrl, topicName, extensionId, package names, docs path, tool prefix, setup command, and only broadly safe corpus-format hints from the URL unless the user overrides them. Search stopwords/downweights should be tuned during the agent review from observed corpus behavior, not hard-coded into the general scaffold. Generic repository basenames like documentation, docs, doc, wiki, and website should not become the topic; use the repository owner or known project identity instead.

/wiki-create is intentionally interactive in UI mode. Use --yes --no-agent-review only for old non-interactive scaffold-only behavior.

Naming defaults

For a new topic named Example:

• package directory: pi-extension-example-wiki-local
• package name: @firstpick/pi-extension-example-wiki-local
• extension id: example
• skill name: example-local
• setup command: /example-wiki-local-setup
• tool prefix: example_wiki_*
• parser format: markdown by default; use asciidoc for .adoc corpora and html for rendered/static HTML corpora
• search tuning: query expansions plus corpus-derived stopwords/downweights for broad terms

Evaluation report expectations

Save a concise report when tuning a generated wiki, typically under references/ in the generated package. Include:

• corpus profile
• simulation table with scores
• output-size observations
• concrete failure modes
• changes applied
• remaining caveats
• final confidence level

For AsciiDoc corpora, explicitly verify that code comments and delimited blocks are not parsed as headings and that include-heavy parent pages produce useful output.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Firstp1ck
• Source: Firstp1ck/pi-coding-agent-forge
• License: MIT

Install and usage instructions live in the source repository linked above.