hive-intelligence 1.1.4 → 1.3.0

package/agent-skills/packs/hive-defi-research/references/workflow.md

@@ -1,41 +0,0 @@
-# DeFi Research Workflow
-
-Use this reference for protocol TVL, fees, revenue, yields, stablecoins,
-bridges, and chain-level DeFi metrics.
-
-## Required identifiers
-
-- Protocol slug or chain.
-- Optional: time window, metric type, yield pool, stablecoin, or bridge.
-
-Ask for a protocol slug or choose a provider-supported slug only when the user
-clearly named the protocol.
-
-## Tool selection order
-
-1. Resolve protocol or chain.
-2. Use `search_tools` for protocol, TVL, fee/revenue, yield, stablecoin, bridge,
-   or chain metrics.
-3. Inspect schemas before invocation.
-4. Pull only the metrics needed for the question.
-5. For comparisons, normalize metric type and timestamp.
-
-## Bounded calls
-
-- Limit protocol lists and yield pools.
-- Avoid comparing TVL snapshots from different dates without caveat.
-- Mark missing fee/yield/stablecoin metrics instead of omitting them.
-
-## Report template
-
-- Summary: protocol or chain DeFi read.
-- Calls made: endpoints, protocol/chain, metric filters.
-- Evidence: TVL, fees/revenue, yield, bridge/stablecoin metrics, freshness.
-- Caveats: unavailable metrics, stale snapshots, methodology differences.
-- Next action: compare peers, inspect yield pool, or add token/pool diligence.
-
-## Gotchas
-
-- TVL, revenue, and fees answer different questions.
-- High APY without liquidity/risk context is not a recommendation.
-- Provider methodology can differ across chains and protocols.

package/agent-skills/packs/hive-dex-pool-analysis/references/workflow.md

@@ -1,42 +0,0 @@
-# DEX And Pool Analysis Workflow
-
-Use this reference for pool, pair, liquidity, swap, trade, OHLCV, and DEX-flow
-questions.
-
-## Required identifiers
-
-- Chain/network.
-- Pair/pool address, token contract, or both token sides.
-- Optional: DEX name, time window, candle interval, trade direction.
-
-If the user gives only one token, search candidate pools and prefer the pool
-most relevant to liquidity/volume.
-
-## Tool selection order
-
-1. Resolve chain and pool/pair/token identifiers.
-2. Use `search_tools` for pair search, pool info, liquidity, trades, OHLCV, and
-   trending pool tools.
-3. Inspect schemas before invocation.
-4. Start with pool/pair metadata and liquidity.
-5. Add trades/OHLCV for flow or trend questions.
-
-## Bounded calls
-
-- Limit trade lists and candle counts.
-- Do not infer token-wide liquidity from one pool without saying so.
-- Keep pool-level and token-level metrics separate.
-
-## Report template
-
-- Summary: pool/liquidity/trade-flow read.
-- Calls made: endpoints, chain, pair/pool/token identifiers.
-- Evidence: liquidity, volume, trades, OHLCV, provider/freshness/runtime status.
-- Caveats: missing pools, stale candles, thin liquidity, degraded provider.
-- Next action: compare pools, widen time window, or add token diligence.
-
-## Gotchas
-
-- Same token pair can have multiple pools with different fee tiers and liquidity.
-- Trending pools are not necessarily safe or liquid.
-- OHLCV data can be unavailable even when pair metadata exists.

package/agent-skills/packs/hive-market-research/references/workflow.md

