Skill.md検索

通常clone・bare repo・worktreeの3つの環境で並行テストし、git alias やシェルスクリプトが異なるリポジトリコンテキストで正しく動作するか確認できます。 GIT_DIR環境変数のリークを検出し、別リポジトリの操作に意図せず干渉していないかを自動的にチェックできます。 bats ヘルパー関数を再利用して、複数コンテキストのテストケースを効率的に追加・保守できます。 他リポジトリからの呼び出し時の動作を検証し、本番環境での予期しない挙動を事前に防げます。 git alias やシェルスクリプトを開発・保守するエンジニア worktree や bare repo を扱うスクリプトの品質を高めたい人 マルチコンテキスト対応の git 関連ツールを安心してリリースしたい人 Git の ! エイリアスは実行時に GIT_DIR 環境変数をセットします。worktree内では絶対パス（.../. git/worktrees/）になるため、git -C では上書きされず別リポジトリの操作に干渉するリスクがあります。回避策として、3つの必須テストコンテキスト（通常clone・bare repo・worktree）からのテストを含めます。bats ヘルパーパターンとして、setup_caller_remote()、enter_other_regular_repo()、enter_other_bare_repo()、enter_other_worktree_repo() の実装例を提供します。テストケース命名は「他リポジトリの[コンテキスト名]内から実行して[期待動作]」とします。Git alias では関数冒頭で環境変数をクリアする（unset GIT_DIR GIT_WORK_TREE）ことでリーク対策を講じます。

