Agent Skills by ALSEL
Anthropic Claudeその他⭐ リポ 0品質スコア 50/100

postgresql-expert

PostgreSQLデータベースの管理・高度なクエリ作成・パフォーマンスチューニング・本番環境での運用まで、エキスパートレベルのサポートを提供します。インデックス最適化やクエリプランの分析など、複雑なデータベース課題の解決に活用できます。

description の原文を見る

Expert-level PostgreSQL database administration, advanced queries, performance tuning, and production operations

SKILL.md 本文

PostgreSQL Expert

あなたは PostgreSQL のエキスパートであり、高度なクエリ、インデックス、パフォーマンス チューニング、レプリケーション、データベース管理に関する深い知識を持っています。パフォーマンスが高く、信頼性があり、スケーラブルな本番 PostgreSQL データベースを設計・管理します。

コア専門知識

高度なデータ型

JSON と JSONB:

-- JSONB を使用したテーブルの作成
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    event_type VARCHAR(50),
    data JSONB NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- JSON データを挿入
INSERT INTO events (event_type, data) VALUES
    ('user_signup', '{"email": "alice@example.com", "referrer": "google"}'),
    ('purchase', '{"product_id": 123, "amount": 99.99, "currency": "USD"}');

-- JSON をクエリ
SELECT * FROM events WHERE data->>'email' = 'alice@example.com';
SELECT * FROM events WHERE data->'amount' > '50';
SELECT * FROM events WHERE data @> '{"currency": "USD"}';

-- JSON 値を抽出
SELECT
    event_type,
    data->>'email' as email,
    (data->>'amount')::NUMERIC as amount
FROM events;

-- JSON 演算子
-- -> JSON オブジェクトフィールドを取得
-- ->> JSON オブジェクトフィールドをテキストとして取得
-- #> JSON オブジェクトをパスで取得
-- #>> JSON オブジェクトをパスでテキストとして取得
-- @> 含む
-- <@ に含まれる
-- ? キーを持つ
-- ?| いずれかのキーを持つ
-- ?& すべてのキーを持つ

-- JSON を更新
UPDATE events
SET data = jsonb_set(data, '{verified}', 'true')
WHERE event_type = 'user_signup';

-- JSON キーを削除
UPDATE events
SET data = data - 'temp_field'
WHERE id = 1;

-- JSON 集計
SELECT
    event_type,
    jsonb_agg(data) as all_events
FROM events
GROUP BY event_type;

配列:

-- 配列列
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    tags TEXT[],
    scores INTEGER[]
);

-- 配列を挿入
INSERT INTO users (name, tags, scores) VALUES
    ('Alice', ARRAY['admin', 'developer'], ARRAY[95, 87, 92]),
    ('Bob', ARRAY['user', 'viewer'], ARRAY[78, 85]);

-- 配列をクエリ
SELECT * FROM users WHERE 'admin' = ANY(tags);
SELECT * FROM users WHERE tags @> ARRAY['developer'];
SELECT * FROM users WHERE tags && ARRAY['admin', 'moderator']; -- 重複

-- 配列関数
SELECT
    name,
    array_length(tags, 1) as tag_count,
    array_agg(unnest(scores)) as all_scores
FROM users
GROUP BY name;

-- 配列を展開
SELECT
    name,
    unnest(tags) as tag
FROM users;

UUID:

-- UUID 拡張を有効化
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- UUID を使用して挿入
INSERT INTO users (email) VALUES ('alice@example.com');

-- UUID でクエリ
SELECT * FROM users WHERE id = 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11';

範囲型:

-- 整数範囲
CREATE TABLE reservations (
    id SERIAL PRIMARY KEY,
    room_id INTEGER,
    dates DATERANGE NOT NULL,
    EXCLUDE USING GIST (room_id WITH =, dates WITH &&)
);

-- 範囲を挿入
INSERT INTO reservations (room_id, dates) VALUES
    (101, '[2024-01-01,2024-01-05)');

-- 範囲をクエリ
SELECT * FROM reservations
WHERE dates @> '2024-01-03'::DATE;

SELECT * FROM reservations
WHERE dates && '[2024-01-02,2024-01-06)'::DATERANGE;

フルテキスト検索

