Measure how long GitHub Actions jobs and steps took across past runs, and find the pull request that made CI slower. Use for any question about CI duration, a slow job, or when CI got slow.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
ci-times.mjs reads run, job and step timings from the GitHub API with gh.
Run it with mise's Node, and redirect its output to a file in scratchpad/:
a sweep over a month makes hundreds of API calls.
Sweep the runs on main, one row per run, oldest first:
mise exec -- node .claude/skills/ci-timing/ci-times.mjs \
--since 2026-09-01 --job 'E2E\+stdlib' --step stdlib \
> scratchpad/ci-times.tsv
Each matched job prints as name=STEP/JOB in seconds. - means the step did
not run or there was no --step. The row ends with the run's title, which
names the merged pull request. Look for the row where a job's total steps up
and stays up.
Only runs on main from push events give a clean timeline: each one is a
single merge. The defaults are --workflow ci.yml --branch main --event push.
The job total can grow while the step you guessed stays flat. A step that a
pull request added is invisible to --step. Print every step of the runs on
either side of the jump and compare them:
mise exec -- node .claude/skills/ci-timing/ci-times.mjs --sha <before> --job 'stdlib O3'
mise exec -- node .claude/skills/ci-timing/ci-times.mjs --sha <after> --job 'stdlib O3'
--run <run id> does the same for a run that is not on main, such as a pull
request's run.
wado-compiler/tests/fixtures/*.wado, test
blocks under wado-compiler/lib/) before calling it a regression.还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Measure Wado's performance or the size of the Wasm it generates, and refresh the benchmark/ and wasm-size/ README files. Use for any benchmarking or size-measurement request, whichever benchmark it names.
中文简介正在准备中。当前显示原文说明。
How to answer code review feedback — a human reviewer, CodeRabbit, or any review bot. Verify the findings, report the classes they are instances of to the user before fixing, then fix the class rather than the sites named. Put design decisions to the user, then run /distill. Invoke when responding to review comments on a pull request, or to the findings of a /code-review run.
中文简介正在准备中。当前显示原文说明。
Investigate and improve code coverage for the wado-compiler crate. Use for any question about what the tests do and do not reach, dead code included.
中文简介正在准备中。当前显示原文说明。
Review the branch with /code-review at high, then answer the findings with /code-review-response.
中文简介正在准备中。当前显示原文说明。
Use rust-gdb to inspect variables and step through code without modifying it. Prefer it over print debugging for any investigation into what the compiler is actually doing (lldb is unavailable on Claude Code Web).
中文简介正在准备中。当前显示原文说明。
Cut the branch down to what the code cannot say: reuse what exists, remove duplication, dead code, and wasted work, turn invariants into asserts, and delete the comments the code already speaks. Run it after answering review feedback too — a fix written to satisfy a reviewer is the least distilled code on the branch.
中文简介正在准备中。当前显示原文说明。