{"owner":"JuliaLang","repo":"julia","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# Information for AI agents\n\n## Module Organization\n- [`base/`](base/) - Core standard library (loaded at startup)\n- [`stdlib/`](stdlib/) - Standard library packages (can be loaded independently)\n- [`Compiler/`](Compiler/) - Julia compiler as a separate module (can be swapped)\n- [`src/`](src/) - C/C++ runtime and LLVM codegen\n- [`cli/`](cli/) - Command-line interface and loader\n- [`doc/`](doc/) - Documentation and User Manual\n\n## Running Julia\n\nYou should have a recent binary copy of julia in your `$HOME/.juliaup/bin` directory.\nYou may use this julia executable for validation.\nIf a built version of Julia exists in the current source tree (at `usr/bin/julia`),\nprefer that version.\nNote that any changes you make to the source code after the binary is built\nwill not be reflected, unless you use `Revise`.\n\n## For all changes\n\n1. Sign off every commit you create with an `Assisted-by: <tool> (<model>)` trailer naming both the\n   tool and the model behind it, for example `Assisted-by: Claude Code (Opus 5)`. Name the model,\n   not just the harness - it is what tells a later reader what actually produced the work. Do not\n   use `Co-authored-by:` for tools, and do not list a tool as an author; this trailer replaces any\n   co-author trailer your harness adds by default.\n2. Agents aren't permitted to open PRs or post comments autonomously.\n\n## Building Julia\n\nIf you made changes to the runtime (any files in `src/`), you will need to rebuild\njulia. Run `make -j` to rebuild julia. This process may take up to 10 minutes\ndepending on your changes.\n\nAfter modifying any C/C++ file under `src/`, also run the Clang static analysis\nchecks — see the `c-static-analysis` skill ([`doc/src/devdocs/agents/skills/c-static-analysis/`](doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md)).\n\n### Testing LLVM-related changes\n\nWhen making changes to LLVM passes or codegen, add `LLVM_ASSERTIONS=1` to `Make.user` to enable\nLLVM assertions. This helps catch IR verification errors early:\n\n```bash\necho \"LLVM_ASSERTIONS=1\" >> Make.user\n```\n\nTo run LLVM pass tests:\n```bash\nmake -C test/llvmpasses <testname>.ll\n```\n\n## Using Revise\n\nIf you have made changes to files included in the system image (base/ or stdlib/),\nand need to run code with these changes included, you can use `Revise`.\nTo do so, run `using Revise; Revise.track(Base)` (or Revise.track with the stdlib you modified).\nThe test system supports doing this automatically.\n\nFor instance testing Base changes without rebuilding, using failfast, you can run:\n```\nJULIA_TEST_FAILFAST=1 ./julia -e 'using Revise; Revise.track(Base); include(\"test.jl\")'\n```\n\n## Writing code\n\nAfter writing code, look up the docstring for each function you used. If there\nare recommendations or additional considerations that apply to these functions,\nmake sure to take them into account.\n\n- Do not `ccall` runtime C functions directly if there are existing wrappers for the function.\n- Do not explicitly add a module prefix if the code you're adding is in the same module. E.g. do not use `Base.` for code in Base unless required.\n\n## Task-specific skills\n\nDetailed, situational procedures are provided as Agent Skills following the\n[agentskills.io](https://agentskills.io) open standard. The canonical location is\n`doc/src/devdocs/agents/skills/`; `.agents/skills/` and `.claude/skills/` are\nsymlinks to that directory so skills-aware agents can discover the skills\nautomatically. Agents that support the standard load each skill's `description`\nautomatically and pull in the full `SKILL.md` when relevant; otherwise read the\ncanonical `SKILL.md` directly.\n\n- [`doc/src/devdocs/agents/skills/doctests/`](doc/src/devdocs/agents/skills/doctests/SKILL.md) — writing and verifying `jldoctest` code blocks.\n- [`doc/src/devdocs/agents/skills/test-changes/`](doc/src/devdocs/agents/skills/test-changes/SKILL.md) — running and updating tests after changing them.\n- [`doc/src/devdocs/agents/skills/c-static-analysis/`](doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md) — Clang static analysis and GC-rooting for C/C++ changes under `src/`.\n- [`doc/src/devdocs/agents/skills/external-deps/`](doc/src/devdocs/agents/skills/external-deps/SKILL.md) — modifying external dependencies (`deps/`, patches) and JLLs.\n- [`doc/src/devdocs/agents/skills/buildkite-logs/`](doc/src/devdocs/agents/skills/buildkite-logs/SKILL.md) — fetching and inspecting Buildkite CI logs without web sign-in.\n- [`doc/src/devdocs/agents/skills/ci-timing/`](doc/src/devdocs/agents/skills/ci-timing/SKILL.md) — comparing a PR's Buildkite job durations against recent CI history.\n- [`doc/src/devdocs/agents/skills/compiler-jl/`](doc/src/devdocs/agents/skills/compiler-jl/SKILL.md) — developing and testing Compiler.jl.\n- [`doc/src/devdocs/agents/skills/julia-syntax-lowering/`](doc/src/devdocs/agents/skills/julia-syntax-lowering/SKILL.md) — developing and testing JuliaSyntax and JuliaLowering.\n\n## Commit messages and pull requests\n\nWhen writing commit messages, follow the format \"component: Brief summary\" for\nthe title. In the body of the commit message, provide a brief prose summary\nof the purpose of the changes made. Do not specifically mention added tests, comments,\ndocumentation, etc., unless this is the main purpose of the change. Do not mention\nthe test plan, unless it differs from what you were instructed to do in AGENTS.md.\nIf your change fixes one or more issues, use the syntax \"Fixes #\" at the end of the commit message, but do not include it in the title.\n\nWhen referencing external GitHub PRs or issues, use proper GitHub interlinking format (e.g., `owner/repo#123` for PRs/issues).\nWhen fixing CI failures, include the link to the specific CI failure in the commit message.\nAlways quote macro names in backticks in commit messages and PR titles/bodies (e.g. `` `@inbounds` ``, not @inbounds), so GitHub does not notify the unrelated user with that handle.\n\nWhen preparing a pull request for the human author to open, draft the body as follows, expecting\nthem to reword it:\n1. If the pull request consists of one commit only, use the body of the commit for the body of the pull request.\n2. If there are multiple commits in the pull request, follow the same guidelines for the pull request as for the commit body.\n3. Make sure that the base commit of the pull request is recent (within the past two days) - if not rebase your changes first.\n4. If a separate tool reviews the commit, this is useful to note. Encourage the human to state how carefully they read and understood the content also, for example, by drafting the text to say the human author has *not* read any of it, and expecting they will update that once they read that disclaimer.\n","CLAUDE.md":"<!--\n\nInclude the contents of AGENTS.md\n\nhttps://code.claude.com/docs/en/claude-code-on-the-web#best-practices\n\n-->\n\n@AGENTS.md\n"},"files":{"AGENTS.md":"# Information for AI agents\n\n## Module Organization\n- [`base/`](base/) - Core standard library (loaded at startup)\n- [`stdlib/`](stdlib/) - Standard library packages (can be loaded independently)\n- [`Compiler/`](Compiler/) - Julia compiler as a separate module (can be swapped)\n- [`src/`](src/) - C/C++ runtime and LLVM codegen\n- [`cli/`](cli/) - Command-line interface and loader\n- [`doc/`](doc/) - Documentation and User Manual\n\n## Running Julia\n\nYou should have a recent binary copy of julia in your `$HOME/.juliaup/bin` directory.\nYou may use this julia executable for validation.\nIf a built version of Julia exists in the current source tree (at `usr/bin/julia`),\nprefer that version.\nNote that any changes you make to the source code after the binary is built\nwill not be reflected, unless you use `Revise`.\n\n## For all changes\n\n1. Sign off every commit you create with an `Assisted-by: <tool> (<model>)` trailer naming both the\n   tool and the model behind it, for example `Assisted-by: Claude Code (Opus 5)`. Name the model,\n   not just the harness - it is what tells a later reader what actually produced the work. Do not\n   use `Co-authored-by:` for tools, and do not list a tool as an author; this trailer replaces any\n   co-author trailer your harness adds by default.\n2. Agents aren't permitted to open PRs or post comments autonomously.\n\n## Building Julia\n\nIf you made changes to the runtime (any files in `src/`), you will need to rebuild\njulia. Run `make -j` to rebuild julia. This process may take up to 10 minutes\ndepending on your changes.\n\nAfter modifying any C/C++ file under `src/`, also run the Clang static analysis\nchecks — see the `c-static-analysis` skill ([`doc/src/devdocs/agents/skills/c-static-analysis/`](doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md)).\n\n### Testing LLVM-related changes\n\nWhen making changes to LLVM passes or codegen, add `LLVM_ASSERTIONS=1` to `Make.user` to enable\nLLVM assertions. This helps catch IR verification errors early:\n\n```bash\necho \"LLVM_ASSERTIONS=1\" >> Make.user\n```\n\nTo run LLVM pass tests:\n```bash\nmake -C test/llvmpasses <testname>.ll\n```\n\n## Using Revise\n\nIf you have made changes to files included in the system image (base/ or stdlib/),\nand need to run code with these changes included, you can use `Revise`.\nTo do so, run `using Revise; Revise.track(Base)` (or Revise.track with the stdlib you modified).\nThe test system supports doing this automatically.\n\nFor instance testing Base changes without rebuilding, using failfast, you can run:\n```\nJULIA_TEST_FAILFAST=1 ./julia -e 'using Revise; Revise.track(Base); include(\"test.jl\")'\n```\n\n## Writing code\n\nAfter writing code, look up the docstring for each function you used. If there\nare recommendations or additional considerations that apply to these functions,\nmake sure to take them into account.\n\n- Do not `ccall` runtime C functions directly if there are existing wrappers for the function.\n- Do not explicitly add a module prefix if the code you're adding is in the same module. E.g. do not use `Base.` for code in Base unless required.\n\n## Task-specific skills\n\nDetailed, situational procedures are provided as Agent Skills following the\n[agentskills.io](https://agentskills.io) open standard. The canonical location is\n`doc/src/devdocs/agents/skills/`; `.agents/skills/` and `.claude/skills/` are\nsymlinks to that directory so skills-aware agents can discover the skills\nautomatically. Agents that support the standard load each skill's `description`\nautomatically and pull in the full `SKILL.md` when relevant; otherwise read the\ncanonical `SKILL.md` directly.\n\n- [`doc/src/devdocs/agents/skills/doctests/`](doc/src/devdocs/agents/skills/doctests/SKILL.md) — writing and verifying `jldoctest` code blocks.\n- [`doc/src/devdocs/agents/skills/test-changes/`](doc/src/devdocs/agents/skills/test-changes/SKILL.md) — running and updating tests after changing them.\n- [`doc/src/devdocs/agents/skills/c-static-analysis/`](doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md) — Clang static analysis and GC-rooting for C/C++ changes under `src/`.\n- [`doc/src/devdocs/agents/skills/external-deps/`](doc/src/devdocs/agents/skills/external-deps/SKILL.md) — modifying external dependencies (`deps/`, patches) and JLLs.\n- [`doc/src/devdocs/agents/skills/buildkite-logs/`](doc/src/devdocs/agents/skills/buildkite-logs/SKILL.md) — fetching and inspecting Buildkite CI logs without web sign-in.\n- [`doc/src/devdocs/agents/skills/ci-timing/`](doc/src/devdocs/agents/skills/ci-timing/SKILL.md) — comparing a PR's Buildkite job durations against recent CI history.\n- [`doc/src/devdocs/agents/skills/compiler-jl/`](doc/src/devdocs/agents/skills/compiler-jl/SKILL.md) — developing and testing Compiler.jl.\n- [`doc/src/devdocs/agents/skills/julia-syntax-lowering/`](doc/src/devdocs/agents/skills/julia-syntax-lowering/SKILL.md) — developing and testing JuliaSyntax and JuliaLowering.\n\n## Commit messages and pull requests\n\nWhen writing commit messages, follow the format \"component: Brief summary\" for\nthe title. In the body of the commit message, provide a brief prose summary\nof the purpose of the changes made. Do not specifically mention added tests, comments,\ndocumentation, etc., unless this is the main purpose of the change. Do not mention\nthe test plan, unless it differs from what you were instructed to do in AGENTS.md.\nIf your change fixes one or more issues, use the syntax \"Fixes #\" at the end of the commit message, but do not include it in the title.\n\nWhen referencing external GitHub PRs or issues, use proper GitHub interlinking format (e.g., `owner/repo#123` for PRs/issues).\nWhen fixing CI failures, include the link to the specific CI failure in the commit message.\nAlways quote macro names in backticks in commit messages and PR titles/bodies (e.g. `` `@inbounds` ``, not @inbounds), so GitHub does not notify the unrelated user with that handle.\n\nWhen preparing a pull request for the human author to open, draft the body as follows, expecting\nthem to reword it:\n1. If the pull request consists of one commit only, use the body of the commit for the body of the pull request.\n2. If there are multiple commits in the pull request, follow the same guidelines for the pull request as for the commit body.\n3. Make sure that the base commit of the pull request is recent (within the past two days) - if not rebase your changes first.\n4. If a separate tool reviews the commit, this is useful to note. Encourage the human to state how carefully they read and understood the content also, for example, by drafting the text to say the human author has *not* read any of it, and expecting they will update that once they read that disclaimer.\n","CLAUDE.md":"<!--\n\nInclude the contents of AGENTS.md\n\nhttps://code.claude.com/docs/en/claude-code-on-the-web#best-practices\n\n-->\n\n@AGENTS.md\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Information for AI agents\n\n## Module Organization\n- [`base/`](base/) - Core standard library (loaded at startup)\n- [`stdlib/`](stdlib/) - Standard library packages (can be loaded independently)\n- [`Compiler/`](Compiler/) - Julia compiler as a separate module (can be swapped)\n- [`src/`](src/) - C/C++ runtime and LLVM codegen\n- [`cli/`](cli/) - Command-line interface and loader\n- [`doc/`](doc/) - Documentation and User Manual\n\n## Running Julia\n\nYou should have a recent binary copy of julia in your `$HOME/.juliaup/bin` directory.\nYou may use this julia executable for validation.\nIf a built version of Julia exists in the current source tree (at `usr/bin/julia`),\nprefer that version.\nNote that any changes you make to the source code after the binary is built\nwill not be reflected, unless you use `Revise`.\n\n## For all changes\n\n1. Sign off every commit you create with an `Assisted-by: <tool> (<model>)` trailer naming both the\n   tool and the model behind it, for example `Assisted-by: Claude Code (Opus 5)`. Name the model,\n   not just the harness - it is what tells a later reader what actually produced the work. Do not\n   use `Co-authored-by:` for tools, and do not list a tool as an author; this trailer replaces any\n   co-author trailer your harness adds by default.\n2. Agents aren't permitted to open PRs or post comments autonomously.\n\n## Building Julia\n\nIf you made changes to the runtime (any files in `src/`), you will need to rebuild\njulia. Run `make -j` to rebuild julia. This process may take up to 10 minutes\ndepending on your changes.\n\nAfter modifying any C/C++ file under `src/`, also run the Clang static analysis\nchecks — see the `c-static-analysis` skill ([`doc/src/devdocs/agents/skills/c-static-analysis/`](doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md)).\n\n### Testing LLVM-related changes\n\nWhen making changes to LLVM passes or codegen, add `LLVM_ASSERTIONS=1` to `Make.user` to enable\nLLVM assertions. This helps catch IR verification errors early:\n\n```bash\necho \"LLVM_ASSERTIONS=1\" >> Make.user\n```\n\nTo run LLVM pass tests:\n```bash\nmake -C test/llvmpasses <testname>.ll\n```\n\n## Using Revise\n\nIf you have made changes to files included in the system image (base/ or stdlib/),\nand need to run code with these changes included, you can use `Revise`.\nTo do so, run `using Revise; Revise.track(Base)` (or Revise.track with the stdlib you modified).\nThe test system supports doing this automatically.\n\nFor instance testing Base changes without rebuilding, using failfast, you can run:\n```\nJULIA_TEST_FAILFAST=1 ./julia -e 'using Revise; Revise.track(Base); include(\"test.jl\")'\n```\n\n## Writing code\n\nAfter writing code, look up the docstring for each function you used. If there\nare recommendations or additional considerations that apply to these functions,\nmake sure to take them into account.\n\n- Do not `ccall` runtime C functions directly if there are existing wrappers for the function.\n- Do not explicitly add a module prefix if the code you're adding is in the same module. E.g. do not use `Base.` for code in Base unless required.\n\n## Task-specific skills\n\nDetailed, situational procedures are provided as Agent Skills following the\n[agentskills.io](https://agentskills.io) open standard. The canonical location is\n`doc/src/devdocs/agents/skills/`; `.agents/skills/` and `.claude/skills/` are\nsymlinks to that directory so skills-aware agents can discover the skills\nautomatically. Agents that support the standard load each skill's `description`\nautomatically and pull in the full `SKILL.md` when relevant; otherwise read the\ncanonical `SKILL.md` directly.\n\n- [`doc/src/devdocs/agents/skills/doctests/`](doc/src/devdocs/agents/skills/doctests/SKILL.md) — writing and verifying `jldoctest` code blocks.\n- [`doc/src/devdocs/agents/skills/test-changes/`](doc/src/devdocs/agents/skills/test-changes/SKILL.md) — running and updating tests after changing them.\n- [`doc/src/devdocs/agents/skills/c-static-analysis/`](doc/src/devdocs/agents/skills/c-static-analysis/SKILL.md) — Clang static analysis and GC-rooting for C/C++ changes under `src/`.\n- [`doc/src/devdocs/agents/skills/external-deps/`](doc/src/devdocs/agents/skills/external-deps/SKILL.md) — modifying external dependencies (`deps/`, patches) and JLLs.\n- [`doc/src/devdocs/agents/skills/buildkite-logs/`](doc/src/devdocs/agents/skills/buildkite-logs/SKILL.md) — fetching and inspecting Buildkite CI logs without web sign-in.\n- [`doc/src/devdocs/agents/skills/ci-timing/`](doc/src/devdocs/agents/skills/ci-timing/SKILL.md) — comparing a PR's Buildkite job durations against recent CI history.\n- [`doc/src/devdocs/agents/skills/compiler-jl/`](doc/src/devdocs/agents/skills/compiler-jl/SKILL.md) — developing and testing Compiler.jl.\n- [`doc/src/devdocs/agents/skills/julia-syntax-lowering/`](doc/src/devdocs/agents/skills/julia-syntax-lowering/SKILL.md) — developing and testing JuliaSyntax and JuliaLowering.\n\n## Commit messages and pull requests\n\nWhen writing commit messages, follow the format \"component: Brief summary\" for\nthe title. In the body of the commit message, provide a brief prose summary\nof the purpose of the changes made. Do not specifically mention added tests, comments,\ndocumentation, etc., unless this is the main purpose of the change. Do not mention\nthe test plan, unless it differs from what you were instructed to do in AGENTS.md.\nIf your change fixes one or more issues, use the syntax \"Fixes #\" at the end of the commit message, but do not include it in the title.\n\nWhen referencing external GitHub PRs or issues, use proper GitHub interlinking format (e.g., `owner/repo#123` for PRs/issues).\nWhen fixing CI failures, include the link to the specific CI failure in the commit message.\nAlways quote macro names in backticks in commit messages and PR titles/bodies (e.g. `` `@inbounds` ``, not @inbounds), so GitHub does not notify the unrelated user with that handle.\n\nWhen preparing a pull request for the human author to open, draft the body as follows, expecting\nthem to reword it:\n1. If the pull request consists of one commit only, use the body of the commit for the body of the pull request.\n2. If there are multiple commits in the pull request, follow the same guidelines for the pull request as for the commit body.\n3. Make sure that the base commit of the pull request is recent (within the past two days) - if not rebase your changes first.\n4. If a separate tool reviews the commit, this is useful to note. Encourage the human to state how carefully they read and understood the content also, for example, by drafting the text to say the human author has *not* read any of it, and expecting they will update that once they read that disclaimer.\n","category":"root","tokens":1670},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"<!--\n\nInclude the contents of AGENTS.md\n\nhttps://code.claude.com/docs/en/claude-code-on-the-web#best-practices\n\n-->\n\n@AGENTS.md\n","category":"root","tokens":32}]}