think

think skill の概要

think skill でできること

think は、コードを書く前に、ざっくりしたアイデアを明確で承認可能な計画に落とし込むための意思決定支援 skill です。機能設計、アーキテクチャの選定、トレードオフ分析、「これをやるべきか？」といった判断が主題の場面に向いており、実装そのものよりも判断が求められるときに最も力を発揮します。

どんな人にインストール向きか

repo-first のワークフローの中で、プロダクト判断、技術方針、スコープを切った計画づくりを頻繁にサポートしてほしいなら、think skill の導入がおすすめです。特に、依頼の入り口が「これを計画して」「最適な進め方は？」「これを残すべき？」のような価値判断ベースなら相性が良いです。

何が違うのか

この skill はかなり方針がはっきりしています。具体的な推奨案を出し、判断を変える可能性がある証拠を示し、早すぎるコード生成は避けます。そのため、決断に使える形のアウトプットが欲しいときには、think for Decision Support は一般的なブレインストーミング用プロンプトよりもずっと有効です。

think skill の使い方

インストールして起動する

npx skills add tw93/Waza --skill think でインストールします。そのうえで、タスクが「既知の不具合を直す」ことではなく、「方向性を選ぶ」「形を整える」「妥当性を検証する」ことにあるときに使います。think install の手順自体は簡単ですが、出力の質は、実際の意思決定コンテキストをどれだけ与えられるかで大きく変わります。

適切な入力の形にする

強い think usage プロンプトには、目的、制約、対象読者、そして実際にどの選択肢が開いているのかを入れるべきです。例えば、「SMB 管理者向けにオンボーディングを速くしたい。UI だけ変更可能で、このスプリントではバックエンド作業は増やせない。トレードオフ込みで推奨案がほしい」といった形です。

最初に読むべきファイル

まずは SKILL.md を読んでください。この repo は意図的に最小構成で、rules/、references/、resources/ のような補助フォルダはありません。実務上のガイドは skill 本体にまとまっており、軽量モード、評価モード、そして承認前は実装に入らないというルールが中心です。

ワークフローを意思決定のふるいとして使う

良い think guide の流れは、まず決定事項を明示し、制約を列挙し、最適な進め方を尋ね、必要に応じてリスクと代替案を追加で求める、というものです。軽量モードとフルモードのどちらを使うべきか迷う場合は、その問題がすでに定義済みかどうかを説明してください。その一点だけでも出力はかなり変わります。

think skill の FAQ

think は新機能向けだけですか？

いいえ。アーキテクチャの判断、プロダクト価値の評価、明確なトレードオフを伴うリファクタリング、そして「やる価値があるか？」という問いにも使えます。一方で、単純なバグ修正や、答えがほぼ自明な小さな編集には最適ではありません。

通常のプロンプトと何が違いますか？

通常のプロンプトだと、曖昧な選択肢が並ぶだけで終わることがよくあります。think skill は、推奨案を 1 つに絞り、トレードオフを明示し、承認前にコーディングへ進まない境界をはっきりさせる設計です。そのため、チームメイトや関係者にレビューしてもらう前提の計画を作るときに向いています。

think は初心者向けですか？

はい。ユーザーが目的を平易な言葉で説明できるなら使えます。初心者でも、技術用語を知らなくても、問題・制約・望む結果を伝えられれば、最も価値を得やすいです。

いつ think を使うべきではありませんか？

すでに修正方法が分かっていて、あとは実行するだけのときは使わないでください。あるいは、分析するより直接編集したほうが早いほど範囲が狭いタスクでも不要です。また、本当に決めることがなく、単に短い書き換えだけが必要な場合も、追加価値は小さいです。

think skill をどう改善するか

判断に足るコンテキストを与える

最良の think skill 入力には、現状、目標状態、譲れない制約、そして成功の定義が含まれます。例えば、「セットアップ時間を 10 分から 2 分に短縮したい。現在のバックエンドは維持し、新しい依存関係は増やしたくない」と書けば、「オンボーディングを改善して」よりずっと実用的な助言が得られます。

アイデアではなく決定を求める

think usage を改善したいなら、候補を並べてもらうより、理由付きの推奨を求めてください。良い例は「この制約下で勝つのはどの方法かを 1 つ選び、その理由を説明して」です。弱い例は「いくつかアイデアを出して」です。

重視するトレードオフを明示する

速度、保守性、コスト、UX、リスク、チームの稼働余力など、何を最優先したいのかを伝えてください。これにより、think for Decision Support は、一般論ではなく、あなたの優先順位に合った計画を返しやすくなります。

制約を絞って反復する

最初の結果が広すぎるなら、次の一手で条件を 1 つ足して絞り込んでください。締切、禁止したい依存関係、対象ユーザー、絶対に残すべきコンポーネントなどです。出力を最も早く改善する方法は、見えない前提を明文化してから次の計画を求めることです。