domain-wiki-builder

name	domain-wiki-builder
description	Bootstrap or refresh a schema-first, agent-retrievable knowledge base (sources/ + wiki/ layers, YAML frontmatter, id cross-references) for a technical domain, generalized from the KernelWiki pattern. Triggers on "build a wiki for X", "do what KernelWiki does for Y", "帮我做一个X领域的agent知识库", "把这个领域的资料整理成可检索的wiki", "用workflow构建<domain>wiki", "refresh the domain wiki". Do NOT use for a single one-off research question (use deep-research instead) or to query a wiki this skill already built (that wiki's own generated SKILL.md/scripts handle queries, not this one).
argument-hint	domain=<name> seeds=<repo/doc/blog list> outputDir=<path>
allowed-tools	Workflow Bash Read Write Glob Grep

Domain Wiki Builder

Generalizes the retrieval architecture observed in KernelWiki (~/code/KernelWiki or wherever that repo is checked out) to an arbitrary technical domain: raw evidence lives in sources/, synthesized cross-referenced knowledge lives in wiki/, every page carries YAML frontmatter with a globally unique id, and retrieval is grep/filter over structured fields rather than embeddings. See that repo's CLAUDE.md for the fully worked-out schema this pattern is derived from.

When to use

Use when the user is about to do sustained, recurring work in a new technical domain and wants a persistent knowledge base that future agent sessions can query cheaply — not a one-off answer. Signs this applies: the user names a domain and a set of seed sources (repos, docs sites, blogs) and wants them turned into structured, queryable pages.

Do not use for a single research question with no need for a persistent artifact — that's deep-research. Do not use this skill to query a wiki it already built — once built, the wiki should get its own query-side tooling (see "Known gap" below); this skill only covers the build/refresh pipeline.

Why the build pipeline runs as a Workflow, not ad hoc agent calls

The pipeline has five stages: discover candidates per seed, triage each candidate (include/defer/exclude), synthesize one source page per included candidate, cluster all source pages into wiki topics, synthesize one wiki page per cluster, then validate. The first three stages are independent per-item work — discovery is naturally parallel across seeds, triage/synthesis naturally pipeline per candidate so one candidate can be mid-synthesis while another is still being triaged. The cluster stage is a genuine barrier: it needs every source page written so far to decide topic groupings, so it cannot pipeline. Validation must stay a literal check (duplicate ids, missing required fields, dangling sources: references) run by an agent with Bash/Grep, not a judgment call — that is what keeps a rebuilt/refreshed wiki safe to point retrieval scripts at later. This shape is exactly what the Workflow tool's pipeline()/parallel() primitives are for, so the pipeline is implemented as a workflow script rather than as sequential Task calls in the main loop.

Invocation contract

Building or refreshing a domain wiki is multi-agent orchestration and follows the same opt-in rule as any other Workflow use: only run it when the user has explicitly asked for workflow/multi-agent orchestration in their own words (e.g. "用 workflow 构建 CUDA graph 优化 wiki", "fan out agents to build a wiki for X"). Given that, call:

Workflow({
  scriptPath: "<this skill's directory>/workflows/build-domain-wiki.js",
  args: {
    domain: "<short domain name, e.g. 'CUDA graph capture optimization'>",
    seeds: [
      { name: "pytorch/pytorch", kind: "repo", location: "github.com/pytorch/pytorch" },
      { name: "official docs", kind: "doc-site", location: "https://..." }
    ],
    outputDir: "<absolute path to write sources/ and wiki/ under>",
    tagWhitelist: ["tag-a", "tag-b"],
    schemaHint: "optional: override the default frontmatter field list"
  }
})

The script is at workflows/build-domain-wiki.js in this skill directory — read it before invoking if you need to explain the exact prompts each stage sends. It has been run end-to-end against the real Workflow engine on a live domain (see "Known issue (fixed)" below) and passed independent verification.

Pass args as a literal object in the Workflow() tool call, not as a JSON string. The script normalizes either shape (see below), but a real object is the documented calling convention and avoids relying on the fallback.

Known issue (fixed) — args delivered as a JSON string

Symptom: first live invocation (session 67f6d725, curryGPU project, 2026-07-13) returned instantly with {"error":"missing_required_args"} and 0 agents spawned, even though a complete args object was passed to Workflow().

Root cause: the tool call carried args as a JSON-encoded string rather than an already-parsed object. The script's original guard did !args.domain etc. directly, so on a string args.domain was undefined and the guard fired before any agent ran.

Fix: a normalization shim now runs before the guard —

const A = typeof args === 'string' ? JSON.parse(args) : (args || {})

— and every downstream reference uses A. instead of args., so the pipeline accepts either an object or a JSON-string payload.

Verification performed this session (independent of the session that introduced the fix): reconstructed the script's meta block + body into two standalone Node harnesses with stub agent/parallel/pipeline/log/phase — one invoking the body with args as a real object, one with args as JSON.stringify(...) of the same payload (reproducing the exact failure shape from session 67f6d725). Both ran all six phases to completion and returned domain threaded through correctly, with no missing_required_args error. Artifacts: /tmp/claude-1006/-home-yanggl-code-KernelWiki/8077244b-b9d8-4abc-b3e4-89c6786e9ce9/scratchpad/verify-args-object.mjs (exit 0), /tmp/claude-1006/-home-yanggl-code-KernelWiki/8077244b-b9d8-4abc-b3e4-89c6786e9ce9/scratchpad/verify-args-string.mjs (exit 0) — both are session-scratchpad paths, not checked into this skill; re-derivable from the script by wrapping its body in an async IIFE with stub globals. Not re-verified this session: the real Workflow engine's actual argument-marshaling path (the harnesses stub the runtime rather than invoking it) and the live-domain synthesis quality — those were validated in session 67f6d725 itself (556 agents, 0 errors, 163 source pages + 40 wiki pages, independently PASS-verified by a separate general-purpose/opus agent against the same corpus).

args fields

Field	Required	Meaning
domain	yes	Short description of the domain; threaded into every agent prompt
seeds	yes	Array of {name, kind, location} — repos, doc sites, blogs, etc. to discover candidates from
outputDir	yes	Absolute path; the script writes outputDir/sources/*.md and outputDir/wiki/*.md
tagWhitelist	no	Controlled vocabulary to steer triage/synthesis tagging; omit to let agents propose tags freely
schemaHint	no	Free-text frontmatter requirement; defaults to id/title/type/tags (+url/captured_at for sources)

The workflow returns { domain, discovered, included, sourcePages, wikiPages, validation } — check validation.errors before trusting the output; a non-empty errors[] means the corpus has duplicate ids, missing fields, or dangling cross-references and should not be shipped as-is.

Known gap — not yet built

This skill currently only covers the build side. KernelWiki's retrieval side (scripts/query.py, get_page.py, grep_wiki.py, validate.py, data/schemas.yaml/tags.yaml/aliases.yaml) has not been generalized into this skill yet — a domain wiki built by this workflow must be queried with plain Read/Grep until those generic scripts exist. Flagging this explicitly rather than implying it works end-to-end: do not claim a built wiki has KernelWiki-equivalent query ergonomics until that follow-up is done.