ops-query

Correlate indexer API data, broker telemetry, and CloudWatch logs to diagnose production operational issues.

Updated Apr 11, 2026
One-click install
npx skills add https://github.com/Current-cmd/TrustMeBRO --skill ops-query-current-cmd
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ops-query
Source: https://github.com/Current-cmd/TrustMeBRO/tree/main/.claude/skills/ops-query
Command: npx skills add https://github.com/Current-cmd/TrustMeBRO --skill ops-query-current-cmd

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Investigating production incidents on the Boundless market requires manually stitching together on-chain indexer data, broker telemetry in Redshift, and CloudWatch service logs, which is slow and error-prone when diagnosing slashings, fulfillment drops, or prover failures. ## Core Features & Use Cases - Cross-source correlation: Joins market indexer request lifecycles with Redshift broker telemetry and CloudWatch logs via request_id and request_digest to build a complete incident narrative. - Pre-built investigation playbooks: Tested step-by-step guides for market summaries, slashing root-cause analysis, fulfillment rate drops, prover performance deep dives, and request lifecycle tracing. - Structured reporting: Standardized prover summary tables with failure, skip, and drop breakdowns, plus address labeling and day-over-day comparisons. - Use Case: A prover was slashed on staging overnight. Ask the skill to investigate, and it finds the slashed requests in the indexer, pulls telemetry error codes and proving-time estimates, checks broker load during the window, and reports the likely root cause. ## Quick Start Ask the agent to investigate why prover 0x8305... was slashed on production in the last 24 hours and summarize the root cause.

Frequently Asked Questions about ops-query

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I investigate why a prover was slashed on Boundless?▼

Use the slashing-reasons playbook: find slashed requests via the market indexer by filtering on a non-null slashed_at field, then look up telemetry completions and evaluations for those request IDs to identify root causes like proving timeouts, estimation errors, or broker overload.

How do I diagnose a fulfillment rate drop in a proving market?▼

Query hourly market aggregates from the indexer to pinpoint when the rate dropped, then check telemetry request_completions for error code breakdowns and broker heartbeats for health during that window. For operated provers, also check bento logs for recent deployments.

What data sources are needed to investigate prover issues?▼

Three sources are combined: the market indexer API for on-chain request lifecycle data, Redshift telemetry for broker-side decisions and error codes, and CloudWatch logs for raw service errors. Credentials come from a network_secrets.toml file.

Why does a prover have no telemetry data in Redshift?▼

Broker telemetry is opt-in, so not all provers send data to Redshift. If a prover address has no telemetry rows, rely on indexer data only, such as lock and slash timing and cycle counts, and note the gap in your report.

When should I use CloudWatch logs instead of telemetry for debugging?▼

Use CloudWatch logs only as a last resort when indexer and telemetry data are insufficient, such as for infrastructure failures, panics, or stack traces. Logs are only available for services the team operates, not third-party provers.

Can this skill debug local code changes or review pull requests?▼

No. This skill is strictly for investigating issues in deployed production and staging environments using live operational data. It explicitly excludes debugging local code, reviewing PRs, or analyzing the codebase itself.