warehouse-init
データウェアハウスのスキーマ探索を初期化します。すべてのテーブルメタデータを含む `.astro/warehouse.md` を生成し、即座な情報参照を可能にします。プロジェクトごとに一度実行し、スキーマ変更時に再実行してください。ユーザーが `/astronomer-data:warehouse-init` と入力したとき、またはデータ探索のセットアップを求めたときに使用します。
description の原文を見る
Initialize warehouse schema discovery. Generates .astro/warehouse.md with all table metadata for instant lookups. Run once per project, refresh when schema changes. Use when user says "/astronomer-data:warehouse-init" or asks to set up data discovery.
SKILL.md 本文
ウェアハウススキーマの初期化
データウェアハウスの包括的でユーザーが編集可能なスキーマリファレンスファイルを生成します。
Scripts: ../analyzing-data/scripts/ — 以下のすべての CLI コマンドは analyzing-data スキルのディレクトリに相対的です。scripts/cli.py コマンドを実行する前に、このファイルから相対的に ../analyzing-data/ に移動してください。
実行内容
- ウェアハウスからすべてのデータベース、スキーマ、テーブル、列を検出
- コードベースコンテキストで拡張 (dbt モデル、gusty SQL、スキーマドキュメント)
- 行数を記録し、大規模テーブルを特定
.astro/warehouse.mdを生成 — バージョン管理可能でチーム共有可能なリファレンス- ウェアハウスクエリなしに概念→テーブルの即座参照を有効化
プロセス
ステップ 1: ウェアハウス構成を読み込む
cat ~/.astro/agents/warehouse.yml
検出するデータベースのリストを取得します (例: databases: [HQ, ANALYTICS, RAW])。
ステップ 2: コードベースでコンテキストを検索 (並列)
ビジネスコンテキストをコード内で見つけるサブエージェントを起動:
Task(
subagent_type="Explore",
prompt="""
Search for data model documentation in the codebase:
1. dbt models: **/models/**/*.yml, **/schema.yml
- Extract table descriptions, column descriptions
- Note primary keys and tests
2. Gusty/declarative SQL: **/dags/**/*.sql with YAML frontmatter
- Parse frontmatter for: description, primary_key, tests
- Note schema mappings
3. AGENTS.md or CLAUDE.md files with data layer documentation
Return a mapping of:
table_name -> {description, primary_key, important_columns, layer}
"""
)
ステップ 3: 並列ウェアハウス検出
Task ツールを使用して、データベースごとに 1 つのサブエージェントを起動:
For each database in configured_databases:
Task(
subagent_type="general-purpose",
prompt="""
Discover all metadata for database {DATABASE}.
Use the CLI to run SQL queries:
# Scripts are relative to ../analyzing-data/
uv run scripts/cli.py exec "df = run_sql('...')"
uv run scripts/cli.py exec "print(df)"
1. Query schemas:
SELECT SCHEMA_NAME FROM {DATABASE}.INFORMATION_SCHEMA.SCHEMATA
2. Query tables with row counts:
SELECT TABLE_SCHEMA, TABLE_NAME, ROW_COUNT, COMMENT
FROM {DATABASE}.INFORMATION_SCHEMA.TABLES
ORDER BY TABLE_SCHEMA, TABLE_NAME
3. For important schemas (MODEL_*, METRICS_*, MART_*), query columns:
SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, COMMENT
FROM {DATABASE}.INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'X'
Return a structured summary:
- Database name
- List of schemas with table counts
- For each table: name, row_count, key columns
- Flag any tables with >100M rows as "large"
"""
)
すべてのサブエージェントを並列実行 (複数の Task 呼び出しを含む単一メッセージ)。
ステップ 4: カテゴリカル値ファミリーを検出
OPERATOR、STATUS、TYPE、FEATURE などの主要なカテゴリカル列に対して、値ファミリーを検出します:
uv run cli.py exec "df = run_sql('''
SELECT DISTINCT column_name, COUNT(*) as occurrences
FROM table
WHERE column_name IS NOT NULL
GROUP BY column_name
ORDER BY occurrences DESC
LIMIT 50
''')"
uv run cli.py exec "print(df)"
関連する値を共通のプリフィックス/サフィックスでファミリーにグループ化します (例: Export* for ExportCSV, ExportJSON, ExportParquet)。
ステップ 5: 結果をマージ
ウェアハウスメタデータ + コードベースコンテキストを結合:
- クイックリファレンステーブル — 概念 → テーブルマッピング (コードから見つかった場合は事前入力)
- カテゴリカル列 — 主要フィルター列の値ファミリー
- データベースセクション — データベースごとに 1 つ
- スキーマサブセクション — スキーマでグループ化されたテーブル
- テーブル詳細 — 列、行数、コードからの説明、警告
ステップ 6: warehouse.md を生成
ファイルを以下に書き込みます:
.astro/warehouse.md(デフォルト — プロジェクト固有、バージョン管理可能)~/.astro/agents/warehouse.md(--globalフラグを指定した場合)
出力形式
# Warehouse Schema
> Generated by `/astronomer-data:warehouse-init` on {DATE}. Edit freely to add business context.
## Quick Reference
| Concept | Table | Key Column | Date Column |
|---------|-------|------------|-------------|
| customers | HQ.MODEL_ASTRO.ORGANIZATIONS | ORG_ID | CREATED_AT |
<!-- Add your concept mappings here -->
## Categorical Columns
When filtering on these columns, explore value families first (values often have variants):
| Table | Column | Value Families |
|-------|--------|----------------|
| {TABLE} | {COLUMN} | `{PREFIX}*` ({VALUE1}, {VALUE2}, ...) |
<!-- Populated by /astronomer-data:warehouse-init from actual warehouse data -->
## Data Layer Hierarchy
Query downstream first: `reporting` > `mart_*` > `metric_*` > `model_*` > `IN_*`
| Layer | Prefix | Purpose |
|-------|--------|---------|
| Reporting | `reporting.*` | Dashboard-optimized |
| Mart | `mart_*` | Combined analytics |
| Metric | `metric_*` | KPIs at various grains |
| Model | `model_*` | Cleansed sources of truth |
| Raw | `IN_*` | Source data - avoid |
## {DATABASE} Database
### {SCHEMA} Schema
#### {TABLE_NAME}
{DESCRIPTION from code if found}
| Column | Type | Description |
|--------|------|-------------|
| COL1 | VARCHAR | {from code or inferred} |
- **Rows:** {ROW_COUNT}
- **Key column:** {PRIMARY_KEY from code or inferred}
{IF ROW_COUNT > 100M: - **⚠️ WARNING:** Large table - always add date filters}
## Relationships
{Inferred relationships based on column names like *_ID}
コマンドオプション
| オプション | 効果 |
|---|---|
/astronomer-data:warehouse-init | .astro/warehouse.md を生成 |
/astronomer-data:warehouse-init --refresh | 再生成、ユーザー編集を保持 |
/astronomer-data:warehouse-init --database HQ | 特定のデータベースのみを検出 |
/astronomer-data:warehouse-init --global | ~/.astro/agents/ に書き込み |
ステップ 7: キャッシュを事前入力
warehouse.md を生成した後、概念キャッシュを入力します:
# Scripts are relative to ../analyzing-data/
uv run cli.py concept import -p .astro/warehouse.md
uv run cli.py concept learn customers HQ.MART_CUST.CURRENT_ASTRO_CUSTS -k ACCT_ID
ステップ 8: CLAUDE.md 統合を提供 (ユーザーに質問)
ユーザーに質問:
Would you like to add the Quick Reference table to your CLAUDE.md file?
This ensures the schema mappings are always in context for data queries, improving accuracy from ~25% to ~100% for complex queries.
Options:
- Yes, add to CLAUDE.md (Recommended) - Append Quick Reference section
- No, skip - Use warehouse.md and cache only
ユーザーが「はい」を選択した場合:
.claude/CLAUDE.mdまたはCLAUDE.mdが存在するかチェック- 存在する場合、クイックリファレンスセクションを追加 (重複を回避)
- 存在しない場合、クイックリファレンスのみで
.claude/CLAUDE.mdを作成
追加するクイックリファレンスセクション:
## Data Warehouse Quick Reference
When querying the warehouse, use these table mappings:
| Concept | Table | Key Column | Date Column |
|---------|-------|------------|-------------|
{rows from warehouse.md Quick Reference}
**Large tables (always filter by date):** {list tables with >100M rows}
> Auto-generated by `/astronomer-data:warehouse-init`. Run `/astronomer-data:warehouse-init --refresh` to update.
「はい」の場合: .claude/CLAUDE.md または CLAUDE.md にクイックリファレンスセクションを追加します。
生成後
ユーザーに以下を伝えます:
Generated .astro/warehouse.md
Summary:
- {N} databases, {N} schemas, {N} tables
- {N} tables enriched with code descriptions
- {N} concepts cached for instant lookup
Next steps:
1. Edit .astro/warehouse.md to add business context
2. Commit to version control
3. Run /astronomer-data:warehouse-init --refresh when schema changes
リフレッシュ動作
--refresh が指定されている場合:
- 既存の warehouse.md を読み込む
- すべての HTML コメント (
<!-- ... -->) を保持 - クイックリファレンステーブルエントリ (ユーザーが追加) を保持
- ユーザーが追加した説明を保持
- 行数を更新し、新しいテーブルを追加
- 削除されたテーブルを
<!-- REMOVED -->コメントでマーク
キャッシュの古さ & スキーマドリフト
ランタイムキャッシュは、デフォルトで 7 日の TTL を持ちます。7 日後、キャッシュされたエントリは有効期限切れになり、次の使用時に再検出されます。
リフレッシュが必要な場合
以下の場合に /astronomer-data:warehouse-init --refresh を実行:
- スキーマ変更: テーブルが追加、名前変更、または削除された
- 列の変更: 新しい列が追加されたか、タイプが変更された
- デプロイ後: データパイプラインがスキーママイグレーションをデプロイしている場合
- 週次: 既知の変更がなくても、良い習慣として
古いキャッシュの兆候
以下の指標に注意:
- クエリが「テーブルが見つかりません」エラーで失敗する
- 結果が間違っているか古いように見える
- 新しいテーブルが検出されていない
手動キャッシュリセット
キャッシュの問題が疑わしい場合:
# Scripts are relative to ../analyzing-data/
uv run scripts/cli.py cache status
uv run scripts/cli.py cache clear --stale-only
uv run scripts/cli.py cache clear
コードベースパターン認識
| パターン | ソース | 抽出内容 |
|---|---|---|
**/models/**/*.yml | dbt | テーブル/列の説明、テスト |
**/dags/**/*.sql | gusty | YAML frontmatter (説明、主キー) |
AGENTS.md、CLAUDE.md | ドキュメント | データレイヤー階層、規約 |
**/docs/**/*.md | ドキュメント | ビジネスコンテキスト |
サンプルセッション
User: /astronomer-data:warehouse-init
Agent:
→ Reading warehouse configuration...
→ Found 1 warehouse with databases: HQ, PRODUCT
→ Searching codebase for data documentation...
Found: AGENTS.md with data layer hierarchy
Found: 45 SQL files with YAML frontmatter in dags/declarative/
→ Launching parallel warehouse discovery...
[Database: HQ] Discovering schemas...
[Database: PRODUCT] Discovering schemas...
→ HQ: Found 29 schemas, 401 tables
→ PRODUCT: Found 1 schema, 0 tables
→ Merging warehouse metadata with code context...
Enriched 45 tables with descriptions from code
→ Generated .astro/warehouse.md
Summary:
- 2 databases
- 30 schemas
- 401 tables
- 45 tables enriched with code descriptions
- 8 large tables flagged (>100M rows)
Next steps:
1. Review .astro/warehouse.md
2. Add concept mappings to Quick Reference
3. Commit to version control
4. Run /astronomer-data:warehouse-init --refresh when schema changes
ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- astronomer
- リポジトリ
- astronomer/agents
- ライセンス
- Apache-2.0
- 最終更新
- 不明
Source: https://github.com/astronomer/agents / ライセンス: Apache-2.0
関連スキル
hugging-face-trackio
Trackioを使用してMLトレーニング実験を追跡・可視化できます。トレーニング中のメトリクスログ記録(Python API)、トレーニング診断のアラート発火、ログされたメトリクスの取得・分析(CLI)が必要な場合に活用してください。リアルタイムダッシュボード表示、Webhookを使用したアラート、HF Space同期、自動化向けのJSON出力に対応しています。
btc-bottom-model
ビットコインのサイクルタイミングモデルで、加重スコアリングシステムを搭載しています。日次パルス(4指標、32ポイント)とウィークリー構造(9指標、68ポイント)の2カテゴリーにわたる13の指標を追跡し、0~100のマーケットヒートスコアを算出します。ETFフロー、ファンディングレート、ロング/ショート比率、恐怖・貪欲指数、LTH-MVRV、NUPL、SOPR(LTH+STH)、LTH供給率、移動平均倍率(365日MA、200週MA)、週次RSI、出来高トレンドに対応します。市場サイクル全体を通じて買いと売りの両方の推奨を提供します。ビットコインの底値拾い、BTCサイクルポジション、買い時・売り時、オンチェーン指標、MVRV、NUPL、SOPR、LTH動向、ETFの流出入、ファンディングレート、恐怖指数、ビットコインが過熱状態か、マイナーコスト、暗号資産市場のセンチメント、BTCのポジションサイジング、「今ビットコインを買うべきか」「BTCが天井をつけているか」「オンチェーン指標は何を示しているか」といった質問の際にこのスキルを活用します。
protein_solubility_optimization
タンパク質の溶解性最適化 - タンパク質の溶解性を最適化します。タンパク質の特性を計算し、溶解性と親水性を予測し、有効な変異を提案します。タンパク質配列の特性計算、タンパク質機能の予測、親水性計算、ゼロショット配列予測を含むタンパク質エンジニアリング業務に使用できます。3つのSCPサーバーから4つのツールを統合しています。
research-lookup
Parallel Chat APIまたはPerplexity sonar-pro-searchを使用して、最新の研究情報を検索できます。学術論文の検索にも対応しています。クエリは自動的に最適なバックエンドにルーティングされるため、論文の検索、研究データの収集、科学情報の検証に活用できます。
tree-formatting
ggtree(R)またはiTOL(ウェブ)を使用して、系統樹の可視化とフォーマットを行います。系統樹を図として描画する際、ツリーレイアウトの選択、分類学に基づく枝やラベルの色付け、クレードの折りたたみ、サポート値の表示、またはツリーへのオーバーレイ追加が必要な場合に使用してください。系統推定(protein-phylogenyスキルを使用)やドメイン注釈(今後の独立したスキル)には使用しないでください。
querying-indonesian-gov-data
インドネシア政府の50以上のAPIとデータソースに接続できます。BPJPH(ハラール認証)、BOM(食品安全)、OJK(金融適正性)、BPS(統計)、BMKG(気象・地震)、インドネシア中央銀行(為替レート)、IDX(株式)、CKAN公開データポータル、pasal.id(第三者法MCP)に対応しています。インドネシア政府データを活用したアプリ開発、.go.idウェブサイトのスクレイピング、ハラール認証の確認、企業の法的適正性の検証、金融機関ステータスの照会、またはインドネシアMCPサーバーへの接続時に使用できます。CSRF処理、CKAN API使用方法、IP制限回避など、すぐに実行可能なPythonパターンを含んでいます。