build2-review: 公開前パッケージレビュー

build2-review

ROOTの解決

HERE を、この SKILL.md を含むディレクトリの絶対パス（システムコンテキストからのもの）とします。

ROOT は build2 スキルツリーです。guides/packaging-guide-review.md が存在する最初の候補を使用します：

1. HERE/../build2（兄弟レイアウト：このディレクトリが build2 スキルの隣にある場合。ユーザーレベルのスキルディレクトリへのコピーを含む）
2. HERE/../..（ネストレイアウト：このディレクトリが build2 スキルの skills/ サブディレクトリ下にある場合）

どちらも存在しない場合は、停止します。

以降のすべての read_file パスは ${ROOT}/... です。

これは読み取り専用のローカル健全性チェックです。公開前にパッケージングの問題を発見するために存在し、cppget.org のレビュアーがリポジトリに対して使用するのと同じチェックリストを実行します。GitHub Issue やプルリクエストを作成、コメント、マージすること、ブランチをプッシュすること、メールを送信すること、レビュー中のリポジトリを変更すること（コミット、タグ、ファイル編集、bdep release、bdep publish、git push）は絶対に行ってはなりません。以下のステップでそのような変更を行う場合は、スキップして報告される所見に変換します。レビュー中のリポジトリは、このチェックの前後でまったく同じ状態でなければなりません。報告された所見に対する計画の草案を作成することは、それを実行しない限り変更にはカウントされません。「プランモード」の項を参照してください。

${ROOT}/guides/packaging-guide-review.md のチェックリストと基準が信頼できる情報源です。チェックリストの項目をコピーしてください。必要な基準を言い換えてはいけません。レビュー基準を考案してはいけません。

レビューはビルドとパッケージングのサポートのみを対象とします。上流のソース品質、上流のドキュメント、上流のC/C++のスタイルは無視します。

ハードルール

1. 外部から見える変更を一切行わない：GitHub Issue やプルリクエストを作成、コメント、マージすること、ブランチをプッシュすること、メールを送信することは絶対に行いません。これは無条件です。ユーザーが実行中に明示的にこれらのいずれかを要求した場合でも適用されます。その場合は拒否し、別の手動レビューワークフロー（下記「停止して確認」を参照）を案内し、ここでは実行しません。
2. レビュー中のリポジトリを変更しない：コミット、タグ、ファイル編集、git push、bdep release、bdep publish は行いません。検査のみ（git log、git show、git diff、ファイルの読み取り）です。項目を検証するために何かをビルドまたはテストする場合は、スクラッチディレクトリでアウトオブツリーで実行し、レビュー中のリポジトリのワーキングツリー内では決して実行しないでください。
3. ローカルパスが指定された場合は、その場で読み取り専用で使用します。別の ref をチェックアウトしたり、スタッシュしたり、リセットしたりしないでください。
4. リモートリポジトリまたは URL が指定された場合は、/tmp/claude/ 下のスクラッチディレクトリに読み取り専用でクローンします。プッシュ可能なリモートや git push は決して使用しないでください。クローンは使い捨てとして扱います。
5. チェックリストの項目は、この実行で自分で検証するまでチェックしません。
6. ブロッキングか非ブロッキングかは、ガイドの基準に従います。疑わしい場合は、概念的な buildfile のエラーを黙ってダウングレードするのではなく、そのように明言します。
7. 出力は会話内のレポートです（オプションで /tmp/claude/ 下のスクラッチファイルにも書き込まれます）。外部に投稿してはいけません。

必須読み物（所見を報告する前に）

所見を報告する前に、read_file で以下のファイルを完全に読んでください。斜め読みはしないでください。

1. ${ROOT}/guides/packaging-guide-review.md
2. ${ROOT}/guides/packaging-guide-antipatterns.md
3. ${ROOT}/HOWTO/package-naming.md
4. ${ROOT}/guides/packaging-guide-testing.md、ステップ9（「パッケージをテストする」）のみ。ステップ10（「公開する」）は review を main にマージするもので、ここでは対象外なので無視します。

末尾のマップから必要に応じてロードします。packaging-guide-review.md 内の初回レビューチェックリストが、あなたが取り組むチェックリストです。そのファイルが唯一のコピーです。

引数

$ARGUMENTS は /build2-review（または /build2 review）の後のテキストです。順番に解析します。最初に一致したルールが優先されます。

