hive-intelligence 1.1.4 → 1.4.0

package/agent-skills/packs/hive-security-risk/SKILL.md

@@ -1,42 +1,133 @@
 ---
 name: hive-security-risk
-description: Use this skill before advising on swaps, approvals, signatures, dApps, contracts, URLs, or transaction payloads where token, address, approval, phishing, or simulation risk matters. Report severity, evidence, and remediation instead of guessing.
+description: Use this skill before the user signs, approves, swaps, connects a wallet to a dApp, or touches an unknown contract, URL, or transaction payload — any "should I sign/approve/ape/connect" moment, even when the user only implies the transaction. Runs token, address, approval, phishing, and simulation risk checks and reports severity, evidence, and remediation instead of guessing. For research-style "is this token worth a look" questions use hive-token-diligence.
 license: MIT
 metadata:
   package: "@hiveintelligence/agent-skills"
   category: "security"
   requires_network: "true"
-version: 1.0.0
+version: 1.4.0
 ---
 
 # hive-security-risk — Security Risk
 
-Use this skill before explaining swaps, approvals, signatures, dApps, or
-unknown contracts.
+Assess transaction-time risk — tokens, addresses, approvals, dApps, phishing,
+simulations — and report severity, evidence, and remediation. Wrong "looks
+fine" answers here cost users real money, so never conclude safety without a
+tool-backed check.
 
-## Task toolset
+## Task toolset and identifiers
 
-Use `security_risk`.
+Toolset: `security_risk`. Read `hive://toolsets/security_risk` before
+execution; it is authoritative for the current output schema, material-call
+budget, phases, fallback condition, and stop conditions.
 
-Required identifiers: chain and token contract, wallet address, spender,
-dApp URL, or transaction payload depending on the request.
+Required identifiers depend on the risk object: chain plus token contract,
+wallet address, spender, dApp URL, or transaction payload. Never invent a
+spender, owner, calldata, or URL — ask for whatever is missing.
+
+Before choosing endpoints, select exactly one matching entry from the exact
+workflow's routes[]. Follow its ordered steps, use a fallback only under that
+step's published condition, stop at four material calls, and preserve the
+selected route_id in the typed result. The broad coverageCatalog is discovery
+coverage, not an execution plan.
 
 ## Procedure
 
