Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
tmp-output
ユーザーからのファイル出力依頼(分析結果・調査レポート・ログ抜粋・要約・ドラフト・一時的なメモなど)に応えて新規ファイルを作成するときの出力先ルール。プロジェクト直下の`tmp-agents/`への出力命名規則を含む。調査結果やレポートを保存するとき、ドラフトを作るとき、ユーザー向けの一時成果物を書き出すときに必ず参照する。
ただし、プロジェクト本体のソースコード作成、既存ファイルの編集、プロジェクト規定のドキュメント(docs/配下等)出力は対象外。
含まれるファイル(3)
- SKILL.md2.8 KB
- scripts/ensure-ignored.sh3.1 KB
- scripts/tests/ensure-ignored.test.sh5.3 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
ファイル出力先ルール
ユーザーからファイル出力(コード生成・ログ出力・分析結果・調査レポート・ドラフトなど)の依頼を受けた場合のルール。
出力先の判断順序
- 基本: コーディングエージェント(Claude Code・Codex 等)が作業しているプロジェクトディレクトリのルートに
tmp-agents/ディレクトリを作成して出力する - 優先順位: ただし、プロジェクト固有のエージェント向け設定(AGENTS.md/CLAUDE.md/スキル等)によって出力先が指定された場合は、指定された出力先に出力する
- 依頼内容や出力される作業内容に基づいて、適切な名前をつけたファイルを出力する
git の ignore 保証(tmp-agents/ へ書き出す前に必須)
tmp-agents/ へ最初に書き出す前に、プロジェクトルートで次を実行する。ignore の有無を推測で判断しない。
bash <skill-dir>/scripts/ensure-ignored.sh
already-ignored(.gitignore・.git/info/exclude・全体設定のいずれかで ignore 済み)/added: <path>(.git/info/excludeへ追記した)/skip: not a git repositoryのいずれも、そのまま書き出してよい- exit 1 のときは書き出さず、stderr の理由をユーザーへ報告する(
.gitignoreの否定パターンなど) .gitignoreは編集しない。ignore の追加はスクリプトが.git/info/excludeへ行い、コミット対象を汚さない
ファイル名の命名規則
- 説明的で短い名前(例:
nvim_config_analysis.md、lua_syntax_errors.txt) - 日付やタイムスタンプを含める場合は
YYYYMMDD_形式で先頭に付ける - 拡張子は出力内容に合わせて選択(
.md、.txt、.json、.luaなど)
対象外
- 既存ファイルの編集・更新(ファイル編集ツールの対象)
- プロジェクト本体のソースコード作成(プロジェクトの所定位置に出力)
- 外部システム(Notion等)への書き込み(
external-writesスキル参照)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 で明示的に呼び出されたときのみ使用する。