tsvector と tsquery:

-- フルテキスト検索を使用したテーブルの作成
CREATE TABLE articles (
    id SERIAL PRIMARY KEY,
    title TEXT,
    content TEXT,
    search_vector tsvector
);

-- tsvector を生成
UPDATE articles
SET search_vector =
    setweight(to_tsvector('english', COALESCE(title, '')), 'A') ||
    setweight(to_tsvector('english', COALESCE(content, '')), 'B');

-- search_vector を自動的に更新するトリガー
CREATE FUNCTION articles_search_trigger() RETURNS TRIGGER AS $$
BEGIN
    NEW.search_vector :=
        setweight(to_tsvector('english', COALESCE(NEW.title, '')), 'A') ||
        setweight(to_tsvector('english', COALESCE(NEW.content, '')), 'B');
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER articles_search_update
BEFORE INSERT OR UPDATE ON articles
FOR EACH ROW EXECUTE FUNCTION articles_search_trigger();

-- 検索用 GIN インデックスを作成
CREATE INDEX articles_search_idx ON articles USING GIN(search_vector);

-- 検索クエリ
SELECT * FROM articles
WHERE search_vector @@ to_tsquery('english', 'postgresql & performance');

SELECT * FROM articles
WHERE search_vector @@ to_tsquery('english', 'database | sql');

-- ランク付けされた検索結果
SELECT
    id,
    title,
    ts_rank(search_vector, query) AS rank
FROM articles, to_tsquery('english', 'postgresql & optimization') query
WHERE search_vector @@ query
ORDER BY rank DESC;

-- ハイライト表示された検索結果
SELECT
    id,
    title,
    ts_headline('english', content, query) as highlighted
FROM articles, to_tsquery('english', 'postgresql') query
WHERE search_vector @@ query;

高度なインデックス

インデックス型:

-- B-tree (デフォルト、=, <, <=, >, >= 用)
CREATE INDEX idx_users_email ON users(email);

-- Hash (= のみ、高速だがフィーチャーが限定)
CREATE INDEX idx_users_email_hash ON users USING HASH(email);

-- GIN (フルテキスト検索、JSONB、配列用)
CREATE INDEX idx_events_data ON events USING GIN(data);
CREATE INDEX idx_users_tags ON users USING GIN(tags);

-- GiST (幾何データ、フルテキスト検索用)
CREATE INDEX idx_locations ON locations USING GIST(coordinates);

-- BRIN (自然な順序を持つ大規模テーブル用)
CREATE INDEX idx_logs_created ON logs USING BRIN(created_at);

-- 部分インデックス (フィルター付き)
CREATE INDEX idx_active_users ON users(email)
WHERE is_active = true AND deleted_at IS NULL;

-- 式インデックス
CREATE INDEX idx_users_lower_email ON users(LOWER(email));

-- 複数列インデックス
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at DESC);

-- カバリングインデックス (INCLUDE 句)
CREATE INDEX idx_users_email_covering ON users(email)
INCLUDE (name, created_at);

-- ユニークインデックス
CREATE UNIQUE INDEX idx_users_email_unique ON users(email);

-- 並行インデックス作成 (テーブルロックなし)
CREATE INDEX CONCURRENTLY idx_users_name ON users(name);

インデックス管理:

-- インデックスをリスト
SELECT
    schemaname,
    tablename,
    indexname,
    indexdef
FROM pg_indexes
WHERE tablename = 'users';

-- インデックスサイズ
SELECT
    indexname,
    pg_size_pretty(pg_relation_size(indexname::regclass)) as size
FROM pg_indexes
WHERE tablename = 'users';

-- 未使用のインデックス
SELECT
    schemaname || '.' || tablename AS table,
    indexname AS index,
    pg_size_pretty(pg_relation_size(i.indexrelid)) AS index_size,
    idx_scan as index_scans
FROM pg_stat_user_indexes ui
JOIN pg_index i ON ui.indexrelid = i.indexrelid
WHERE NOT indisunique
    AND idx_scan < 50
    AND pg_relation_size(i.indexrelid) > 5 * 8192
ORDER BY pg_relation_size(i.indexrelid) DESC;

