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 skills add juspay/xyne-spaces --skill explanation-documentgit clone --depth 1 https://github.com/juspay/xyne-spacesWrote 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/juspay/xyne-spaces/explanation-document)<a href="https://agentmods.dev/skills/juspay/xyne-spaces/explanation-document"><img src="https://agentmods.dev/badge/skills/juspay/xyne-spaces/explanation-document/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/juspay/xyne-spaces/explanation-document"><img src="https://agentmods.dev/badge/skills/juspay/xyne-spaces/explanation-document.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00042 | $0.00979 |
| Opus 5.5 | $0.00017 | $0.00392 |
| Sonnet 5.5 | $0.00008 | $0.00196 |
| Haiku 4.5 | $0.00004 | $0.00098 |
Grade A, and why
explanation-document 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 2mo 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 — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Explanation document
The deliverable is ONE self-contained .html file written in the sandbox and
sent with sandbox-deliver-files. Not chat prose, not a ledger dump.
One document, stable name, survives a sandbox recycle
Give the document a single stable filename and reuse it for the whole run —
<topic>-explained.html, never epoch1.html, epoch2.html, …-final-v3.html.
Every pass EXTENDS that one file. A pile of per-pass fragments cannot be merged
later: sandboxes are ephemeral and the earlier ones are gone.
Because the sandbox recycles, treat a missing file as "fresh machine, not blank
slate": if your canonical .html is not on local disk when you start, you were
moved to a new sandbox — recover the last version you delivered
(spaces-thread-attachments to locate it, spaces-fetch-attachment to pull it
back) and extend that, rather than starting over or shipping a stub. Re-deliver
the same filename each time so the newest upload is always the whole document.
Order it for the reader, not for yourself
You will DISCOVER the system component by component, in whatever order the code led you. Do NOT ship it in that order. A reader needs to build a mental model before any detail lands, and the detail has to get progressively deeper — an appended list of "here's the next file I opened" is an exploration log, not an explanation. Before delivering, reorganise into this shape, top to bottom:
- TL;DR — 3–5 sentences: what the system is, its one job, and the single most important thing to know. A reader who stops here is not lost.
- Mental model — the handful of concepts and the vocabulary. Name the actors and the nouns before using them.
- End-to-end flows — the 2–4 paths that actually matter (e.g. "a message becomes a desktop notification", "…a mobile push", "…a Slack fallback"), each as a numbered walk from trigger to outcome, WITH A DIAGRAM. This is the part a reader returns to most; make it the strongest part.
- Per-component detail — grouped by role, not one section per file.
Cluster (
gateway_*, producers vs filters vs channels, config vs routing vs audit); a flat run of 20+ sections is the inventory this format exists to avoid. Each group explains what the flows glossed over. - Deep reference / appendix — the exhaustive material: per-table field notes, payload budgets, queue config, error-code maps, dead-code findings. A reader consults this; they do not read it linearly. It belongs at the END, never interleaved with the conceptual sections above.
- Lookup table — every entity, one line each, so the document doubles as a reference after the first read.
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.
- 2mo ago First seen · 77 lines · 42 tokens per session scan A 80075eb5aff5
explanation-document is a skill published in the GitHub repository juspay/xyne-spaces (827 stars, last pushed today), licensed Apache-2.0. It adds 42 tokens to every session and 979 once invoked, about $0.0002 per session on Opus 5.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
git-workflow-branching
When creating, updating, and merging code in a collaborative version control environment.
omh-code-review
This is an OMH code-review workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).
redteam-web-detail-pack
Routing and boundary guidance for authorized general web application security testing. Use as a web testing router when the attack surface should be dispatched to more specific web vulnerability skills.
android-pentest
A guide for authorized security testing of Android apps, covering APK inspection, runtime testing, traffic capture, code review, and function hooking. An APK is the installable package used by an Android app.
manage-schemas
Creates, views, edits, deletes, and validates note schemas for the MCP Task Orchestrator in .taskorchestrator/config.yaml — the templates that define which notes agents must fill at each workflow phase. Also recommends schema designs from a library of workflow patterns (autonomous coding loops, spec-driven teams…
queues-jobs
Implement reliable asynchronous jobs and message consumers with explicit delivery, retry and shutdown semantics. Use when adding BullMQ or another established queue, background processing or scheduled work; enqueue success is not job completion.