jpskill.com
💬 コミュニケーション コミュニティ

write-query

Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o write-query.zip https://jpskill.com/download/22591.zip && unzip -o write-query.zip && rm write-query.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/22591.zip -OutFile "$d\write-query.zip"; Expand-Archive "$d\write-query.zip" -DestinationPath $d -Force; ri "$d\write-query.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して write-query.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → write-query フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

[Skill 名] write-query

/write-query - 最適化されたSQLの記述

見慣れないプレースホルダーがある場合や、どのツールが接続されているかを確認する必要がある場合は、CONNECTORS.mdをご覧ください。

自然言語の記述からSQLクエリを作成します。このクエリは、特定のSQL方言に最適化され、ベストプラクティスに従っています。

使用法

/write-query <description of what data you need>

ワークフロー

1. リクエストの理解

ユーザーの記述を解析して、以下を特定します。

  • 出力列: 結果に含めるべきフィールドは何ですか？
  • フィルター: データを制限する条件（時間範囲、セグメント、ステータス）は何ですか？
  • 集計: GROUP BY操作、カウント、合計、平均はありますか？
  • 結合: 複数のテーブルを結合する必要がありますか？
  • 順序付け: 結果はどのようにソートされるべきですか？
  • 制限: トップNまたはサンプルの要件はありますか？

2. SQL方言の決定

ユーザーのSQL方言がまだ不明な場合は、使用している方言を尋ねます。

  • PostgreSQL (Aurora、RDS、Supabase、Neonを含む)
  • Snowflake
  • BigQuery (Google Cloud)
  • Redshift (Amazon)
  • Databricks SQL
  • MySQL (Aurora MySQL、PlanetScaleを含む)
  • SQL Server (Microsoft)
  • DuckDB
  • SQLite
  • その他 (詳細を尋ねてください)

同じセッションでの今後のクエリのために、その方言を覚えておいてください。

3. スキーマの検出 (ウェアハウスが接続されている場合)

データウェアハウスのMCPサーバーが接続されている場合：

  1. ユーザーの記述に基づいて関連するテーブルを検索します。
  2. 列名、型、およびリレーションシップを検査します。
  3. パフォーマンスに影響を与えるパーティショニングキーまたはクラスタリングキーを確認します。
  4. クエリを簡素化する可能性のある、事前に構築されたビューまたはマテリアライズドビューを探します。

4. クエリの記述

以下のベストプラクティスに従ってください。

構造:

  • クエリに複数の論理ステップがある場合、可読性のためにCTE（WITH句）を使用します。
  • 論理的な変換またはデータソースごとに1つのCTEを使用します。
  • CTEには記述的な名前を付けます（例: daily_signups、active_users、revenue_by_product）。

パフォーマンス:

  • 本番環境のクエリでSELECT *は絶対に使用しないでください。必要な列のみを指定してください。
  • 早期にフィルターを適用します（WHERE句をベーステーブルにできるだけ近づけます）。
  • 利用可能な場合はパーティションフィルターを使用します（特に日付パーティション）。
  • 大規模な結果セットを持つサブクエリにはINよりもEXISTSを優先します。
  • 適切なJOINタイプを使用します（INNER JOINが正しい場合にLEFT JOINを使用しないでください）。
  • JOINまたはウィンドウ関数で機能する場合、相関サブクエリを避けます。
  • 爆発的なJOIN（多対多）に注意してください。

可読性:

  • 自明でないロジックの「理由」を説明するコメントを追加します。
  • 一貫したインデントとフォーマットを使用します。
  • テーブルには意味のある短いエイリアスを付けます（単にa、b、cではない）。
  • 各主要な句を独自の行に配置します。

方言固有の最適化:

  • 方言固有の構文と関数を適用します（詳細はsql-queriesスキルを参照してください）。
  • 方言に適した日付関数、文字列関数、ウィンドウ構文を使用します。
  • 方言固有のパフォーマンス機能（例: Snowflakeクラスタリング、BigQueryパーティショニング）に注意します。

5. クエリの提示

以下を提供します。

  1. 構文ハイライト付きのSQLコードブロック内の完全なクエリ
  2. 各CTEまたはセクションが何をするかの簡単な説明
  3. 関連する場合のパフォーマンスに関する注意点（予想されるコスト、パーティションの使用状況、潜在的なボトルネック）
  4. 変更の提案 — 一般的なバリエーション（異なる時間範囲、異なる粒度、追加のフィルター）に合わせて調整する方法