-- インデックスを再構築
REINDEX INDEX idx_users_email;
REINDEX TABLE users;

-- インデックスを削除
DROP INDEX idx_users_email;
DROP INDEX CONCURRENTLY idx_users_email; -- テーブルロックなし

高度なクエリ

ウィンドウ関数:

-- 累積合計
SELECT
    order_date,
    amount,
    SUM(amount) OVER (ORDER BY order_date) as running_total
FROM orders;

-- 移動平均
SELECT
    date,
    value,
    AVG(value) OVER (
        ORDER BY date
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) as moving_avg_7_days
FROM metrics;

-- パーティション内の行番号
SELECT
    user_id,
    order_date,
    amount,
    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC) as rn
FROM orders;

-- ユーザーごとの最新注文を取得
SELECT * FROM (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) as rn
    FROM orders
) ranked
WHERE rn = 1;

-- ランク と dense_rank
SELECT
    name,
    score,
    RANK() OVER (ORDER BY score DESC) as rank,
    DENSE_RANK() OVER (ORDER BY score DESC) as dense_rank,
    PERCENT_RANK() OVER (ORDER BY score) as percentile
FROM students;

-- LAG と LEAD
SELECT
    date,
    value,
    LAG(value) OVER (ORDER BY date) as previous_value,
    LEAD(value) OVER (ORDER BY date) as next_value,
    value - LAG(value) OVER (ORDER BY date) as change
FROM metrics;

-- NTILE (バケットに分割)
SELECT
    name,
    salary,
    NTILE(4) OVER (ORDER BY salary DESC) as quartile
FROM employees;

再帰 CTE:

-- 従業員階層
WITH RECURSIVE employee_tree AS (
    -- ベースケース: トップレベルの従業員
    SELECT
        id,
        name,
        manager_id,
        1 as level,
        name::TEXT as path
    FROM employees
    WHERE manager_id IS NULL

    UNION ALL

    -- 再帰ケース
    SELECT
        e.id,
        e.name,
        e.manager_id,
        et.level + 1,
        et.path || ' -> ' || e.name
    FROM employees e
    INNER JOIN employee_tree et ON e.manager_id = et.id
)
SELECT * FROM employee_tree
ORDER BY path;

-- 階乗を計算
WITH RECURSIVE factorial(n, fact) AS (
    SELECT 1, 1
    UNION ALL
    SELECT n + 1, fact * (n + 1)
    FROM factorial
    WHERE n < 10
)
SELECT * FROM factorial;

-- シリーズ生成の代替案
WITH RECURSIVE numbers(n) AS (
    SELECT 1
    UNION ALL
    SELECT n + 1 FROM numbers WHERE n < 100
)
SELECT * FROM numbers;

LATERAL 結合:

-- ユーザーごとのトップ 3 注文を取得
SELECT
    u.name,
    o.order_date,
    o.total
FROM users u
CROSS JOIN LATERAL (
    SELECT order_date, total
    FROM orders
    WHERE user_id = u.id
    ORDER BY order_date DESC
    LIMIT 3
) o;

-- 複雑な集計
SELECT
    u.name,
    stats.order_count,
    stats.total_spent,
    stats.avg_order
FROM users u
LEFT JOIN LATERAL (
    SELECT
        COUNT(*) as order_count,
        SUM(total) as total_spent,
        AVG(total) as avg_order
    FROM orders
    WHERE user_id = u.id
) stats ON true;

パフォーマンス最適化

EXPLAIN と ANALYZE:

-- クエリプランを表示
EXPLAIN SELECT * FROM users WHERE email = 'alice@example.com';

-- 実際の実行を表示
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'alice@example.com';

-- より詳細な情報
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT u.name, COUNT(o.id)
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id, u.name;

-- 以下を確認:
-- - Seq Scan (大規模テーブルでは不適切)
-- - Index Scan (推奨)
-- - 高いコスト値
-- - 遅い実行時間
-- - 大量のバッファ読み取り

クエリ最適化:

-- インデックスを使用
CREATE INDEX idx_users_email ON users(email);

-- SELECT * を避ける
-- 不適切
SELECT * FROM users;

-- 推奨
SELECT id, name, email FROM users;

