Julia 仓库的 Agent Skills面向 AI 开发者的项目内技能体系详解【免费下载链接】juliaThe Julia Programming Language项目地址: https://gitcode.com/gh_mirrors/ju/julia导读本文介绍 Julia 语言官方仓库JuliaLang/julia 镜像中一套面向 AI 编程助手Agent的项目内技能Agent Skills体系。该体系将 Julia 开发中的关键工作流——从写jldoctest、跑测试、做 Clang 静态分析、改外部依赖到排查 Buildkite CI 日志——沉淀为带结构化元数据的SKILL.md技能文件并通过符号链接供 Claude Code、Cursus 等支持 Agent Skills 的工具自动发现。读完本文你将理解这套技能的存放位置、SKILL.md格式约定、自动发现机制以及 8 个内置技能各自解决什么问题、如何被调用。技能仓库的整体布局Julia 仓库将项目内 Agent Skills 的规范canonical副本统一放在一个目录下doc/src/devdocs/agents/skills/这是所有技能文件的唯一事实来源。该目录下每个子目录对应一个技能每个技能的主体是一个遵循 Agent Skills 规范的SKILL.md文件。以当前仓库为例共包含 8 个技能技能目录用途doctests编写与验证jldoctest代码块test-changes修改测试后运行与更新测试c-static-analysis对src/下 C/C 改动做 Clang 静态分析与 GC-rooting 检查external-deps修改外部依赖deps/、补丁与 JLL 包buildkite-logs无需网页登录即可抓取与检查 Buildkite CI 日志ci-timing对比 PR 的 Buildkite 任务耗时与近期 CI 历史compiler-jl开发与测试 Compiler.jljulia-syntax-lowering开发与测试 JuliaSyntax 与 JuliaLowering技能的元数据名称、描述随后会被文档构建系统读取将每个SKILL.md渲染进官方开发文档。SKILL.md格式与自动发现机制Frontmatter 元数据每个技能文件都以 YAML frontmatter 开头包含name与description两个字段。description尤其关键因为它描述了该技能的使用时机是技能感知型 Agent 决定何时加载技能的依据。例如c-static-analysis/SKILL.md的元数据为--- name: c-static-analysis description: Run Clang static analysis on Julias 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. ---name与目录名保持一致description以 Use ... 的祈使句式明确触发条件便于 Agent 在任务描述中自动匹配。符号链接实现自动发现为了让支持 Agent Skills 的客户端开箱即用地发现这些技能仓库在根目录提供了两个指向规范目录的符号链接当前仓库中已确认存在.agents/skills/→../doc/src/devdocs/agents/skills.claude/skills/→../doc/src/devdocs/agents/skills这意味着无论 Agent 按.agents/skills/Cursus 等通用 Agent Skills 规范约定还是按.claude/skills/Claude Code 约定去查找都能落到同一份规范技能。仓库明确规定不要通过这两个发现路径直接编辑技能文件所有修改都应在规范目录下的SKILL.md中完成以避免符号链接路径与规范副本之间出现不一致。文档构建集成doc/下的文档构建流程会读取每个规范SKILL.md连同其 Agent Skill 元数据一起渲染成文档页面使这些技能既能被机器发现也能被人类开发者阅读。相关文档目录见 doc/src/devdocs/agents。八个内置技能的实战要点下面逐一展开各技能的核心工作流全部内容继承自对应的SKILL.md。1. doctests编写与验证jldoctest适用场景在base/、stdlib/、Compiler/的 docstring 中或doc/下新增、修改任何jldoctest代码块或在提交涉及 doctest 的 PR 之前。写作前应先复习 jldoctests 最佳实践涉及过滤器、标签、setup 代码。验证步骤为# 使用预构建的 juliaup 运行 doctest make -C doc doctesttrue revisetrue JULIA_EXECUTABLE$HOME/.juliaup/bin/julia # 使用仓库内构建的 julia首选不要传其他选项 make -C doc doctesttrue revisetrue注意doctest 可能耗时长达 15 分钟不应中途终止也不应为该命令设置超时。2. test-changes修改测试后的标准流程适用场景在test/或stdlib/**/test/下新增、修改任何测试文件。修改了某个测试如foo后运行make test-revise-foo确认改动后测试仍然通过新增测试应加入已有测试文件除非明确要求否则不要新建测试文件每个测试文件顶部写一条注释说明测试内容其余注释保持精简使用环境变量JULIA_TEST_FAILFAST1让测试快速失败不要在测试中用固定的sleep协调时序——CI 机器负载不可控应基于可观察状态就绪标记、往返消息同步或采用重试机制。3. c-static-analysisC/C 运行时与 GC-rooting 检查适用场景修改src/下的运行时/codegen C/C 源文件不含头文件之后、提 PR 之前。注意运行时改动还需重新构建make -j。首次使用或 LLVM/Clang 工具链依赖变化后先初始化依赖make -C src install-analysis-deps然后对指定源文件取去掉.c/.cpp后的文件主干名运行分析# 分析 src/jloptions.c make -C src analyze-jloptions -j8 # 分析 src/codegen.cpp make -C src analyze-codegen -j8若make支持--output-sync可加上以保持并行输出分组。也可单独重跑某个检查clang-sa-file-stem、clang-sagc-file-stem、clang-safety-file-stem、clang-tidy-file-stem。修复 GC-rooting 检查器clang-sagc的注意事项优先通过建立真实的 rooting如添加合适的JL_GC_PUSH/JL_GC_POP作用域或锁/控制流修复不要未经用户或维护者确认就添加JL_GC_PROMISE_ROOTED——它只是断言某个值已被 rooting并不会真的 root 该值。若确有必要应停下来说明具体表达式、使其安全的既有 root 以及所考虑的 safepoints请求确认。一个诊断提示如果值被临时搬进 struct/arraylist 后重新加载promise 表达式应引用重新加载后的字段如JL_GC_PROMISE_ROOTED(struct-field)且应放在尽可能靠前、靠近定义或重新加载处而非使用处。4. external-deps外部依赖与 JLL 修改适用场景改动deps/、依赖补丁或任何*_jll目录包括刷新 checksums。外部依赖deps/、deps/patches/始终以USE_BINARYBUILDER0测试构建确保源码构建可用对外部库补丁先运行解压与打补丁步骤验证补丁可干净应用随后用make -C deps USE_BINARYBUILDER0 compile-depname完整构建该依赖优先使用git am格式如git format-patch的完整上游 commit以保留正确的提交元数据更新依赖版本时确保所有关联补丁仍然可用。外部 JLL在对应 jll 目录更新版本号若上游 jll 的依赖发生变化则更新Project.toml最后运行make -f contrib/refresh_checksums.mk jll刷新校验和可能耗时数分钟。5. buildkite-logs免登录抓取 Buildkite CI 日志适用场景调试 Julia CI 失败、审查 Buildkite job或 Buildkite MCP 不可用时。该配方依赖gh、curl、python3以及对 GitHub 和 Buildkite 的网络访问。Julia 的 CI 运行在 Buildkite 上PR 构建在julialang/julia-pr流水线merge 后的 master 构建在julialang/julia-ci定时运行在julialang/julia-master-scheduled旧的julia-master流水线已不存在。公开 Web UI 下载raw_log需要登录但公开流水线有两个可匿名访问的前端 JSON 端点。步骤 1找到构建号。gh pr checks PR-number会给出形如https://buildkite.com/julialang/julia-pr/builds/BUILD#uuid的 launcher-job URL对 master commit 则用 commit statusesgh api repos/JuliaLang/julia/commits/sha/status。注意其中的#uuid片段只是顶层 launcher jobBuild/Check/Test/…不是按平台的子 job。步骤 2列出构建内所有 job名称、状态、退出码、UUIDcurl -sS -H Accept: application/json \ https://buildkite.com/julialang/PIPELINE/builds/BUILD/data/jobs \ -o /tmp/bkjobs.json python3 -c import json; [print(j[state],|,j.get(exit_status),|,j[name],|,j[id]) \ for j in json.load(open(/tmp/bkjobs.json))[records]]/data/jobs端点正是构建页面前端所用的接口一次返回全部 jobrecords另有has_next_page。不要用builds/BUILD.json来发现 job——匿名访问时它返回的jobs数组为空statistics字段仍会显示真实 job 数。步骤 3抓取某个 job 的日志 JSONcurl -sS -H Accept: application/json \ https://buildkite.com/organizations/julialang/pipelines/PIPELINE/builds/BUILD/jobs/JOB-UUID/log \ -o /tmp/bk.json日志文本位于 JSON 的output字段内嵌 HTMLtime时间戳、ANSI 颜色的span以及实体编码的 shell 输出。可这样清洗python3 -c import json,re,html; sjson.load(open(/tmp/bk.json))[output]; \ sre.sub(r[^],,s); print(html.unescape(s)) /tmp/bk.txt清洗后的日志应写入文件再搜索日志可达数百 KB整段灌入上下文会浪费 token。该日志端点对仍在运行的 job 也会返回部分输出。对于挂起的测试 job仓库内的看门狗.buildkite/utilities/timeout.jl、JL_TERM_TIMEOUT会在杀掉任务前打印每个 worker 的逐任务 Julia 回溯core dump 会作为 artifact 上传并在日志中附带lldb bt all摘要——可在日志中搜索---- Task、Waiting for、core dumped。6. ci-timing对比 PR 与历史 CI 耗时适用场景判断某个 PR 是拖慢还是加快了 CI或对照周基线检查构建耗时。julia --startup-fileno --projectcontrib/ci-timing contrib/ci-timing/ci_timing_compare.jl PR-number脚本会输出一张 markdown 表格最慢的 job 排在最前并附 TOTAL 行展示该 PR 在julia-pr构建中各 job 的耗时与过去 7 天 julia-ci-timing 历史中同名 job 的均值/最小/最大值对比。⚠️表示超过周最大值✅表示低于周最小值。无需 Buildkite tokengh仅用于把 PR 号转成构建号。可选参数--build julia-pr/853、--days N、--include-failed、--min-seconds N隐藏短任务。阅读结果的注意事项单次构建对比一周采样落在 min/max 区间内属于 Agent 方差即使出现⚠️/✅也需要第二个构建佐证juliasyntax/Launch *等任务只有几秒其百分比是噪声可用--min-seconds 120剔除全机群同方向偏移会影响 TOTAL 行并非 PR 自身效果损坏从未运行、运行中与被取代的重试 job 会被排除失败 job 的耗时会被失败截短或拉长。对慢速或失败 job 背后的日志参见buildkite-logs技能。7. compiler-jl开发与测试 Compiler.jl适用场景修改Compiler/源码、测试或包元数据调试编译器行为或激活 stdlib Compiler 做反射/native-codegen 实验而非使用 sysimage 中的Base.Compiler。背景bootstrap 期间Compiler/会被构建进 sysimage 成为Base.Compiler日常原生编译使用的就是这个内建编译器。由于它已固化在 sysimage 中构建后对Compiler/的修改不会反映到Base.Compiler除非重新构建 Julia。Compiler/也可作为 stdlib 包加载得到与Base.Compiler不同的独立Compiler模块——日常开发、测试、调试 post-sysimage 源码改动时优先用这个 stdlibCompiler而非尝试用 Revise 替换Base.Compiler。排查运行时兼容性问题时make -C src更新运行时的速度比重建整个 sysimage 快当需要把更新后的Compiler/固化进Base.Compiler或检查 sysimage/native-codegen 集成时再重建 Julia。以 stdlib 方式实验./usr/bin/julia --projectCompiler反射后端日常调试首选using InteractiveUtils, Compiler activate Compiler # 等价于 activate Compiler[:reflection]此时code_typed、code_typed、code_warntype等 Base/InteractiveUtils 反射工具会使用加载的 stdlibCompiler无需重建 sysimage 即可试验编译器改动。原生编译后端仅在专门调试 native compilation/codegen 行为时使用using InteractiveUtils, Compiler activate Compiler[:codegen]这比反射激活更激进会让运行时在编译请求时调用加载的编译器失败往往涉及 sysimage、runtime、native-codegen 或 compiler-cache 交互。普通调试优先用反射激活最终集成检查应重建 Julia 并测试 sysimage 内的Base.Compiler。以 stdlib 方式跑测试./usr/bin/julia --projectCompiler -e using Pkg; Pkg.test() # 单个测试文件包在 Test.testset 下直接 include ./usr/bin/julia --projectCompiler -e using Test; testset inline include(Compiler/test/inline.jl)大多数Compiler/test/文件都会 includeCompiler/test/setup_Compiler.jl它为此工作流激活或导入合适的Compiler模块。测试 sysimage 中的Base.Compiler使用顶层测试入口./usr/bin/julia test/runtests.jl Compiler如果改了Compiler/且需要让这些改动反映到Base.Compiler先重建 Julia 使 sysimage 包含更新后的编译器代码。8. julia-syntax-lowering开发 JuliaSyntax 与 JuliaLowering适用场景修改JuliaSyntax/或JuliaLowering/源码、测试或包元数据。测试 JuliaSyntax与仓库内运行时解耦若改动可能对版本敏感应结合相关已安装 Julia 版本测试julia --projectJuliaSyntax -e using Pkg; Pkg.test()测试 JuliaLowering优先使用仓库内运行时因为与 Julia 运行时兼容性可能很重要./usr/bin/julia --projectJuliaLowering -e using Pkg; Pkg.test()若./usr/bin/julia不可用应说明该限制并仅用可用的julia做初步验证。本仓库中JuliaLowering/Project.toml将JuliaSyntax依赖指向同级 checkoutpath ../JuliaSyntax因此 JuliaSyntax 改动会影响 JuliaLowering——当 JuliaSyntax 改动可能影响 lowering 行为或 JuliaLowering 消费的语法数据时也应运行 JuliaLowering 测试。定向运行 JuliaLowering 测试先 includeJuliaLowering/test/utils.jl与JuliaLowering/test/runtests.jl的做法一致./usr/bin/julia --projectJuliaLowering -e cd(JuliaLowering/test) do; include(utils.jl); include(scopes.jl); end # 对 _ir.jl fixtures加载 utils.jl 后调用 test_ir_cases ./usr/bin/julia --projectJuliaLowering -e cd(JuliaLowering/test) do; include(utils.jl); test_ir_cases(scopes_ir.jl); end快速执行检查用仓库内运行时加 JuliaLowering 项目启动然后显式求值using JuliaLowering JuliaLowering.include_string(Main, 1 2)或激活为进程的 lowerer 后再正常求值using JuliaLowering JuliaLowering.activate!() 1 2激活后可配合include(path/to/file.jl)检查文件。若从-e使用JuliaLowering.activate!()被测试代码应作为激活后的独立顶层语句或放进include(...)中。技能文件与仓库其他部分的对应关系这套技能并非凭空设计而是与仓库实际布局一一对应可在源码与配置中找到依据技能元数据与文档构建doc/src/devdocs/agents/README.md说明文档构建会渲染每个SKILL.md符号链接仓库根目录的.agents/skills与.claude/skills均指向doc/src/devdocs/agents/skillsexternal-deps技能引用的 checksums 刷新脚本位于 contrib/refresh_checksums.mk依赖版本与补丁位于 deps/ 与 deps/patches/ci-timing技能调用的分析脚本位于 contrib/ci-timing/ci_timing_compare.jl对应contrib/ci-timing/目录buildkite-logs技能提到的看门狗脚本为 .buildkite/utilities/timeout.jlc-static-analysis技能的analyze-file-stem等 make 目标定义于 src/Makefile静态分析支持代码位于 src/clangsa/compiler-jl技能的测试辅助文件为 Compiler/test/setup_Compiler.jljulia-syntax-lowering技能提到的测试工具为 JuliaLowering/test/utils.jl其JuliaSyntaxpath 依赖可核对 JuliaLowering/Project.toml。如何为 Julia 开发贡献新的 Agent Skill从现有 8 个技能可以归纳出新增技能的约定流程在doc/src/devdocs/agents/skills/skill-name/SKILL.md创建规范技能文件frontmatter 提供name与description正文用清晰的分步指令描述工作流包括可复制的命令、注意事项、失败时的处理原则保持根目录.agents/skills/与.claude/skills/符号链接不变它们已指向规范目录无需新建在 doc/src/devdocs/agents/README.md 的技能清单中登记新技能使文档构建将其渲染出来参照test-changes、external-deps等技能的写法将命令与环境变量如JULIA_TEST_FAILFAST1等实测细节写全并像buildkite-logs那样注明依赖的命令行工具。这套体系的价值在于把散落在 CONTRIBUTING、Makefile 与 CI 配置中的工程知识变成 Agent 在提 PR 前可主动发现、按步骤执行的结构化技能从而让 AI 辅助开发与 Julia 仓库的既有工程规范保持一致。【免费下载链接】juliaThe Julia Programming Language项目地址: https://gitcode.com/gh_mirrors/ju/julia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Julia 仓库的 Agent Skills：面向 AI 开发者的项目内技能体系详解
Julia 仓库的 Agent Skills面向 AI 开发者的项目内技能体系详解【免费下载链接】juliaThe Julia Programming Language项目地址: https://gitcode.com/gh_mirrors/ju/julia导读本文介绍 Julia 语言官方仓库JuliaLang/julia 镜像中一套面向 AI 编程助手Agent的项目内技能Agent Skills体系。该体系将 Julia 开发中的关键工作流——从写jldoctest、跑测试、做 Clang 静态分析、改外部依赖到排查 Buildkite CI 日志——沉淀为带结构化元数据的SKILL.md技能文件并通过符号链接供 Claude Code、Cursus 等支持 Agent Skills 的工具自动发现。读完本文你将理解这套技能的存放位置、SKILL.md格式约定、自动发现机制以及 8 个内置技能各自解决什么问题、如何被调用。技能仓库的整体布局Julia 仓库将项目内 Agent Skills 的规范canonical副本统一放在一个目录下doc/src/devdocs/agents/skills/这是所有技能文件的唯一事实来源。该目录下每个子目录对应一个技能每个技能的主体是一个遵循 Agent Skills 规范的SKILL.md文件。以当前仓库为例共包含 8 个技能技能目录用途doctests编写与验证jldoctest代码块test-changes修改测试后运行与更新测试c-static-analysis对src/下 C/C 改动做 Clang 静态分析与 GC-rooting 检查external-deps修改外部依赖deps/、补丁与 JLL 包buildkite-logs无需网页登录即可抓取与检查 Buildkite CI 日志ci-timing对比 PR 的 Buildkite 任务耗时与近期 CI 历史compiler-jl开发与测试 Compiler.jljulia-syntax-lowering开发与测试 JuliaSyntax 与 JuliaLowering技能的元数据名称、描述随后会被文档构建系统读取将每个SKILL.md渲染进官方开发文档。SKILL.md格式与自动发现机制Frontmatter 元数据每个技能文件都以 YAML frontmatter 开头包含name与description两个字段。description尤其关键因为它描述了该技能的使用时机是技能感知型 Agent 决定何时加载技能的依据。例如c-static-analysis/SKILL.md的元数据为--- name: c-static-analysis description: Run Clang static analysis on Julias 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. ---name与目录名保持一致description以 Use ... 的祈使句式明确触发条件便于 Agent 在任务描述中自动匹配。符号链接实现自动发现为了让支持 Agent Skills 的客户端开箱即用地发现这些技能仓库在根目录提供了两个指向规范目录的符号链接当前仓库中已确认存在.agents/skills/→../doc/src/devdocs/agents/skills.claude/skills/→../doc/src/devdocs/agents/skills这意味着无论 Agent 按.agents/skills/Cursus 等通用 Agent Skills 规范约定还是按.claude/skills/Claude Code 约定去查找都能落到同一份规范技能。仓库明确规定不要通过这两个发现路径直接编辑技能文件所有修改都应在规范目录下的SKILL.md中完成以避免符号链接路径与规范副本之间出现不一致。文档构建集成doc/下的文档构建流程会读取每个规范SKILL.md连同其 Agent Skill 元数据一起渲染成文档页面使这些技能既能被机器发现也能被人类开发者阅读。相关文档目录见 doc/src/devdocs/agents。八个内置技能的实战要点下面逐一展开各技能的核心工作流全部内容继承自对应的SKILL.md。1. doctests编写与验证jldoctest适用场景在base/、stdlib/、Compiler/的 docstring 中或doc/下新增、修改任何jldoctest代码块或在提交涉及 doctest 的 PR 之前。写作前应先复习 jldoctests 最佳实践涉及过滤器、标签、setup 代码。验证步骤为# 使用预构建的 juliaup 运行 doctest make -C doc doctesttrue revisetrue JULIA_EXECUTABLE$HOME/.juliaup/bin/julia # 使用仓库内构建的 julia首选不要传其他选项 make -C doc doctesttrue revisetrue注意doctest 可能耗时长达 15 分钟不应中途终止也不应为该命令设置超时。2. test-changes修改测试后的标准流程适用场景在test/或stdlib/**/test/下新增、修改任何测试文件。修改了某个测试如foo后运行make test-revise-foo确认改动后测试仍然通过新增测试应加入已有测试文件除非明确要求否则不要新建测试文件每个测试文件顶部写一条注释说明测试内容其余注释保持精简使用环境变量JULIA_TEST_FAILFAST1让测试快速失败不要在测试中用固定的sleep协调时序——CI 机器负载不可控应基于可观察状态就绪标记、往返消息同步或采用重试机制。3. c-static-analysisC/C 运行时与 GC-rooting 检查适用场景修改src/下的运行时/codegen C/C 源文件不含头文件之后、提 PR 之前。注意运行时改动还需重新构建make -j。首次使用或 LLVM/Clang 工具链依赖变化后先初始化依赖make -C src install-analysis-deps然后对指定源文件取去掉.c/.cpp后的文件主干名运行分析# 分析 src/jloptions.c make -C src analyze-jloptions -j8 # 分析 src/codegen.cpp make -C src analyze-codegen -j8若make支持--output-sync可加上以保持并行输出分组。也可单独重跑某个检查clang-sa-file-stem、clang-sagc-file-stem、clang-safety-file-stem、clang-tidy-file-stem。修复 GC-rooting 检查器clang-sagc的注意事项优先通过建立真实的 rooting如添加合适的JL_GC_PUSH/JL_GC_POP作用域或锁/控制流修复不要未经用户或维护者确认就添加JL_GC_PROMISE_ROOTED——它只是断言某个值已被 rooting并不会真的 root 该值。若确有必要应停下来说明具体表达式、使其安全的既有 root 以及所考虑的 safepoints请求确认。一个诊断提示如果值被临时搬进 struct/arraylist 后重新加载promise 表达式应引用重新加载后的字段如JL_GC_PROMISE_ROOTED(struct-field)且应放在尽可能靠前、靠近定义或重新加载处而非使用处。4. external-deps外部依赖与 JLL 修改适用场景改动deps/、依赖补丁或任何*_jll目录包括刷新 checksums。外部依赖deps/、deps/patches/始终以USE_BINARYBUILDER0测试构建确保源码构建可用对外部库补丁先运行解压与打补丁步骤验证补丁可干净应用随后用make -C deps USE_BINARYBUILDER0 compile-depname完整构建该依赖优先使用git am格式如git format-patch的完整上游 commit以保留正确的提交元数据更新依赖版本时确保所有关联补丁仍然可用。外部 JLL在对应 jll 目录更新版本号若上游 jll 的依赖发生变化则更新Project.toml最后运行make -f contrib/refresh_checksums.mk jll刷新校验和可能耗时数分钟。5. buildkite-logs免登录抓取 Buildkite CI 日志适用场景调试 Julia CI 失败、审查 Buildkite job或 Buildkite MCP 不可用时。该配方依赖gh、curl、python3以及对 GitHub 和 Buildkite 的网络访问。Julia 的 CI 运行在 Buildkite 上PR 构建在julialang/julia-pr流水线merge 后的 master 构建在julialang/julia-ci定时运行在julialang/julia-master-scheduled旧的julia-master流水线已不存在。公开 Web UI 下载raw_log需要登录但公开流水线有两个可匿名访问的前端 JSON 端点。步骤 1找到构建号。gh pr checks PR-number会给出形如https://buildkite.com/julialang/julia-pr/builds/BUILD#uuid的 launcher-job URL对 master commit 则用 commit statusesgh api repos/JuliaLang/julia/commits/sha/status。注意其中的#uuid片段只是顶层 launcher jobBuild/Check/Test/…不是按平台的子 job。步骤 2列出构建内所有 job名称、状态、退出码、UUIDcurl -sS -H Accept: application/json \ https://buildkite.com/julialang/PIPELINE/builds/BUILD/data/jobs \ -o /tmp/bkjobs.json python3 -c import json; [print(j[state],|,j.get(exit_status),|,j[name],|,j[id]) \ for j in json.load(open(/tmp/bkjobs.json))[records]]/data/jobs端点正是构建页面前端所用的接口一次返回全部 jobrecords另有has_next_page。不要用builds/BUILD.json来发现 job——匿名访问时它返回的jobs数组为空statistics字段仍会显示真实 job 数。步骤 3抓取某个 job 的日志 JSONcurl -sS -H Accept: application/json \ https://buildkite.com/organizations/julialang/pipelines/PIPELINE/builds/BUILD/jobs/JOB-UUID/log \ -o /tmp/bk.json日志文本位于 JSON 的output字段内嵌 HTMLtime时间戳、ANSI 颜色的span以及实体编码的 shell 输出。可这样清洗python3 -c import json,re,html; sjson.load(open(/tmp/bk.json))[output]; \ sre.sub(r[^],,s); print(html.unescape(s)) /tmp/bk.txt清洗后的日志应写入文件再搜索日志可达数百 KB整段灌入上下文会浪费 token。该日志端点对仍在运行的 job 也会返回部分输出。对于挂起的测试 job仓库内的看门狗.buildkite/utilities/timeout.jl、JL_TERM_TIMEOUT会在杀掉任务前打印每个 worker 的逐任务 Julia 回溯core dump 会作为 artifact 上传并在日志中附带lldb bt all摘要——可在日志中搜索---- Task、Waiting for、core dumped。6. ci-timing对比 PR 与历史 CI 耗时适用场景判断某个 PR 是拖慢还是加快了 CI或对照周基线检查构建耗时。julia --startup-fileno --projectcontrib/ci-timing contrib/ci-timing/ci_timing_compare.jl PR-number脚本会输出一张 markdown 表格最慢的 job 排在最前并附 TOTAL 行展示该 PR 在julia-pr构建中各 job 的耗时与过去 7 天 julia-ci-timing 历史中同名 job 的均值/最小/最大值对比。⚠️表示超过周最大值✅表示低于周最小值。无需 Buildkite tokengh仅用于把 PR 号转成构建号。可选参数--build julia-pr/853、--days N、--include-failed、--min-seconds N隐藏短任务。阅读结果的注意事项单次构建对比一周采样落在 min/max 区间内属于 Agent 方差即使出现⚠️/✅也需要第二个构建佐证juliasyntax/Launch *等任务只有几秒其百分比是噪声可用--min-seconds 120剔除全机群同方向偏移会影响 TOTAL 行并非 PR 自身效果损坏从未运行、运行中与被取代的重试 job 会被排除失败 job 的耗时会被失败截短或拉长。对慢速或失败 job 背后的日志参见buildkite-logs技能。7. compiler-jl开发与测试 Compiler.jl适用场景修改Compiler/源码、测试或包元数据调试编译器行为或激活 stdlib Compiler 做反射/native-codegen 实验而非使用 sysimage 中的Base.Compiler。背景bootstrap 期间Compiler/会被构建进 sysimage 成为Base.Compiler日常原生编译使用的就是这个内建编译器。由于它已固化在 sysimage 中构建后对Compiler/的修改不会反映到Base.Compiler除非重新构建 Julia。Compiler/也可作为 stdlib 包加载得到与Base.Compiler不同的独立Compiler模块——日常开发、测试、调试 post-sysimage 源码改动时优先用这个 stdlibCompiler而非尝试用 Revise 替换Base.Compiler。排查运行时兼容性问题时make -C src更新运行时的速度比重建整个 sysimage 快当需要把更新后的Compiler/固化进Base.Compiler或检查 sysimage/native-codegen 集成时再重建 Julia。以 stdlib 方式实验./usr/bin/julia --projectCompiler反射后端日常调试首选using InteractiveUtils, Compiler activate Compiler # 等价于 activate Compiler[:reflection]此时code_typed、code_typed、code_warntype等 Base/InteractiveUtils 反射工具会使用加载的 stdlibCompiler无需重建 sysimage 即可试验编译器改动。原生编译后端仅在专门调试 native compilation/codegen 行为时使用using InteractiveUtils, Compiler activate Compiler[:codegen]这比反射激活更激进会让运行时在编译请求时调用加载的编译器失败往往涉及 sysimage、runtime、native-codegen 或 compiler-cache 交互。普通调试优先用反射激活最终集成检查应重建 Julia 并测试 sysimage 内的Base.Compiler。以 stdlib 方式跑测试./usr/bin/julia --projectCompiler -e using Pkg; Pkg.test() # 单个测试文件包在 Test.testset 下直接 include ./usr/bin/julia --projectCompiler -e using Test; testset inline include(Compiler/test/inline.jl)大多数Compiler/test/文件都会 includeCompiler/test/setup_Compiler.jl它为此工作流激活或导入合适的Compiler模块。测试 sysimage 中的Base.Compiler使用顶层测试入口./usr/bin/julia test/runtests.jl Compiler如果改了Compiler/且需要让这些改动反映到Base.Compiler先重建 Julia 使 sysimage 包含更新后的编译器代码。8. julia-syntax-lowering开发 JuliaSyntax 与 JuliaLowering适用场景修改JuliaSyntax/或JuliaLowering/源码、测试或包元数据。测试 JuliaSyntax与仓库内运行时解耦若改动可能对版本敏感应结合相关已安装 Julia 版本测试julia --projectJuliaSyntax -e using Pkg; Pkg.test()测试 JuliaLowering优先使用仓库内运行时因为与 Julia 运行时兼容性可能很重要./usr/bin/julia --projectJuliaLowering -e using Pkg; Pkg.test()若./usr/bin/julia不可用应说明该限制并仅用可用的julia做初步验证。本仓库中JuliaLowering/Project.toml将JuliaSyntax依赖指向同级 checkoutpath ../JuliaSyntax因此 JuliaSyntax 改动会影响 JuliaLowering——当 JuliaSyntax 改动可能影响 lowering 行为或 JuliaLowering 消费的语法数据时也应运行 JuliaLowering 测试。定向运行 JuliaLowering 测试先 includeJuliaLowering/test/utils.jl与JuliaLowering/test/runtests.jl的做法一致./usr/bin/julia --projectJuliaLowering -e cd(JuliaLowering/test) do; include(utils.jl); include(scopes.jl); end # 对 _ir.jl fixtures加载 utils.jl 后调用 test_ir_cases ./usr/bin/julia --projectJuliaLowering -e cd(JuliaLowering/test) do; include(utils.jl); test_ir_cases(scopes_ir.jl); end快速执行检查用仓库内运行时加 JuliaLowering 项目启动然后显式求值using JuliaLowering JuliaLowering.include_string(Main, 1 2)或激活为进程的 lowerer 后再正常求值using JuliaLowering JuliaLowering.activate!() 1 2激活后可配合include(path/to/file.jl)检查文件。若从-e使用JuliaLowering.activate!()被测试代码应作为激活后的独立顶层语句或放进include(...)中。技能文件与仓库其他部分的对应关系这套技能并非凭空设计而是与仓库实际布局一一对应可在源码与配置中找到依据技能元数据与文档构建doc/src/devdocs/agents/README.md说明文档构建会渲染每个SKILL.md符号链接仓库根目录的.agents/skills与.claude/skills均指向doc/src/devdocs/agents/skillsexternal-deps技能引用的 checksums 刷新脚本位于 contrib/refresh_checksums.mk依赖版本与补丁位于 deps/ 与 deps/patches/ci-timing技能调用的分析脚本位于 contrib/ci-timing/ci_timing_compare.jl对应contrib/ci-timing/目录buildkite-logs技能提到的看门狗脚本为 .buildkite/utilities/timeout.jlc-static-analysis技能的analyze-file-stem等 make 目标定义于 src/Makefile静态分析支持代码位于 src/clangsa/compiler-jl技能的测试辅助文件为 Compiler/test/setup_Compiler.jljulia-syntax-lowering技能提到的测试工具为 JuliaLowering/test/utils.jl其JuliaSyntaxpath 依赖可核对 JuliaLowering/Project.toml。如何为 Julia 开发贡献新的 Agent Skill从现有 8 个技能可以归纳出新增技能的约定流程在doc/src/devdocs/agents/skills/skill-name/SKILL.md创建规范技能文件frontmatter 提供name与description正文用清晰的分步指令描述工作流包括可复制的命令、注意事项、失败时的处理原则保持根目录.agents/skills/与.claude/skills/符号链接不变它们已指向规范目录无需新建在 doc/src/devdocs/agents/README.md 的技能清单中登记新技能使文档构建将其渲染出来参照test-changes、external-deps等技能的写法将命令与环境变量如JULIA_TEST_FAILFAST1等实测细节写全并像buildkite-logs那样注明依赖的命令行工具。这套体系的价值在于把散落在 CONTRIBUTING、Makefile 与 CI 配置中的工程知识变成 Agent 在提 PR 前可主动发现、按步骤执行的结构化技能从而让 AI 辅助开发与 Julia 仓库的既有工程规范保持一致。【免费下载链接】juliaThe Julia Programming Language项目地址: https://gitcode.com/gh_mirrors/ju/julia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考