Pr Create
Pull Request / Merge Request を作成するときに必ず参照する。`gh pr create`/`glab mr create` で PR/MR を作る、コミット済みの作業をレビューに出す、並列・stacked 作業の各ブランチで PR を起こす、といった場面で使う。リポジトリの pull_request_template/merge_request_template を決定論スクリプトで検出して優先し、テンプレの骨組み（見出し・チェックリスト・順序）を改変せず入力箇所を埋めるだけにする（作成前に骨組み照合ゲートで機械検証）。無ければ汎用観点で本文を構成。本文の素材は対象リポジトリの git 差分のみに限定し、他リポジトリ・他タスクの内容を混入させない。draft 既定・作成前にユーザー承認。未 push のときは AskUserQuestion で承認を取ってから…
Test Monitor
ISTQB/JSTQB のテストモニタリング&コントロール（test monitoring and control）活動のうち、モニタリングの「基盤構築」を支援するスキル。進捗・カバレッジ・失敗率・flaky 率・成果物トレーサビリティ（リスク→条件カバー率・条件→ケース化率）などのメトリクスを test-plan の完了基準と紐づけて定義し、プロジェクトの CI/ツール構成を調査した上で計測基盤（CI 設定・集計スクリプト・バッジ等）の実装を支援して test-monitoring.md と実装物を作る。「テストのメトリクスを決めたい」「CI でテスト進捗を可視化したい」「カバレッジや失敗率を計測する仕組みを作りたい」「トレーサビリティを継続計測したい」と依頼されたときに使う。**AI が継続的なモニタリングを代行することはしない（計測は基盤が行う）。集まったデータの分析・傾向判断は対…
Gh Push
非対話セッション（claude-code の remote-control / CI など TTY が無く SSH 鍵パスフレーズを入力できない状況）で git push を通すスキル。remote が SSH URL で `ssh -o BatchMode=yes` による非対話 SSH 認証が実際に通る（agent の鍵・パスフレーズ無しのディスク鍵・macOS キーチェーン鍵のいずれでも可）なら素の SSH push を実行し、非対話 SSH 認証が通らず `git push` が `Permission denied (publickey)` で失敗する場合は、push を HTTPS + gh トークン（credential.helper='!gh auth git-credential'）経由へ自動フォールバックして標準入力なしで実行する。「push して」「リモートに反映し…
Gh Fetch
非対話セッション（claude-code の remote-control / CI など TTY が無く SSH 鍵パスフレーズを入力できない状況）で git fetch / pull を通すスキル。remote が SSH URL で `ssh -o BatchMode=yes` による非対話 SSH 認証が実際に通る（agent の鍵・パスフレーズ無しのディスク鍵・macOS キーチェーン鍵のいずれでも可）なら素の SSH fetch を実行し、非対話 SSH 認証が通らず `git fetch`/`git pull` が `Permission denied (publickey)` で失敗する場合は、取り込みを HTTPS + gh トークン（credential.helper='!gh auth git-credential'）経由へ自動フォールバックして標準入力なしで実行す…
Test Design
ISTQB/JSTQB のテスト設計（test design）活動を支援するスキル。test-analyze が識別したテスト条件から、テスト対象の特性に応じたテスト技法（同値分割・境界値分析・デシジョンテーブル・状態遷移・カバレッジ基準・エラー推測など）を選定提案し、承認された技法で具体的なテストケース（入力値・前提・期待結果）を導出して、設計書 test-design.md（技法選定根拠・カバレッジ）とケース一覧 test-case.md の 2 本を作る。「テストケースを作って」「テストケースを設計して」「どの技法で網羅すべきか提案して」「境界値/デシジョンテーブルでテストを起こして」と依頼されたときに使う。テストコード実装（test-implement）は対象外。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-design <テスト対象名> で明示的…
Response Format
ファイル編集・コマンド実行・調査・複数ツール呼び出しを伴う作業の最終応答時に、指定の日本語Markdownテンプレ（タイトル/解釈の要約/対応内容/影響）で対応内容を報告する。複数ターンに分かれた作業の最終完了時、複数ファイル編集を含む実装完了時、調査・分析タスクの結果報告時、新規ファイル作成を伴う作業の完了時に必ず参照する。単発の質問への即答（ツール呼び出しなし、または1〜2回のRead/Bashのみ）は対象外。
Diff Review
作業ブランチの diff を複数観点(レンズ)で並列レビューするオーケストレーションスキル。「レビューして」「diff をレビュー」「〇〇観点で見て」などユーザーが明示的にコードレビューを依頼したときに必ず使用する。決定論スクリプトで差分を収集し、レンズごとに diff-reviewer サブエージェントを並列起動して結果を統合報告する。コードの修正は行わない。
Biz Translate
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
Navigating
Navigate the user through reading code stop by stop to pay down understanding debt left by AI tooling. Explicit invocation only.
Nix Cache Check
Nix パッケージがバイナリキャッシュから降ってこずローカルビルドになる原因を調査する。
Review Converge
diff-review を指摘ゼロまで繰り返し、修正と再レビューの収束ループを回す `/review-converge [--until <閾値>]` の明示実行専用スキル。
Test Execute
ISTQB/JSTQB のテスト実行（test execution）活動を支援するスキル。test-implement が具体化したテストを実行し、結果を記録し、失敗を欠陥候補として整理して test-execution-log.md にまとめる。自動テストならランナーを実行し結果を解釈、手動テストなら利用者の実施結果を聞き取って記録する。失敗は欠陥候補として整理し、外部 issue 化は提案に留める。「テストを実行して結果を記録して」「テスト実行ログを作って」「失敗を欠陥として整理して」「手動テストの結果を記録して」と依頼されたときに使う。ワークフローの test-targeted（修正範囲にテストランナーを絞り込んで実行するだけ）とは別物で、こちらは ISTQB プロセスとしての実行・記録・欠陥候補整理を成果物 test-execution-log.md に残す。単発のテスト作成依頼…
Project Session
ghq 管理下のプロジェクトを 1 つ選び、そのディレクトリでブランチを変えずに claude を detached tmux セッションとして起動する。`/project-session` の明示実行専用。
Test Plan
ISTQB/JSTQB のテスト計画（test planning）活動を支援するスキル。テスト対象のプロダクトリスク（product risk）を発生可能性×影響度で識別・評価し、それを根拠にテストアプローチ（どこを厚くテストするか）・開始基準（entry criteria）・完了基準（exit criteria）を定めた test-plan.md を作る。「テスト計画を立てて」「テスト戦略を決めたい」「何をどこまでテストすべきか整理して」「リスクベースでテスト範囲を決めたい」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-plan <テスト対象名> で明示的に呼び出されたときのみ使用する。
Test Analyze
ISTQB/JSTQB のテスト分析（test analysis）活動を支援するスキル。テストベース（仕様・設計・コード・リスク）を分析して「何をテストすべきか」= テスト条件（test condition）を識別し、test-plan のプロダクトリスク評価があればそれを入力に優先度を付けた test-analysis.md を作る。「何をテストすべきか洗い出して」「テスト条件を整理して」「テスト観点を出して」「テスト分析して」と依頼されたときに使う。テストケースの導出（test-design）は対象外。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-analyze <テスト対象名> で明示的に呼び出されたときのみ使用する。
Quizzing
Quiz the user on a plan, implementation, or codebase to pay down understanding debt left by AI tooling. Explicit invocation only.
Tutoring
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.
Test Report
ISTQB/JSTQB のテスト完了（test completion）活動のうち、テスト実行結果の評価と完了基準（exit criteria）判定を支援するスキル。テスト実行ログ（test-execution-log.md）と test-plan の完了基準を突き合わせ、完了とみなせるかを判定した test-summary-report.md を作る。テスト完了時の最終レポートにも、テスト途中の中間評価にも使える。「テスト結果をまとめて」「完了基準を満たしたか判定して」「テストレポートを書いて」「今どこまでテストが進んだか評価して」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-report <テスト対象名> で明示的に呼び出されたときのみ使用する。
Commit Flow
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコ…
Dev Pipeline
シフトレフト開発プロセスの現在フェーズ・ゲート通過状況・マージ可否の判定材料を成果物と git/gh から決定論的に導出し、次に実行すべき工程スキルを提案する読み取り専用のパイプ役。/dev-pipeline [対象名] の明示実行専用。
Doc Integrate
機能単位の作業ドキュメント docs/dev/<対象>/ の仕様・基本設計を本体ドキュメントへ反映し、承認のうえ作業ディレクトリを削除するパイプライン終端のスキル。/doc-integrate <対象> で明示的に呼び出されたときのみ使用する。
Parallel Worktree
計画ファイルを読み、worktrunk(wt) で worktree を分けて並列・stacked に実装を進めるオーケストレーション。独立タスクは tmux の独立 claude で並列実行、依存連鎖は stacked PR として逐次構築する。`--remote-control` 指定で各 worktree の claude を Remote Control 付きで起動し、detached tmux のまま claude.ai 等からリモート接続できる。`--model`/`--permission-mode`/`--effort` で各 claude の起動モデル・パーミッションモード・effort を切り替えられる（task 個別上書きも可）。`/parallel-worktree resume` でPCの強制終了・クラッシュ等による不意の中断後、全レーン（worktree）の未…
Session Insights
Claude Code の過去セッション（transcript JSONL）・設定・スキル・運用パターンを決定論スクリプトで収集し、指定された分析観点に沿って傾向分析と改善案を出す。/session-insights で明示起動されたときのみ使用する。キーワードマッチによる自動起動はしない。起動時に分析観点の指定が必須。
Tmp Output
ユーザーからのファイル出力依頼（分析結果・調査レポート・ログ抜粋・要約・ドラフト・一時的なメモなど）に応えて新規ファイルを作成するときの出力先ルール。プロジェクト直下の`tmp_claude/`への出力命名規則を含む。調査結果やレポートを保存するとき、ドラフトを作るとき、ユーザー向けの一時成果物を書き出すときに必ず参照する。ただし、プロジェクト本体のソースコード作成、既存ファイルの編集、プロジェクト規定のドキュメント（docs/配下等）出力は対象外。
Test Targeted
テスト実行時の絞り込み運用ルール。プロジェクト全体テストではなく修正範囲に絞ったテスト実行を行う。`gradlew test`/`pytest`/`jest`/`go test`等のテストランナーを実行するとき、テスト実行コマンドを組み立てるときに必ず参照する。コミット差分や修正ファイルから対象テストを特定する手順を含む。
Commit Plan
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや parallel-worktree のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・…
Product Spec
新しいソフトウェア/デジタルプロダクトのコンセプトを対話で固め、競合・類似プロダクトを並列調査し、軽量な仕様ドラフトを作るオーケストレーションスキル。/product-spec <一言のプロダクトアイデア> で明示的に呼び出されたときのみ使用する。
Rebase Flow
git rebase / git pull --rebase を伴う操作の安全運用ルール。履歴書き換えは復旧不能な事故になり得るため、rebase 系コマンドを 1 つでも実行する前に必ず本スキルを参照する。「rebase して」「main に追従して」「ブランチを最新化して」「コミットをまとめて / 整理して」「squash して」「fixup を畳んで」「履歴をきれいにして」「force-push して」と依頼される、PR 前に履歴を整える、コンフリクト解消のために rebase する、といった場面すべてが対象。決定論スクリプトによるガードレール判定（保護ブランチ・push 済み範囲・子ブランチ・進行中操作・コンフリクト予測）→ 計画提示 → ユーザー承認 → backup ブランチ作成 → 非対話実行 → range-diff / tree 同一性による機械検証、のゲートを固定化す…
Latency Triage
Claude Code 自体の応答遅延・長考・作業中断のトリアージ。「応答が遅い」「回答が返ってこない」「思考が長すぎる」「固まった」「反応がない」「作業が中断された」「タイムアウトで止まった」「opus(モデル)が重い」と報告されたとき、遅延・中断の再発防止策を求められたとき、長時間セッションで応答性の低下を指摘されたときに必ず参照する。thinking/effort 設定・コンテキスト肥大・Bash タイムアウト・API 障害の切り分け手順と、既知の根本原因を含む。
Def Done
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。
Feature Spec
既存プロダクトへの機能追加の仕様を対話で固め、既存コード・既存仕様との整合を調査して REQ-# 契約付きの docs/dev/<対象>/spec.md を作成・改訂するスキル。/feature-spec <対象名> で明示的に呼び出されたときのみ使用する。
Test Implement
ISTQB/JSTQB のテスト実装（test implementation）活動を支援するスキル。test-design が導出したテストケースを、実行できる形に具体化する。自動テストなら実行手順（テストコード・テストデータ・テストダブル）をコンパイル/構文レベルの動作確認まで、手動テストなら手順書・テストデータ・環境準備手順を作る。「テストケースを実装して」「テストコードに落として」「テスト手順書を作って」「テストデータ・モックを用意して」と依頼されたときに使う。テスト対象の検証としての実行（結果の解釈・欠陥候補整理）は test-execute の担当でここではしない。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-implement <テスト対象名> で明示的に呼び出されたときのみ使用する。
Test Review
ISTQB/JSTQB のテストプロセス各工程の出口ゲートとして、工程成果物（test-plan.md / test-analysis.md / test-design.md / test-case.md / テスト実装 / test-execution-log.md / test-monitoring.md / test-summary-report.md）をレビューするスキル。決定論スクリプトの機械検査（トレーサビリティ ID 突合・テンプレ準拠）と test-reviewer サブエージェントの定性レビューを行い、利用者が通過/条件付き通過/差し戻しを判定して軽量記録 test-review-<工程>.md を残す。上流の仕様・基本設計（spec / design-doc 工程。docs/dev/<対象>/spec.md・basic-design.md）は機械検査と利用者判定のみの…
Reset Flow
git reset（HEAD / ブランチポインタの移動）の安全運用ルール。reset --hard は未コミット変更をどこにも残さず消せる唯一の日常操作であり、git reset を 1 つでも実行する前に必ず本スキルを参照する。「reset して」「巻き戻して」「直前のコミットを取り消して」「コミットをやり直したい」「変更を全部捨てて」「HEAD を◯◯に戻して」と依頼される、rebase-flow の失敗から backup へ復旧する、reflog から復元する、といった場面すべてが対象。決定論スクリプトで失われるもの（外れるコミット・push 済み範囲・消える未コミット変更）を判定 → 計画提示 → ユーザー承認 → safety branch 作成（arm）→ 実行 → 検証、のゲートを固定化する。plugin hooks の git-guard により arm なしの git…
Basic Design
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
Gh Ci Investigate
GitHub Actions の CI 失敗を調査するスキル。失敗した run / PR / job の URL（例: https://github.com/OWNER/REPO/actions/runs/RUNID、…/pull/PR、…/job/JOBID）や run_id・PR 番号を貼られて「このCIが失敗している、原因を調査して」「ビルド/テストがコケた、なぜ落ちたか調べて」「workflow が failed、修正案を出して」「job のログを見て」と頼まれたら必ず使う。WebFetch では github.com のログは取れない（PreToolUse hook が差し戻し、HTML しか返らない）ため、gh（`gh run view --log-failed` / `gh run view --job` / `gh pr checks` / `gh api`）で失敗ジョブ…
Nix Devenv
Nix + flake-parts 開発環境の構築パターン: root flake.nix（成果物）+ dev/flake.nix（devShell + CI シェル）を direnv で読み込む構成、および GitHub Actions CI テンプレートを提供する。このスキルは /nix-devenv と明示的に呼び出されたときのみ使用する。キーワードマッチによる自動起動はしない。
External Writes
Notion・Slack・GitHub Issue/PR・Linear等の外部システムへの書き込み・更新・コメント操作時の運用ルール。MCP書き込み系操作、Notion転記、Slack投稿、Issue/PRコメント、Linearチケット更新等を実行するときに必ず参照する。URLが会話に登場しても自動更新しないという原則を含む。