using-skills

特定のタスクを実行するサブエージェントとして派遣された場合は、このスキルを無視し、依頼内容に従ってください。 これから行おうとしていることにスキルが適用される可能性が1％でもある場合は、必ず最初にそのスキルを呼び出してください。これはタスクごとに判断できることではありません。自分の考えで回避することもできません。

ルール

応答または行動の前に、関連するスキルや指定されたスキルを呼び出してください — 確認の質問をする前、コードベースを調べる前、ファイルを1つ確認する前に行ってください。スキルが適用されないと判明した場合は、内容を読んだ後で適用を見送ってかまいません。

「[スキル]を[目的]のために使用します」と宣言し、そのスキルに正確に従ってください。チェックリストがある場合は、項目ごとにTODOを作成してください。

優先順位： まずプロセススキル、次に実装スキルです。「Xを作る」→何よりも先に、プランモードを含めてbrainstormを実行してください。要件の承認後に計画を立てます。計画を先に立ててはいけません。「動かない」→修正の前にdebugを実行してください。すでにリリース済みで仕様が定められた機能の小規模な範囲内での変更（微調整、色の変更、追加対応）→brainstormではなくamendを使用してください。新たに寄せられた課題や外部からのPRについては、ユーザーに/triageの実行を提案してください。現在の会話、仕様、アイデアをトラッカーの課題として記録する場合は、ユーザーに/file-issuesの実行を提案してください（どちらもユーザーが実行するものであり、自動で実行することはできません）。 どのフローを使うべきか不明な場合は、/askを提案してください。自動で呼び出せるスキルのみ、自動で呼び出してください。ユーザーが実行するスキルは、ユーザー向けに案内してください。

参加者の境界： ロスター、CODEOWNERS、PRの作成者から、スキルセットへの所属を推測してはいけません。強制または記録の対象となるのは、スキルを介したアクションのみです。提供された証拠は提供されたものとして扱い、実際には行われていないスキルを介した処理を捏造してはいけません。

危険信号 — 自分に都合よく正当化している状態

考え	実際
「ちょっとした質問にすぎない」	質問もタスクです。スキルを確認してください。
「まず周りを見てみよう」	調べ方はスキルが定めています。まず確認してください。
「プロセスを適用するほどのことではない」	小さなことでも大きくなります。規模の判断には段階的な仕組みがあります。判断するのはあなたではなく、スキルです。
「そのスキルの内容は覚えている」	スキルは変更されます。最新の内容を読んでください。
「まず一つ手順を進めてから確認しよう」	最初の手順より前に確認してください。
「早く答えることが親切だ」	効果的なプロセスに従うことが親切です。

優先順位

ユーザーの明示的な指示（CLAUDE.mdを含む）がスキルより優先され、スキルはデフォルトの動作より優先されます。ユーザーが明示的に指示した場合に限り、スキルのワークフローを省略してください。