/* Generated from Zero skill data. Run node --experimental-strip-types --disable-warning=ExperimentalWarning scripts/embed-skill-data.mts to refresh. */ #ifndef ZERO_EMBEDDED_SKILLS_INC #define ZERO_EMBEDDED_SKILLS_INC typedef struct { const char *name; const char *description; bool hidden; const char *const *content; } ZeroEmbeddedSkill; static const char *const zero_embedded_skill_agent_chunks[] = { "---\nname: agent\ndescription: Graph-first agent workflow for making focused Zero changes with CLI feedback.\n---\n\n# Zero Agent Workflow\n\nUse this when editing Zero code. `zero.graph` is compiler input; `.0` is the human projection. Use JSON only when another tool must parse stable fields.\n\n## Edit Through Patch\n\nAnchored edits win. Do not retype a function for one line or rewrite `.0` for one declaration.\n\n1. `--replace-in-fn`: edit one function's canonical body text.\n\n```sh\nzero patch . --replace-in-fn handleLine --old 'limit + 1' --new 'limit + 2'\n```\n\n`--old` must match `zero view --fn ` output exactly once.\n\n2. `--replace-fn` for one whole body:\n\n```sh\nzero patch . --replace-fn greet --body-file - <<'EOF'\ncheck world.out.write(\"hello agent\\n\")\nEOF\n```\n\n3. Declaration work stays in ops; call sites update:\n\n```sh\nzero patch . --op 'setConst name=\"limit\" value=\"64\"'\nzero patch . --op 'addParamTo fn=\"scan\" name=\"bias\" type=\"i32\" default=\"0\"' # updates every call site\nzero patch . --op 'setReturnType fn=\"scan\" type=\"i64\"'\n```\n\n4. New helpers stay graph-native:\n\n```text\nzero-program-graph-patch v1\nupsertFunction handle\nfn handle(request: Span, response: MutSpan) -> Maybe> {\n return null\n}\nend\n```\n\nPass a patch file, or stream full `zero-program-graph-patch v1` text with `zero patch . --patch-text -`.\n\nUse `addReturnExpr fn=\"maybe\" expr=\"null\"` for non-id returns and `appendStmt fn=\"main\" stmt=\"check std.http.listen(world, 3000_u16)\"` for one stmt. For pure helper tests, use `addTest name=\"addition works\" call=\"add\" arg0=\"2\" arg1=\"3\" expect=\"5\" type=\"i32\"`; reserve `addTestBody name=\"api add\" ... end` for custom bodies and remove bad ones with `deleteTest name=\"api add\"`. Labels are display names, not `__zero_test_*`.\n\nRunnable CLIs keep `World` on `pub fn main`; helpers are value-based. HTTP uses `handle(request, response)`.\n\nAfter `validated: check-equivalent`, the graph is saved and checked. Do not run `zero check`, `zero view`, or `zero export` just to confirm. `zero run . -- ` / `zero test` prove behavior or debug. Export only for requested `.0` review. Repeat `--op` to batch edits. For rewrites/handles: `zero skills get graph`.\n\nRead only for current code or handles:\n\n- `zero view --fn `: one function source.\n- `zero view --fn --around `: enclosing block only.\n- `zero view --outline `: signatures plus one-line docs.\n\nFor a new package: `zero init`, then `zero patch --op 'addMain'`.\n\n## zero query\n\n```text\nzero query [--json] [--fn ] [--find ] [--refs ] [--calls ]\n [--node ] [--depth ] [--full] [--handles] [--no-help] [graph-input|name]\n```\n\n- bare name that is not an existing path: runs `--find` against the current package\n- `zero query --fn --handles`: patch handles for one function\n", "- add `--no-help` when you need handles without the patch-operation footer\n- `--find `: search names, ids, types, values, and node kinds; prints matches with spans\n- `--calls ` / `--refs `: resolved calls and semantic references\n- `--node `: one node's span, parents, and children; short handles resolve here too\n\nImport/export, identity recovery, structural edits, and merge live in `graph`. Direct `.0` edits are a last resort; never delete `zero.graph`.\n\n## Verify Before Done\n\nAfter a fix works, exercise typical and boundary inputs.\n\n```sh\nzero run . -- \nzero run . -- \nzero test\n```\n\nIf behavior changed, add or update a `test` block. On a diagnostic, run `zero explain `.\n\n## Rules\n\n- Treat effects as capabilities, not ambient globals: `World`, `std.fs`, `std.args`, `std.env`.\n- Use `Maybe`, explicit `raises` / `raises [...]`, and `check` / `rescue` instead of hidden failure.\n- Do not invent syntax or CLI fields; load `language` when unsure.\n- Check `stdlib` before hand-writing parsing or validation; it ships validators such as `std.time`, `std.inet`, `std.regex`, and `std.unicode`. Fetch one module with `zero skills get stdlib --topic std.time`.\n", NULL }; static const char *const zero_embedded_skill_builds_chunks[] = { "---\nname: builds\ndescription: Build, run, target, and profile Zero programs.\n---\n\n# Zero Builds\n\nUse this when an agent needs to run, build, cross-build, inspect artifacts, or explain target support for a Zero program.\n\n## Inputs\n\nMost build commands accept one of these graph-backed inputs:\n\n- a direct `.graph` or `.program-graph` artifact\n- a package directory containing `zero.toml` or `zero.json`\n- a direct path to `zero.toml` or `zero.json`\n\nWhen both manifests are present in the same package root, Zero uses\n`zero.toml`. Prefer one checked-in manifest unless testing precedence.\n\nFor packages, normal check, build, run, test, size, and mem commands compile from the checked-in `zero.graph` store. When the `.0` source projection was edited, those commands refresh the stale store from source first and note it on stderr; set `ZERO_STALE=fail` to make staleness an error (RGP008) instead. They never rewrite `.0` files. Use `zero verify-projection` when CI or review needs projection drift to fail, and `zero export` only when a human-readable projection needs regeneration. When already inside a package, omit the input and commands default to the current directory.\n\n## Run\n\nUse `zero run` for the host development loop:\n\n```sh\nzero run\nzero run -- input.txt\nzero run examples/hello.graph\nzero run examples/cli-file.graph -- input.txt\n```\n\nArguments after `--` are passed to the Zero program.\n\n## Build\n\nUse `zero build` when the user asks for an artifact. It is the normal command\nfor executables, object files, LLVM IR, cross-target artifacts, and CI outputs.\nUse direct emitters. The removed generated-C backend is not a fallback path.\n\n```sh\nzero build --emit exe --out .zero/out/app\nzero build --emit obj --out .zero/out/app.o\nzero build --emit exe examples/hello.graph --out .zero/out/hello\nzero build --emit obj examples/hello.graph --out .zero/out/hello.o\n```\n\nUse LLVM only when the request is explicit. LLVM is experimental: it is not the\ndefault backend and not release eligible. Textual IR is inspectable with\n`--emit llvm-ir`; host executable builds require a ready clang toolchain. LLVM\ncurrently lowers scalar code, direct calls, branches, loops, primitive fixed\narrays, byte views, readonly strings, and primitive `std.mem` helpers:\n\n```sh\nzero build --backend llvm --emit llvm-ir examples/hello.graph --out .zero/out/hello.ll\nzero build --backend llvm --emit exe examples/hello.graph --out .zero/out/hello-llvm\nzero run --backend llvm examples/hello.graph\n```\n\nUse `--json` when a tool will read exact build fields:\n\n```sh\nzero build --json --target linux-musl-x64 examples/memory-package\n```\n\nUseful JSON fields include `artifact`, `sizeBytes`, `toolchain`, `releaseTargetContract`, selected target facts, linker flavor, and sysroot status.\n\n## Graph Inputs\n\nWhen an agent is authoring a repository graph package, patch the package graph\n", "and use normal build/run commands. They compile from `zero.graph` and do not\nrequire `.0` projections to exist:\n\n```sh\nzero patch --op 'addMain'\nzero run\nzero build --out .zero/out/app\n```\n\nUse `zero export` when humans need checked-in `.0` projections. After a human edits a projection, the next graph-store compile refreshes the store automatically, or run `zero import` to refresh it explicitly. `zero status` reports the active store format.\n\nBuild, run, test, size, and mem commands maintain a derived final-MIR cache in the native cache, keyed by graph hash, compiler version, target, emit kind, and backend request. Agents should not patch `.zmir` files; JSON outputs report cache reuse in a `mappedFinalMir` row.\n\nIf another tool hands you a standalone `.program-graph`, normal `zero build`\nand `zero run` can validate it as an interchange artifact. Do not create a\nstandalone graph artifact for the ordinary package loop; use the package path so\nthe compiler reads `zero.graph` directly.\n\n## Targets\n\nInspect target names and capability facts before cross-building:\n\n```sh\nzero targets\nzero check --target linux-musl-x64 examples/memory-package\nzero inspect --target linux-musl-x64 examples/memory-package\n```\n\nHosted APIs such as process args, environment, filesystem, net, and proc are target-gated. A non-host target may reject code that checks on the host.\n\n## Profiles\n\nCommon profile names are `debug`, `dev`, `release-fast`, `release-small`, `tiny`, and `audit`.\n\n```sh\nzero build --profile release-small examples/hello.graph\nzero size --profile tiny examples/hello.graph\n```\n\nUse `zero size` to explain retained functions, sections, literals, runtime shims, imports, debug metadata, and optimization hints. Add `--json` when a tool needs exact fields.\nUse `zero size --backend llvm` when the question is specifically about the explicit LLVM backend; the report includes LLVM target triple, optimization level, retained runtime/helper facts, toolchain readiness, and direct-vs-LLVM comparison rows.\n\n## Troubleshooting\n\n- `zero doctor` checks host and target readiness.\n- `zero doctor --json` reports `llvmToolchain` readiness for explicit LLVM host builds.\n- LLVM JSON facts include `backendLifecycle` so tools can distinguish explicit experimental readiness from release support.\n- `BLD003` means an old backend flag was requested; remove it.\n- `BLD004` with `backendBlocker.backend: \"llvm\"` means the selected LLVM artifact, target, command, MIR subset, or clang toolchain is not ready.\n- Missing sysroot facts identify the required `ZERO_SYSROOT_*` variable.\n- Unsupported targets fail explicitly instead of silently choosing another backend.\n", NULL }; static const char *const zero_embedded_skill_diagnostics_chunks[] = { "---\nname: diagnostics\ndescription: Read Zero diagnostics, explanations, and typed fix plans.\n---\n\n# Zero Diagnostics\n\nUse this when Zero code fails to parse, typecheck, build, test, or target-check.\nZero diagnostics are intended for agents: start with the readable command\noutput. Use JSON only when an automation tool needs stable fields or a debugging\nsession needs exact spans, repair metadata, or machine-readable diagnostics.\n\n## Commands\n\n```sh\nzero check\nzero explain \n```\n\nUse machine-readable output when a tool needs exact fields:\n\n```sh\nzero check --json\nzero explain --json \nzero fix --plan --json\n```\n\n`zero fix` reads graph-backed inputs. It reports candidate repairs for graph diagnostics; projection-only source must be imported before repair planning.\n\n## Diagnostic Shape\n\nImportant fields from `zero check --json`:\n\n- `code`: stable diagnostic code such as `NAM003` or `TAR002`\n- `message`: short human summary\n- `path`, `line`, `column`, `length`: source span\n- `expected` and `actual`: structured mismatch facts when available\n- `help`: concise next action\n- `fixSafety`: safety label for an agent repair\n- `repair`: optional repair id and summary\n- `related`: extra spans or facts\n\nDo not scrape terminal prose for automation. Use JSON when a script or tool needs stable fields.\n\n## Fix Safety\n\n`zero fix --plan --json` reports `safetyLevels` and per-fix `safety`:\n\n- `format-only`: formatting or trivia only\n- `behavior-preserving`: intended not to change runtime behavior\n- `api-changing`: signatures, exports, or call sites may change\n- `target-changing`: target support or capability use may change\n- `requires-human-review`: the compiler cannot prove the edit is safe\n\nApply only the edit you can justify from the source and fix plan. Treat `requires-human-review` as a planning hint, not an automatic patch.\n\n## Common Codes\n\n- `NAM003`: unknown name; declare it, import it, or fix spelling.\n- `IMP001`: unknown package-local import.\n- `IMP002`: package-local import cycle.\n- `PKG001`: local dependency path lacks `zero.toml` or a compatibility\n `zero.json`.\n- `PKG002`: package dependency cycle.\n- `PKG003`: one package name resolves to conflicting versions.\n- `PKG004`: selected target is not supported by a dependency.\n- `TAR001`: unknown target; inspect `zero targets`.\n- `TAR002`: capability unavailable for selected target.\n- `BLD003`: removed backend flag; use direct emitters.\n- `STD002`: unknown standard-library helper; use a documented `std..` name.\n- `STD003`: standard-library capability or contract mismatch; inspect the helper signature and required capability.\n- `TYP009`: immutable value used where a mutable destination is required; make the binding `var` or pass mutable storage.\n", "- `MEM003`: one function's fixed locals exceed the 128 KiB frame limit; split the buffer into smaller buffers in helper functions, or process the data in fixed-size chunks.\n- `RGP007`: ambiguous source identity during import; split the text edit into smaller passes or make the change with `zero patch`.\n- `RGP008`: stale package projection while `ZERO_STALE=fail` is set; run `zero import`, or unset the variable to let the command refresh automatically.\n- `RGP009`: binary `zero.graph` store unreadable by this compiler, usually written by a different zero build; rebuild it with this binary via `zero import .` or install the matching compiler (compare `zero --version` build hashes).\n\n## Agent Triage\n\n1. Run the failing command normally first.\n2. If a debugging session needs exact machine fields, rerun with `--json` and use the span to inspect only the relevant source.\n3. Run `zero explain ` before broad refactors.\n4. If multiple diagnostics share a root cause, fix the earliest source issue.\n5. Re-run the same command after the patch.\n", NULL }; static const char *const zero_embedded_skill_graph_chunks[] = { "---\nname: graph\ndescription: Use ProgramGraph commands as the primary agent authoring and inspection surface.\n---\n\n# Zero Graph Authoring\n\nUse this when creating, inspecting, patching, importing, or exporting Zero programs through the graph interface, the primary agent authoring surface. `zero.graph` is the repository graph store for packages, `.0` files are the human-readable source projection, and `.program-graph` files are derived debug/interchange artifacts.\n\n## Source Boundary\n\n- Normal `zero check`, `zero run`, `zero test`, `zero build`, `zero size`, and `zero mem` compile packages from `zero.graph` (`zero.toml` takes precedence over `zero.json`). When the `.0` projection was edited, those commands refresh the stale store from source first and note it on stderr; `ZERO_STALE=fail` turns that refresh into an RGP008 error instead.\n- `zero import` refreshes `zero.graph` from edited source explicitly. It accepts the package root, manifest, or any source path inside the package, updates an existing store in place, and preserves node handles where the edit is unambiguous. When several edited nodes could claim one handle, import picks the structurally closest match and notes it on stderr. A whole-file rewrite that keeps the file's function set (names and signatures) is accepted in one pass with regenerated node identities for that file, noted on stderr; only ties that span files or change the function set fail (RGP007) with a split-the-edit strategy. Never delete the store to force a reimport, and omit `--out` for package imports.\n- `zero export [package]` materializes `.0` projections for human review; do not export just to silence stale-projection notes or after every patch. Compiler commands report projection state but never rewrite `.0` files. `zero verify-projection [package]` fails on drift without writing anything.\n- `zero.graph` is binary by default. Reads auto-detect text and binary stores, writes preserve the existing encoding, and `zero status` reports `store format: text|binary`. Use `--format text` only for a deliberately readable debug store. Stdlib `std/*.graph` stores are binary; sibling `std/*.0` files are projections, not the stdlib compile source.\n\n## Create\n\n```sh\nzero init\nzero patch --op 'addMain'\n```\n\n`zero init` defaults to the current directory and that folder's name. Use `zero init app` for a new subdirectory, `--manifest json` only for explicit compatibility, and `--template cli|lib|package` only when the user asks for starter files.\n\n## Inspect\n\n```sh\nzero query userTotals # bare name that is not a path = --find in the current package\nzero query --fn main # one function's signature and call summary\nzero query --fn main --handles # adds stmt/param patch handles; use before patching\nzero query --calls std # resolved call targets\nzero query --refs add # semantic references\nzero query --node '#expr_2cad38f9' --depth 2 # node-scoped: span, parents, children\n", "zero view --fn main # one function's canonical source\nzero view --fn main --handles # the same source with a trailing // #handle per statement\nzero view --fn main --around minLength # only the enclosing block containing the text\nzero view --outline src/main.0 # signatures plus one-line docs, no bodies\nzero status # store format and projection state\n```\n\n`--node` defaults to depth 1; add `--full` for the whole-module report. Use handles from `zero view --fn --handles`, `--find`, or `--fn --handles` for checked edits (`set`, `insert`, `insertEdge`, `replace`, `replaceExpr`, `rename`, `delete`); delete compacts ordered graph groups so valid sibling order is preserved. Handles accept short forms: the id segment (`#55ae541c`), any unique prefix (`#55ae`), or `#head..tail` for ids with long shared prefixes; `--handles` views print the shortest form that resolves, and a missing handle fails with the nearest existing one. Reserve unfiltered `zero query` dumps for tools that need every node and edge.\n\n## Patches\n\nEdit through the graph: `zero patch` covers everything from one-line changes (`addCheckWrite`, `rename`, `set`) to whole function bodies (`--replace-fn --body-file -` with a heredoc). Direct `.0` text edits are a last resort for changes no patch op expresses; the compiler will refresh the graph from edited source, but patch keeps the loop faster (0.2s validation, no reconcile pass) and preserves node identity for queries.\n\nA successful patch loads, applies, validates, and saves `zero.graph`, and prints the saved path, new graph hash, functions, and tests. Do not run `zero check`, `zero view`, `zero query`, or `zero export` just to confirm that the patch applied. Use those only when you need current text/handles, projection review, or a diagnostic loop.\n\n```sh\nzero patch \\\n --op 'addFunction name=\"add\" ret=\"i32\"' \\\n --op 'addParam fn=\"add\" name=\"left\" type=\"i32\"' \\\n --op 'addParam fn=\"add\" name=\"right\" type=\"i32\"' \\\n --op 'addReturnBinary fn=\"add\" name=\"+\" left=\"left\" right=\"right\" type=\"i32\"' \\\n --op 'addTest name=\"addition works\" call=\"add\" arg0=\"40\" arg1=\"2\" expect=\"42\" type=\"i32\"'\n```\n\nUse `addTest` for one pure helper call; reserve `addTestBody` for custom body rows. Test labels are display names, not `__zero_test_*` function names. If a custom test fails as an unknown function label, delete it and recreate simple coverage with `addTest` instead of renaming the label.\n\n", "For declaration-level edits, stay in patch ops instead of rewriting files. `setConst name=\"limit\" value=\"64\"` replaces a top-level const's initializer by package-scoped name. `addParamTo fn=\"scan\" name=\"bias\" type=\"i32\" default=\"0\"` appends a parameter to an existing function and updates every call site in the package (nested calls included) to pass the default explicitly, reporting `updated N call sites`; without `default` it fails with the call-site count. `setReturnType fn=\"scan\" type=\"i64\"` changes a declared return type. All three revalidate and batch like any other op.\n\nFor a new or replacement multi-statement helper, use complete source through `upsertFunction` instead of editing `.0` and importing:\n\n```text\nzero-program-graph-patch v1\nupsertFunction handle\nfn handle(request: Span, response: MutSpan) -> Maybe> {\n return null\n}\nend\n```\n\nFor runnable CLI programs, keep `World` on `pub fn main`; value-based helpers build and run more reliably. HTTP server helpers use `handle(request, response)`.\n\n`upsertFunction` parses exactly one complete function declaration, inserts it if missing, and replaces the prior declaration and body if it already exists. For smaller append-only work, `appendStmt fn=\"main\" stmt=\"check std.http.listen(world, 3000_u16)\"` appends one canonical statement, and `addReturnExpr fn=\"maybe\" expr=\"null\"` appends a return statement for any expression. `addReturnValue` is only for identifier returns.\n\nFor sub-line edits, think in graph: take a handle from `zero view --fn --handles` and change exactly one thing. `set` edits one field (a literal `value`, a declared `type`, a `name`/operator); `replaceExpr` swaps any expression subtree, and aimed at a statement handle it replaces that statement's expression (initializer, condition, return value). Repeat `--op` to batch several micro-ops into one patch with a single revalidation:\n\n```sh\nzero patch . \\\n --op 'set node=\"#a647\" field=\"value\" expect=\"1\" value=\"8\"' \\\n --op 'replaceExpr node=\"#5f15\" with=\"i < k + 1\"'\n```\n\nTo express one cross-cutting transformation instead of editing N sites, use structural rewrite by example. `--rewrite '' --to '