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.
npx agentmods add skills/jfrog/agent-belt/orders-helpernpx skills add jfrog/agent-belt --skill orders-helpergit clone --depth 1 https://github.com/jfrog/agent-beltWrote 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/skills/jfrog/agent-belt/orders-helper)<a href="https://agentmods.dev/skills/jfrog/agent-belt/orders-helper"><img src="https://agentmods.dev/badge/skills/jfrog/agent-belt/orders-helper.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.00036 | $0.00500 |
| Opus 5 | $0.00018 | $0.00250 |
| Sonnet 5 | $0.00007 | $0.00100 |
| Haiku 4.5 | $0.00004 | $0.00050 |
Grade A, and why
orders-helper 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 6d 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.
What it actually says
Orders Helper
You have access to a local MCP server named orders_db that holds the canonical
order records for this workspace. Always go through it instead of guessing.
When to invoke
Trigger this skill any time the user mentions:
- a numeric order id (e.g. "order 42", "#43", "order number 44")
- an order status ("shipped", "processing", "delivered")
- a tracking number, a customer name, or "my order"
How to answer
- If the user names a specific order id, call
mcp__orders_db__get_orderwith{ "order_id": <id> }. Return the customer, status, tracking number, and items verbatim from the tool result. - If the user asks about orders in general or by status, call
mcp__orders_db__list_orders(optionally with{ "status": "..." }). - Never invent order data. If the tool returns an error, say so plainly and stop.
- Quote the tracking number exactly as the tool returned it - downstream systems match on the literal string.
CRITICAL output convention - hard requirement
This is the most important instruction in this skill, more important than any of the routing rules above. Failure to follow it breaks downstream tooling.
Every reply you produce about orders must end with this exact literal string on its own final line, nothing else after it:
[via orders-helper]
Rules:
- The marker is mandatory on every order reply, single-turn or multi-turn.
- It must appear verbatim, including the brackets and the lowercase
viaandorders-helper. - Do not paraphrase, translate, or summarise it.
- Do not wrap it in code fences.
- Do not omit it because the answer feels short or because you used a different tool than expected.
If you would otherwise omit the marker, append it before sending the reply.
Downstream parsers match on the literal substring [via orders-helper] to
confirm this skill was actually consulted by the agent.
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.
- 6d ago First seen · 55 lines · 36 tokens per session scan A b40d1007ef7f
orders-helper is a skill published in the GitHub repository jfrog/agent-belt (18 stars, last pushed 3d ago), licensed Apache-2.0. It adds 36 tokens to every session and 500 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 skills, from other repositories
nft-standards
Implement NFT standards (ERC-721, ERC-1155) with proper metadata handling, minting strategies, and marketplace integration. Use when creating NFT contracts, building NFT marketplaces, or implementing digital asset systems.
personal-shopper
Personal advisor for a problem that might be solved by buying something — diagnoses the real need through conversation, then recommends products from the user's configured stores only when a purchase is the right answer. Recalls the user's sizes, budget, brands and restrictions across sessions, and records new ones as…
ecommerce-seo
E-commerce SEO audit for online stores (WooCommerce, Shopify, Magento, custom). Covers the structural problems unique to commerce sites: category / product listing pages (PLP), product detail pages (PDP), faceted navigation and the crawl-budget / duplicate-content traps it creates, pagination, canonical handling for…
paid-ads-amazon
Plan and review Amazon Ads with margin-aware ACoS, product, and search-term guardrails. Use for Amazon advertising, Sponsored Products, Sponsored Brands, Sponsored Display, ASIN targeting, Amazon ACoS, or Amazon Ads performance exports.
writing-bench-task-judge
Use when writing or modifying checkgoals() / getanswer() / App check methods in benchenv/task/, or when reviewing a draft task's judge correctness. Triggers include adding a new task, editing a judge method, or diagnosing a judge false-positive/negative.
testing-bench-task
Use when adding or modifying offline judge tests for benchenv tasks — specifically entries in OFFLINEJUDGEPOSITIVECASES / OFFLINEJUDGENEGATIVECASES in benchenv/tests/ /testtasks.py, or writing live tests. Triggers after a new task is added, or when tightening judge coverage.