Repository navigation
FAQ
Fifteen questions that come up before, during and after a run, answered from the source at 7e17a11, the kit's documented field history, and this wiki run's own measurements. Longer treatments are linked from each answer.
- Does the kit write the wiki itself?
- Which agents can operate it?
- Does it work with private repositories?
- The subject is not a PHP web app. Now what?
- Can I use the auditor on a wiki I already have?
- The repository already has a wiki with pages. Will publishing destroy it?
- How long does a full run take, and what does it cost?
- What Python and platforms are covered?
- What actually goes over the network during a run?
- Are the probe payloads dangerous?
- The auditor reported 300 errors on a wiki that looks fine. What now?
- Why do my wiki-links work locally but die on GitHub?
- Where do I record things the wiki must never claim?
- My session died mid-run. What survives?
- Can I reuse the output somewhere other than a GitHub wiki?
- What is the license, and may I fork the tools?
- See also
No. It has no text generator and makes no model API calls — the twelve Python files import only the standard library, and the scan's external-host inventory shows no AI endpoints anywhere in the tool code. What the kit does is everything around the writing: inventory the subject, run it, capture evidence, scaffold QA-clean skeletons, audit the result to zero errors, and package the delivery. The prose is written by the agent (or human) operating it, under the one rule: every claim traced to a source line or reproduced by execution. See Features and Verification Model.
Any tool-using agent that can run shell commands and write files: Claude Code (the SKILL.md follows the Agent Skills format — YAML frontmatter with name, description, license), Codex-class agents, or custom harnesses. PROMPT.md is the entry point for a human driving an agent: a paste-ready task prompt in which only the header block (repo URL, stack, entry points, audience, size target) changes between projects. A human can also run the whole pipeline by hand at a terminal — nothing requires a model at runtime.
Yes, wherever your agent can git clone the subject. The kit itself talks to the network in exactly three places: bootstrap (distro packages, optional Sury recipe), publish.sh (cloning the .wiki.git remote), and the probe helpers (localhost or a URL you supply). Private subjects never leave the machine; private wikis publish with your own credentials via the PUBLISH.md hand-over options.
Three adaptation paths, all documented and one verified in this run: a different server — pass --serve-cmd (node {root}/server.js, python3 -m http.server {port} -d {root}; the static-app path measured at T10); a CLI — skip serve.py, write a driver that shells out and records stdout/stderr/exit codes in the same evidence shape; a library — execute every documented recipe in a clean venv; the recipes are the probe surface. repo_scan.py extracts symbols for nine languages and detects manifests for eight ecosystems regardless. See Research and Probing Guide.
Yes — qa_wiki.py takes any directory of wiki Markdown:
python3 qa/qa_wiki.py path/to/existing.wiki --strictIt audits links, anchors (GitHub's slug algorithm), structure, alerts, fences, mermaid, shell/Python blocks, filler, emoji, and optionally terminology and banned claims. This is the "audit/improve an existing wiki for accuracy" use case SKILL.md lists. Run --self-test once first — the standard discipline.
No. publish.sh clones the existing .wiki.git history and commits on top; force-push appears nowhere in the script, and PUBLISHING.md opens with the rule ("A GitHub repository — including a wiki repository — may already contain the owner's commits. --force destroys them."). When histories are unrelated (bundle applies), the documented flow is git merge --allow-unrelated-histories. Placeholder Home.md from the GitHub UI gets overwritten by your Home.md as a normal commit — recoverable like any git change.
The measured effort split from the reference run: research ~40%, wiki architecture ~3%, writing ~45%, QA + delivery ~12% — for 20 pages / ~73k words. The tooling itself is seconds: the scan brief is "two minutes of reading", the full MD.Viewer battery ran in 0.46 s (T14), the audit of a 22-file wiki runs in well under a second. The real cost is agent tokens for reading source and writing prose; the recovery files exist so an interrupted run does not pay it twice.
The README floor is Python 3.8+; CI runs 3.9, 3.11 and 3.12 on ubuntu-latest; this wiki was verified on 3.11.2. One self-test fixture was made platform-independent in 7e17a11 (the unwritable-path trick now works on Windows too), and CHANGELOG 1.2.1 records CI steps verified under bash -e and sh -e on Windows — but the tested-and-gated target is Linux; treat other platforms as best-effort until you have run the self-tests there.
Bootstrap: your distro's package mirrors (plus packages.sury.org and raw.githubusercontent.com if you enable the PHP-8.3 recipe), and three egress probes to GitHub domains. Probing: nothing — staged servers bind 127.0.0.1. Publishing: one git clone of the .wiki.git remote (and a push only with --push and credentials). If your sandbox has no egress, everything except clone/publish still works on pre-cloned inputs.
They are attack payloads — path traversal, XSS, SSTI, command injection, SQLi, CRLF — fired at whatever URL you give them. The kit's design keeps this contained: --repo mode stages a throwaway copy in a temp directory on localhost and kills it after; that is the intended target. Pointing --base-url at a live system you do not own or are not authorized to test is misuse. Evidence files may capture sensitive response data; review before sharing. Full doctrine: Security Considerations.
Suspect the checker before the wiki — it happened three times in the kit's own history (381, 12 and 235 phantom errors from three separate bugs). The procedure: verify one reported case by hand; run --self-test (22 detections must pass); if the self-test fails, the checker is broken — fix it before trusting any clean run. PITFALLS D2 is the written form of this scar. See Troubleshooting.
Almost always the filename rule: GitHub maps spaces in a wiki filename to hyphens in the URL and resolves [[Page Name]] against that. Security Hardening Guide.md + [[Security Hardening Guide]] works; Security-Hardening-Guide.md makes the same link dead. The auditor detects this (its error even prints the "name files with SPACES" hint when it sees the hyphenated twin). Second cause: anchors — GitHub's slug algorithm does not collapse repeated hyphens; run fix_toc.py instead of hand-writing slugs.
research/sources.md §D during Phase 1 (claims deliberately not made, each with a reason), mirrored into ban.json for enforcement. This wiki's own §D grew to 18 entries — including stale numbers ("the trap count is 31, not the older figure"), unverified platform claims, and figures that must be cited as measurements rather than transcribed. The ban loader skips _-prefixed documentation keys, downgrades negated mentions to warnings, and reports exemptions as INFO. See QA and Audit Guide.
Everything under the workspace root, if you kept the discipline: STATE.md (orientation + next single action), PROGRESS.json (per-page status), REWORK-STATE.md (resume recipe + append-only log), research/ (with facts.json + sources.md enough to resume writing without re-reading the subject), and any snapshot.sh commits. The reference datum: a hard interruption in the middle of Phase 4 cost zero work because those files were current. What does not survive: anything in /tmp, anything in snapshot-excluded directories, and un-snapshotted in-flight edits. See Sandbox Survival Guide.
The deliverable is plain GFM Markdown — it ports to MkDocs/Docusaurus (adjust [[wiki-links]] to relative .md links and keep the slug rules), to a docs/ tree in the repo, or to any Markdown host. The auditor is wiki-shaped (sidebar/footer coverage, [[…]] links), so re-point its link conventions if you fork it. Mermaid, alerts and tables render on any GFM-current platform.
MIT (standard text, verified by the scan's license reader). The README's maintenance note asks the one thing the license cannot: if a run improves a tool — and each new subject surfaces an edge case — commit the improvement back. This wiki run did exactly that (a scaffold footer defect, fixed and recorded in Extending the Kit).
- Home — start here if you are new
- Getting Started — the first run, command by command
- Comparison with Alternatives — when a hosted AI wiki is the better tool
- Troubleshooting — when an answer above did not cover your error
- Glossary — the vocabulary these answers use
github-wiki-llm-writer 1.2.1 · MIT · Repository · Report an issue · Home · Glossary · FAQ · Troubleshooting
Facts in this wiki are verified against the source at commit 7e17a11; see Changelog and Versioning.
Home Getting Started Features and Verification Model Comparison with Alternatives
Installation and Setup Configuration Reference
The Four Phase Workflow Research and Probing Guide Writing Pages Guide QA and Audit Guide
Publishing and Delivery Security Considerations Sandbox Survival Guide Extending the Kit
Tool Reference Architecture Troubleshooting FAQ Changelog and Versioning Glossary
1.2.1 · MIT