sql-queries

sql-queries skill の概要

sql-queries skill でできること

sql-queries skill は、業務上の問いやざっくりした分析ゴールを、主要なデータウェアハウスやデータベース向けの SQL に落とし込む skill です。結果は欲しいけれど、そのために必要な join、filter、aggregation、dialect の構文がまだはっきりしていない、という場面で特に役立ちます。

どんな人に向いているか

sql-queries は、レポーティング、探索的分析、アドホック分析に取り組むプロダクトマネージャー、アナリスト、データエンジニア、AI ユーザーに向いています。特定の schema に合ったクエリが必要で、汎用テンプレートでは足りない sql-queries for Data Analysis の場面では、特に有効です。

何が違うのか

この skill は単に「プロンプトから SQL を書く」だけではありません。schema の文脈を前提にし、対象 dialect の指定を求め、最適化された説明可能な出力を目指します。だからこそ、速度だけでなく、クエリの正確性、性能、table 関係が重要なときに強みがあります。

sql-queries skill の使い方

sql-queries をインストールする

次の repo path から skill をインストールします。
npx skills add phuryn/pm-skills --skill sql-queries

sql-queries install を行う場合は、pm-data-analytics/skills/sql-queries 配下に skill が追加されていることを確認し、そのうえで workflow で使う前に skill ファイルを開いてください。

最初に適切な入力をそろえる

sql-queries usage をうまく使うには、まず 3 つが重要です。質問、SQL dialect、そして schema です。良いプロンプトには、必要な metric や rows、対象の date range や filter、さらに grouping や sorting の条件まで入っている必要があります。

良い入力例:

• “Write a PostgreSQL query to show weekly active users by signup cohort for the last 12 weeks.”
• “Use this BigQuery schema to find top 20 customers by total revenue, excluding refunds.”

弱い入力例:

• “Make a SQL query for my data.”

先に repo ファイルを読む

まず SKILL.md を開き、続いて README.md、AGENTS.md、metadata.json、または周辺にある supporting folders があればそれも確認してください。この repo では SKILL.md が主な source of truth なので、prompt を投げる前に、目的、workflow steps、例のパターンを読むのが最短ルートです。

より良い出力のために依頼を具体化する

join や metric を正しく推論できるよう、skill に十分な構造を与えてください。わかるなら table 名を入れ、CTE ベースのクエリにしたいのか、短くまとめた形にしたいのかも伝えます。出力をそのまま実行できる形にしたいのか、注釈を多めに入れてほしいのかも明記してください。database が大きい場合は、scan を絞る、cross join を避ける、date partition filter を優先する、といった performance 制約も伝えると効果的です。

sql-queries skill FAQ

sql-queries は上級者向けの SQL ユーザー専用ですか？

いいえ。初心者にも役立ちますが、欲しい data を平易な言葉で説明できるほど結果は良くなります。metric、grain、date window を言語化できない場合は、query を完成させるのに何度か反復が必要になることがあります。

sql-queries はどの database に対応していますか？

この skill は BigQuery、PostgreSQL、MySQL、そのほかの dialect 向けに説明されており、対象 engine の確認を明示的に求めます。functions、quoting、date handling、performance pattern が異なるため、この dialect 確認は重要です。

どんな場合に sql-queries を使わない方がいいですか？

schema の詳細を提供できず、かつ本番で完全に検証された query が必要な場合や、タスクが query 作成より database design に近い場合は使わない方がよいです。また、問いが曖昧すぎて measurable な結果に変換できない場合も、相性はよくありません。

通常のプロンプトと何が違うのですか？

通常の prompt でもそれらしい query は出せますが、sql-queries skill は workflow を schema 読解、dialect 選択、最適化、テスト可能性へと寄せます。実際の table 構造に依存する query では、その違いが推測の余地を減らします。

sql-queries skill を改善するには

schema と意図をセットで伝える

品質を最も大きく上げるのは、業務上の問いと table structure をセットで渡すことです。column 名、relationship、既知の edge case を共有すれば、skill は join の経路や aggregation の grain を推測ではなく根拠をもって選べます。

query を左右する制約を明示する

performance を重視するなら、そう伝えてください。null を除外したいのか、user の重複排除が必要か、refund をどう扱うか、time zone を尊重するか、partition 済み date で絞るか。こうした details は、質問文そのものより SQL を大きく変えることがよくあります。

まず 1 回目で validation を求める

sql-queries guide の強い workflow は、query を生成し、前提を確認し、違和感があれば 2 版目を依頼する、という流れです。最初の回答が広すぎる場合は、join を簡略化する、各 CTE の役割を説明する、別の dialect 向けに書き直す、といった指示を追加してください。

出力は最終版ではなく下書きとして使う

この skill は、query accelerator として扱うと最も効果を発揮します。特に sql-queries for Data Analysis では、grain のわずかなズレが結果を歪めることがあるため、実行前に join key、grouping level、filter logic を確認してください。