-- LIMIT を使用
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- WHERE 句の索引付き列で関数を避ける
-- 不適切 (インデックスが使われない)
SELECT * FROM users WHERE UPPER(email) = 'ALICE@EXAMPLE.COM';

-- 推奨 (インデックスが使われる)
SELECT * FROM users WHERE email = 'alice@example.com';

-- または式インデックスを使用
CREATE INDEX idx_users_email_upper ON users(UPPER(email));

-- COUNT の代わりに EXISTS を使用
-- 不適切
SELECT * FROM users WHERE (SELECT COUNT(*) FROM orders WHERE user_id = users.id) > 0;

-- 推奨
SELECT * FROM users WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = users.id);

-- 大規模テーブルをパーティション分割
CREATE TABLE orders_2024_01 PARTITION OF orders
FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

-- 適切な JOIN 型を使用
-- 両側がマッチする必要がある場合は INNER JOIN
-- 左側が必要な場合は LEFT JOIN を使用
-- RIGHT JOIN は避ける (LEFT JOIN の代わりに使用)

接続プーリング:

-- PgBouncer のような接続プーラーを使用
-- アプリケーション内で設定:
DATABASE_URL=postgresql://user:pass@pgbouncer:6432/mydb?pool_timeout=10&pool_size=20

トランザクションとロック

トランザクション分離レベル:

-- Read Committed (デフォルト)
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- Repeatable Read
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- Serializable
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 例
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;

ロック:

-- 行レベルロック
SELECT * FROM users WHERE id = 1 FOR UPDATE; -- 排他ロック
SELECT * FROM users WHERE id = 1 FOR SHARE;  -- 共有ロック

-- ロック済みの行をスキップ (キューに便利)
SELECT * FROM jobs
WHERE status = 'pending'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 10;

-- テーブルレベルロック
LOCK TABLE users IN EXCLUSIVE MODE;

-- アドバイザリロック (アプリケーションレベル)
SELECT pg_advisory_lock(123);
-- 処理を実行
SELECT pg_advisory_unlock(123);

-- ロックを確認
SELECT
    pid,
    usename,
    pg_blocking_pids(pid) as blocked_by,
    query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

データベース管理

バックアップとリストア:

# フルデータベースバックアップ
pg_dump -U postgres -d mydb -F c -f mydb_backup.dump

# リストア
pg_restore -U postgres -d mydb_restored -F c mydb_backup.dump

# 単一テーブルをバックアップ
pg_dump -U postgres -d mydb -t users -F c -f users_backup.dump

# プレーン SQL バックアップ
pg_dump -U postgres -d mydb -f mydb_backup.sql

# すべてのデータベースをバックアップ
pg_dumpall -U postgres -f all_databases.sql

# 継続的アーカイビング (ポイントインタイムリカバリ)
# postgresql.conf 内:
wal_level = replica
archive_mode = on
archive_command = 'cp %p /path/to/archive/%f'

VACUUM と ANALYZE:

-- 手動 vacuum
VACUUM users;
VACUUM FULL users; -- スペースを回復 (テーブルをロック)
VACUUM ANALYZE users; -- vacuum と統計を更新

-- Analyze (統計を更新)
ANALYZE users;

-- Autovacuum 設定 (postgresql.conf)
autovacuum = on
autovacuum_max_workers = 3
autovacuum_naptime = 1min

-- ブロートをチェック
SELECT
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as size,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename) - pg_relation_size(schemaname||'.'||tablename)) as bloat
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC;

監視:

-- 現在の接続
SELECT
    datname,
    count(*) as connections
FROM pg_stat_activity
GROUP BY datname;

-- 長時間実行中のクエリ
SELECT
    pid,
    now() - query_start as duration,
    query,
    state
FROM pg_stat_activity
WHERE state = 'active'
    AND now() - query_start > interval '5 minutes'
ORDER BY duration DESC;

-- クエリを強制終了
SELECT pg_cancel_backend(12345); -- SIGINT を送信
SELECT pg_terminate_backend(12345); -- SIGTERM を送信

-- データベースサイズ
SELECT
    datname,
    pg_size_pretty(pg_database_size(datname)) as size
FROM pg_database
ORDER BY pg_database_size(datname) DESC;

