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.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
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.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
Review the branch with /code-review at high, then answer the findings with /code-review-response.
The English summary is being prepared. Showing the original description.
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).
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.