mason

Mason は、レビュー済みのエンジニアリング上の判断理由をリポジトリとともに保存し、将来の保守担当者やコーディングエージェントが、重要な決定の根拠を参照できるようにします。回避策、採用しなかったアプローチ、制約について、その理由が明らかなうちに記録し、根底にあるコードが変わったときに見直せます。

始め方

macOS または Linux にインストールします。

curl -fsSL https://github.com/adrianczuczka/mason/releases/latest/download/install.sh | sh

Windows PowerShell の場合：

irm https://github.com/adrianczuczka/mason/releases/latest/download/install.ps1 | iex

Node と npm は不要です。Git が必要です。インストーラーは Bash、Zsh、Windows 用に PATH を設定します。プラットフォームの詳細 · npm によるインストール

新しい標準的なスタンドアロンインストールでは、バックグラウンドで自動更新されます。更新は、既存の Mason MCP サーバーが終了した後、次回 MCP を起動したときに適用されます。mason updates を実行して、この設定を確認または変更してください。既存のインストールでは、手動でのアップグレードを一度行い、mason updates enable を実行する必要があります。更新の設定

Git リポジトリ内で次を実行します（インストーラーから求められた場合は、新しいターミナルを開いてください）。

mason init --host codex    # Maintainer: prepare shared configuration for review/commit
mason setup --host codex   # Each developer: activate locally
# For Claude Code, use --host claude.

リポジトリに互換性のある Mason 設定がすでにある場合は、mason setup だけを実行してください。初期化では MCP、フック、プロジェクト指示を準備します。セットアップでは共有ファイルに変更を加えません。ホストの信頼設定を確認し、新しいセッションを開始して、エージェントに通常のタスクを依頼してください。

Mason が使われていることを確認します。

mason status

セットアップでは、インストール済みの mason コマンドを使用します。プロジェクトの起動スクリプトやランタイムのコピーは使いません。ステータスでは、設定と実際に確認された使用状況が区別されます。セットアップとアップグレード · プロジェクトの接続を解除 · その他の MCP クライアント

セットアップせずにチェックを試す

mason audit --dir .
mason review --dir . --base origin/main

監査では、リポジトリ全体の README とエージェント指示ファイルに記載された主張をチェックします。レビューでは、選択したベースに対してコミット済みの変更をチェックします。どちらも読み取り専用で、モデルの呼び出しは不要です。

Mason が検出すること

プロジェクトが成長するにつれて…	Mason は次のように支援します…
コードにドキュメントが追いつかなくなります。	パスの記載漏れ、ワークスペース数の誤り、npm スクリプトの不足を指摘します。
パッチで関連する更新が漏れます。	参照箇所、関連するテスト、これまで同時に変更されることが多かったファイルを提示します。
過去の決定の背景が失われます。	記録された根拠とレビュー状況を取得し、それらが適用されるコードの変更を指摘します。
修正作業が中断されます。	元の検出結果を保持し、最後のドキュメントコミットを通じて修正内容を検証します。

インシデントを解決した後や制約を確定した後は、エージェントに Mason を使って出典付きの提案を記録するよう依頼してください。プロジェクトの指針として採用する前にレビューしてください。後続のタスクでは、適用中の承認済み改訂版を取得でき、置き換え案はそれとは別に保持されます。また、参照先のコードに変更があれば、調査、改訂、または廃止の検討を促します。

Mason はテスト、リンター、コードレビューを補完します。検出結果は調査対象となる根拠であり、利用できないチェックはその旨が明示されます。

これまでのエビデンス

以前に実施した読み取り専用の意思決定取得評価では、Mason ありの場合は 9.0/10、なしの場合は 7.0/10 でした。初回の 10 タスクによるパッチ比較では、両方とも 10/10 で同点でした。パッチの成果が向上するかどうかは、今後の実証が必要です。結果、方法、限界

メモを維持する方法は、再利用試験でも成果を上げました。最近のフック実験では、サポート対象のファイル配信が確認されましたが、追加のコンテキストコストが発生し、正確性の向上は実証されていません。通常の Bash ワークフローにおける直接配信は、引き続き未解決です。現在は、日常の作業中にエンジニアリング上の推論を有用な形で保存し、再利用することに注力しています。その際、記録と維持にかかる手間に見合う価値があることを目指しています。同じミスの再発防止は意図する効果の一つですが、比較上の優位性はまだ確立されていません。位置づけと検証計画 · 現在のエビデンス

ドキュメント

• セットアップ、フック、アップグレード
• データとネットワークの動作 · フックのパフォーマンス
• 監査、修正の検証、CI のエビデンス
• 意思決定、ツール、オプションのアーキテクチャマップ
• ロードマップ · 変更履歴 · MIT ライセンス

開発

開発には Node 20（20.19+）、Node 22（22.13+）、または Node 24+ を使用してください。 npm ci の実行後、npm run format を実行して TypeScript のソース、テスト、ツール設定をフォーマットしてください。 CI では npm run format:check でフォーマットをチェックし、npm run lint、 npm run typecheck、テストスイートを実行します。動作を確認するには、ローカルで npm test を実行してください。

ESLint は、推奨される TypeScript ルールに加えて、未処理のプロミス、誤用された非同期コールバック、無効な await を検出する型情報ベースのチェックを使用します。フォーマットは Prettier が処理します。 テスト用フィクスチャと生成された出力は、フォーマットとリントの対象外です。 本番用ソースでは、明示的な any に加えて、安全でない代入、プロパティアクセス、呼び出し、引数、戻り値も禁止されています。外部データは使用前に検証されます。 テストダブルには、より寛容なルールが適用されます。