テーマ： tooling

• 判断モデルでツールやスキルを選ぶ：Choiceで順位付けし、Noulで選択を見送る

  候補ツールに対するChoiceは「どの候補が最も合うか」という相対的な問いに答え、候補ごとのNoulは「このターンにそもそもツールが必要か」という絶対的な問いに答えます。TypeSafeのスキル提案クックブックは182スキルのカタログで両方を使い、1回目で全件を順位付けし、2回目で上位3件を読み、すべてを却下することもできます。

  article · ja · reviewed · 知識の基準日 2026-09-21

• ローカルDBのシードとフィクスチャ：小さく、冪等に、スキーマとともに版管理する

  全環境に必要な参照データ、開発・デモ用のサンプル、テスト自身が作るデータを分けます。自然キーで upsert する冪等なシードを作り、サンプルを小さく名前付きに保ち、セットアップと CI の両方でマイグレーション後に実行します。未加工の本番データを開発機に投入してはいけません。

  methodology · ja · reviewed · 知識の基準日 2026-09-17

• 継続的インテグレーションのパイプラインを設計する

  CI パイプラインは速く、自己テストを行い、どの変更にも同じ処理を適用する必要がある。クリーンなチェックアウトからビルドし、リンターとテストを段階的に実行し、失敗を明確に知らせる。全体の時間は、人が結果を待てる長さに保つ。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Keeping CI and local checks identical: one entry point, pinned tools, same container

  A check that passes locally should pass in CI and vice versa: define every check once as a named task, pin the toolchain in a committed manifest that both the bootstrap and the pipeline install from, run CI in the same container image as the dev environment, fix locale and timezone, and treat any CI-only failure as a parity bug to eliminate before fixing the symptom.

  methodology · en · reviewed · 知識の基準日 2026-09-17

• 自動整形と lint をチームの約束にする

  レイアウトをフォーマッターに、機械的なチェックをリンターに任せると、レビューからスタイルの議論を取り除ける。EditorConfig、PEP 8、Ruff などのツールは、その約束をリポジトリに記述する方法を示している。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Konfigurationsformate wählen: JSON, YAML oder TOML

  JSON (RFC 8259) ist streng und überall lesbar, kennt aber keine Kommentare; YAML ist gut lesbar, doch unzitierte Werte werden nach Muster typisiert; TOML ist für Konfiguration entworfen, mit Kommentaren, expliziten Typen und Tabellen. Wer die Datei bearbeitet und was sie liest, entscheidet – und jedes Format braucht nach dem Parsen eine Prüfung gegen ein Schema.

  article · de · reviewed · 知識の基準日 2026-09-16

• Checking whether a task wrapper hid the failure of its inner command

  Determine whether a reported successful task actually propagated the outcome of the compiler, test runner, or migration command on which success depends.

  methodology · en · reviewed · 知識の基準日 2026-09-22

• 初日の環境構築を自己検証するスクリプト：bootstrap、doctor、スモークテスト

  クローン後の一つのコマンドで、動く環境か、不足しているものと修正方法の正確な一覧を得ます。読み取り専用の doctor が各要件を確認し、冪等な bootstrap が不足と判定されたものだけをインストールし、スモークテストが終了ステータスを決めます。CI でクリーンなマシンから実行し、新人が来るまでの間に使えなくなるのを防ぎます。

  methodology · ja · reviewed · 知識の基準日 2026-09-17

• 型ヒントで Python に段階的な型付けを導入する

  型ヒント（PEP 484）は任意の注釈で、mypy などの外部ツールが検査する。コードベースへ少しずつ追加すると、実行時の動作を変えずにインターフェースの利用ミスを見つけ、意図を文書化できる。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Choosing a configuration format: JSON, YAML or TOML

  JSON is strict and universal but has no comments; YAML is readable but has surprising implicit typing; TOML is explicit and comment-friendly for flat-to-moderate structures. Pick by who edits the file and what parses it.

  article · en · reviewed · 知識の基準日 2026-09-15

• EditorConfig and committed editor settings: the small conventions that stop whitespace diffs

  A .editorconfig file fixes indentation, line endings, charset and final newlines per file type across editors, before any formatter runs; editor workspace settings committed next to it should encode project decisions such as format-on-save, not personal preferences.

  article · en · reviewed · 知識の基準日 2026-09-17

• Virtual environments: one interpreter state per project

  A virtual environment is a private site-packages tied to an interpreter; creating one per project prevents version conflicts and makes the dependency set reproducible and disposable.

  methodology · en · reviewed · 知識の基準日 2026-09-15

• 開発コンテナ：devcontainer.json で再現可能な開発環境を定義する

  devcontainer.json は、エディター、クラウドワークスペース、CI ランナーがリポジトリ用に構築すべきコンテナを記述する。イメージまたは Dockerfile、features、転送ポート、ライフサイクルコマンド、エディター設定を含む。containers.dev の公開仕様により、同じファイルをローカル、ホスト型ワークスペース、パイプラインで使い、各ホストではなくコードとともにツールチェーンを固定できる。

  article · ja · reviewed · 知識の基準日 2026-09-17

• Which pre-commit hooks survive a year in a team repository, and which get removed or routinely bypassed?

  Open question: Git's pre-commit hook can be bypassed with --no-verify, so a local hook only helps while contributors keep it; which hook types (formatters, linters, secret scanners, test subsets) have stayed in use for a year or more in team repositories, which were removed or moved to CI, and how often were they bypassed?

  question · en · reviewed · 知識の基準日 2026-09-16

• Git hooks for fast local checks

  Client-side hooks such as pre-commit run formatters and quick linters before a commit exists; they save review time but must stay fast, must not be the only gate, and are not versioned by Git itself.

  article · en · reviewed · 知識の基準日 2026-09-15

• Task runners beyond make: just, npm scripts and Invoke for project commands

  A task runner gives a project one place for its commands so that people, agents and CI invoke the same names; just stores recipes in a justfile with make-like syntax and no timestamp logic, npm scripts live in package.json with pre and post hooks, and Invoke turns @task functions in a tasks.py into a command line. Pick the one that needs no extra toolchain, keep recipes short, and let CI call them.

  article · en · reviewed · 知識の基準日 2026-09-17

機械可読： JSON