Skill.md検索

ラベルルールを自動設定: .github/labeler.ymlを管理して、PR作成時に GitHub Actionsで自動的に適切なラベルが付与される仕組みを構築します。 手動ラベル付与の手間を削減: ファイル変更パターンに基づいて自動ラベル化されるため、毎回手動でラベルを選ぶ必要がなくなります。 カスタムラベルを柔軟に追加: アプリケーション別（backend/frontend）、カテゴリ別（docs/tests/infra）、技術スタック別（typescript/python）など、プロジェクト固有のラベルルールを追加・更新できます。 新規ラベルの作成と設定を一括管理: gh label createコマンドでラベルを作成し、labeler.yml に対応ルールを追加する手順を自動化できます。 GitHub PRの整理と管理を効率化したい開発チーム: 自動ラベリングにより、PRをカテゴリ別・優先度別に素早く分類・検索できます。 複数リポジトリ・複数プロジェクトを運用している人: ラベリングルールの標準化と一元管理で、PR対応の効率が上がります。 新しいラベルルールを追加・更新したい人: ユーザーのヒアリング→ファイル確認→設定更新→コミット・プッシュの流れを効率的に実行できます。 Pull Requestに変更内容に応じて自動ラベルを付与する設定を管理します。実行手順は①ユーザーから追加したいラベルルールをヒアリング②.github/labeler.ymlを確認・更新③変更をコミット・プッシュの3ステップ。ラベリングルールは【アプリケーション】backend（apps/backend/）・frontend（apps/frontend/）【カテゴリ】infra（.github/、docker-compose.yml）・docs（/*.md、docs/）・tests（/tests/、/*.test.{ts,tsx,py}）・dependencies（package.json、pyproject.toml）【技術スタック】typescript（/*.{ts,tsx}）・python（/*.py）を標準提供。設定ファイルは.github/labeler.ymlで、changed-filesとany-glob-to-any-fileを組み合わせてパターンマッチング。カスタマイズはgh label createでラベル作成後、labeler.ymlにルール追加。参考は[actions/labeler](https://github.com/actions/labeler)。

VitestとReact Testing Libraryを使い、コンポーネント・関数の単体テストを素早く作成・実行できます。 getByRole「アクセシビリティ」getByLabelText「フォーム要素」など、ユーザーの視点に基づくテスト方法でブラウザ実装の信頼性を高めます。 describeでテストケースをグループ化し、it/testで個別の動作を記述し、可読性の高いテストスイートを組織できます。 userEvent.setup()でマウス・キーボード操作をシミュレートし、実ユーザーに近い動作検証ができます。 テストファイル配置、セットアップ、テストテンプレート（コンポーネント・関数別）を即座に実装できます。 フロントエンド開発者で、コンポーネントの動作を自動テストで保証したい人。 TypeScript/React環境で、変更時の既存テスト破損を防ぎたい開発者。 ボタンクリック、フォーム入力、不正値検証など、ユーザー操作を含むテストを書きたい人。 初めてVitest/React Testing Libraryを導入する際にセットアップから実装まで一気に進めたい人。 推奨：Vitest（高速テストランナー、Viteベース）、React Testing Library（コンポーネントテスト）、@testing-library/user-event（ユーザー操作シミュレーション）。セットアップ：pnpm add -D vitest @vitejs/plugin-react jsdom、pnpm add -D @testing-library/react @testing-library/jest-dom @testing-library/user-event。vitest.config.ts設定例：environment:jsdom、globals:true、setupFiles:vitest.setup.ts指定、include:src/**/*.{test,spec}.{ts,tsx}。vitest.setup.ts：import @testing-library/jest-dom/vitest。テストファイル配置：コンポーネントと同階層に*.test.tsx、ユーティリティと同階層に*.test.ts。コンポーネントテストテンプレート：render+screen.getByRole+expect、userEventでクリック・入力、vi.fnでmock関数作成、disabled状態確認。関数テストテンプレート：describe/it構造、複数の入力値・戻り値検証、エッジケース（無効データ等）確認。