最初のトークン	種類
空 / 省略	ターゲット解決後に自動検出
initial	完全な初回提出チェックリスト
version	新しい上流バージョン、差分ベース
revision	新しいパッケージングリビジョン、差分ベース＋追加チェック
その他	<repo-or-local-path> として扱い、種類を自動検出

残りのトークン：<repo-or-local-path>（GitHub URL、owner/repo、またはローカルクローンパス）とオプションの <version>。ターゲットがない場合は確認します。

開始する前に、選択した種類とバージョンをユーザーに報告します。

リポジトリを取得する

ユーザーがローカルパスを指定した場合は、そのまま読み取り専用で使用します。

それ以外の場合は、スクラッチディレクトリに読み取り専用でクローンします（このクローンにプッシュしたり、他の何かのプッシュターゲットとして追加したりしないでください）：

git clone --recurse-submodules --shallow-submodules <url> /tmp/claude/<name>

分類

manifest の version: フィールドから <VERSION> を決定します（複数のパッケージがある場合は最新のリリースタグ）。種類を決定します：

証拠	種類
リリースタグがまだない、またはレビュー対象の ref が最初の bdep new コミットのまま	initial
vX.Y.Z タグがすでに存在し、このバージョンが X.Y.Z+R	revision
以前のバージョンがタグ付けされており、これが新しい X.Y.Z	version

リポジトリの最初のコミットを検証します（読み取り専用）：

git log -p "$(git rev-list --all | tail -1)"

そのコミットには bdep new によって生成されたファイルのみが含まれている必要があり、そのメッセージは正確なコマンドラインでなければなりません。逸脱があれば記録します。無視しないでください。

種類: initial

packaging-guide-review.md の初回レビューチェックリストセクションのすべての項目をリポジトリに対して実行します。自分で検証した後（ツリー、manifest、buildfiles、インストールレイアウト、テスト、タグ）にのみ項目をチェックします。記憶ではなく、各項目にリンクされた HOWTO/ガイドを使用します。

各所見をガイドが行うとおりに正確に分類します：

クラス	条件
ブロッキング	重大度または影響が高い、多くのユーザー、概念的なエラー（buildfiles の誤ったコンパイルオプション）、または後で互換性を壊さずに修正できないもの
非ブロッキング	リビジョンまたは次のバージョンで修正されるべきもの、チェックに失敗しないもの
注意	観察のみ

チェック中に必要に応じてロードします：

• 名前：${ROOT}/HOWTO/package-naming.md
• ライセンス：${ROOT}/guides/packaging-license.md
• 付属の -tests サマリー/README：${ROOT}/HOWTO/tests-extra-dependencies.md
• プライベートヘッダー：${ROOT}/HOWTO/third-party-private-headers.md
• コンパイルオプション：${ROOT}/HOWTO/buildfile-compile-options.md
• やってはいけないこと：${ROOT}/guides/packaging-guide-antipatterns.md
• buildfiles、manifest、README 内の日記形式のコメントやメモ（プロセスナレーション、うまくいかなかった以前のアプローチ、途中の事故）：${ROOT}/guides/packaging-guide-antipatterns.md「日記形式のコメントやメモを残さない」

「上流に git サブモジュールとシンボリックリンクを使用する」を検証するとき：各パッケージディレクトリで find . -type l -exec test -d {} \; -print も実行し、すべての結果がそのパッケージ自身の <pkg>/.gitattributes に対応する symlink=dir エントリを持つことを確認します（${ROOT}/guides/packaging-guide-summary.md ステップ5を参照）。git はシンボリックリンクのタイプを記録しないため、このエントリがないディレクトリシンボリックリンクは Windows チェックアウトを静かに壊します。エントリの欠落はブロッキングとして扱います。

インストールと配布をテストする

チェックリストの静的検査だけでは不十分です。ビルド時にのみ現れる問題（インストールツリーに到達する不足ヘッダーやプライベートヘッダー、buildfile グラフから欠落しているファイル、壊れた clean ルール）を捕捉するために、パッケージをアウトオブツリーでビルドも行います。これは /tmp/claude/ 下のスクラッチディレクトリで行い、レビュー中のリポジトリ内では決して行いません。${ROOT}/guides/packaging-guide-testing.md の「ステップ9：パッケージをテストする」に従います：