@@ -1,47 +0,0 @@
-# Market Research Workflow
-
-Use this reference for live prices, venue data, order books, OHLC, derivatives,
-and liquidity context.
-
-## Required identifiers
-
-- Asset: token id, symbol, or contract address.
-- Quote currency, usually `usd`, when asking for prices.
-- Venue/exchange id when the request is order-book, ticker, or derivatives
-  specific.
-- Time window and candle interval for OHLC or trend questions.
-
-Ask for missing venue or chain details when the choice changes the answer. For
-general price questions, choose a broad market-data toolset and state the source.
-
-## Tool selection order
-
-1. Use `search_tools` with the asset, venue, and market-data intent.
-2. Inspect the exact schema with `get_api_endpoint_schema`.
-3. For spot context, prefer price, ticker, and liquidity tools.
-4. For chart context, prefer OHLC/OHLCV tools with explicit interval and limit.
-5. For venue context, use exchange/order-book tools only after venue resolution.
-6. For derivatives, include funding/open-interest context when available.
-
-## Bounded calls
-
-- Use small limits for candles and order-book depth unless the user asks for
-  more.
-- Avoid fetching all exchanges or all markets for a single-asset question.
-- Do not compare data from different timestamps without saying so.
-
-## Report template
-
-- Summary: current market read in one sentence.
-- Calls made: task toolset and exact endpoints.
-- Evidence: provider, venue, identifiers, freshness, and key metrics.
-- Caveats: stale data, missing venue, fallback, degraded provider, or thin
-  liquidity.
-- Next action: deeper venue, time-window, or liquidity drilldown if needed.
-
-## Gotchas
-
-- Symbols collide. Prefer contract addresses, CoinGecko ids, or venue ids.
-- Order-book liquidity is venue-specific; do not generalize it to the full
-  market.
-- Market data can be fresh but still incomplete if a venue/provider is degraded.

package/agent-skills/packs/hive-network-infrastructure/references/workflow.md

@@ -1,41 +0,0 @@
-# Network Infrastructure Workflow
-
-Use this reference for gas, blocks, receipts, logs, transaction status,
-supported networks, fee data, and RPC diagnostics.
-
-## Required identifiers
-
-- Chain/network.
-- Optional: transaction hash, block number/hash, contract address, log topic,
-  account address, or time window.
-
-Ask for exact chain and transaction/block identifiers before status checks.
-
-## Tool selection order
-
-1. Resolve chain/network id.
-2. Use `search_tools` for gas, block, transaction, receipt, log, supported
-   network, or RPC diagnostic tools.
-3. Inspect schemas before invocation.
-4. Use current-state tools for gas and block questions.
-5. Use transaction/receipt/log tools only with exact identifiers.
-
-## Bounded calls
-
-- Bound log queries by block range and topics.
-- Do not run broad chain scans for a single transaction question.
-- Retry transient RPC failures once when appropriate.
-
-## Report template
-
-- Summary: network or transaction state.
-- Calls made: endpoints, chain, identifiers, filters.
-- Evidence: block/slot, gas/fee, receipt/log/status, freshness/runtime status.
-- Caveats: provider mismatch, stale block, rate limit, incomplete logs.
-- Next action: narrower log filter, alternate provider, or retry.
-
-## Gotchas
-
-- A transaction hash is not globally unique without chain context.
-- Logs require bounded block ranges.
-- HTTP health does not prove provider data freshness.

package/agent-skills/packs/hive-nft-research/references/workflow.md

@@ -1,42 +0,0 @@
-# NFT Research Workflow
-
-Use this reference for NFT collections, ownership, metadata, floors, sales,
-rarity, spam checks, and Solana assets.
-
-## Required identifiers
-
-- Chain/network.
-- Collection contract, token id, asset id, wallet address, or mint.
-- Optional: marketplace, time window, trait filter, or owner.
-
-Ask for chain and contract/asset identifiers when the user gives only a
-collection name.
-
-## Tool selection order
-
-1. Resolve collection, token, wallet, or asset id.
-2. Use `search_tools` for metadata, owners, floor, sales, rarity, spam, and
-   Solana DAS asset tools.
-3. Inspect schemas before invocation.
-4. Start with metadata/identity.
-5. Add floor/sales or owner/rarity only when relevant.
-
-## Bounded calls
-
-- Limit owner and sales lists.
-- Keep collection-level and token-level evidence separate.
-- Do not treat one marketplace floor as the entire market without caveat.
-
-## Report template
-
-- Summary: collection/token ownership or market read.
-- Calls made: endpoints, chain, contract/asset/token identifiers.
-- Evidence: metadata, owner/floor/sales/rarity/spam, freshness/runtime status.
-- Caveats: marketplace coverage, stale floor, missing metadata, degraded data.
-- Next action: trait drilldown, ownership verification, or market comparison.
-
-## Gotchas
-
-- NFT metadata can be mutable or stale.
-- Spam checks can lag new collections.
-- Solana assets often require Solana-native DAS identifiers.

package/agent-skills/packs/hive-prediction-markets/references/workflow.md