GitHub アカウント（tqer39）の全リポジトリを自動検出し、git submodule として追加・更新できます。新しいリポジトリを作成した際も自動で反映されます。 アーカイブ済みリポジトリや不要なサブモジュールを自動削除し、常に最新の状態を保ちます。 各リポジトリのデフォルトブランチ（main / master / trial など、リポジトリごとに異なる）を自動検出し、確実に最新コミットに更新できます。 複数のサブモジュール更新を並列処理で高速化し、効率的に一元管理できます。 複数のリポジトリを管理しており、統一的なコンテキストで全体を参照したい開発者 CI/CD パイプラインで複数リポジトリを同期し、最新状態を保ちたいエンジニア 新規リポジトリ追加時に手動設定の手間を減らしたい組織 repos-context を常に最新に保ち、AI エージェントに正確な情報を提供したい人 gh repo list tqer39 --limit 1000 --no-archived --json name,isFork,defaultBranchRef で全リポジトリ取得（40件以上が期待値）。除外条件：repos-context 自己参照防止、.github 衝突回避、isFork=true の実験リポ、defaultBranchRef=null の空リポ。.gitmodules から既存サブモジュール確認、不足分を git submodule add で追加（失敗時スキップ）。全サブモジュール最新化は git submodule update --remote 非推奨、代わり各リポジトリで fetch → checkout {default_branch} → pull を実行（決め打ちなしで step1 で取得した defaultBranchRef.name 使用）。10個以上時は並列処理（5個ずつ）。.gitmodules に存在するが検出結果に無いサブモジュール検出、gh repo view で状態確認。アーカイブ済みは自動削除、削除済みはユーザー報告待ち。git status と git diff --stat で追加・更新・削除済み一覧を報告。

install.sh または install.ps1 を編集した際に、関連ドキュメント（README.md、日本語版）との整合性を自動チェックできます。 コマンドラインオプションの追加・削除・変更が README のオプションテーブルに正しく反映されているか確認できます。 ヘルプテキスト（show_help() / Show-Help）と README の説明が一致しているか検証できます。 英語版 README と日本語版 README.ja が両方とも更新されているか整合性をチェックできます。 just lint で自動的にリント検証を実行し、エラーを検出・修正できます。 インストールスクリプトを頻繁に更新・改善している開発プロジェクトのメンテナー 英語版・日本語版の両方のドキュメントを維持管理している多言語対応プロジェクト スクリプトの変更がドキュメント未更新のまま放置されているプロジェクト CI/CDでドキュメント検証を組み込みたいチーム 対象トリガーファイル：install.sh、install.ps1。チェック対象ドキュメント：README.md（Quick Start、Command Line Options）、docs/README.ja.md（対応セクション）、install.sh内 show_help() 関数、install.ps1内 Show-Help 関数。チェック項目：(1)オプションの追加・削除・変更がREADMEのオプションテーブルに反映、(2)show_help()/Show-Help内のヘルプテキストとREADMEが一致、(3)install.sh と install.ps1 で同名オプション説明が一致、(4)Quick Start使用例が現在のスクリプト動作と一致、(5)前提条件に変更なし、(6)README.md（英語）と docs/README.ja.md（日本語）が両方更新済み、(7)両言語のオプションテーブル構造・内容が一致。手順：git diff で差分確認→ヘルプテキスト読み込み→READMEと比較→日本語版も確認→ドキュメント更新→just lint 実行→エラー修正。

Gitの変更内容を自動解析し、絵文字付きの分かりやすいコミットメッセージを生成できます。 「新機能」「バグ修正」「ドキュメント更新」など、変更の種類に応じた適切なラベルと絵文字を自動選択します。 コミットメッセージのフォーマットが統一され、チーム全体で見やすく・管理しやすいコードの歴史が作れます。 1つのコミットに複数の変更を混ぜないよう、コミット設計をサポートします。 Gitの使用は分かるが、毎回メッセージを工夫するのが面倒な開発者 チーム内でコミットメッセージの書き方がバラバラで、統一したい開発リーダー コード変更の履歴を後から確認しやすくしたいプロジェクトマネージャー

タイトル、説明、タスク、実行コマンドなど、GitHub Issueに必要な情報を構造化して自動作成できます。 「機能追加」「バグ報告」「ドキュメント整備」など、Issue の種類に応じた絵文字とラベルを自動で付与します。 ラベル（backend/frontend など）とマイルストーン（MVP/v1.0 など）を必ず設定し、プロジェクト全体の進捗管理が容易になります。 実行手順や検証方法まで含めて記録するため、チームメンバーが確認しやすく、対応漏れが減ります。 バグ報告や機能要望を受けたものの、どう整理して記録すればいいか分からない非エンジニア プロジェクト全体のタスク管理を一元化したいプロジェクトマネージャー チーム内での Issue 作成方法を統一・自動化したい開発リーダー