スナップショットテストの実行タイミングを自動判定 – Envoy設定やport-forward生成ロジックを変更した時、CIで実行すべきか自動で判定します。 テスト失敗時の原因を素早く特定 – Envoy設定ファイルやマッピングの差分を表示し、何が変わったかを一目で確認できます。 スナップショット更新を安全に実行 – 意図した変更なのか意図しない変更なのかを確認した上で、スナップショットを更新できます。 新機能追加時のテスト追加を効率化 – TCP proxy対応やプロトコル追加時、新しいスナップショットを生成・管理する手順を自動化。 リスク のある更新を未然に防止 – 「原因を理解せずに更新してはいけない」「差分レビュー必須」といった運用ルール を自動でサポート。 kubectl-localmeshの開発者 – Envoy設定やport-forward生成ロジックを開発・保守している方 プルリクエストレビュアー – テスト変更が適切なタイミングで実行されているかを確認したい方 CI/CD管理者 – テスト自動化の運用ガイドラインを整えたい方 QA・テスト担当者 – スナップショットテストの品質管理ルールを理解・維持したい方 kubectl-localmeshは Envoy 設定とport-forwardマッピングを動的に生成し、スナップショットテストで生成結果が期待通りであることを検証します。検証対象は HTTP/gRPC/TCPリスナー設定、Upstreamクラスタ設定、ルーティング設定（test/snapshot/testdata/snapshots/*.yaml）と、サービス名・ローカルポート・接続先マッピング（test/snapshot/testdata/portforward-mappings/*.txt）です。必須実行タイミングは：（1）internal/envoy/ 配下のコード変更、（2）internal/snapshot/ 配下のマッピング生成ロジック変更、（3）internal/dump/やcmd/dump_envoy_config.goの変更、（4）プルリクエスト前、（5）コミット前確認。更新が適切なケースは意図的な設定変更・新機能追加・テストケース追加時です。ただし「テスト失敗時、原因を理解せずに更新」「『とりあえず』テストを通すための更新」「git diff確認なしの更新」は禁止です。基本コマンドは test/snapshot/scripts/run-snapshots.sh（実行）、test/snapshot/scripts/update-snapshots.sh（更新）、test/snapshot/scripts/diff-snapshot.sh {名} （個別確認）。

開発したMCPツール（orm-discovery-mcp-go）を自分自身でビルド・インストール・実行し、実際に動作するか確認できます。 CI（継続的インテグレーション）→ インストール → MCP反映確認 → 全ツールのスモークテスト → PR自動レビューを一連で実行し、品質ゲートを自動化できます。 oreilly_search_content・oreilly_ask_question・Resources・Prompts・review_prなど、複数のMCPツールを順序立てて検証できます。 認証エラー・404・タイムアウトなど、各種エラーパターンを検出し、具体的な修正案内ができます。 draft-pr完了後に自動的にドッグフーディング検証を実行し、人手なしでフィードバックループを回せます。 MCPツール・CLIツール・APIサーバーなど、自分たちが開発したツール自体の品質を検証したい開発チーム ビルド・インストール・テスト・デプロイまでの全フロー自動化を目指すDevOpsエンジニア PR作成後、マージ前に自動で総合品質評価を行いたい組織 エラーハンドリング・認証・キャッシュなど、実運用レベルの細かい検証を自動化したい開発者 本スキルは5フェーズで構成されます。トリガー条件 は「ドッグフーディング」「dogfood」「verify」「検証」のキーワード、またはdraft-pr完了後の自動呼び出し。Contextで現在のブランチ・git status・PR status・インストール状態を把握。Phase 1（CI実行） でtask ciを実行し、失敗時は即停止、成功時はPhase 2へ。Phase 2（インストール） でtask install実行後、which orm-discovery-mcp-goで存在確認、未発見時は$GOPATH/binをPATH確認案内。Phase 3（MCP反映確認） でoreilly-researcher subagentで「Go」1件検索実行、失敗時はMCPサーバー再起動案内で停止。Phase 4（全ツールスモークテスト） で4-1～4-5を順序実行：(1)oreilly_search_content「Docker」5件 (2)oreilly_ask_question「What is Docker?」(3)Resources検証（product_id取得→book-details） (4)Prompts動作確認（learn-technology）(5)review_pr実行（存在時のみ）。各フェーズで成功条件・失敗時対応を定義、エラー検出時は具体的な修正案内を提示します。

macOSが.localhostドメインを特殊に扱う（RFC 6761）ために発生する接続問題を診断・解説します。/etc/hostsの設定が無視されて常に127.0.0.1に解決される仕組みを理解できます。 TCPサービス（DB接続など）で.localhostを使うと接続失敗する理由を明確に説明し、.localdomainなどの代替TLDへの変更を提案します。 HTTP/gRPCサービスが.localhostでも動く理由（ホストヘッダーベースのルーティング）との違いを理解し、適切なドメイン設定を判定できます。 kubectl-localmeshやローカル開発環境で原因不明のドメイン解決エラーに悩んでいるエンジニア macOSのDNS挙動と/etc/hostsの関係を深く理解したい方 TCP・HTTP・gRPCサービスの接続設定を正確に構築したい方 macOSはRFC 6761に基づき.localhost TLDを予約済みドメインとして特別扱いし、/etc/hosts設定を無視して常に127.0.0.1またはIPv6の::1に解決します。TCPサービスで.localhostを使用する場合、/etc/hostsに127.0.0.2 db.localhostと記述しても、macOSが127.0.0.1に解決してしまい、Envoyが127.0.0.2で待機していれば接続失敗します。確認方法はcat /etc/hostsとpython3 -c "import socket; print(socket.gethostbyname(...))" のコマンド実行で検証可能。解決方法は.localdomain「.local「.dev「.testなど代替TLDを使用することです。HTTP/gRPCは0.0.0.0:80全インターフェースでリッスンするため、Hostヘッダーベースのルーティングで正しいバックエンドに到達し、.localhostでも動きます。

プロジェクトのタスク・アイデア・イシューを .backlog/ ディレクトリのJSONLファイルで一元管理でき、Excelや外部ツールに頼らず管理できます。 タスク（優先度付き）・アイデア（ブレストストレージ）・イシュー（問題報告）の3種類を区別して追加・完了処理し、プロジェクト段階に応じた柔軟な管理ができます。 全アクティブアイテムの一覧表示や完了アイテムへの移動を自動化し、バックログの鮮度を保つことができます。 バックログの履歴（監査ログ）を自動記録し、意思決定プロセスを追跡可能にできます。 Markdownサマリを自動再生成し、ドキュメント・チーム共有資料を最新に保つことができます。 スクラム・カンバン開発を実践するプロダクトマネージャーやスクラムマスター GitHub Issuesではなくローカルベースでバックログを管理したい開発チーム 振り返り（レトロスペクティブ）や監査ログを重視するプロジェクトマネージャー タスク・アイデア・イシューを柔軟に分類・管理したい研究開発チーム バックログ管理は .backlog/ ディレクトリのJSONLファイル（tasks.jsonl・ideas.jsonl・issues.jsonl）を backlog-cli (Go CLI) で操作。バイナリは .claude/skills/backlog-manage/cli/bin/backlog-cli に配置。未ビルド時は自動ビルド（task backlog:build）。コマンド仕様：add task（title・description・priority・tags）、add idea（title・description・tags）、add issue（title・description・severity・tags）、complete（IDで指定アイテムをdoneファイル移動）、list（全アクティブアイテム表示）。IDプレフィックス（task/idea/issue）から自動ファイル判定し status・done_at・resolved_at を設定。プロジェクトルートから実行、デフォルト--dir .backlog 使用。