-Read `references/workflow.md` when the request involves signing, approvals,
-dApps, simulations, or any risk report that needs severity and remediation.
+1. Identify the risk object: token, address, approval, dApp, contract, or
+   transaction payload.
+2. Call `search_tools` for the matching security/risk capabilities.
+3. Call `get_api_endpoint_schema` for each endpoint before calling it.
+4. Run the narrowest risk check first; add simulation or approval analysis
+   only when the required payload/owner details exist.
+5. For Solana, send only the base64 serialized transaction to the GoPlus
+   pre-execution check. Never ask for or forward signing secrets.
+6. Report severity, evidence, and remediation steps.
+7. Do not provide signing guidance while a critical risk is unresolved.
+
+## 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.
+
+## Worked example
+
+User: "A dApp wants unlimited approval of my USDC
+(0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48) on Ethereum to spender
+0x… — should I sign?"
+
+1. Collect chain, token contract, owner wallet, and spender — all four are
+   required before any approval analysis.
+2. `search_tools` → `{"query": "token approval allowance spender risk ethereum", "limit": 5}`
+3. `get_api_endpoint_schema` for the approval/address-risk endpoints returned,
+   then `invoke_api_endpoint` with schema-valid arguments.
+4. Report severity and remediation (for example "revoke, or approve a bounded
+   amount") using the template below. If the spender flags critical risk, say
+   "do not sign" plainly.
+
+## Report template
+
+```markdown
+## Summary
+[Risk level and the safest recommendation in one or two sentences.]
+
+## Calls made
+- Toolset: security_risk
+- Endpoint(s): [exact endpoint names]
+- Identifiers: [chain, risk object, addresses, payload]
 
-1. Identify the asset, address, approval, dApp, or transaction payload.
-2. Run token/address/approval/phishing/simulation checks as appropriate.
-3. Report severity, evidence, and remediation steps.
-4. Do not provide signing guidance when critical risk is unresolved.
+## Evidence
+- Flags: [provider risk flags with the fields that triggered them]
+- Simulation/approval results: [if run]
+- Provenance: [provider, fetched_at, observed_at/cache_age_ms, runtime status per call]
 
-## Example
+## Caveats
+[Missing payload, incomplete provider coverage, degraded/rate-limited provider.]
 
-For an ERC-20 approval concern, collect chain, token contract, owner wallet, and
-spender before selecting the approval or allowance tool.
+## 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 — say the check is unavailable, never that the asset is safe.
+- Do not provide signing instructions when a critical risk is unresolved.
+
+## Evidence receipt (required)
+
+End every Hive-backed answer with a compact receipt built from the `_hive`
+object on each material tool response:
+
+- `provider`, `tool`, `fetched_at`, `observed_at`, `cache_age_ms`, and `runtime_status`
+- `receipt_id`, `receipt_version`, server/build version, and SHA-256 input/result
+  digests when present (self-checks, not signatures)
+- `source`, `cache_status`, `truncated`, and any warnings
+- canonical chain/entity identifiers plus block, slot, transaction, or query ids
+  present in provider data
+- material provider disagreements and how they were handled
+- checks that were unavailable, gated, stale, truncated, or intentionally not run
+- a `claims[]` citation from each material statement to exact receipt IDs
+- one `coverage[]` entry for every canonical evidence phase, with each gap explained
+
+Never turn missing evidence into a clean result, silently merge conflicting
+provider values, or omit a degraded/fallback call from the receipt.
+`observed_at` is Hive's first-observation/original cache-population time, and
+`cache_age_ms: 0` only means newly retrieved by Hive. Use provider time, block,
+slot, transaction, or candle close for source recency; if absent, mark it
+unknown. Run `validate_task_result` before presenting the typed workflow result;
+it checks structure but cannot authenticate an invented receipt.
 
 ## Runtime status handling
 
-`rate_limited` and `degraded` can be retried with backoff. `plan_required` means
-the tool exists but the upstream account cannot execute it right now.
+`rate_limited` and `degraded` can be retried with backoff. `plan_required`
+means the tool exists but the upstream account cannot execute it right now. A
+blocked check is a caveat in the report, not a clean bill of health.
+
+## Hand-offs
+
+- Broader "is this token a good buy" research → `hive-token-diligence`.
+- Wallet-wide activity review → `hive-wallet-investigation`.
+- Solana mint or transaction safety → `hive-solana-analysis`.

package/agent-skills/packs/hive-security-risk/evals/evals.json

@@ -4,12 +4,14 @@
     {
       "id": 1,
       "prompt": "Is it safe to approve this spender for my ERC-20 token?",
-      "expected_output": "Uses security_risk, asks for chain/token/owner/spender if missing, checks approval risk, and avoids signing guidance until risk is resolved.",
+      "expected_output": "Uses security_risk, asks for chain/token/owner/spender if missing, checks approval risk, avoids signing guidance until risk is resolved, and ends with a runtime evidence receipt.",
       "files": [],
       "assertions": [
         "Chooses security_risk.",
+        "Selects approval_risk for this intent and uses only its conditional fallback when required.",
         "Requests missing approval identifiers.",
-        "Does not tell the user to sign while risk is unresolved."
+        "Does not tell the user to sign while risk is unresolved.",
+        "Includes receipt ids and any unavailable checks."
       ]
     },
     {

package/agent-skills/packs/hive-security-risk/evals/triggers.json

@@ -0,0 +1,50 @@
+[
+  {
+    "query": "a dapp wants unlimited approval of my USDC to spender 0x…, should i sign?",
+    "should_trigger": true
+  },
+  {
+    "query": "is mintify-airdrop dot xyz legit? i was about to connect my wallet",
+    "should_trigger": true
+  },
+  {
+    "query": "i got this transaction payload from a swap site, simulate it before i send it",
+    "should_trigger": true
+  },
+  {
+    "query": "is the token at 0x6982508145454Ce325dDbE47a25d4ec3d2311933 a honeypot?",
+    "should_trigger": true
+  },
+  {
+    "query": "check if this address that messaged me is flagged for scams before i reply",
+    "should_trigger": true
+  },
+  {
+    "query": "which of my open approvals are risky and should be revoked?",
+    "should_trigger": true
+  },
+  {
+    "query": "is PEPE worth buying? run diligence on holders and liquidity",
+    "should_trigger": false
+  },
+  {
+    "query": "what does this wallet hold across defi",
+    "should_trigger": false
+  },
+  {
+    "query": "audit my solidity contract source code for reentrancy bugs",
+    "should_trigger": false
+  },
+  {
+    "query": "explain how approval phishing scams work conceptually",
+    "should_trigger": false
+  },
+  {
+    "query": "whats the floor price of this nft collection",
+    "should_trigger": false
+  },
+  {
+    "query": "compare aave vs compound tvl",
+    "should_trigger": false
+  }
+]

package/agent-skills/packs/hive-solana-analysis/SKILL.md

@@ -1,42 +1,138 @@
 ---
 name: hive-solana-analysis
-description: Use this skill for Solana-specific analysis covering wallets, SPL token accounts, DAS assets, parsed transactions, priority fees, launch data, mints, or Solana NFT assets. Prefer Solana-native identifiers and providers over EVM assumptions.
+description: Use this skill for anything Solana-native — wallets, mints, SPL token accounts, DAS assets, parsed transactions, priority fees, pump.fun launches, Solana NFTs, Solana token risk. Prefer it over EVM-shaped skills whenever the identifier is a base58 address, mint, or transaction signature, even if the user never says "Solana". Uses Solana-native identifiers and providers instead of EVM assumptions.
 license: MIT
 metadata:
   package: "@hiveintelligence/agent-skills"
   category: "solana"
   requires_network: "true"
-version: 1.0.0
+version: 1.4.0
 ---
 
 # hive-solana-analysis — Solana Analysis
 
-Use this skill for Solana wallets, mints, SPL accounts, DAS assets, parsed
-transactions, priority fees, or Solana token safety questions.
+Analyze Solana wallets, mints, SPL accounts, DAS assets, parsed transactions,
+priority fees, and launch data with Solana-native tools — never EVM
+assumptions.
 
-## Task toolset
+## Task toolset and identifiers
 
-Use `solana_analysis`.
+Toolset: `solana_analysis`. Read `hive://toolsets/solana_analysis` before
+execution; it is authoritative for the current output schema, material-call
+budget, phases, fallback condition, and stop conditions.
 
-Required identifiers: Solana wallet, mint, asset id, or transaction signature.
+- Required: Solana wallet, mint, token account, asset id, program id, or
+  transaction signature.
+- Optional: slot/time window, owner, collection, token filter.
 
-## Procedure
+Wallets, mints, token accounts, and asset ids are different identifier types —
+classify before selecting tools. Do not apply EVM address, chain-id, or
+approval assumptions to Solana requests.
+
+Before choosing endpoints, select exactly one matching entry from the exact
+workflow's routes[]. Follow its ordered steps, use a fallback only under that
+step's published condition, stop at four material calls, and preserve the
+selected route_id in the typed result. The broad coverageCatalog is discovery
+coverage, not an execution plan.
 
-Read `references/workflow.md` when the request needs Solana-native identifier
-handling, DAS/SPL routing, priority-fee context, or a structured Solana report.
+## Procedure
 
-1. Confirm the identifier type: wallet, mint, asset id, program id, or
+1. Classify the identifier: wallet, mint, token account, asset, program, or
    transaction signature.
-2. Use Solana-native tools instead of EVM assumptions.
-3. For wallets, combine balances, token accounts, assets, and parsed history.
-4. For execution context, include slot/priority fee/freshness.
+2. Call `search_tools` for Solana wallet, SPL token, DAS, parsed-transaction,
+   priority-fee, or launch-data capabilities.
+3. Call `get_api_endpoint_schema` for each endpoint before calling it.
+4. Use wallet paths for owner/balance/history questions; mint/asset paths for
+   token/NFT questions.
+5. Prefer Helius `getTransactionsForAddress` or `getTransfersByAddress` for
+   current address history. Treat Enhanced Transactions parsers as deprecated
+   compatibility surfaces.
+6. For a prepared serialized transaction, run the GoPlus Solana pre-execution
+   check before signing guidance; never request a private key or seed phrase.
+7. For execution context, include slot, priority fee, and freshness.
+
+## Bounded calls
+
+- Limit parsed history, asset lists, and token accounts.
+- Include slot or fetched time where available.
+- Avoid multi-provider mixing without source labels.
+
+## Worked example
+
+User: "This pump.fun token is mooning — can you check the mint
+<base58 mint> for safety and who holds it?"
+
+1. Classify: a base58 mint → token/security and asset paths, not wallet paths.
+2. `search_tools` → `{"query": "solana mint token security holders launch data", "limit": 5}`
+3. `get_api_endpoint_schema` for the mint-security and holder endpoints
+   returned, then `invoke_api_endpoint` with schema-valid arguments.
+4. Report safety flags, holder concentration, and launch context with slot or
+   provider time, `observed_at`/`cache_age_ms`, and Hive retrieval time
+   (`fetched_at`).
+
+If the user gives a wallet instead, use owner/balance/token-account paths and
+add parsed history only for activity questions.
+
+## Report template
+
+```markdown
+## Summary
+[Solana-specific read in one or two sentences.]
 
-## Example
+## Calls made
+- Toolset: solana_analysis
+- Endpoint(s): [exact endpoint names]
+- Identifiers: [wallet/mint/asset/signature, filters]
 
-If the user gives a mint, use token/security or asset search paths. If the user
-gives a wallet, use owner/balance paths.
+## Evidence
+- Balances/assets/transactions/fees: [as relevant]
+- Provenance: [provider, slot, fetched_at, observed_at/cache_age_ms, runtime status per call]
+
+## Caveats
+[Missing key, rate limit, DAS coverage, stale slot, truncated history.]
+
+## Next action
+[Transaction drilldown, asset verification, or risk check — only if needed.]
+```
+
+## 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.
+
+## Evidence receipt (required)
+
+End every Hive-backed answer with a compact receipt built from the `_hive`
+object on each material tool response:
+
+- `provider`, `tool`, `fetched_at`, `observed_at`, `cache_age_ms`, and `runtime_status`
+- `receipt_id`, `receipt_version`, server/build version, and SHA-256 input/result
+  digests when present (self-checks, not signatures)
+- `source`, `cache_status`, `truncated`, and any warnings
+- canonical chain/entity identifiers plus block, slot, transaction, or query ids
+  present in provider data
+- material provider disagreements and how they were handled
+- checks that were unavailable, gated, stale, truncated, or intentionally not run
+- a `claims[]` citation from each material statement to exact receipt IDs
+- one `coverage[]` entry for every canonical evidence phase, with each gap explained
+
+Never turn missing evidence into a clean result, silently merge conflicting
+provider values, or omit a degraded/fallback call from the receipt.
+`observed_at` is Hive's first-observation/original cache-population time, and
+`cache_age_ms: 0` only means newly retrieved by Hive. Use provider time, block,
+slot, transaction, or candle close for source recency; if absent, mark it
+unknown. Run `validate_task_result` before presenting the typed workflow result;
+it checks structure but cannot authenticate an invented receipt.
 
 ## Runtime status handling
 
-Classify Helius or Solana provider issues as `missing_key`, `rate_limited`,
-`degraded`, or `failing`. Ask for a retry only when the status is transient.
+Classify Helius or other Solana provider issues as `invalid_input`,
+`missing_key`, `plan_required`, `rate_limited`, `degraded`, or `failing`. Ask for a retry only when the status
+is transient.
+
+## Hand-offs
+
+- EVM wallets and tokens → `hive-wallet-investigation` / `hive-token-diligence`.
+- EVM NFT collections → `hive-nft-research`.
+- Cross-chain market prices → `hive-market-research`.

package/agent-skills/packs/hive-solana-analysis/evals/evals.json

@@ -4,12 +4,14 @@
     {
       "id": 1,
       "prompt": "Analyze this Solana wallet's SPL token accounts and recent parsed activity.",
-      "expected_output": "Uses solana_analysis, treats the identifier as Solana-native, inspects schemas, bounds token/history calls, and reports slot/freshness/runtime status.",
+      "expected_output": "Uses solana_analysis, treats the identifier as Solana-native, inspects schemas, bounds token/history calls, and ends with a slot/freshness/runtime receipt.",
       "files": [],
       "assertions": [
         "Chooses solana_analysis.",
+        "Selects wallet_snapshot, token_risk, or transaction_readiness from routes[] before endpoint selection.",
         "Avoids EVM assumptions.",
-        "Reports Solana-specific freshness such as slot or fetched time."
+        "Reports Solana-specific freshness such as slot or fetched time.",
+        "Includes receipt ids and unavailable checks."
       ]
     },
     {

package/agent-skills/packs/hive-solana-analysis/evals/triggers.json

@@ -0,0 +1,50 @@
+[
+  {
+    "query": "analyze this solana wallet's SPL token accounts and recent activity: 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM",
+    "should_trigger": true
+  },
+  {
+    "query": "is this pump.fun mint safe? looks like its mooning",
+    "should_trigger": true
+  },
+  {
+    "query": "what are solana priority fees right now",
+    "should_trigger": true
+  },
+  {
+    "query": "parse this solana tx signature and tell me what actually happened",
+    "should_trigger": true
+  },
+  {
+    "query": "who are the top holders of this mint",
+    "should_trigger": true
+  },
+  {
+    "query": "check this DAS asset / compressed nft on solana",
+    "should_trigger": true
+  },
+  {
+    "query": "investigate this ethereum wallet 0x28C6c06298d514Db089934071355E5743bf21d60",
+    "should_trigger": false
+  },
+  {
+    "query": "floor price of this eth nft collection",
+    "should_trigger": false
+  },
+  {
+    "query": "whats SOL trading at",
+    "should_trigger": false
+  },
+  {
+    "query": "explain how solana proof of history works",
+    "should_trigger": false
+  },
+  {
+    "query": "watch this mint and alert me if liquidity drops",
+    "should_trigger": false
+  },
+  {
+    "query": "add hive to cursor",
+    "should_trigger": false
+  }
+]

package/agent-skills/packs/hive-stateful-monitoring/SKILL.md

@@ -1,75 +1,120 @@
 ---
 name: hive-stateful-monitoring
-description: Use this skill when a user asks Hive to remember, monitor, schedule, alert, or report on crypto intelligence across sessions. Creates durable monitor intent through Hive's stateful monitoring tools.
+description: Use this skill whenever the user wants Hive to remember, watch, monitor, schedule, alert, or report on crypto state across sessions — "watch this wallet", "alert me if the price moves", "send me a daily digest", "what changed since last time", "remember that I care about X". Converts durable intent into Hive monitors, alerts, reports, and memory facts that Hive workers execute later. For one-off live questions use hive-query or a domain skill instead.
 license: MIT
 metadata:
   package: "@hiveintelligence/agent-skills"
   category: "stateful-monitoring"
   requires_network: "true"
-version: 1.0.0
+version: 1.4.0
 ---
 
-# hive-stateful-monitoring - Stateful Monitoring
+# hive-stateful-monitoring — Stateful Monitoring
 
-Use this skill when the user wants Hive to remember a wallet, token, protocol,
-market, prediction market, watchlist digest, token discovery risk workflow, or
-risk watch workflow and keep reporting on it later.
+Turn durable intent — watch, alert, schedule, remember — into Hive monitors,
+alerts, reports, and memory facts. Monitor execution happens on Hive workers
+between sessions, not in the current chat, so the contract is: capture intent
+precisely, confirm what was saved, and never pretend something was saved when
+the call failed.
 
-## Task toolset
+## Task toolset and identifiers
 
-Use `stateful_monitoring`.
+Toolset: `stateful_monitoring`. Read `hive://toolsets/stateful_monitoring`
+before execution; it is authoritative for the current output schema,
+material-call budget, phases, fallback condition, stop conditions, and the
+read/write routing policy.
 
-Required identifiers: monitor kind and target object.
+Required identifiers: monitor kind and target object. Worker-supported monitor
+kinds are `wallet`, `token`, `protocol`, `market`, `prediction_market`,
+`watchlist_digest`, `token_discovery_risk`, and `risk_watch`.
 
-For B2B adapter mode, Hive state is isolated by server-injected subject context:
-`partner API key -> Hive owner user_id -> tenant_id -> end_user_id -> subject_id`.
-The adapter must sign `METHOD + "\n" + PATH + "\n" + TENANT_ID + "\n" +
-END_USER_ID + "\n" + TIMESTAMP` with HMAC-SHA256 and send the
-`X-Hive-Tenant-Id`, `X-Hive-End-User-Id`, `X-Hive-Subject-Timestamp`, and
-`X-Hive-Subject-Signature` headers. Never ask the model or end user to provide
-`__hive_user_id` or `__hive_subject_id`; those are hidden server-injected args.
-In TypeScript backends with controlled source or release-tarball access, use
-`hive-mcp-client` with `subjectSigningSecret` and per-call
-`subject`/`withSubject(...)` context instead of hand-building these headers.
+Before choosing endpoints, select exactly one matching entry from the exact
+workflow's routes[]. Follow its ordered steps, use a fallback only under that
+step's published condition, stop at four material calls, and preserve the
+selected route_id in the typed result. The broad coverageCatalog is discovery
+coverage, not an execution plan.
 
 ## Procedure
 
-1. Convert the user's durable intent into a monitor `kind`, `target`, `rules`,
-   and `cadence`.
-2. Use `hive_create_monitor` for new watch requests.
-3. Use `hive_list_monitors` before creating a duplicate monitor.
-4. Use `hive_update_monitor` to change cadence, rules, target, metadata, or
-   status.
-5. Use `hive_archive_monitor` when the user asks Hive to stop watching.
-6. Use `hive_get_monitor_runs`, `hive_list_observations`,
-   `hive_list_alerts`, `hive_get_latest_snapshot`, or
-   `hive_generate_monitor_report` when the user asks what changed, what is
-   alerting, or what Hive remembers from previous runs.
+1. Convert the user's durable intent into a monitor `kind`, `target`,
+   `rules`, and `cadence`.
+2. Inspect each exact endpoint schema. On the compact root, state reads route
+   through `invoke_api_endpoint`. Every create, update, archive, remember,
+   forget, acknowledge, or resolve action routes through
+   `invoke_stateful_endpoint`, which must never be auto-approved.
+3. Call `hive_list_monitors` before creating — update instead of duplicating.
+4. Describe the proposed state change to the user and obtain explicit approval.
+5. Call `hive_create_monitor` for new watch requests, `hive_update_monitor`
+   to change cadence, rules, target, metadata, or status, and
+   `hive_archive_monitor` when the user asks Hive to stop watching.
+6. For "what changed / what is alerting / what does Hive remember": use
+   `hive_get_monitor_runs`, `hive_list_observations`, `hive_list_alerts`,
+   `hive_get_latest_snapshot`, or `hive_generate_monitor_report`.
 7. Use `hive_update_alert_status` when the user acknowledges, reopens, or
    resolves an alert.
 8. Use `hive_remember_fact`, `hive_list_memory_facts`, and
    `hive_forget_memory_fact` for durable user-scoped facts that should appear
    in future monitor reports.
-9. Use `hive_list_subjects`, `hive_get_subject`, `hive_archive_subject`, and
-   `hive_list_subject_audit_events` only when operating or auditing a B2B
-   adapter's downstream state boundaries.
-10. Explain that monitor execution is handled by Hive workers, not by the
-   current chat session. Worker-supported monitor kinds are wallet, token,
-   protocol, market, prediction_market, watchlist_digest,
-   token_discovery_risk, and risk_watch.
+9. After any write, verify the persisted result, then confirm back to the user exactly what is being watched,
+   the rules, and the cadence — that confirmation is their only window to
+   catch a mis-captured intent before workers start running it.
 
-## Example
+For B2B adapters serving multiple tenants/end users, read
+`references/b2b-subject-context.md` before using subject-scoped state or the
+`hive_list_subjects` / `hive_get_subject` / `hive_archive_subject` /
+`hive_list_subject_audit_events` tools.
 
-For "Watch this Ethereum wallet and tell me when it moves more than $100k",
-create a wallet monitor with an Ethereum address target, a large-transfer rule,
-and the requested cadence or default cadence.
+## Worked example
 
-For "Send every customer a daily crypto watchlist brief", create a
-`watchlist_digest` monitor per B2B subject with saved wallets, tokens,
-protocols, markets, and optional prediction markets in the target.
+User: "Watch this Ethereum wallet and tell me when it moves more than $100k."
+
+1. `hive_list_monitors` — no existing monitor for this wallet.
+2. `hive_create_monitor` with kind `wallet`, the Ethereum address as target,
+   a large-transfer rule with the $100k threshold, and the requested or
+   default cadence.
+3. Confirm: "Watching 0x… on Ethereum; you'll get an alert on any transfer
+   over $100k; checks run on Hive workers at [cadence]."
+
+User: "Send every customer a daily crypto watchlist brief."
+
+Create a `watchlist_digest` monitor per B2B subject with saved wallets,
+tokens, protocols, markets, and optional prediction markets in the target —
+after reading the B2B reference above.
+
+## Evidence receipt (required)
+
+End every Hive-backed answer with a compact receipt built from the `_hive`
+object on each material tool response:
+
+- `provider`, `tool`, `fetched_at`, `observed_at`, `cache_age_ms`, and `runtime_status`
+- `receipt_id`, `receipt_version`, server/build version, and SHA-256 input/result
+  digests when present (self-checks, not signatures)
+- `source`, `cache_status`, `truncated`, and any warnings
+- canonical chain/entity identifiers plus block, slot, transaction, or query ids
+  present in provider data
+- material provider disagreements and how they were handled
+- checks that were unavailable, gated, stale, truncated, or intentionally not run
+- a `claims[]` citation from each material statement to exact receipt IDs
+- one `coverage[]` entry for every canonical evidence phase, with each gap explained
+
+Never turn missing evidence into a clean result, silently merge conflicting
+provider values, or omit a degraded/fallback call from the receipt.
+`observed_at` is Hive's first-observation/original cache-population time, not
+necessarily upstream event time. Use provider time, block, slot, transaction,
+or candle close for source recency; if absent, mark upstream recency unknown.
+Run `validate_task_result` before presenting the typed workflow result; it
+checks structure but cannot authenticate an invented receipt.
 
 ## Runtime status handling
 
-If stateful tools return `missing_key` or an auth-required error, explain that
-hosted MCP authentication or the Hive persistence backend must be configured
-before durable monitoring can be used. Do not pretend the monitor was saved.
+If stateful tools return `missing_key` or an auth-required error, explain
+that hosted MCP authentication or the Hive persistence backend must be
+configured before durable monitoring can be used. Do not pretend the monitor
+was saved.
+
+## Hand-offs
+
+- One-off live question, no durable intent → `hive-query` or the matching
+  domain skill.
+- The data to monitor needs diligence first (which token? which pool?) → run
+  the domain skill, then create the monitor.