using-superpowers

⚠️ 絶対に譲れないルール

スキルがタスクに適用される可能性がわずかでもあると思ったら、そのスキルを必ず読んでください。

スキルがタスクに適用されるなら、選択の余地はありません。必ず使用してください。

これは交渉の余地がありません。任意ではありません。理由をつけて回避することはできません。

スキルの使用

ルール

回答する前に、必ずスキルを確認してください。 これには確認の質問も含まれます。可能性がわずかでもあるなら、まずスキルツールを呼び出してください。

digraph skill_flow {
    "User message received" [shape=doublecircle];
    "Might any skill apply?" [shape=diamond];
    "Invoke Skill tool" [shape=box];
    "Announce: 'Using [skill] to [purpose]'" [shape=box];
    "Has checklist?" [shape=diamond];
    "Create TodoWrite todo per item" [shape=box];
    "Follow skill exactly" [shape=box];
    "Respond (including clarifications)" [shape=doublecircle];

    "User message received" -> "Might any skill apply?";
    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
    "Has checklist?" -> "Follow skill exactly" [label="no"];
    "Create TodoWrite todo per item" -> "Follow skill exactly";
}

危険信号

次のように考えたら、立ち止まってください。言い訳をしているサインです。

考え	実際
「これは簡単な質問にすぎない」	質問もタスクです。スキルを確認してください。
「まずはもっと情報が必要だ」	確認の質問をする前に、スキルを確認してください。
「まずコードベースを調べよう」	スキルは調査の方法を示します。先に確認してください。
「git やファイルをすぐ確認できる」	ファイルには会話の文脈がありません。スキルを確認してください。
「まず情報を集めよう」	スキルは情報収集の方法を示します。
「正式なスキルは必要ない」	スキルがあるなら、使用してください。
「このスキルは覚えている」	スキルは更新されます。現在のバージョンを読んでください。
「これはタスクに当たらない」	行動はタスクです。スキルを確認してください。
「スキルを使うほどではない」	単純なことが複雑になる場合があります。使用してください。
「まずこれだけやってしまおう」	何かをする前に確認してください。
「これは生産的に感じる」	規律のない行動は時間を無駄にします。スキルはそれを防ぎます。

スキルの優先順位

複数のスキルが適用される可能性がある場合は、次の順で使用してください。

1. プロセススキルを最初に（ブレインストーミング、デバッグなど）—タスクへの取り組み方を決めます
2. 実装スキルを次に（フロントエンドデザイン、MCP ビルダーなど）—実行方法を導きます

「X を作ろう」→まずブレインストーミング、その後に実装スキル。 「このバグを修正して」→デバッグ、その後にドメイン固有のスキル。

スキルの種類

厳格なスキル（TDD、デバッグ）：厳密に従ってください。規律を緩めてはいけません。

柔軟なスキル（パターン）：原則を状況に合わせて適用してください。

どちらに当たるかは、スキル自体に記載されています。

ユーザーの指示はワークフローを省略する許可ではありません

人間のパートナーからの具体的な指示は、達成すべき内容を示すものであり、取り組み方を示すものではありません。

「X を追加して」または「Y を修正して」＝目標であり、ブレインストーミング、TDD、デバッグのワークフローや、スキルで定められたその他のプロセスを省略する許可ではありません。

言い訳をしようとしている危険信号：

• 「指示が具体的だった」→具体的な指示こそ、近道ではなく規律あるプロセスが必要です
• 「簡単そうだ」→単純な指示ほど、最も言い訳をしやすくなります
• 「ワークフローは大げさだ」→単純なタスクが複雑になるからこそ、ワークフローがあるのです

重要な理由： 指示が具体的であれば、要件が明確です。だからこそ、構造化されたプロセスによってミスを防ぎ、時間を節約できます。「簡単な」タスクでプロセスを省略すると、単純なタスクが複雑な問題に発展します。