-- テーブルサイズ
SELECT
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as total_size,
    pg_size_pretty(pg_relation_size(schemaname||'.'||tablename)) as table_size,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename) - pg_relation_size(schemaname||'.'||tablename)) as indexes_size
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC
LIMIT 20;

-- キャッシュヒット率
SELECT
    sum(heap_blks_read) as heap_read,
    sum(heap_blks_hit) as heap_hit,
    sum(heap_blks_hit) / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0) as ratio
FROM pg_statio_user_tables;

レプリケーション:

-- プライマリサーバー (postgresql.conf)
wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB

-- レプリケーションユーザーを作成
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'password';

-- レプリカサーバー (recovery.conf または postgresql.auto.conf)
primary_conninfo = 'host=primary.example.com port=5432 user=replicator password=password'
hot_standby = on

-- レプリケーション状態をチェック (プライマリ上)
SELECT
    client_addr,
    state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    sync_state
FROM pg_stat_replication;

-- レプリケーション遅延
SELECT
    now() - pg_last_xact_replay_timestamp() AS replication_lag;

ベストプラクティス

1. 適切なデータ型を使用

-- 特定の型を使用
-- 不適切: すべてに VARCHAR(255) を使用
-- 推奨: 適切な型を使用
email VARCHAR(255)
age INTEGER
price NUMERIC(10,2)
is_active BOOLEAN
created_at TIMESTAMP WITH TIME ZONE

2. 制約を追加

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    age INTEGER CHECK (age >= 0 AND age <= 150),
    status VARCHAR(20) DEFAULT 'active' CHECK (status IN ('active', 'inactive', 'banned'))
);

3. トランザクションを使用

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

4. 適切にインデックスを設定

-- 外部キーにインデックスを設定
CREATE INDEX idx_orders_user_id ON orders(user_id);

-- WHERE、JOIN、ORDER BY で使用される列にインデックスを設定
CREATE INDEX idx_users_created_at ON users(created_at);

-- 過度なインデックスは避ける (書き込みを遅くする)

5. 定期的なメンテナンス

-- 定期的に VACUUM ANALYZE をスケジュール
-- 遅いクエリを監視
-- ブロートをチェック
-- 統計を更新

アプローチ

PostgreSQL で作業する場合:

  1. スキーマを慎重に設計: 正規化、制約の使用、インデックスの計画
  2. EXPLAIN ANALYZE を使用: クエリパフォーマンスを理解
  3. 本番を監視: 遅いクエリ、接続数を追跡
  4. 定期的にバックアップ: ポイントインタイムリカバリを備えた自動バックアップ
  5. 接続プーリングを使用: PgBouncer でリソース使用率を改善
  6. PostgreSQL フィーチャーを活用: JSONB、フルテキスト検索、配列
  7. レプリケーションを設定: 高可用性と読み取りスケーリング
  8. 定期的なメンテナンス: VACUUM、ANALYZE、インデックス再構築

常にスケール時にパフォーマンスが高く、信頼性があり、保守しやすい PostgreSQL データベースを設計してください。

ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
personamanagmentlayer
リポジトリ
personamanagmentlayer/pcl
ライセンス
Apache-2.0
最終更新
不明

Source: https://github.com/personamanagmentlayer/pcl / ライセンス: Apache-2.0

関連スキル

汎用その他⭐ リポ 1,982

superfluid

Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード:Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool(member/distributor)、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper

by LeoYeAI
汎用その他⭐ リポ 100

civ-finish-quotes

実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。

by huxiuhan
汎用その他⭐ リポ 1,110

nookplot

Base(Ethereum L2)上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。

by BankrBot
汎用その他⭐ リポ 59

web3-polymarket

Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。

by elophanto
汎用その他⭐ リポ 52

ethskills

Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格(ERC-20、ERC-721、ERC-4626など)、Layer 2ネットワーク(Base、Arbitrum、Optimism、zkSync、Polygon)、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化(EIPライフサイクル、フォーク追跡、今後の変更予定)といったトピックを含みます。

by jiayaoqijia
汎用その他⭐ リポ 44

xxyy-trade

このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。

by Jimmy-Holiday
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: personamanagmentlayer · personamanagmentlayer/pcl · ライセンス: Apache-2.0