yasunori0418

テスト実行時の絞り込み運用ルール。プロジェクト全体テストではなく修正範囲に絞ったテスト実行を行う。`gradlew test`/`pytest`/`jest`/`go test`等のテストランナーを実行するとき、テスト実行コマンドを組み立てるときに必ず参照する。コミット差分や修正ファイルから対象テストを特定する手順を含む。

ユーザーからのファイル出力依頼（分析結果・調査レポート・ログ抜粋・要約・ドラフト・一時的なメモなど）に応えて新規ファイルを作成するときの出力先ルール。プロジェクト直下の`tmp-agents/`への出力命名規則を含む。調査結果やレポートを保存するとき、ドラフトを作るとき、ユーザー向けの一時成果物を書き出すときに必ず参照する。ただし、プロジェクト本体のソースコード作成、既存ファイルの編集、プロジェクト規定のドキュメント（docs/配下等）出力は対象外。

git rebase / git pull --rebase を伴う操作の安全運用ルール。履歴書き換えは復旧不能な事故になり得るため、rebase 系コマンドを 1 つでも実行する前に必ず本スキルを参照する。「rebase して」「main に追従して」「ブランチを最新化して」「コミットをまとめて / 整理して」「squash して」「fixup を畳んで」「履歴をきれいにして」「force-push して」と依頼される、PR 前に履歴を整える、コンフリクト解消のために rebase する、といった場面すべてが対象。決定論スクリプトによるガードレール判定（保護ブランチ・push 済み範囲・子ブランチ・進行中操作・コンフリクト予測）→ 計画提示 → ユーザー承認 → backup ブランチ作成 → 非対話実行 → range-diff / tree 同一性による機械検証、のゲートを固定化する。plugin hooks の git-guard により backup 作成（解錠）なしの git rebase は機械的にブロックされる。

Quiz the user on a plan, implementation, or codebase to pay down understanding debt left by AI tooling. Explicit invocation only.

日本語の概要は準備中です。原文の説明を表示しています。

Nix + flake-parts 開発環境の構築パターン: root flake.nix（成果物）+ dev/flake.nix（devShell + CI シェル）を direnv で読み込む構成、および GitHub Actions CI テンプレートを提供する。このスキルは /nix-devenv と明示的に呼び出されたときのみ使用する。キーワードマッチによる自動起動はしない。

/nix/store 配下の store path・ファイルを特定するときに必ず参照する。`find /nix/store` で名前を総当たりする前に読む。「あのパッケージの store path が知りたい」「nix-unit のバイナリはどこ」「flake input の実体パスを知りたい」「derivation の出力パスを取りたい」「store の中のこのファイルを探したい」「store path が実在するか確かめたい」といった場面が対象。/nix/store は数万エントリあり深さ無制限の find は完了しない（実測: 20秒でも終わらず出力ゼロ）。同梱の collect_store_lookup.sh が入力の種別判定・一意な解決・候補収集・実在確認までを決定論的に行うので、まずそれを実行してから分析する。nix-locate が返す path はローカルに存在しないことがあるという反直感的な挙動も、データとして検出される。

新しいソフトウェア/デジタルプロダクトのコンセプトを対話で固め、競合・類似プロダクトを並列調査し、軽量な仕様ドラフトを作るオーケストレーションスキル。/product-spec <一言のプロダクトアイデア> で明示的に呼び出されたときのみ使用する。

ISTQB/JSTQB のテストモニタリング&コントロール（test monitoring and control）活動のうち、モニタリングの「基盤構築」を支援するスキル。進捗・カバレッジ・失敗率・flaky 率・成果物トレーサビリティ（リスク→条件カバー率・条件→ケース化率）などのメトリクスを test-plan の完了基準と紐づけて定義し、プロジェクトの CI/ツール構成を調査した上で計測基盤（CI 設定・集計スクリプト・バッジ等）の実装を支援して test-monitoring.md と実装物を作る。「テストのメトリクスを決めたい」「CI でテスト進捗を可視化したい」「カバレッジや失敗率を計測する仕組みを作りたい」「トレーサビリティを継続計測したい」と依頼されたときに使う。**AI が継続的なモニタリングを代行することはしない（計測は基盤が行う）。集まったデータの分析・傾向判断は対象外**。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-monitor <テスト対象名> で明示的に呼び出されたときのみ使用する。

ISTQB/JSTQB のテスト計画（test planning）活動を支援するスキル。テスト対象のプロダクトリスク（product risk）を発生可能性×影響度で識別・評価し、それを根拠にテストアプローチ（どこを厚くテストするか）・開始基準（entry criteria）・完了基準（exit criteria）を定めた test-plan.md を作る。「テスト計画を立てて」「テスト戦略を決めたい」「何をどこまでテストすべきか整理して」「リスクベースでテスト範囲を決めたい」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-plan <テスト対象名> で明示的に呼び出されたときのみ使用する。

Notion・Slack・GitHub Issue/PR・Linear等の外部システムへの書き込み・更新・コメント操作時の運用ルール。MCP書き込み系操作、Notion転記、Slack投稿、Issue/PRコメント、Linearチケット更新等を実行するときに必ず参照する。URLが会話に登場しても自動更新しないという原則を含む。

GitHub の PR を入力に、変更されたコードやドキュメントを mermaid の図（全体像・関数単位のシーケンス図・参照箇所起点のシーケンス図）で可視化し、短い解説を付けて Markdown ファイルに書き出す。stacked PR では、スタックの全体像と、現在の段を強調した変更の全体像を描く。`/pr-visualize` の明示起動のみ。`--comment` で PR コメントへ投稿（承認必須）。レビューの指摘は行わない。GitHub(gh) 前提。

Tutor the user step by step on a plan, implementation, codebase, or topic to pay down understanding debt left by AI tooling. Explicit invocation only.

日本語の概要は準備中です。原文の説明を表示しています。

「レビューして」「diff をレビュー」「〇〇観点で見て」「PR に出す前にセルフレビュー」などユーザーがコードレビューを依頼したら、観点・レンズ名を挙げていなくても必ず使用する。作業ブランチの diff を複数観点(design / test / yagni、条件付きで spec 等)で並列レビューし統合報告するオーケストレーションスキル。既定は diff 内で完結する fix 指摘のみで、既存コードへの改善提案(リファクタ候補の洗い出し)は起動引数 --improvement の明示時のみ報告する。コードの修正は行わない。

Navigate the user through reading code stop by stop to pay down understanding debt left by AI tooling. Explicit invocation only.

日本語の概要は準備中です。原文の説明を表示しています。

`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。

実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。

PR マージ後のローカル後片付け（worktree / ブランチ / tmux セッションの削除と main の最新化）を、収集 → 計画提示 → 承認 → 実行 → 検証のゲートで定型化する。`/post-merge-cleanup [PR番号|ブランチ名]...` の明示実行専用。