{"owner":"JuliaLang","repo":"julia","hasSkills":true,"totalSkillsCount":11,"totalTokensCount":6572,"categories":["anthropic-skill","subagent-persona","claude-rule","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["doc/src/devdocs/agents/skills/external-deps/SKILL.md","doc/src/devdocs/agents/skills/ci-timing/SKILL.md","doc/src/devdocs/agents/skills/doctests/SKILL.md","doc/src/devdocs/agents/skills/julia-syntax-lowering/SKILL.md","doc/src/devdocs/agents/skills/compiler-jl/SKILL.md","doc/src/devdocs/agents/skills/test-changes/SKILL.md","doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md","doc/src/devdocs/agents/skills/buildkite-logs/SKILL.md","doc/src/devdocs/agents/README.md","CLAUDE.md","AGENTS.md"],"skills":{"doc/src/devdocs/agents/skills/external-deps/SKILL.md":"---\nname: external-deps\ndescription: Modify Julia's external dependencies and JLLs — patches under deps/patches/, version bumps in deps/, and JLL updates. Use when touching deps/ or any *_jll folder, including refreshing checksums.\n---\n\n# External dependencies & JLLs\n\nUse this when modifying `deps/`, dependency patches, or a JLL.\n\n## External dependencies (deps/, deps/patches/)\n\nWhen modifying external dependencies (patches in `deps/patches/` or version\nupdates in `deps/`):\n\n1. Always test builds with `USE_BINARYBUILDER=0` to ensure source builds work correctly.\n2. For patches to external libraries:\n - Verify the patch applies cleanly by running the extraction and patch steps.\n - Test the full build of the dependency: `make -C deps USE_BINARYBUILDER=0 compile-`.\n - Prefer using the full upstream commit in `git am` format (e.g., `git format-patch`) which includes proper commit metadata.\n3. When updating dependency versions, ensure all associated patches still apply.\n\n## External JLLs\n\nTo update a JLL to the latest version:\n\n- Update the version number in the appropriate jll folder.\n- If the dependencies in the upstream jll changed, update the `Project.toml`.\n- Run `make -f contrib/refresh_checksums.mk ` to update the checksums. This may take a few minutes.\n","doc/src/devdocs/agents/skills/ci-timing/SKILL.md":"---\nname: ci-timing\ndescription: Compare a Julia PR's Buildkite job durations against recent CI history (per-job mean/min/max over the last N days). Use when asked whether a PR slows down or speeds up CI, or to check a build's timings against the weekly baseline.\n---\n\n# CI timing analysis\n\n```sh\njulia --startup-file=no --project=contrib/ci-timing contrib/ci-timing/ci_timing_compare.jl \n```\n\nPrints a markdown table, slowest job first, plus a TOTAL row: each job's duration\nin the PR's `julia-pr` build vs. the mean/min/max of the same job name over the\nlast 7 days of [julia-ci-timing](https://github.com/JuliaCI/julia-ci-timing)\nhistory. `⚠️` = above the weekly max, `✅` = below the weekly min. No Buildkite\ntoken needed; `gh` is only needed to turn a PR number into a build.\n\nFlags: `--build julia-pr/853`, `--days N`, `--include-failed`, `--min-seconds N`\n(hides short jobs).\n\nCaveats when reading it:\n\n- One build vs. a week of samples — anything inside the min/max band is agent\n variance, and even ⚠️/✅ rows need a second build to mean anything.\n- `juliasyntax`/`Launch *` jobs are seconds long, so their percentages are noise;\n `--min-seconds 120` drops them.\n- A fleet-wide shift in one direction skews TOTAL and is not a PR effect.\n- Broken (never run), running, and superseded retry jobs are excluded; a failed\n job's time is cut short or stretched by the failure.\n\nFor logs behind a slow or failed job, see the `buildkite-logs` skill.\n","doc/src/devdocs/agents/skills/doctests/SKILL.md":"---\nname: doctests\ndescription: Write and verify Julia `jldoctest` code blocks. Use whenever adding or changing a `jldoctest` block in a docstring (base/, stdlib/, Compiler/) or under doc/, and before opening a PR that touches doctests.\n---\n\n# Julia doctests\n\nUse this whenever you add or modify any `jldoctest` code block.\n\n## Writing\n\nBefore writing new doctests, review `doc/src/devdocs/contributing/jldoctests.md`\nfor best practices (filters, labels, setup code).\n\n## Verifying\n\nIf you changed any `jldoctest` block you MUST verify it. Follow these steps for\nEVERY doctest change:\n\n1. Review `doc/src/devdocs/contributing/jldoctests.md`. In particular, determine\n if any of the changed doctests require filters, labels or setup code.\n2. Run the doctests to verify that your change works:\n - To run doctest with the pre-built juliaup: `make -C doc doctest=true revise=true JULIA_EXECUTABLE=$HOME/.juliaup/bin/julia`\n - To run doctest with in-tree julia (preferred): `make -C doc doctest=true revise=true`. Do not pass any other options.\n - IMPORTANT: The doctests may take up to 15 minutes. Do NOT terminate the doctests before completion. Do NOT use a timeout for doctests.\n - If you are ChatGPT, you may have to increase yield_timeout_ms.\n","doc/src/devdocs/agents/skills/julia-syntax-lowering/SKILL.md":"---\nname: julia-syntax-lowering\ndescription: Develop and test JuliaSyntax and JuliaLowering in Julia's source tree. Use when modifying JuliaSyntax/ or JuliaLowering/, running package or targeted tests, or checking JuliaLowering execution.\n---\n\n# JuliaSyntax & JuliaLowering development\n\nUse this when modifying `JuliaSyntax/` or `JuliaLowering/` source, tests, or\npackage metadata.\n\n## Testing JuliaSyntax\n\nRun package tests from the repository root:\n\n```sh\njulia --project=JuliaSyntax -e 'using Pkg; Pkg.test()'\n```\n\n`JuliaSyntax` is not tied only to the in-tree Julia runtime; if a change may be\nversion-sensitive, test it with the relevant installed Julia version(s).\n\n## Testing JuliaLowering\n\nPrefer the in-tree Julia runtime because compatibility with the Julia runtime\nmay matter:\n\n```sh\n./usr/bin/julia --project=JuliaLowering -e 'using Pkg; Pkg.test()'\n```\n\nIf `./usr/bin/julia` is unavailable, note that limitation and use an available\n`julia` executable only for preliminary validation.\n\nIn this repository, `JuliaLowering/Project.toml` points its `JuliaSyntax`\ndependency at the sibling `JuliaSyntax` checkout\n(`path = \"../JuliaSyntax\"`). Therefore, `JuliaSyntax` changes can affect\n`JuliaLowering`. When a `JuliaSyntax` change may affect lowering behavior or\nsyntax data consumed by `JuliaLowering`, run the `JuliaLowering` test command as\nwell.\n\n### Targeted JuliaLowering tests\n\nFor targeted `JuliaLowering` test execution, include\n`JuliaLowering/test/utils.jl` before the test file, matching\n`JuliaLowering/test/runtests.jl`:\n\n```sh\n./usr/bin/julia --project=JuliaLowering -e 'cd(\"JuliaLowering/test\") do; include(\"utils.jl\"); include(\"scopes.jl\"); end'\n```\n\nFor `_ir.jl` fixtures, call `test_ir_cases` after loading `utils.jl`:\n\n```sh\n./usr/bin/julia --project=JuliaLowering -e 'cd(\"JuliaLowering/test\") do; include(\"utils.jl\"); test_ir_cases(\"scopes_ir.jl\"); end'\n```\n\n## Trying JuliaLowering execution\n\nFor quick execution checks, run with the in-tree Julia runtime and the\n`JuliaLowering` project:\n\n```sh\n./usr/bin/julia --project=JuliaLowering\n```\n\nThen either evaluate code explicitly through `JuliaLowering`:\n\n```julia\nusing JuliaLowering\nJuliaLowering.include_string(Main, \"1 + 2\")\n```\n\nor activate `JuliaLowering` as the process lowerer, then evaluate subsequent\ncode normally:\n\n```julia\nusing JuliaLowering\nJuliaLowering.activate!()\n\n1 + 2\n```\n\nUse `include(\"path/to/file.jl\")` after activation when checking a file. When\nusing `JuliaLowering.activate!()` from `-e`, make the code under test a separate\ntop-level statement after activation, or put it in `include(...)`.\n","doc/src/devdocs/agents/skills/compiler-jl/SKILL.md":"---\nname: compiler-jl\ndescription: Develop and test Julia's Compiler.jl. Use when modifying Compiler/, debugging compiler behavior, or activating stdlib Compiler for reflection/native-codegen experiments instead of using sysimage Base.Compiler.\n---\n\n# Compiler.jl development\n\nUse this when modifying `Compiler/` source, tests, or package metadata.\n\n## Compiler modules in Julia\n\nDuring bootstrap, `Compiler/` is built into the sysimage as `Base.Compiler`.\nThat in-sysimage compiler is what Julia normally uses for native compilation.\nBecause it is baked into the sysimage, changes made to `Compiler/` after the\nsysimage was built are not reflected in `Base.Compiler` unless Julia is rebuilt.\n\n`Compiler/` can also be loaded as a stdlib package, producing a separate\n`Compiler` module from `Base.Compiler`. For day-to-day development, testing, and\ndebugging of post-sysimage source changes, prefer this stdlib `Compiler` module\nover trying to replace `Base.Compiler` with Revise. It is usually reliable except\nfor failures caused by compatibility with the `src/` runtime or other\nsysimage/native-codegen integration issues.\n\nWhen investigating a runtime compatibility issue, `make -C src` can update the\nruntime faster than rebuilding the full Julia sysimage. Rebuild Julia when the\nupdated `Compiler/` code needs to be baked into `Base.Compiler` or when checking\nsysimage/native-codegen integration.\n\n## Experimenting with Compiler as a stdlib\n\nRun the in-tree Julia runtime with the `Compiler` project:\n\n```sh\n./usr/bin/julia --project=Compiler\n```\n\n### Reflection backend\n\nFor reflection-oriented debugging, activate the stdlib `Compiler` module:\n\n```julia\nusing InteractiveUtils, Compiler\n@activate Compiler\n```\n\n`@activate Compiler` is equivalent to `@activate Compiler[:reflection]`: Base and\nInteractiveUtils reflection utilities such as `code_typed`, `@code_typed`, and\n`code_warntype` will use the loaded stdlib `Compiler` module. This is useful for\ntrying compiler changes without rebuilding the sysimage.\n\n### Native compilation backend\n\nIf you specifically need to exercise the loaded stdlib `Compiler` as the native\ncompilation backend, use:\n\n```julia\nusing InteractiveUtils, Compiler\n@activate Compiler[:codegen]\n```\n\nThis is broader than reflection activation: it makes the runtime invoke the\nloaded compiler for compilation requests. Use it only when debugging native\ncompilation/codegen behavior, and expect failures here to involve sysimage,\nruntime, native-codegen, or compiler-cache interactions.\n\nFor ordinary debugging, prefer reflection activation. Use `[:codegen]` only when\nyou specifically need to test the native compilation backend; for final\nintegration checks, rebuild Julia and test the in-sysimage `Base.Compiler`.\n\n## Testing Compiler as a stdlib package\n\nRun package tests from the repository root with the in-tree Julia runtime:\n\n```sh\n./usr/bin/julia --project=Compiler -e 'using Pkg; Pkg.test()'\n```\n\nTo run a single test file, include it directly under a `Test.@testset`:\n\n```sh\n./usr/bin/julia --project=Compiler -e 'using Test; @testset \"inline\" include(\"Compiler/test/inline.jl\")'\n```\n\nMost `Compiler/test/` files include `Compiler/test/setup_Compiler.jl`, which\nactivates or imports the appropriate `Compiler` module for this workflow.\n\n## Testing `Base.Compiler`\n\nUse the top-level test entry point when the goal is to test the `Base.Compiler`\nthat is baked into the sysimage:\n\n```sh\n./usr/bin/julia test/runtests.jl Compiler\n```\n\nIf you changed `Compiler/` and need those changes reflected in `Base.Compiler`,\nrebuild Julia first so the sysimage contains the updated compiler code.\n","doc/src/devdocs/agents/skills/test-changes/SKILL.md":"---\nname: test-changes\ndescription: Run and update Julia tests after changing test files. Use when adding to or modifying any test file under test/ or stdlib/**/test/.\n---\n\n# Julia test changes\n\nUse this when you change or add a Julia test.\n\n- If you have changed a test (e.g. `foo`), run `make test-revise-foo` for the\n corresponding test to ensure that the test is still passing with your changes.\n- If you are adding a new test, add it to an existing test file. Do not create a\n new test file unless explicitly instructed.\n- Write one comment at the top of the test to explain what is being tested.\n Otherwise keep comments minimal.\n- Use the environment variable `JULIA_TEST_FAILFAST=1` to make tests fail fast.\n- Do not coordinate with fixed `sleep`s — loaded CI machines break any fixed\n delay. Synchronize on observable state (readiness markers, round-trips), or\n retry.\n","doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md":"---\nname: c-static-analysis\ndescription: Run Clang static analysis on Julia's C/C++ runtime and codegen, and satisfy the GC-rooting checker. Use after modifying runtime/codegen .c/.cpp files under src/ (excluding headers), before opening a PR.\n---\n\n# C/C++ static analysis (src/)\n\nUse this after you modify a runtime/codegen C/C++ source file under `src/` (not\nheaders). Note that runtime changes also require a rebuild (`make -j`).\n\nRun static analysis checks:\n\n- First run `make -C src install-analysis-deps` to initialize dependencies (only\n needed once the first time, or after the LLVM/Clang toolchain dependencies\n change). This may download and install LLVM/Clang artifacts.\n- For a source file such as `src/jloptions.c` or `src/codegen.cpp`, use the file\n stem without the `.c`/`.cpp` extension:\n ```sh\n make -C src analyze- -j8 [--output-sync]\n ```\n For example, to analyze `src/jloptions.c`, run:\n ```sh\n make -C src analyze-jloptions -j8\n ```\n Add `--output-sync` when your `make` supports it to keep parallel output\n grouped; otherwise omit it.\n- Checks can also be rerun individually with `clang-sa-`,\n `clang-sagc-`, `clang-safety-` or\n `clang-tidy-`.\n\n## Fixing the GC-rooting checker (clang-sagc)\n\nIf `clang-sagc-` fails, first look for fixes that establish real\nrooting, such as adding appropriate `JL_GC_PUSH`/`JL_GC_POP` scopes, or for\nlock/control-flow fixes.\n\nDo not add `JL_GC_PROMISE_ROOTED` without explicit user or maintainer\nconfirmation. `JL_GC_PROMISE_ROOTED` asserts that a value is already rooted; it\ndoes not root the value. If it appears necessary, stop and ask for confirmation,\nshowing the exact expression, the existing root that makes it safe, and the\nsafepoints considered.\n\n- Remember arguments are assumed rooted, so check the callers to make sure that\n is handled.\n- As a diagnostic hint when asking for confirmation: if the value is temporarily\n moved through a struct or arraylist and then reloaded, the promised expression\n may need to refer to the reloaded field, such as\n `JL_GC_PROMISE_ROOTED(struct->field)`, immediately after the reload and before\n any use of that field.\n- If confirmed, put the promise as early in the code as is legal, near the\n definition or reload rather than the use.\n","doc/src/devdocs/agents/skills/buildkite-logs/SKILL.md":"---\nname: buildkite-logs\ndescription: Fetch and inspect Julia Buildkite CI logs and artifacts without web sign-in, including the TTFX benchmark jobs. Use when debugging Julia CI failures, reviewing Buildkite jobs, investigating a TTFX regression, or when the Buildkite MCP is unavailable.\n---\n\n# Reviewing Buildkite CI logs\n\nUse this when investigating Julia Buildkite CI failures, especially if the\nBuildkite MCP is unavailable. The recipe requires `gh`, `curl`, `python3`, and\nnetwork access to GitHub and Buildkite.\n\nJulia's CI runs on Buildkite. PR builds run in the `julialang/julia-pr`\npipeline, post-merge master builds in `julialang/julia-ci`, and scheduled runs\nin `julialang/julia-master-scheduled` (the old `julia-master` pipeline no\nlonger exists). The public web UI requires sign-in to download `raw_log`, but\ntwo frontend JSON endpoints are anonymously accessible for public pipelines.\nRecipe:\n\n1. Find the build number. `gh pr checks ` gives launcher-job URLs\n like `https://buildkite.com/julialang/julia-pr/builds/#`; for a\n master commit, use the commit statuses\n (`gh api repos/JuliaLang/julia/commits//status`). The `#`\n fragments there are only the top-level launcher jobs (Build/Check/Test/…),\n not the per-platform jobs.\n\n2. List all jobs in the build, with names, states, exit statuses, and UUIDs:\n\n ```sh\n curl -sS -H \"Accept: application/json\" \\\n \"https://buildkite.com/julialang//builds//data/jobs\" \\\n -o /tmp/bkjobs.json\n python3 -c \"import json; [print(j['state'],'|',j.get('exit_status'),'|',j['name'],'|',j['id']) \\\n for j in json.load(open('/tmp/bkjobs.json'))['records']]\"\n ```\n\n This `/data/jobs` endpoint is what the build page's frontend uses; it\n returns every job in one page (`records`, plus `has_next_page`). Do NOT use\n `builds/.json` for job discovery — anonymously it returns build\n metadata with an *empty* `jobs` array (the `statistics` field still shows\n the true job count).\n\n3. Fetch a job's log JSON (replace ``, ``, ``):\n\n ```sh\n curl -sS -H \"Accept: application/json\" \\\n \"https://buildkite.com/organizations/julialang/pipelines//builds//jobs//log\" \\\n -o /tmp/bk.json\n ```\n\n The log text lives under the JSON `output` field, with embedded HTML\n (`