6. 実行の申し出

データウェアハウスが接続されている場合、クエリを実行して結果を分析することを提案します。ユーザーが自分で実行したい場合、クエリはコピー＆ペーストする準備ができています。

例

単純な集計:

/write-query Count of orders by status for the last 30 days

複雑な分析:

/write-query Cohort retention analysis -- group users by their signup month, then show what percentage are still active (had at least one event) at 1, 3, 6, and 12 months after signup

パフォーマンスが重要なクエリ:

/write-query We have a 500M row events table partitioned by date. Find the top 100 users by event count in the last 7 days with their most recent event type.

ヒント

  • 正しい構文をすぐに得るために、SQL方言を事前に伝えてください。
  • テーブル名を知っている場合は、それらを含めてください。そうでない場合、Claudeがそれらを見つけるのを手伝います。
  • クエリが冪等（再実行しても安全）である必要があるか、1回限りであるかを指定してください。
  • 定期的なクエリの場合、日付範囲のためにパラメータ化されるべきかどうかを伝えてください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

/write-query - Write Optimized SQL

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Write a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.

Usage

/write-query <description of what data you need>

Workflow

1. Understand the Request

Parse the user's description to identify:

  • Output columns: What fields should the result include?
  • Filters: What conditions limit the data (time ranges, segments, statuses)?
  • Aggregations: Are there GROUP BY operations, counts, sums, averages?
  • Joins: Does this require combining multiple tables?
  • Ordering: How should results be sorted?
  • Limits: Is there a top-N or sample requirement?

2. Determine SQL Dialect

If the user's SQL dialect is not already known, ask which they use:

  • PostgreSQL (including Aurora, RDS, Supabase, Neon)
  • Snowflake
  • BigQuery (Google Cloud)
  • Redshift (Amazon)
  • Databricks SQL
  • MySQL (including Aurora MySQL, PlanetScale)
  • SQL Server (Microsoft)
  • DuckDB
  • SQLite
  • Other (ask for specifics)

Remember the dialect for future queries in the same session.

3. Discover Schema (If Warehouse Connected)

If a data warehouse MCP server is connected:

  1. Search for relevant tables based on the user's description
  2. Inspect column names, types, and relationships
  3. Check for partitioning or clustering keys that affect performance
  4. Look for pre-built views or materialized views that might simplify the query

4. Write the Query

Follow these best practices:

Structure:

  • Use CTEs (WITH clauses) for readability when queries have multiple logical steps
  • One CTE per logical transformation or data source
  • Name CTEs descriptively (e.g., daily_signups, active_users, revenue_by_product)

Performance:

  • Never use SELECT * in production queries -- specify only needed columns
  • Filter early (push WHERE clauses as close to the base tables as possible)
  • Use partition filters when available (especially date partitions)
  • Prefer EXISTS over IN for subqueries with large result sets
  • Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)
  • Avoid correlated subqueries when a JOIN or window function works
  • Be mindful of exploding joins (many-to-many)

Readability:

  • Add comments explaining the "why" for non-obvious logic
  • Use consistent indentation and formatting
  • Alias tables with meaningful short names (not just a, b, c)
  • Put each major clause on its own line

Dialect-specific optimizations:

  • Apply dialect-specific syntax and functions (see sql-queries skill for details)
  • Use dialect-appropriate date functions, string functions, and window syntax
  • Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)

5. Present the Query

Provide:

  1. The complete query in a SQL code block with syntax highlighting
  2. Brief explanation of what each CTE or section does
  3. Performance notes if relevant (expected cost, partition usage, potential bottlenecks)
  4. Modification suggestions -- how to adjust for common variations (different time range, different granularity, additional filters)

6. Offer to Execute

If a data warehouse is connected, offer to run the query and analyze the results. If the user wants to run it themselves, the query is ready to copy-paste.

Examples

Simple aggregation:

/write-query Count of orders by status for the last 30 days

Complex analysis:

/write-query Cohort retention analysis -- group users by their signup month, then show what percentage are still active (had at least one event) at 1, 3, 6, and 12 months after signup

Performance-critical:

/write-query We have a 500M row events table partitioned by date. Find the top 100 users by event count in the last 7 days with their most recent event type.

Tips

  • Mention your SQL dialect upfront to get the right syntax immediately
  • If you know the table names, include them -- otherwise Claude will help you find them
  • Specify if you need the query to be idempotent (safe to re-run) or one-time
  • For recurring queries, mention if it should be parameterized for date ranges