本文へ移動
cccskills
無料GitHub で公開

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 に ci devShell が必要か判断(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'

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

agent-teams

無料日本語概要

Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。

yasunori0418/skills82026年10月12日 更新

basic-design

無料日本語概要

spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。

yasunori0418/skills82026年10月12日 更新

biz-translate

無料日本語概要

技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。

yasunori0418/skills82026年10月12日 更新

commit-flow

無料日本語概要

`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 スキルの領分。

yasunori0418/skills82026年10月12日 更新

commit-plan

無料日本語概要

実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション(論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ)が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施(素材収集・メッセージ確定・git commit 実行)は commit-flow スキルが担う。

yasunori0418/skills82026年10月12日 更新

def-done

無料日本語概要

プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。

yasunori0418/skills82026年10月12日 更新

yasunori0418 のスキルをすべて見る

このスキルの問題を報告する