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.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
日本語の概要は準備中です。原文の説明を表示しています。