# jkz docs

> Human-in-the-loop multi-agent engineering — three phases, twelve roles, you as the final arbiter.

## Get started

- [An ad-hoc fix without the full pipeline](https://docs.j0kz.dev/get-started/ad-hoc-fix/): A hands-on first run of the lightweight path — ship a tiny fix with /jkz:quick (Builder + Judge, no plan, no QA), or just edit it inline when it's truly trivial. The fast loop for changes that don't earn an Architect.
- [Your first issue with a plan checkpoint](https://docs.j0kz.dev/get-started/first-issue-with-plan-checkpoint/): A hands-on first run driving the phases yourself (/jkz:plan, then /jkz:build, /jkz:review, /jkz:qa) so you feel the human-in-the-loop control at every phase boundary instead of letting the autonomous pipeline advance for you.
- [How jkz works](https://docs.j0kz.dev/get-started/how-jkz-works/): The three phases of the pipeline, the twelve roles, the multi-backend deliberation loop, and the human checkpoints that gate every merge.
- [Install & setup](https://docs.j0kz.dev/get-started/install/): Install jkz on a clean machine — prerequisites, the install command, standalone vs plugin, environment configuration, and the merge gate.
- [Quickstart](https://docs.j0kz.dev/get-started/quickstart/): Install jkz, run your first pipeline, and ship a change end-to-end.
- [Why jkz?](https://docs.j0kz.dev/get-started/why-jkz/): The problem jkz solves, the design constraints, and where it fits next to other agent frameworks.

## Concepts

- [Ambiguity gate](https://docs.j0kz.dev/concepts/ambiguity-gate/): The two inline checkpoints where jkz scans for ambiguity it should not resolve alone — how TRIVIAL, FIX, and DECIDE are classified, and why the gate fails open.
- [Context management](https://docs.j0kz.dev/concepts/context-management/): How jkz keeps a long-running pipeline inside the context window — snapshotting state before a compaction, compressing oversized context sections, and smart-truncating wrapper output without losing the verdict.
- [Cross-chat awareness](https://docs.j0kz.dev/concepts/cross-chat/): How jkz keeps several Claude Code sessions on the same project from colliding — issue ownership, the contested-issue stop, heartbeats, and session snapshots.
- [Evidence hierarchy](https://docs.j0kz.dev/concepts/evidence-hierarchy/): Why an adversarial verdict in jkz must rest on execution output or a file citation, never on reasoning alone — the three levels, and the gotchas that disguise level 3 as level 1.
- [Fallback](https://docs.j0kz.dev/concepts/fallback/): What happens when a model or a backend goes down — the automatic model retries and rate-limit cascade that recover silently, and the service-level failures that stop and ask a human to decide.
- [Issue types](https://docs.j0kz.dev/concepts/issue-types/): How jkz classifies work into feature, bug, refactor, and chore — and how that one label reshapes the plan focus, the review focus, and whether QA is required.
- [Merge gate](https://docs.j0kz.dev/concepts/merge-gate/): The four-layer, server-side enforcement that keeps merging to main a human-only act — why prompts alone are not enough, and how the passphrase checkpoint works.
- [Models & invocation](https://docs.j0kz.dev/concepts/models-and-invocation/): How jkz maps each role to a model and invokes it — the four model kinds, the create-challenge-confirm pattern they form, and the endpoint routing that decides which backend runs each role.
- [The pipeline](https://docs.j0kz.dev/concepts/pipeline/): The three-phase state machine behind jkz — how Plan, Build, and QA map to roles, why each phase iterates up to three times, and when QA is required.
- [Plugin mode](https://docs.j0kz.dev/concepts/plugin-mode/): How jkz installs into any project as a plugin — one command to wire up the pipeline, the dual-root layout that keeps source and state separate, and how to remove it without touching your data.
- [Signal format](https://docs.j0kz.dev/concepts/signal-format/): How agents communicate without talking to each other — the Context Protocol that feeds them, the verdict-json block that carries every PASS/FAIL decision, and the issue-proposal marker for out-of-scope work.
- [Worktree isolation](https://docs.j0kz.dev/concepts/worktree-isolation/): Why every issue and every agent gets its own git worktree, the two-layer layout, the lifecycle from ensure to cleanup, and the safety rails that stop cleanup from eating live work.

## Build

- [Lightweight routes — /jkz:quick & /jkz:fix](https://docs.j0kz.dev/build/lightweight-routes/): When a change is too small for the full pipeline. /jkz:quick runs Builder + Judge with no plan and no QA; /jkz:fix is the Doctor's surgical fix cycle. How the complexity classifier routes you here.
- [Run a pipeline — /jkz:pipeline end-to-end](https://docs.j0kz.dev/build/run-a-pipeline/): The operational walkthrough of /jkz:pipeline — what you type, what runs autonomously through Plan, Build, Review, and QA, and the four points where you decide. Includes the phase/role flow and every human checkpoint.

## Commands

- [ask](https://docs.j0kz.dev/commands/ask/): Ask an ad-hoc question to an external model (Codex or Gemini) without any pipeline context. Each call is ephemeral — no session carries over between invocations.
- [bugs](https://docs.j0kz.dev/commands/bugs/): Scan the codebase for bugs at three levels of depth — a fast deterministic pass, a deeper run that adds the test suite and cross-file analysis, and a full run that layers adversarial review on top. Advisory; it reports, it does not gate.
- [build](https://docs.j0kz.dev/commands/build/): The build phase. The Builder implements the approved plan inside an isolated worktree and opens the pull request — resumable, worktree-confined, and never able to merge.
- [calibrate](https://docs.j0kz.dev/commands/calibrate/): Promote significant memory-store patterns into validator agents' calibration sections through a three-model tribunal with minority veto, so learned signals sharpen future reviews.
- [commit](https://docs.j0kz.dev/commands/commit/): Reviews your staged changes with CodeRabbit before committing, applies the valid fixes in a bounded loop, then commits via the conventional-commit skill. No push unless you ask.
- [cost](https://docs.j0kz.dev/commands/cost/): Report the API-equivalent cost of a pipeline issue at any point — broken down by phase, role, and iteration, with CodeRabbit-driven rows flagged so you can see CR overhead at a glance.
- [cr-fix](https://docs.j0kz.dev/commands/cr-fix/): An automated loop over an open PR — CodeRabbit reviews, Claude classifies and fixes the valid findings, commits once, pushes, and resolves the addressed review threads. Out-of-scope findings become a separate issue.
- [debate](https://docs.j0kz.dev/commands/debate/): Run an on-demand adversarial debate between two or three models on any topic. Three phases — constructive, development, crystallization — with early termination on consensus, concession, or decisive evidence.
- [deps](https://docs.j0kz.dev/commands/deps/): A proactive dependency audit for the target project. Reports vulnerabilities, optionally applies safe fixes, previews breaking upgrades behind a confirmation gate, and escalates to a full supply-chain audit when the issue's compliance tier demands it.
- [deslop](https://docs.j0kz.dev/commands/deslop/): Clean AI-typical writing patterns from text — filler phrases, hedging, verbose constructions, em-dash overuse, redundant adverbs, and repetitive bullets. Preserves meaning and technical content; removes the fluff.
- [dev-self-review](https://docs.j0kz.dev/commands/dev-self-review/): A fresh subagent reviews your pending diff against the jkz integration checklist before you open a PR — catching cross-file and consistency issues that only show up when the change is read as a whole.
- [doc-sync](https://docs.j0kz.dev/commands/doc-sync/): Scans project state and compares it against auto-doc markers in the documentation, reporting where the docs have drifted. Optionally opens one issue per drifted doc so unactioned drift doesn't sit silently.
- [e2e](https://docs.j0kz.dev/commands/e2e/): Generate and run end-to-end browser tests against a running app. Opus explores the codebase to write scenarios, Sonnet executes them through agent-browser, and the run produces a report with screenshots. Manual and advisory — it never blocks the pipeline.
- [fix](https://docs.j0kz.dev/commands/fix/): The surgical repair cycle. When a reviewer returns FAIL, the Doctor takes the failing verdict, applies a minimal targeted fix, and re-triggers the phase that failed — up to three attempts before escalating.
- [health](https://docs.j0kz.dev/commands/health/): A full system health check — CLI version freshness, changelog review, relevance insights, and infrastructure status. The --fix flag auto-updates outdated CLIs and cleans stale worktrees; --deep adds auth, MCP, and notification checks.
- [insights](https://docs.j0kz.dev/commands/insights/): Analyze the deliberation history and surface pipeline metrics — pass rates, agent agreement, token usage, SLO status, groupthink signals, and optional skill-discovery candidates.
- [issue](https://docs.j0kz.dev/commands/issue/): The direct route to a well-formed issue. /jkz:issue takes a plan file or a free-text description and produces a labeled, classified GitHub issue — skipping the conversational exploration of /jkz:start while keeping the same enrichment, implementation gate, and alignment checks.
- [load](https://docs.j0kz.dev/commands/load/): Retrieve the most recent session snapshot — from this chat or another — and present what was done, decided, and left pending, so you can continue with full reasoning context instead of starting cold.
- [memory-promote](https://docs.j0kz.dev/commands/memory-promote/): Score a single memory file across five weighted dimensions and recommend whether to promote it to a rule, keep it, or archive it — behind a mandatory human checkpoint.
- [memory-review](https://docs.j0kz.dev/commands/memory-review/): Scan the Claude Code memory files for staleness, overlaps, redundancy against existing rules, and promotion candidates — then suggest concrete curation actions.
- [memory-status](https://docs.j0kz.dev/commands/memory-status/): A quick health dashboard for the Claude Code memory directory — total files, stale count, overlap pairs, and a by-type breakdown, with a one-line next step.
- [new-chat](https://docs.j0kz.dev/commands/new-chat/): Spin up a git worktree as a sibling directory on a fresh branch, so a second Claude Code window can work the same project without file or branch conflicts with your current session.
- [perf-audit](https://docs.j0kz.dev/commands/perf-audit/): Audit code for performance improvements against three strict criteria — needle-moving, isomorphic, and clear path. Only optimizations that pass all three are accepted and applied; everything else is rejected with an explanation.
- [pipeline](https://docs.j0kz.dev/commands/pipeline/): Run the full pipeline autonomously — Plan → Build → Review → QA → Completion. Plan approval is pre-flight; inside the loop you intervene three times: review approval, QA approval, and the manual merge.
- [plan](https://docs.j0kz.dev/commands/plan/): The planning phase. Architect drafts the implementation strategy, the Auditor challenges it, the Curator validates the audit — up to three iterations, then a mandatory human checkpoint before any code is written.
- [qa](https://docs.j0kz.dev/commands/qa/): The QA phase. Lens (frontend / accessibility) and Sentinel (backend / security) review the PR in parallel; a FAIL routes to the Doctor. The post-QA ambiguity gate is the last checkpoint before a human merges.
- [quality](https://docs.j0kz.dev/commands/quality/): An on-demand quality scan across thirteen categories — formatting, linting, security, dead code, TODOs, dependencies, coverage, and more. Optionally auto-fixes formatting and linting, files findings as an issue, or narrows to a single category.
- [quick](https://docs.j0kz.dev/commands/quick/): The minimum viable pipeline for small scoped changes. No Architect, no QA — the Builder implements the issue directly and the Judge is the sole reviewer, with the Doctor fixing on failure.
- [quit](https://docs.j0kz.dev/commands/quit/): The clean way to end a session. /jkz:quit fetches live PR state, saves context, reviews memory-promotion candidates, checks open and pipeline PRs, releases a finished worktree lock, and deregisters the chat — then tells you it's safe to close.
- [refine](https://docs.j0kz.dev/commands/refine/): A lightweight pre-plan step. /jkz:refine explores the codebase, asks targeted questions grounded in what it found, and writes a structured brief that the Architect and downstream agents consume automatically.
- [research](https://docs.j0kz.dev/commands/research/): Orchestrate a four-phase financial research pipeline — SCOPE → RESEARCH → AUDIT → OUTPUT — with an Analyst that gathers evidence, an adversarial audit loop, and generated deliverables. Resumable per topic.
- [resume](https://docs.j0kz.dev/commands/resume/): When a pipeline was interrupted — a crash, a stop, an expired lock — /jkz:resume diagnoses exactly where it stalled and what happened, then delegates to the right command to pick up from that point.
- [review](https://docs.j0kz.dev/commands/review/): The code-review phase. A CodeRabbit pre-scan and pre-push validators run first, then the Judge reviews the diff as a chaos engineer and the Inspector calibrates that review — a FAIL routes to the Doctor's fix cycle.
- [save](https://docs.j0kz.dev/commands/save/): Capture what this session did, decided, and learned — as a structured snapshot plus a human-readable context.md — so another chat or a future session can pick up exactly where this one left off.
- [ship](https://docs.j0kz.dev/commands/ship/): Runs format, lint, test, simplify, and the CodeRabbit pre-commit loop on the current branch — no pipeline state required. The pre-PR sequence for ad-hoc work, with a final opt-in push and PR.
- [simplify](https://docs.j0kz.dev/commands/simplify/): Review recently changed code for reuse opportunities, quality issues, and efficiency improvements, then apply the refinements. It changes HOW the code works, never WHAT it does — and it refuses to over-simplify.
- [skill-audit](https://docs.j0kz.dev/commands/skill-audit/): Scan skill files for security patterns — code injection, prompt injection, data exfiltration, jkz-specific violations, filesystem escape, and secret exposure. Returns a PASS / WARN / FAIL verdict with a per-finding breakdown.
- [start](https://docs.j0kz.dev/commands/start/): Arrive with a vague idea. jkz triages it, checks for duplicates, explores the codebase, asks targeted questions, writes a brief, creates a labeled GitHub issue, and recommends the right pipeline route.
- [status](https://docs.j0kz.dev/commands/status/): A read-only snapshot of the jkz pipeline — active issues and their phases, open PRs and their merge-gate state, recent agent activity, worktrees, dependencies, and system health.
- [vault](https://docs.j0kz.dev/commands/vault/): A persistent store for researched ideas. List, show, search, and manage vault items across the project and global scopes, with FTS5 full-text search and status tracking.

## Agents

- [Architect](https://docs.j0kz.dev/agents/architect/): The creative role that designs the implementation strategy in the Plan phase (scope before code) and produces a plan rigorous enough to survive adversarial audit.
- [Auditor](https://docs.j0kz.dev/agents/auditor/): The adversarial role that challenges the Architect's plan before any code exists — finding what is missing, vague, or will fail, gated by an evidence hierarchy to keep the challenge honest.
- [Builder](https://docs.j0kz.dev/agents/builder/): The creative role that implements an approved plan inside an isolated worktree and opens the pull request — Claude Opus, worktree-only writes, never merges.
- [Classifier](https://docs.j0kz.dev/agents/classifier/): The utility role that reads an incoming issue and decides how much pipeline it deserves (trivial, quick, or standard) so the work is routed before any model starts deliberating.
- [Curator](https://docs.j0kz.dev/agents/curator/): The validator role that reviews the Auditor's audit — calibrating severity, catching false positives and missed gaps, and acting as the mandatory tiebreaker that closes the Plan phase.
- [Doctor](https://docs.j0kz.dev/agents/doctor/): The creative fix role — surgical intervention on a failing verdict, the smallest correct change, up to three attempts before honest escalation to a human.
- [Inspector](https://docs.j0kz.dev/agents/inspector/): The validator that calibrates the Judge's review — confirms real bugs, exposes false positives with evidence, and finds what the Judge missed in logic and correctness.
- [Judge](https://docs.j0kz.dev/agents/judge/): The adversarial reviewer that chaos-engineers the PR diff — assumes a bug exists, runs the Fault Injection Checklist, and is the last technical gate before QA.
- [Lens](https://docs.j0kz.dev/agents/lens/): The QA-phase validator that owns the frontend — visual fidelity, multimodal output, and accessibility. Runs in parallel with Sentinel.
- [Librarian](https://docs.j0kz.dev/agents/librarian/): The utility role that indexes and retrieves project knowledge with source citations — it makes what we already decided findable, and never invents.
- [Orchestrator](https://docs.j0kz.dev/agents/orchestrator/): The runtime role (Claude Code itself) that directs the pipeline. It never plans, builds, reviews, or merges; it decides who acts next, when, and how to present the decision to you.
- [Sentinel](https://docs.j0kz.dev/agents/sentinel/): The QA-phase adversary that protects the operation — backend integrity, security, performance, and infrastructure. Runs in parallel with Lens.

## Subsystems

- [Automations & GitHub integration](https://docs.j0kz.dev/subsystems/automations-and-github/): jkz treats GitHub as its source of truth and its message bus. A small automations engine reacts to interval and event triggers, while a layer of best-effort integrations keeps labels, issue relationships, Check Runs, pinned comments, and a Projects board in sync with the pipeline — all fail-open, none of them able to block a merge.
- [Classifier & Alignment Validator](https://docs.j0kz.dev/subsystems/classifier-and-alignment/): The two entry gatekeepers that decide how an issue is handled before any agent deliberates — the complexity classifier that routes it, and the alignment validator that checks the issue body still matches what the user actually asked for.
- [CodeRabbit & Notifications](https://docs.j0kz.dev/subsystems/coderabbit/): Two cross-cutting subsystems — the CodeRabbit review bot that adds an independent review pass on every PR, and the notification layer that mirrors agent activity to Discord, Telegram, and GitHub and accepts approvals from your phone.
- [Hermes](https://docs.j0kz.dev/subsystems/hermes/): Hermes is jkz's always-on agent — a VPS container that runs the project's scheduled background work. How its cron scheduler is driven from a single registry, what the jobs are, and which LLM backends it uses.
- [Hooks](https://docs.j0kz.dev/subsystems/hooks/): jkz's hooks extend the Claude Code lifecycle with two distinct families — guard hooks that block dangerous actions before they run, and lifecycle hooks that react to session events for state-keeping and observability. How they are wired, why they fail open, and what the hook server does.
- [MCP servers](https://docs.j0kz.dev/subsystems/mcp-servers/): The Model Context Protocol servers jkz exposes and bundles — the jkz-pipeline server that lets any MCP client query and drive the pipeline, plus the finance data servers wired into the project.
- [Pattern learning loop](https://docs.j0kz.dev/subsystems/pattern-learning/): How jkz learns from its own deliberations — patterns extracted from agent verdicts are stored in SQLite, scored with time decay, re-injected into future prompts under a token budget, and corrected by validator feedback so the pipeline gets sharper over time instead of repeating itself.
- [Research & finance pipeline](https://docs.j0kz.dev/subsystems/research-finance/): How /jkz:research turns a question into an audited financial deliverable — the four-phase flow, its three dedicated agent roles, the finance MCP data sources it pulls from, and how Hermes runs it unattended.
- [Telegram bot](https://docs.j0kz.dev/subsystems/telegram-bot/): The always-on observability layer for jkz — an eleven-check monitoring loop every ten minutes, proactive task discovery, debounced alerts, and human-in-the-loop inline keyboards.
- [Wiki generator](https://docs.j0kz.dev/subsystems/wiki-generator/): The meta pipeline that builds this site — how jkz extracts documentation from a private repo, sanitizes every byte, generates pages with a model mix, guards against hallucination, and publishes to jkz-docs behind a human gate.

## Operations

- [Autonomy & auto-improvement](https://docs.j0kz.dev/operations/autonomy/): jkz is autonomous where execution is mechanical and human-gated where judgement matters. How the autonomy dial works, which decisions always stay the owner's, how the system proposes its own work through proactive discovery and smart maintenance, and how it sharpens its own prompts over time.
- [Maintenance & fallback runbook](https://docs.j0kz.dev/operations/maintenance-and-fallback/): Two operational safety nets — the on-demand maintenance workflow that keeps the repository from rotting, and the fallback chain that keeps the pipeline running when a model 404s, a backend rate-limits, or a whole service goes dark. How to trigger each, what it does, and which failures stop and ask you to decide.
- [Memory](https://docs.j0kz.dev/operations/memory/): How jkz remembers. Three layers — file-based auto-memory that survives across sessions, per-agent notebooks, and a SQLite pattern-learning store — plus the recall and promotion flow that decides what gets carried forward, and the subagents that keep it honest.
- [Mutation testing](https://docs.j0kz.dev/operations/mutation-testing/): How jkz measures whether its test suite catches real regressions — what mutation testing is, how to run it locally with Stryker, where the reports land, the current per-module scores, and how to read killed-versus-survived results.
- [Releasing](https://docs.j0kz.dev/operations/releasing/): The manual release process for jkz — moving the changelog, tagging, and pushing, plus the local validation that mirrors what CI checks before the GitHub Release is cut.
- [SemVer policy](https://docs.j0kz.dev/operations/semver/): How jkz chooses the next version number — which surfaces are part of the public contract and force a MAJOR bump, which are internal and never do, and the MAJOR/MINOR/PATCH and deprecation rules that decide every release.
- [SLOs & monitoring](https://docs.j0kz.dev/operations/slos-and-monitoring/): jkz watches its own health on two timescales — four Service Level Objectives that hold the 30-day pipeline quality bar, and a monitoring loop that runs eleven health checks every ten minutes. What each one measures, how it is evaluated, and when it raises an alert.
- [State schema](https://docs.j0kz.dev/operations/state-schema/): What lives under state/ — the pipeline's runtime memory on disk. Pipeline JSON files and their formal contract with the UI server, plus the surrounding store of deliberations, locks, snapshots, circuit breakers, and SQLite databases that keep a run observable and recoverable.
- [Troubleshooting](https://docs.j0kz.dev/operations/troubleshooting/): A symptom-first reference for the jkz pipeline. Find the error message or behavior you are seeing, jump to the cause, and apply the fix — grouped by where the problem lives, from the Claude Code sandbox and Windows quirks to GitHub, phases, the MCP server, and external models.

## Reference

- [Architecture](https://docs.j0kz.dev/reference/architecture/): **scripts** -- Operational and pipeline scripts. **agents** -- Agent system prompts and configuration. **.claude/skills** -- Reusable Claude Code skill definiti
- [Changelog](https://docs.j0kz.dev/reference/changelog/): Release history for j0KZ/jkz_Multi-Agent_System
- [CLI / commands](https://docs.j0kz.dev/reference/cli/): The /jkz:* slash commands — what each does, when to reach for it, and which models run the work behind it.
- [Design decisions](https://docs.j0kz.dev/reference/design-decisions/): Architecture decision records for jkz — why the pipeline uses multiple backends, why creative roles are fixed on Opus, why adversarial roles require external backends, the fallback tiers, and the docs site tooling choice.
- [Glossary](https://docs.j0kz.dev/reference/glossary/): Canonical system vocabulary — agents, signals, phases, and pipeline mechanisms, ordered alphabetically.
- [Labels](https://docs.j0kz.dev/reference/labels/): GitHub label ownership and transitions — who adds each label, who may remove it, and the legal phase transitions.
- [Scripts](https://docs.j0kz.dev/reference/scripts/): Catalog of the most-referenced scripts in scripts/ — pipeline core, model wrappers, validators, monitoring, GitHub integration, and observability.
- [Skills](https://docs.j0kz.dev/reference/skills/): Catalog of the 39 skills in .claude/skills/ — one-line purpose and trigger for each, grouped by framework, QA, model router, and utility.
- [Validators](https://docs.j0kz.dev/reference/validators/): Deterministic pre-validated checks that run against the diff before push — secrets, TODOs, stubs, capability invariants, and AI-writing artifacts.

## Wiki generator internals

- [skills/wiki-generator/src](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src/): Module skills/wiki-generator/src
- [skills/wiki-generator/src/classifiers](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_classifiers/): Module skills/wiki-generator/src/classifiers
- [skills/wiki-generator/src/config](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_config/): Module skills/wiki-generator/src/config
- [skills/wiki-generator/src/deslop](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_deslop/): Module skills/wiki-generator/src/deslop
- [skills/wiki-generator/src/diff](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_diff/): Module skills/wiki-generator/src/diff
- [skills/wiki-generator/src/diff/lib](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_diff_lib/): Module skills/wiki-generator/src/diff/lib
- [skills/wiki-generator/src/extractors](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_extractors/): Module skills/wiki-generator/src/extractors
- [skills/wiki-generator/src/generators](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_generators/): Module skills/wiki-generator/src/generators
- [skills/wiki-generator/src/guards](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_guards/): Module skills/wiki-generator/src/guards
- [skills/wiki-generator/src/publisher](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_publisher/): Module skills/wiki-generator/src/publisher
- [skills/wiki-generator/src/sanitizers](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_sanitizers/): Module skills/wiki-generator/src/sanitizers
- [skills/wiki-generator/src/state](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_state/): Module skills/wiki-generator/src/state
- [skills/wiki-generator/src/utils](https://docs.j0kz.dev/wiki-generator-internals/skills_wiki-generator_src_utils/): Module skills/wiki-generator/src/utils

## API reference

- [API reference](https://docs.j0kz.dev/api-reference/): Auto-generated module reference for jkz — exports, signatures, params, and returns, refreshed daily by the wiki-generator pipeline.
- [skills/wiki-generator/src](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src/): Module skills/wiki-generator/src
- [skills/wiki-generator/src/classifiers](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_classifiers/): Module skills/wiki-generator/src/classifiers
- [skills/wiki-generator/src/config](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_config/): Module skills/wiki-generator/src/config
- [skills/wiki-generator/src/diff](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_diff/): Module skills/wiki-generator/src/diff
- [skills/wiki-generator/src/diff/lib](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_diff_lib/): Module skills/wiki-generator/src/diff/lib
- [skills/wiki-generator/src/extractors](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_extractors/): Module skills/wiki-generator/src/extractors
- [skills/wiki-generator/src/generators](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_generators/): Module skills/wiki-generator/src/generators
- [skills/wiki-generator/src/guards](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_guards/): Module skills/wiki-generator/src/guards
- [skills/wiki-generator/src/publisher](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_publisher/): Module skills/wiki-generator/src/publisher
- [skills/wiki-generator/src/sanitizers](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_sanitizers/): Module skills/wiki-generator/src/sanitizers
- [skills/wiki-generator/src/state](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_state/): Module skills/wiki-generator/src/state
- [skills/wiki-generator/src/utils](https://docs.j0kz.dev/api-reference/skills_wiki-generator_src_utils/): Module skills/wiki-generator/src/utils
- [src](https://docs.j0kz.dev/api-reference/src/): Module src
- [src/classifiers](https://docs.j0kz.dev/api-reference/src_classifiers/): Module src/classifiers
- [src/config](https://docs.j0kz.dev/api-reference/src_config/): Module src/config
- [src/diff](https://docs.j0kz.dev/api-reference/src_diff/): Module src/diff
- [src/diff/lib](https://docs.j0kz.dev/api-reference/src_diff_lib/): Module src/diff/lib
- [src/extractors](https://docs.j0kz.dev/api-reference/src_extractors/): Module src/extractors
- [src/generators](https://docs.j0kz.dev/api-reference/src_generators/): Module src/generators
- [src/guards](https://docs.j0kz.dev/api-reference/src_guards/): Module src/guards
- [src/publisher](https://docs.j0kz.dev/api-reference/src_publisher/): Module src/publisher
- [src/sanitizers](https://docs.j0kz.dev/api-reference/src_sanitizers/): Module src/sanitizers
- [src/state](https://docs.j0kz.dev/api-reference/src_state/): Module src/state
- [src/utils](https://docs.j0kz.dev/api-reference/src_utils/): Module src/utils

## Section mirrors

Full page text split by section, same shape as `llms-full.txt`. Fetch one
of these instead of the whole site when you only need a single topic.

- [Home](https://docs.j0kz.dev/llms-home.txt): 1 page, ~2 KB — full text of the Home section.
- [Get started](https://docs.j0kz.dev/llms-get-started.txt): 6 pages, ~44 KB — full text of the Get started section.
- [Concepts](https://docs.j0kz.dev/llms-concepts.txt): 12 pages, ~55 KB — full text of the Concepts section.
- [Build](https://docs.j0kz.dev/llms-build.txt): 2 pages, ~14 KB — full text of the Build section.
- [Commands](https://docs.j0kz.dev/llms-commands.txt): 40 pages, ~105 KB — full text of the Commands section.
- [Agents](https://docs.j0kz.dev/llms-agents.txt): 12 pages, ~40 KB — full text of the Agents section.
- [Subsystems](https://docs.j0kz.dev/llms-subsystems.txt): 10 pages, ~79 KB — full text of the Subsystems section.
- [Operations](https://docs.j0kz.dev/llms-operations.txt): 9 pages, ~70 KB — full text of the Operations section.
- [Reference](https://docs.j0kz.dev/llms-reference.txt): 9 pages, ~182 KB — full text of the Reference section.
- [Wiki generator internals](https://docs.j0kz.dev/llms-wiki-generator-internals.txt): 13 pages, ~58 KB — full text of the Wiki generator internals section.
- [API reference](https://docs.j0kz.dev/llms-api-reference.txt): 25 pages, ~98 KB — full text of the API reference section.