1. インストールケース： b install config.install.root=/tmp/claude/<name>-install を実行し、次に、そのインストールコピーに対して tests/ をアウトオブソースでビルドして実行します。予期しないものがインストールされていないことを確認します（不足ヘッダーなし、プライベートヘッダーが誤ってインストールされていないこと）。
2. ソース配布： b dist config.dist.root=/tmp/claude/<name>-dist config.dist.uncommitted=true を実行し、次に、抽出されたアーカイブ内で configure、update、test、clean を実行します。bdep test が成功しただけでは不十分です。これが cppget.org が実際にパッケージをビルドする方法です。

両方のスクラッチディレクトリを後で削除します。失敗は所見として記録します（正しくインストールまたは配布できないパッケージは通常ブロッキングです）。

報告

結果をユーザーに提示します。ガイドの結果コメントと同じセクションレイアウトを使用しますが、どこにも投稿しません：

ブロッキング問題：

...

非ブロッキング問題：

...

注意：

...

空のセクションは省略します。スクラッチコピーを作成した場合は、そのパスに言及します。

種類: version

ベース（以前にレビューされた）バージョンとターゲットバージョンを差分します。両方のタグがクローンで利用可能な場合はローカルの git diff <old-tag>..<new-tag> を優先し、そうでない場合は GitHub 比較ビューを使用します：

https://github.com/<owner>/<project>/compare/vOLD...vNEW

ビルドレベルの互換性を監視します。エクスポートされたターゲットや設定変数の名前変更は、上流の API が安定していても破壊的変更です。

以下のいずれかを報告します：

1. 実質的なパッケージング変更なし、問題なし： その旨を明確に述べ、チェックリストは不要。
2. 実質的なパッケージング変更なし、問題あり： 直接リストアップ（チェックリストは不要）。
3. 実質的なパッケージング変更あり： 上記の完全な初回手順を実行し、チェックリストとインストール・配布テストを含む。

種類: revision

version と同じですが、以下のいずれかが成立しない場合は所見としてフラグを立てます：

• 変更は buildfiles、manifest、および同様のパッケージングファイルのバグ修正に限定されている。
• 上流ソースの修正は、上流からバックポートされた重要なバグに限定されている。
• 置き換えるバージョンと厳密に下位互換性がある。
• 大規模な構造変更（ソースレイアウト、エクスポートされたターゲット名、設定変数名）がない。

プランモード

このスキルはどちらにせよ読み取り専用のままであり、修正を自分で実行することは決してありません。変更されるのは、レポートとともに必要な変更と改善の計画が草案されるかどうかだけです。

• 現在のセッションがプランモードの場合（アシスタントは変更を行う前に承認のための実装計画を提案することが期待され、すぐに行動するわけではない）：報告後、ブロッキングおよび非ブロッキングの所見に対処する計画も草案し、環境が提供する計画承認メカニズムを通じて提示します。計画の範囲をブロッキングおよび非ブロッキングの所見に限定し、ユーザーが要求しない限り注意事項はスキップします。関連する修正をグループ化し、生成された bdep new レイアウト、manifest、または buildfile ファイルに触れ、特に注意や順序付けが必要なものがある場合はそれを明記します。
• それ以外の場合は、上記の確立された報告フローに従い、そこで停止します。実装計画を草案、提案、またはほのめかしてはいけません。修正はユーザーまたは別のワークフローが実行するためのものです。

停止して確認

以下のいずれかに該当する場合は、推測せずに停止して確認します：

• バージョンまたは種類を決定できない。
• リポジトリにアクセスできない（クローン失敗、ローカルパスが無効）。
• 最初のコミットが bdep new コミットではなく、ユーザーがそれをレポートにどのように記録するかを決定していない。
• 互換性を壊す所見について、ブロッキングか非ブロッキングかが不明確。
• ユーザーが実際に GitHub レビュー Issue/PR を開く、何かをマージする、または [email protected] にメールを送信するように要求した。これはこのスキルが実行しない別の対象外ワークフローです。
• ユーザーがチェックではなくパッケージを作成するように要求した（build2-package に切り替える）。

オンデマンドマップ

必要なもの	ファイル
チェックリストと基準	${ROOT}/guides/packaging-guide-review.md
やってはいけないこと	${ROOT}/guides/packaging-guide-antipatterns.md
名前	${ROOT}/HOWTO/package-naming.md
ライセンス	${ROOT}/guides/packaging-license.md
付属パッケージ	${ROOT}/HOWTO/tests-extra-dependencies.md
パッケージの作成	../build2-package/SKILL.md