using-superpowers

会話を始めるときです。作業の種類とは関係ありません。

これは道具ではなく規範です。同じ公開元のスキル群を「使わせる」ための 1 件で、本文のほとんどが呼ばないことへの反論に費やされています。

言い方が異様に強い

本文には <EXTREMELY-IMPORTANT> という札で囲まれた段落があります。

いまやっていることにスキルが当てはまる可能性が 1% でもあるなら、絶対に呼ばなければならない。

スキルが当てはまるなら、選択の余地は無い。これは交渉の対象ではない。言い抜けはできない。

ここまで強く書く必要があったことは、逆に何が起きていたかを示しています。エージェントは「今回は要らない」と判断してしまう。その判断を封じるのがこのスキルの目的です。

呼ぶ順番が決まっている

規則そのものは 1 行です。

どの応答・どの行動よりも前に、関係するスキルを呼べ。確認の質問、コードベースの探索、ファイルの確認も含む。

そして「結果的に状況に合わなかったなら、使わなくてよい」と続きます。判断は読んだあとにするという順序です。

計画を立てる段（plan mode）に入る前にも決まりがあります。まだ案を広げていないなら、先に brainstorming を呼べ、と書かれています。

呼んだら宣言して従う

呼んだら「[スキル名] を [目的] のために使います」と宣言し、そのとおりに従う。チェックリストがあれば 1 項目ずつ課題にする。

工程のスキルが先、実装のスキルがあと

優先順位も決められています。

例も添えられています。「X を作ろう」なら brainstorming が先、「この不具合を直して」なら systematic-debugging が先。

合理化の言葉を 12 個並べている

ここが読む価値のある部分です。「こう思ったら止まれ」という表が 12 行あります。主な 8 行を挙げます。

• ただの簡単な質問だ質問も作業だ。スキルを確認せよ
• まず文脈が要る確認の質問よりスキルの確認が先
• まずコードベースを見ようスキルが「どう見るか」を教える
• このスキルは大げさだ簡単なことは複雑になる。使え
• そのスキルは覚えているスキルは変わる。現在の版を読め
• 概念は知っている知っていることと使うことは違う
• とりあえず 1 つだけ先に何かをする前に確認せよ
• これは前に進んでいる感じがする規律の無い行動は時間を無駄にする

「そのスキルは覚えている」への返しが正しいです。スキルは更新されます。記憶で代替すると古い版で動きます。

利用者の指示が上に立つ

最後の節が、この手の強い規範としては珍しく謙抑的です。

利用者の指示（CLAUDE.md、AGENTS.md、GEMINI.md、直接の依頼）はスキルより優先され、スキルは既定の挙動を上書きする。

「1% でも呼べ」と書きながら、人の指示には勝たないと明記しています。優先順位が 3 段で整理されているのは健全です。

サブエージェントには適用しない

本文の冒頭に <SUBAGENT-STOP> の札があり、サブエージェントはこのスキルを無視せよと書かれています（特定の作業を任された場合）。

これは理にかなっています。1 タスクを渡されたエージェントが毎回スキルの棚卸しを始めると、渡した意味が消えます。

実行環境ごとの補足がある

同梱ファイルは 7 件で、すべて実行環境別の補足です（Claude Code、Codex、Gemini、Pi、Antigravity、Hermes Agent、Muse。2026-10-05 確認）。

公開元が実行環境の名前を挙げている

公開元が実行環境の名前を挙げている数少ない例です。同じ公開元の writing-skills は置き場所まで書き分けているので、当サイトはこの群を Claude Code と Codex 対応として表示しています。

プラグインで入れると毎回読み込まれる

公開元のプラグインで入れると、会話を始めたとき・/clear したとき・/compact したときに、このスキルの本文がフックで自動的に差し込まれます。npx skills add で 1 件ずつ入れた場合はこの差し込みが無く、呼ばれたときに読まれるだけです。入れ方による違いは superpowers の地図にまとめています。

同じ公開元のスキル群を入れていないとき

同じ公開元のスキル群を入れていないなら、意味がありません。呼ぶ先が無い状態で「必ず呼べ」と言われるだけになります。

サブエージェント

サブエージェントには入れないでください。本文自身がそう指示しています。

少数のスキルで回しているとき

少数のスキルで回しているなら大げさです。これは同じ公開元のスキル群（原本は 15 件、当サイトの収録は 14 件。2026-10-09 確認）を確実に発動させるための仕掛けです。

自分の規範を持っている環境

自分の規範を持っている環境では衝突します。CLAUDE.md に進め方を書いているなら、そちらが優先されると本文にはありますが、規範が二重になること自体が読みにくさを生みます。

読み取りと判断だけのスキル

SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは 7 件です（2026-10-05 時点）。

読み取りと判断だけのスキルです。何かを実行する手順はありません。

挙動への影響は大きい

詳しくはスキルを入れる前に確認することにあります。

文脈を使う

毎回スキルの棚卸しをすると、そのぶん会話が消費されます。群が大きいほど効いてきます（スキルを入れすぎて重くなる仕組み）。

強い言い方は保証ではない

「交渉の対象ではない」と書いてあっても、従うのはエージェントです。確実に呼ばせたいなら、依頼文で名前を指定するほうが速いです。

ライセンス

ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。

簡単な質問でもスキルを呼ばれますか

そう書かれています。合理化の表の 1 行目が「ただの簡単な質問だ」で、返しは「質問も作業だ」です。

前置きが煩わしい場合は、依頼文で「今回はスキルを使わずに答えて」と伝えてください。

CLAUDE.md の指示とどちらが優先されますか

利用者の指示が優先されます。本文の最後に「利用者の指示はスキルより優先され、スキルは既定の挙動を上書きする」と 3 段で書かれています。

サブエージェントにも入れますか

入れません。本文の冒頭に、特定の作業を任されたサブエージェントはこのスキルを無視せよという札があります。

1 タスクを渡した相手が棚卸しを始めると、渡した意味が消えます。

どのスキルが先に呼ばれますか

工程のスキルが先です。進め方を決めるものが先に走り、実装のスキルがそれを実行します。

「作ろう」なら brainstorming、「直して」なら systematic-debugging が先です。

これ 1 件だけ入れても意味がありますか

ありません。呼ぶ先のスキル群が前提です。同じ公開元のスキル群と併せて入れてください（原本は 15 件。2026-10-09 確認）。

対応しているエージェントはどれですか

Claude Code と Codex です。同梱に Claude Code・Codex・Gemini・Pi・Antigravity・Hermes Agent・Muse 向けの補足ファイルがあり、同じ公開元の writing-skills では置き場所まで書き分けられています。

当サイトは公開元が明記しているものだけを表示しています（指標の意味と限界）。