Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/get-convex/convex-agent-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/get-convex/convex-agent-plugins/convex-insights)<a href="https://agentmods.dev/commands/get-convex/convex-agent-plugins/convex-insights"><img src="https://agentmods.dev/badge/commands/get-convex/convex-agent-plugins/convex-insights.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00040 | $0.00977 |
| Opus 5 | $0.00020 | $0.00489 |
| Sonnet 5 | $0.00008 | $0.00195 |
| Haiku 4.5 | $0.00004 | $0.00098 |
Grade A, and why
convex-insights scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 28 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Query logs + health in natural language
The deployment already records what happened; the agent just has to ask well. This capability is a disciplined wrapper over the official Convex MCP's read tools (logs, insights, functionSpec, status) that turns operational questions into narrow, evidence-returning queries and hands back answers a human can one-click verify in the dashboard. The discipline is copied from the observability MCP surface that works best in the wild: discover fields before querying, three views not fifteen tools, token-frugal output, and a dashboard deep link on every answer.
Steps
- GUARD: deploy-guard step 0-1 — identify + announce which deployment is being read. Reading logs/insights is read-only; never enable prod mutation flags for an insights pass.
- DISCOVER before you query — never guess identifiers. Use
functionSpecto list the real function names andstatusfor the deployment/version. Note the tool limits up front:logstakes only--history <n>(a COUNT, not a time window),--success,--jsonl,--prod,--deployment— there is NO server-side status/function/requestId/time filter;insightshas no function filter and is cloud dev/prod + user-auth only. So you fetch a recent window and filter CLIENT-SIDE. - PICK ONE OF THREE VIEWS and fetch the raw window, then filter locally:
- failures view →
logs --history <n> --jsonl, then locally keep failures + group by function + error message, returning counts + the first stack per group. Answers 'what's erroring', 'what failed after deploy'. - health view →
insights(cloud only): the typed 72h read-limit / OCC events. Surface + rank them, but hand perf/cost ROOT-CAUSING and fixes to convex-advisor — emit those as pointer findings, do not own the perf-fix framing here. - trace view →
logs --history <n> --jsonlthen locally filter to one requestId/function to read the full execution. Answers 'why did THIS call fail'.
- failures view →
- SCOPE by fetching a bounded recent window (a sensible
--historycount) and filtering client-side to the function/status/requestId asked about; when the window is large, aggregate (counts by function/message) rather than dumping lines. - ANSWER with (a) the one-line finding, (b) the evidence (counts + one representative stack/log line), and (c) WHEN POSSIBLE an agent-constructed dashboard deep link (dashboard.convex.dev, the deployment's Logs/Functions view) for human verification — no tool returns the link, so build it from the deployment name + function; never a raw log dump as the answer.
- CROSS-CHECK deploy causality when asked 'did my deploy break this': compare the failure onset (from the log timestamps) against the deployment version from
status; correlate, don't assert. - HAND OFF, don't fix here: a perf/cost cause → convex-advisor (which owns those fixes); a code defect → convex-reviewer/convex-authz; a live error to react to going forward → monitor/sentinel. Emit findings on the bus (specs/finding.schema.json) — primarily
observability, with perf/cost as pointer findings to advisor — so a composite pass can pick them up.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 28 lines · 40 tokens per session scan A 332e0e99a483
convex-insights is a command published in the GitHub repository get-convex/convex-agent-plugins (112 stars, last pushed 10d ago), licensed MIT. It adds 40 tokens to every session and 977 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
qa-changes
This skill should be used when the user asks to "QA a pull request", "test PR changes", "verify a PR works", "functionally test changes", or when an automated workflow triggers QA validation of code changes. Provides a structured methodology for setting up the environment, exercising changed behavior, and reporting…
doctor
Diagnosticar y reparar problemas del framework Don Cheli, git y entorno. Usa cuando el usuario dice "doctor", "problemas del framework", "don cheli no funciona", "repair Don Cheli", "debug setup", "setup broken", "framework broken", "reparar entorno". Detecta y repara issues de configuración, git y dependencias…
fix
Universal debugging and fix application with semantic code analysis.
doctor
Badi configuration validation. Checks all Badi components and produces a diagnostic report.
http-service
Build, review or debug a Bun HTTP service. Loads the http-service skill, then works the task through its workflow.
gh-issue-use-cypress
Like /gh-issue-use-browser, but pinned to the Cypress MCP — use when your project runs the Cypress MCP for browser automation. Example — /gh-issue-use-cypress "Composer > Save" saving toasts failure but the record persists.