Improving The LLM Wiki Setup Wizard And Public Guidance - Source Excerpt 01 - Improving the LLM Wiki Setup Wizard and Public Guidance

Back to Improving The LLM Wiki Setup Wizard And Public Guidance

Summary

This source excerpt begins near Improving the LLM Wiki Setup Wizard and Public Guidance and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving the LLM Wiki Setup Wizard and Public Guidance.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving the LLM Wiki Setup Wizard and Public Guidance.md

# Improving the LLM Wiki Setup Wizard and Public Guidance

## Executive summary

The current public experience already has a strong conceptual core. `LLMWikis.org` clearly positions itself as a handbook for building durable, reviewable, citation-aware “LLM Wikis,” and the site already exposes useful primitives such as a handbook landing page, a setup wizard, a starter bundle, a metadata standard, a structure standard, `llms.txt`, and explicit authority boundaries with UAIX. The wizard also does something unusually thoughtful: it serves both a human-visible form and a visitor-AI digest on the same public URL. Those are real strengths. citeturn4view0turn4view1turn4view2turn4view3turn4view4turn5view2turn6view3

The main problem is not lack of substance. It is that the public guidance and the wizard are currently **expert-first instead of newcomer-first**. The wizard says it is “step by step,” but the visible question set quickly expands into multisite routing, Git preflight, mutable runtime artifacts, context budgets, duplicate-file policy, graph storage models, claim/source-span rules, GraphRAG planning, and Project Handoff branches. At the same time, the site repeats multiple navigation bars on each page, uses shallow breadcrumbs, and explicitly says that multilingual support is not yet available. There is also no public evidence of a user-facing validation layer beyond local draft saving and a generated packet. citeturn4view1turn5view0turn5view1turn35view3turn36view1turn36view4turn4view0

The second major problem is **discoverability and canonical clarity**. The handbook homepage links to `sitemap.xml`, while `robots.txt` points to `wp-sitemap.xml`. Meanwhile, wiki.fftac.org publicly says that LLMWikis is the handbook source, yet wiki.fftac.org still publishes adjacent concept and recovered-source pages that can compete for overlapping user intent. Google’s canonical, breadcrumb, multilingual, title-link, and snippet guidance all point in the same direction: make ownership, URL intent, hierarchy, and language handling explicit in code and navigation, not just in explanatory copy. citeturn3view2turn6view0turn0search1turn0search2turn0search3turn8search3turn30search0turn30search1turn30search2turn30search3turn30search6

The highest-confidence recommendation is to ship a **foundational simplification pass** before anything more ambitious. In practice, that means: define a clearer public information architecture, reduce repeated navigation chrome, turn the wizard into a progressive-disclosure flow with presets, add explicit inline validation and review checkpoints, repair SEO/discovery signals, and instrument the experience so future changes can be measured. Comparable documentation systems consistently converge on the same patterns: explicit sidebars or section trees, short install or quick-start paths, redirects on rename, built-in analytics or search analytics, versioning or localization support, and progressively advanced configuration rather than front-loading everything. citeturn27search0turn27search1turn27search2turn27search4turn27search5turn27search6turn27search7turn33search2

A practical order of operations emerges from the evidence. First, clarify domain roles and the URL/content model. Second, rewrite the public “Start Here” and wizard introductions so they lead with user goals instead of architecture jargon. Third, replace the current wizard’s long expert checklist with a shorter guided flow that branches only when needed. Fourth, add technical hygiene: canonical URLs, structured breadcrumbs, descriptions, sitemap consistency, redirects, screen-reader and reflow checks, and event instrumentation. Fifth, prepare for internationalization even if translation is phased later. That sequence addresses the largest sources of user friction and search ambiguity with the least implementation risk. citeturn4view0turn4view1turn12view2turn29search1turn29search2turn29search6turn29search15turn30search1turn30search3turn30search6

## Current-state audit

The current public experience is best understood as a **high-quality concept library wrapped around a too-dense onboarding layer**. The homepage provides a useful narrative arc—Understand, Design and build, Operate and govern, Integrate—and it makes the site’s role clear. “Start Here” is also directionally good: it explains the three-layer model, defines starter vocabulary, and tells first-time builders not to dump every file they own into the system. The metadata and structure standards are similarly solid as governance documentation. citeturn4view0turn4view2turn5view4turn4view3turn4view4turn11view1turn11view2

Where the current state breaks down is in the **public interaction model**. On sampled pages, the site displays a skip link, a global top navigation, a second “Menu” strip, and a “Source map” strip before the main content. That helps expose routes, but it also increases visual repetition, keyboard tab burden, and above-the-fold density—especially on smaller screens. Breadcrumbs are present, but they are shallow and inconsistent, typically just “Home > [page],” which gives little hierarchical context. The result is a site that is rich in links but weaker in information scent than it should be. citeturn4view1turn4view2turn4view3turn4view4turn29search6turn29search18

The setup wizard is the clearest example of the core UX problem. It declares a seven-step process, saves drafts only in the current browser, and generates a packet plus JSON companion. But by the visible “Scope and audience” and “Architecture and navigation” sections, the user is already being asked to reason about project stage, collaboration model, audience, root URL, coding-standards path, workspace targeting policy, git health checks, mutable runtime artifacts, context-budget policy, large-file handling, duplicate-file policy, graph strategy, graph export rules, evidence trails, and promotion targets. For experienced operators this is impressive. For first-time builders it is likely overwhelming. GOV.UK and NN/g both recommend wizard structures that focus on one question per page, support branching, and reserve wizard-like flows for infrequent, complex tasks; this wizard matches the “complex task” condition but not yet the “minimal, well-sequenced input” part. citeturn5view0turn5view1turn5view2turn36view4turn29search1turn29search2turn29search4turn29search7

The table below summarizes the audit across the requested dimensions.