Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
response-format
ファイル編集・コマンド実行・調査・複数ツール呼び出しを伴う作業の最終応答時に、指定の日本語Markdownテンプレ(タイトル/解釈の要約/対応内容/影響)で対応内容を報告する。複数ターンに分かれた作業の最終完了時、複数ファイル編集を含む実装完了時、調査・分析タスクの結果報告時、新規ファイル作成を伴う作業の完了時に必ず参照する。
単発の質問への即答(ツール呼び出しなし、または1〜2回のRead/Bashのみ)は対象外。
含まれるファイル(1)
- SKILL.md2.3 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
対応完了レポート出力ルール
ファイル編集・コマンド実行・調査などの作業を伴うユーザー依頼の最終応答時に、必ず以下のテンプレに沿って日本語のプレーンテキストMarkdownで報告する。
適用判断(最重要)
このスキルを適用するかは「対応の規模」で判断する。
適用する(必須)
- 複数ツール呼び出し(Edit/Write/Bashの実行などが3回以上)を伴った作業の最終応答
- 複数ファイル編集・新規ファイル作成を含む実装の完了
- 調査・分析の結果報告
- 複数ターンに分かれた作業の最終完了時
- 設定変更・リファクタリング・移行作業の完了
適用しない(スキップ)
- 単発の質問への即答(ツール呼び出しなし)
- 1〜2回のRead/Bash読み取りのみで完結する確認系応答
- ユーザーの質問への会話的な回答
- 進捗報告・中間確認(最終応答ではないため)
判断に迷う場合は適用する。
出力ルール
- 必ずプレーンテキストのMarkdownで出力する
{}で囲われた説明文を実内容に置き換える- 出力後、システム通知で完了を報告する(環境により省略可)
出力フォーマット
# {私の入力全体を要約し、タイトルに変換}
{私の入力の全て}
## 解釈の要約
- {私の入力に対して、あなたの解釈の要約を箇条書き}
## 対応内容
- {実施した対応内容の全てを箇条書き}
## 影響
- {実施した対応内容による影響を箇条書き}
---
{私の入力に対して必要なデータ出力}
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
`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 で明示的に呼び出されたときのみ使用する。