@@ -1,42 +0,0 @@
-# Prediction Markets Workflow
-
-Use this reference for prediction market discovery, events, outcomes, prices,
-liquidity, stats, traders, holders, and trades.
-
-## Required identifiers
-
-- Topic/search query, event id, market id, token id, or trader address.
-- Optional: status filter, limit, date range, outcome, or liquidity threshold.
-
-If the user starts with a topic, search candidates first and ask for selection
-when multiple markets match.
-
-## Tool selection order
-
-1. Use `search_tools` for prediction market search, event, market, stats,
-   holders, traders, or trade tools.
-2. Inspect schemas before invocation.
-3. Search events/markets for topic prompts.
-4. Resolve exact market/event/token ids before stats, holders, or trades.
-5. Add liquidity/volume and freshness context before interpreting prices.
-
-## Bounded calls
-
-- Use small search limits and page through only when needed.
-- Do not fetch all trades or holders unless the user asks for a deep dive.
-- Keep outcome token prices separate from event-level interpretation.
-
-## Report template
-
-- Summary: market/event read and top outcomes.
-- Calls made: endpoints, market/event/token/trader identifiers.
-- Evidence: price, liquidity, volume, outcomes, holders/traders, freshness.
-- Caveats: market probability is not truth, thin liquidity, stale/incomplete
-  stats, candidate ambiguity.
-- Next action: inspect selected market, holders, trades, or related events.
-
-## Gotchas
-
-- Market prices reflect trading/liquidity, not verified probability.
-- Similar markets can have different resolution criteria.
-- Event-level and outcome-token-level data are not interchangeable.

package/agent-skills/packs/hive-security-risk/references/workflow.md

@@ -1,46 +0,0 @@
-# Security Risk Workflow
-
-Use this reference for token, address, approval, dApp, phishing, contract, and
-transaction simulation risk.
-
-## Required identifiers
-
-- Chain/network.
-- One or more of: token contract, wallet address, spender address, dApp URL,
-  contract address, or transaction payload.
-
-Ask for missing chain and actor details before approval or simulation checks.
-Never invent a spender, owner, calldata, or URL.
-
-## Tool selection order
-
-1. Identify the risk object: token, address, approval, dApp, contract, or
-   transaction.
-2. Use `search_tools` for the matching security/risk endpoints.
-3. Inspect schemas before invocation.
-4. Run the narrowest risk check first.
-5. Add simulation or approval analysis only when the required payload/owner
-   details exist.
-
-## Bounded calls
-
-- Keep risk checks scoped to the provided contract, address, or payload.
-- Avoid broad scans unless the user explicitly asks for an audit.
-- Use severity and evidence rather than unsupported certainty.
-
-## Report template
-
-- Summary: risk level and safest recommendation.
-- Calls made: endpoints, chain, risk object, identifiers.
-- Evidence: flags, simulation results, approval exposure, source/freshness.
-- Caveats: missing payload, incomplete provider coverage, degraded/rate-limited
-  provider.
-- Next action: revoke approval, avoid signing, retry simulation, or provide
-  missing payload.
-
-## Gotchas
-
-- A token can pass metadata checks and still be risky.
-- `plan_required` means the tool exists but cannot run under current upstream
-  credentials.
-- Do not provide signing instructions when a critical risk is unresolved.

package/agent-skills/packs/hive-solana-analysis/references/workflow.md

@@ -1,42 +0,0 @@
-# Solana Analysis Workflow
-
-Use this reference for Solana wallets, SPL accounts, DAS assets, parsed
-transactions, priority fees, launch data, mints, and Solana NFTs.
-
-## Required identifiers
-
-- Solana wallet, mint, token account, asset id, program id, or transaction
-  signature.
-- Optional: slot/time window, owner, collection, or token filter.
-
-Do not apply EVM address, chain id, or approval assumptions to Solana requests.
-
-## Tool selection order
-
-1. Classify the identifier: wallet, mint, token account, asset, program, or
-   transaction.
-2. Use `search_tools` for Solana wallet, SPL token, DAS, parsed transaction,
-   priority fee, or launch-data tools.
-3. Inspect schemas before invocation.
-4. Use wallet paths for owner/balance/history questions.
-5. Use mint/asset paths for token/NFT questions.
-
-## Bounded calls
-
-- Limit parsed history, asset lists, and token accounts.
-- Include slot or fetched time where available.
-- Avoid multi-provider mixing without source labels.
-
-## Report template
-
-- Summary: Solana-specific read.
-- Calls made: endpoints, identifiers, filters.
-- Evidence: balances/assets/transactions/fees, source/freshness/runtime status.
-- Caveats: missing key, rate limit, DAS coverage, stale slot, truncated history.
-- Next action: transaction drilldown, asset verification, or risk check.
-
-## Gotchas
-
-- Wallets, mints, token accounts, and asset ids are different identifiers.
-- Priority fee estimates are time-sensitive.
-- Parsed transaction coverage can vary by provider and transaction type.

