Nix パッケージがバイナリキャッシュから降ってこずローカルビルドになる原因を調査する。
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.
nixos-rebuild switch や home-manager switch、nix build で特定パッケージだけがキャッシュから来ずローカルビルドになるとき、原因は主に3系統に分かれる。闇雲に nix build -L でログを眺める前に、まずどの系統かを切り分ける。
決定論的に確認できる部分（実出力パスの評価、narinfo 直接確認、Hydra API 呼び出し、PR 祖先関係の確認）は scripts/nix-cache-check.sh に切り出してある。HTML を自前でスクレイピングするのは最終手段（失敗ログの中身を読みたいときの build-log サブコマンドのみ）。
同じバージョン表記でも依存関係が更新されれば derivation ハッシュは変わる。まずこれを確定させないと、以降の cache-check や hydra 比較が的外れになる。
bash <skill-dir>/scripts/nix-cache-check.sh outpath '.#nixosConfigurations.<host>.pkgs.<package>'
.#homeConfigurations.<name>.pkgs.<package> や単なる nixpkgs#<package> 相当のインストーラブルでも同様に使える。
nix path-info --store https://... はローカルに .drv が無いと使えないことがあるため、narinfo を HTTP で直接叩くほうが確実。実行環境の nix show-config に登録済みの substituters（cache.nixos.org・cachix 各種）全部を自動で対象にする。
bash <skill-dir>/scripts/nix-cache-check.sh cache-check <出力パスまたは先頭ハッシュ>
HIT … そのキャッシュに存在するMISS … 存在しない（未ビルド or ビルド失敗）NO_ACCESS(401/403) … private cache の可能性。認証設定を疑うcache-check <path> <url> [<url>...] のように明示指定もできる全て MISS なら、次に Hydra 側の状況を見る。
HTML の一覧ページを自前でスクレイピングしない。 nix-community 製の専用ツール hydra-check（nixpkgs に pkgs.hydra-check として収録済み）をまず使う。
bash <skill-dir>/scripts/nix-cache-check.sh hydra <package> --channel nixpkgs-unstable --arch x86_64-linux
ビルド履歴が成功/失敗/日付付きで一覧表示される。特定の build ID の詳細を正確に見たいときは JSON API を使う（一覧ページのステータスバッジは簡易表示で不正確なことがある）。
bash <skill-dir>/scripts/nix-cache-check.sh build-json <build-id>
# finished/buildstatus で正確な成否がわかる。buildstatus: 0 = 成功
失敗していた場合、失敗ログの末尾は JSON に含まれないため HTML から読む（ここだけスクレイピングが必要な理由がある箇所）:
bash <skill-dir>/scripts/nix-cache-check.sh build-log <build-id>
build-log の中身は Python スクリプト（scripts/hydra_build_log.py）で、uv run 経由（PEP 723 inline metadata で Python バージョンを固定）で実行して再現性を持たせている。uv が入っていない環境でも nix さえあれば nix run nixpkgs#uv -- run ... に自動フォールバックするので、素の python3 には依存しない。
「この不具合、nixpkgs の PR #xxxxx で直ってるはずでは?」を確認するとき、対象リポジトリを git clone するのは重すぎる（特に nixpkgs）。GitHub の compare API で祖先関係だけ確認する。
gh api repos/NixOS/nixpkgs/pulls/<PR番号> --jq '{merged, merge_commit_sha, merged_at}'
bash <skill-dir>/scripts/nix-cache-check.sh pr-ancestry NixOS/nixpkgs <PRのmerge_commit_sha> <flake.lockがロックしているrev>
behind_by: 0 なら base（PRの修正）は head（ロック中の revision）の祖先＝取り込み済み。ここが Yes でも 2. でキャッシュに無いなら、原因は「ソースは直っているが Hydra のビルドがまだ/失敗」であって、こちらの設定側の問題ではない。
Queued/Failed → Hydra側の一時的な遅延・インフラ障害。設定側に問題はなく、ローカルビルドを許容するか nix flake update でさらに新しい revision（既にキャッシュ済みの可能性がある）に進めるか判断するNO_ACCESS が出る substituter がある → private cache。認証トークン設定（netrc や nix.conf の access-tokens）を確認するnix（flakes 有効）、curl、jq が必要。gh は pr-ancestry のみで使用（要 gh auth login）hydra-check はサブコマンド内で自動的に nix run nixpkgs#hydra-check -- にフォールバックするが、頻用するなら pkgs.hydra-check を環境に入れておくと速い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.
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
The English summary is being prepared. Showing the original description.
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
The English summary is being prepared. Showing the original description.
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
The English summary is being prepared. Showing the original description.
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
The English summary is being prepared. Showing the original description.
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
The English summary is being prepared. Showing the original description.
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。
The English summary is being prepared. Showing the original description.