Hive stateful monitoring

Skill hive-intel/hive-skills/skills/hive-stateful-monitoring

Installable Hive Intelligence agent skills for crypto MCP setup, discovery, and research workflows.

Install

npx -y skills add hive-intel/hive-skills --skill hive-stateful-monitoring

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.8 KB, 746 tokens by cl100k_base, as published. Nobody here has run it

hive-stateful-monitoring — Stateful Monitoring

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 and identifiers

Toolset: stateful_monitoring.

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.

Procedure

Convert the user's durable intent into a monitor kind, target, rules, and cadence.
Call hive_list_monitors before creating — update instead of duplicating.
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.
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.
Use hive_update_alert_status when the user acknowledges, reopens, or resolves an alert.
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.
After any write, 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.

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.

Worked example

User: "Watch this Ethereum wallet and tell me when it moves more than $100k."

hive_list_monitors — no existing monitor for this wallet.
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.
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.

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.

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.

Gives 0 of the 12 instructions most monitoring observability skills give in 746 tokens

Counted across 481 of the 483 authors here whose files we hold, read 2026-08-06

link every alert to a runbookin 43 of 481, across 35 files
use structured json loggingin 36 of 481, across 31 files
alert on user-facing symptomsin 20 of 481, across 15 files
emit structured JSON logs with stable event namesin 18 of 481, across 13 files
propagate trace context across boundariesin 16 of 481
use histograms for latency trackingin 14 of 481, across 9 files
use OpenTelemetry for distributed tracingin 13 of 481, across 8 files
include a correlation ID on every log linein 13 of 481, across 8 files
Define service level objectivesin 10 of 481, across 7 files
Call useAzureMonitor before importing other modulesin 9 of 481, across 2 files
stop and ask for clarification if inputs are missingin 9 of 481, across 2 files
define on-call questions before adding telemetryin 9 of 481, across 4 files

Said here and by no other author read

list existing monitors before creating new ones
update existing monitors instead of duplicating
archive monitors when asked to stop watching
confirm exact watch rules and cadence after saving
use memory tools for durable user-scoped facts
explain configuration requirements on auth errors

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.