package/agent-skills/packs/hive-token-diligence/references/workflow.md

@@ -1,45 +0,0 @@
-# Token Diligence Workflow
-
-Use this reference when a token needs metadata, liquidity, holder, enrichment,
-and risk evidence.
-
-## Required identifiers
-
-- Chain/network.
-- Exact token contract or provider-specific token id.
-- Optional: quote token, pool address, wallet holder, or time window.
-
-If the user gives only a ticker or name, resolve the exact contract before
-execution. Do not assume a ticker maps to one asset.
-
-## Tool selection order
-
-1. Resolve chain and contract from the prompt or ask for them.
-2. Use `search_tools` for token metadata, market, holder, DEX liquidity, and
-   risk capabilities.
-3. Inspect schemas before calling each endpoint.
-4. Start with metadata and market/liquidity checks.
-5. Add holder distribution and enrichment only when the user needs depth.
-6. Add security/risk checks when the user asks whether to trade, approve, or
-   trust the token.
-
-## Bounded calls
-
-- Limit holder lists and pool searches.
-- Separate token-level data from pool-level data.
-- Preserve provider-specific risk fields when they drive the conclusion.
-
-## Report template
-
-- Summary: token identity and overall diligence posture.
-- Calls made: endpoints and identifiers.
-- Evidence: metadata, liquidity, holders, risk/enrichment, source/freshness.
-- Caveats: missing provider keys, plan gates, stale liquidity, unresolved
-  contract ambiguity.
-- Next action: security drilldown, liquidity venue check, or holder analysis.
-
-## Gotchas
-
-- A verified name/logo is not proof of safety.
-- High FDV or high volume without pool depth can still be risky.
-- Missing enrichment is not the same as a clean risk result.

package/agent-skills/packs/hive-wallet-investigation/references/workflow.md

@@ -1,45 +0,0 @@
-# Wallet Investigation Workflow
-
-Use this reference for wallet balances, transfers, PnL, NFTs, DeFi positions,
-and notable activity.
-
-## Required identifiers
-
-- Wallet address.
-- Chain/network, unless the user explicitly asks for multi-chain.
-- Optional: time window, asset filter, counterparty, protocol, or NFT
-  collection.
-
-Ask for chain when an EVM address appears without context. For Solana wallets,
-use the Solana skill when the request is Solana-specific.
-
-## Tool selection order
-
-1. Validate the identifier shape for the requested chain.
-2. Use `search_tools` for wallet balance, native balance, transfer, NFT, DeFi,
-   and PnL tools.
-3. Inspect schemas before endpoint invocation.
-4. Start with balances/native balance.
-5. Add transfers for activity questions.
-6. Add NFTs, DeFi positions, or PnL only when relevant.
-
-## Bounded calls
-
-- Use explicit `limit`, `page`, `per_page`, or time filters for transfers.
-- Do not fetch full history for a quick portfolio read.
-- Avoid mixing chains unless the user requested multi-chain analysis.
-
-## Report template
-
-- Summary: wallet posture and notable finding.
-- Calls made: endpoints, chain, wallet, filters.
-- Evidence: balances, transfers, exposure, provider/freshness/runtime status.
-- Caveats: missing chains, truncated history, unavailable enrichment, degraded
-  providers.
-- Next action: chain expansion, transfer drilldown, risk check, or PnL detail.
-
-## Gotchas
-
-- Wallet labels and owner identity are not guaranteed.
-- Token balances can include spam or illiquid assets.
-- Absence of DeFi/NFT data may reflect provider coverage, not true absence.