Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
nix-devenv
Nix + flake-parts 開発環境の構築パターン: root flake.nix(成果物)+ dev/flake.nix(devShell + CI シェル)を direnv で読み込む構成、および GitHub Actions CI テンプレートを提供する。
このスキルは /nix-devenv と明示的に呼び出されたときのみ使用する。キーワードマッチによる自動起動はしない。
含まれるファイル(1)
- SKILL.md8.8 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
nix-devenv
Nix + flake-parts 開発環境のセットアップパターン。
ルートの flake.nix はプロジェクト成果物専用、開発ツールは dev/flake.nix に分離し direnv で読み込む。
同じ dev/flake.nix の ci devShell を GitHub Actions でも使う。
構成概要
<project>/
├── flake.nix # プロジェクト成果物 + treefmt-nix (formatter) のみ
├── flake.lock
├── dev/
│ ├── flake.nix # 開発ツール (default) + CI シェル (ci) 定義
│ └── flake.lock
├── .envrc # use flake ./dev ← .gitignore に含める(ユーザーが手動で作成)
├── example.envrc # .envrc のサンプル(リポジトリにコミットする)
└── .github/
├── actions/
│ └── setup-nix/
│ └── action.yaml
└── workflows/
└── check.yml
Key decisions(設計の理由)
- treefmt は root
flake.nixに定義する:nix fmtがプロジェクトルートで動くようにするため。dev/ に置くと root でのnix fmtが効かない dev/flake.nixからinputs'.root.formatterで formatter を参照: treefmt 設定を重複させない。dev/ に treefmt-nix を独立して追加してはいけないdev/flake.nixのnixpkgs・flake-partsは root へのfollowsにする: lock の分散を防ぎ root と完全に同一バージョンを使う。standalone URL を書いてはいけないdevShells.ciは TERM = "dumb" + 最小構成: ターミナル制御コードが CI ログを汚さないようにするため.envrcは .gitignore 対象、example.envrcをコミットする: ユーザー固有の設定は追跡しない
1. ルート flake.nix
{
description = "<プロジェクト説明>";
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
flake-parts.url = "github:hercules-ci/flake-parts";
treefmt-nix = {
url = "github:numtide/treefmt-nix";
inputs.nixpkgs.follows = "nixpkgs";
};
};
outputs =
inputs@{ flake-parts, ... }:
flake-parts.lib.mkFlake { inherit inputs; } {
imports = [ inputs.treefmt-nix.flakeModule ];
systems = [
"x86_64-linux"
"aarch64-linux"
"aarch64-darwin"
"x86_64-darwin"
];
perSystem = { pkgs, ... }: {
treefmt = {
projectRootFile = "flake.nix";
programs.nixfmt = {
enable = true;
package = pkgs.nixfmt;
};
# 追加フォーマッタ例: programs.prettier.enable = true;
# 追加フォーマッタ例: programs.rustfmt.enable = true;
};
};
flake = {
# プロジェクト固有の outputs をここに追加
# 例(Nixライブラリ系):
# lib = import ./lib;
# homeManagerModules.default = ./modules/home-manager.nix;
# nixosModules.default = ./modules/nixos.nix;
# darwinModules.default = ./modules/nix-darwin.nix;
};
};
}
treefmt-nix.flakeModuleを import するとperSystem.config.treefmt.build.wrapperがpackages.formatterとして自動公開される。dev/flake.nixはこれをinputs'.root.formatterで参照する。
2. dev/flake.nix
{
description = "<プロジェクト名> development environment";
inputs = {
root.url = "path:../";
nixpkgs.follows = "root/nixpkgs";
flake-parts.follows = "root/flake-parts";
# NG: treefmt-nix を ここに独立して追加してはいけない
# OK: root の formatter は inputs'.root.formatter 経由で使う
};
outputs =
inputs@{ flake-parts, ... }:
flake-parts.lib.mkFlake { inherit inputs; } {
systems = [
"x86_64-linux"
"aarch64-linux"
"aarch64-darwin"
"x86_64-darwin"
];
perSystem =
{ inputs', pkgs, ... }:
{
devShells = {
# ローカル開発用: LSP・linter・formatter フル搭載
default = pkgs.mkShell {
packages = with pkgs; [
statix # Nix linter
nixd # Nix language server
inputs'.root.formatter # root の treefmt formatter を再利用
# プロジェクト固有ツールを追加
# 例(Rust): cargo rustfmt rust-analyzer
# 例(Python): ruff pyright
];
shellHook = ''
export REPO_ROOT=$(git rev-parse --show-superproject-working-tree --show-toplevel)
'';
};
# CI 用: 最小構成 + TERM=dumb
ci = pkgs.mkShell {
packages = with pkgs; [
# テスト実行に必要な最小限のツールのみ
];
env = {
TERM = "dumb";
};
shellHook = ''
export REPO_ROOT=$(git rev-parse --show-superproject-working-tree --show-toplevel)
'';
};
};
};
};
}
3. .envrc / example.envrc
example.envrc(リポジトリにコミットする):
#!/usr/bin/env bash
use flake ./dev
.envrc はユーザーが example.envrc をコピーして作成する(.gitignore 対象)。
.gitignore に追加:
.envrc
.direnv/
4. GitHub Actions: setup-nix composite action
.github/actions/setup-nix/action.yaml:
name: 'Setup Nix'
description: 'Install Nix and configure Cachix'
inputs:
cachix-auth-token:
description: 'Cachix authentication token'
required: false
runs:
using: 'composite'
steps:
- name: Install Nix
uses: cachix/install-nix-action@1ca7d21a94afc7c957383a2d217460d980de4934 # v31.10.1
with:
github_access_token: ${{ github.token }}
- name: Setup Cachix
uses: cachix/cachix-action@3ba601ff5bbb07c7220846facfa2cd81eeee15a1 # v16
with:
name: <cachix-cache-name>
authToken: ${{ inputs.cachix-auth-token }}
cachix-auth-tokenを省略した場合は read-only でキャッシュを使うだけになる。cachix-cache-nameは cachix.io で作成したキャッシュ名(プレースホルダーのまま渡し、ユーザーが差し替える)。
5. GitHub Actions: CI ワークフロー
.github/workflows/check.yml:
name: Nix Flake Check
on:
push:
branches-ignore:
- main # main は PR 経由でのみ更新するため push を除外
pull_request:
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Setup Nix
uses: ./.github/actions/setup-nix
with:
cachix-auth-token: ${{ secrets.CACHIX_AUTH_TOKEN }}
- name: nix flake check
run: nix flake check
# dev/flake.nix の ci シェルで任意コマンドを実行する場合:
# - name: Run tests
# run: nix develop '.?dir=dev#ci' -c <コマンド>
# env:
# TERM: "dumb"
matrix で複数 system をテストする場合:
strategy:
matrix:
include:
- os: ubuntu-latest
system: x86_64-linux
- os: ubuntu-24.04-arm
system: aarch64-linux
- os: macos-latest
system: aarch64-darwin
runs-on: ${{ matrix.os }}
Setup checklist
-
flake.nix作成・更新 →nix flake checkで評価確認 -
dev/flake.nix作成 →nix develop ./devで動作確認 -
example.envrc作成・コミット -
.gitignoreに.envrc/.direnv/を追加 - ユーザーが
cp example.envrc .envrc && direnv allowで入れることを確認 -
dev/flake.nixにcidevShell が必要か判断(CI でnix developを使う場合は必須) -
.github/actions/setup-nix/action.yaml作成 -
.github/workflows/check.yml作成
Actions hash 更新方法
ハッシュは時間とともに陳腐化する。スキルのテンプレートを更新するときは必ず以下でタグの最新ハッシュを取得し、SKILL.md のテンプレートも合わせて更新すること。
gh api repos/cachix/install-nix-action/git/refs/tags/v31.10.1 | jq -r '.object.sha'
gh api repos/cachix/cachix-action/git/refs/tags/v16 | jq -r '.object.sha'
gh api repos/actions/checkout/git/refs/tags/v6.0.2 | jq -r '.object.sha'
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
`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 スキルの領分。
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション(論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ)が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施(素材収集・メッセージ確定・git commit 実行)は commit-flow スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。