mcpField
B
build-optimize

build-optimize

github.com/paulnsorensen開発093 回インストール3 週間前に更新
リポジトリ

build-optimize について

build-optimizeは、Cargo、pytest、npm、pnpm、Go、justのローカルビルドやテストコマンドを計測・最適化するスキルです。承認済みの計測計画と比較可能な変更前後の証拠を求め、チェックと失敗時の動作を維持します。

主な機能

  1. 01ローカルコマンドの実行時間計測
  2. 02Cargo、pytest、npm、pnpm、Go、justに対応
  3. 03計測前の計画承認
  4. 04正規化した変更前後の証拠を比較
  5. 05チェック、成果物、失敗時の動作を維持
  6. 06コールドとウォームのキャッシュ結果を分離

活用シーン

  1. 01ローカルビルド時間の基準計測
  2. 02承認済みビルド最適化の評価
  3. 03計測比較が阻まれた場合の報告

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/paulnsorensen/git-gouda --skill build-optimize

インストール後、Claude Code で/build-optimizeを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
references/
go.md
js-ts.md
methodology.md
python.md
rust.md

詳細

ローカルビルドの最適化

変更する前にローカルでの実時間を計測してください。チェック、成果物、失敗時の動作を維持してください。

このスキルでは、ローカルの cargo、pytest、npm、pnpm、go、just コマンドを扱います。 GitHub Actions ワークフローの所要時間や変更には、/ci-optimize を使用してください。

規律

鉄則： 具体的な編集を提案する前に、承認済みの実行計画を計測してください。

危険な兆候 — 次の点に気付いたら、作業を中止してください。

  1. 編集によってチェックや成果物が削除される、ワークロードが変更される、または失敗が隠される。
  2. キャッシュ操作、サンプル数、ウォームアップ、または分離が承認済みの計画と異なる。
  3. コールドとウォームのコホートが混在する、またはブロックされたヘルパーとの比較が速度の主張に使われる。
正当化の理由問題点必要な対応
「ウォーム実行のほうが速いので、すべてのビルドが速くなります。」ウォーム実行ではコールドキャッシュ時の処理が省略されます。各コホートを個別に報告してください。
「並列テストのほうが速いです。」並列ワーカーにはテストの分離が必要です。計画を立てる前に、分離されていることを証明してください。
「ヘルパーがないので、生の計測値だけで十分です。」生の計測値だけでは比較ゲートを通過できません。生のエビデンスを保持し、比較がブロックされていると報告してください。

参考資料

実行計画を定義する前に、計測方法を読んでください。 実行計画を定義する前に、該当するエコシステムの参考資料を読んでください。 ローカル計測値を取得する前に、同階層の local.md を読んでください。 正規化された入力を作成する前に、同階層の schemas.md を読んでください。

ワークフロー

  1. リポジトリの指示を読みます。正式なローカルコマンドを特定します。
  2. 正確なコマンド、ウォームアップ数とサンプル数、キャッシュ操作、分離、出力パス、コストを含む実行計画を定義します。
  3. 実行計画について明示的な承認を得ます。
  4. 承認済みのキャッシュコホートを使用してベースラインを計測します。
  5. ベースラインのエビデンスを報告します。
  6. 影響を受けるファイル、効果の仮説、リスク、検証方法、確立されているロールバック方法を提示します。
  7. 追跡対象のソースを変更する前に、編集計画への明示的な承認を待ちます。
  8. リポジトリ既存の編集手順に従って、承認済みの変更を適用します。
  9. 同じプロトコルで再計測します。すべてのチェック、成果物、失敗時の動作を検証します。
  10. 報告を終えるか、必要な入力が不足した時点で作業を終了します。

コマンド

実際に読み込まれた SKILL.md のディレクトリを基準に CI_OPTIMIZE_HELPER を解決してください。 ../ci-optimize/scripts/ci_optimize.py を追加する前に、シンボリックリンクを解決してください。 ヘルパーのパスを利用側リポジトリのカレントディレクトリから導き出さないでください。 ヘルパーはコマンドの実行、ソースの編集、依存関係のインストール、変更のコミットを行いません。

利用側リポジトリの作業ディレクトリからコマンドを実行してください。

python3 "$CI_OPTIMIZE_HELPER" from-hyperfine --input BEFORE-RAW.json --command 'COMMAND' --revision REVISION --environment ENV --cache-state STATE --workload-label LABEL --output BEFORE.json
python3 "$CI_OPTIMIZE_HELPER" from-hyperfine --input AFTER-RAW.json --command 'COMMAND' --revision REVISION --environment ENV --cache-state STATE --workload-label LABEL --output AFTER.json
python3 "$CI_OPTIMIZE_HELPER" compare --before BEFORE.json --after AFTER.json --minimum-samples N --output COMPARISON.json

承認済みのキャッシュコホートごとに、異なる出力パスを指定してこの一連の処理を実行してください。 --force は、既存の明示的な出力ファイルを置き換える場合にのみ使用してください。 同階層のヘルパーがない場合も、生のエビデンスを保持してください。 ヘルパーがない場合は、比較がブロックされていると報告してください。 ヘルパーをインストールしたり、比較ゲートを免除したりしないでください。

エビデンスと報告

COMPARISON.json を読みます。comparability: true を必須とします。 ステータス、コマンドの境界、比較対象に含まれる数と除外された数、中央値と範囲、差分、チェック、成果物、制約事項、次の承認、エビデンスのパスを報告してください。 除外されたすべてのサンプルとその理由を保持してください。 承認済みのコンテキストの違いを確認事項に記録してください。 確認事項によって、ワークロードや検証の不一致を免除したり、カバレッジが同等であることを証明したりすることはできません。 数値上の改善を約束せず、観測内容を説明してください。報告は200語以内にしてください。 無関係なゲートの名前を変更したり、自動修正チェックを追加したり、CI ワークフローを変更したりしないでください。

コメント

Markdown 対応