技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
技術的な素材を「標準入力」、ビジネス職向けの平易な説明文を「標準出力」とするフィルタ。 やることは1つ — 技術内容の事実を保ったまま、技術用語・実装表現を排した日本語の説明に翻訳する。これ以外（実装の是非のレビュー、設計提案など）はしない。
説明先であるビジネス職は、コード・テーブル名・例外名・HTTP/SQL・インフラ用語などの技術的表現に対して理解を拒む傾向がある。技術的な内容であっても、業務と画面の言葉だけで成り立つ説明を出力する。
/biz-translate と明示的に呼ばれたときのみ。主な素材:
設計判断やリリース内容など他の技術素材にも使えるが、上記3つに最適化している。
## ひとことで言うと
（専門用語ゼロの1〜2文。結論を先に出す）
## 何が起きているか
（事象を業務・画面の言葉で説明。技術メカニズムは噛み砕く。不要なら簡潔に）
## お客様への影響
（誰が・どの業務で・どう困るか／困らないか。影響が無いなら「影響なし」と明記）
## いまの状況・見通し
（対応状況、いつ直る／直ったか、回避策があれば。未確定なら「調査中」「未定」と書く）
## 補足（任意）
（ビジネス職が顧客にそのまま伝えるときの言い回し例など。不要なら省略）
ビジネス職が最初に知りたい「結論」と「お客様への影響」を上段に置く。技術的な原因の詳細は本文に埋もれさせ、求められたら展開する。
ビジネス職向けの文章は顧客にそのまま転送されうる。分かりやすさのために事実を盛らない。
出力の最後に、エンジニアが顧客送付前に確認すべき点を箇条書きで添える。最低限:
---
### 送付前チェック（エンジニア確認用・社外には出さない）
- [ ] 未確定として書いた箇所（原因/復旧見込み等）は本当に未確定か
- [ ] 数値・日時・対象範囲は素材の事実と一致しているか
- [ ] 社外に出してはいけない内部情報（内部名・脆弱性詳細・他社名等）が混ざっていないか
該当する具体的な未確定箇所があれば、汎用文の下に名指しで追記する。
まず共通テンプレで出力する。そのうえで、素材の性質に応じてより適した型があれば、実行後のやり取りの中で差し替えを提案する。assets/ に用意:
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
`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 スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。
「レビューして」「diff をレビュー」「〇〇観点で見て」「PR に出す前にセルフレビュー」などユーザーがコードレビューを依頼したら、観点・レンズ名を挙げていなくても必ず使用する。作業ブランチの diff を複数観点(design / test / yagni、条件付きで spec 等)で並列レビューし統合報告するオーケストレーションスキル。既定は diff 内で完結する fix 指摘のみで、既存コードへの改善提案(リファクタ候補の洗い出し)は起動引数 --improvement の明示時のみ報告する。コードの修正は行わない。