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 tonone-ai/tonone --skill pave-cataloggit clone --depth 1 https://github.com/tonone-ai/tononeWrote 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/tonone-ai/tonone/pave-catalog)<a href="https://agentmods.dev/skills/tonone-ai/tonone/pave-catalog"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/pave-catalog/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/tonone-ai/tonone/pave-catalog"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/pave-catalog.svg" alt="Reviewed on agentmods" width="80" 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.00067 | $0.01870 |
| Opus 5.5 | $0.00027 | $0.00748 |
| Sonnet 5.5 | $0.00013 | $0.00374 |
| Haiku 4.5 | $0.00007 | $0.00187 |
Grade A, and why
pave-catalog 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 17d 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 — 205 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Service Catalog
You are Pave — the platform engineer on the Engineering Team.
A service catalog is useful when developers need to find things without asking people. It fails when it becomes a stale spreadsheet nobody trusts. The right catalog is the simplest one that answers questions developers actually ask — and has a governance model that keeps it current.
Start with the questions, not the schema.
Step 0: Identify the Actual Pain
Before designing catalog, establish what problem it's solving:
- Are developers asking "who owns X?" during incidents?
- Are new engineers unable to find service dependencies?
- Are runbooks scattered or missing?
- Is there no single source of truth for what's running in production?
If the answer to all of these is "not really a problem yet," the catalog is premature. Document it as a lightweight table in the root README instead.
If pain is real, continue.
Also check:
- Existing catalog attempts:
catalog-info.yaml, Backstage configs, Port/Cortex/OpsLevel setup, any wiki pages - Where service definitions currently live (deployment configs, Terraform, CI files)
- How many services exist — under 10 is a Markdown table, 10–50 is YAML-in-repo, 50+ consider a tool
Step 1: Define the Schema
Write down only the fields developers actually need. Every field you add is a field someone has to keep updated.
Minimum viable schema (every service must have these):
# catalog-info.yaml — lives in the root of each service repo
name: user-api
description: Handles authentication, user profiles, and session management
type: service # service | library | worker | cron | data-store
status: production # production | beta | deprecated | internal
owner: platform-team # team name, not individual
oncall: @platform-team # who gets paged (Slack handle or PagerDuty rotation)
repo: https://github.com/org/user-api
docs: https://notion.so/org/user-api-runbook
dashboard: https://grafana.org/d/user-api
Extended schema (add only when pain exists):
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.
- 17d ago First seen · 205 lines · 67 tokens per session scan A c9d0bbc9678d
pave-catalog is a skill published in the GitHub repository tonone-ai/tonone (76 stars, last pushed 9d ago), licensed MIT. It adds 67 tokens to every session and 1,870 once invoked, about $0.0003 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-09-27.
Other skills, from other repositories
fleet
The session roster (/foundry:fleet) — native /list-agents annotated with each row's foundry programme, over the NATIVE session/container list. Read-only/advisory. Trigger to see all your parallel sessions and containers at a glance with their foundry context, or when supervising many sessions and asking "what is each…
g-init
The single G-Forge front door — run once after installing the plugin. Detects what's here and routes to /g-onboard (existing codebase) or /g-kickoff (new project) for the brief, scaffolds CLAUDE.md (compact G-rules), g-docs/ROADMAP.md (with the Active Session handoff), g-docs/milestones/, g-docs/todo.md, the…
g-onboard
Onboard G-Forge onto an existing codebase. Reads deeply before asking anything — treats existing CLAUDE.md, rules, agents, and task ledgers as first-class inputs. Only interviews for what it genuinely doesn't know yet. Produces or updates g-docs/projectbrief.md.
g-roadmap
Project-manager-driven milestone planner. Gated phases — feature dump → cluster → sequence → premortem & re-prioritize → approve → write. Narrates reasoning at every step, and runs a premortem + re-prioritization of the whole roadmap whenever a milestone is added or modified. Auto-triggers when no g-docs/ROADMAP.md…
g-roundtable
Bind the session to "the Roundtable" — a shared live Doc that is the human-facing communication layer between you, non-programmers (PMs, collaborators), and the session. start binds a Doc (create-from-template or attach-by-URL); sync reads the Roundtable at a boundary and writes only salient deltas; close distills the…
g-telemetry
Compute the 8 reliability metrics defined in g-docs/telemetry-metrics.md, derive a health profile (stable / cautious / defensive / recovery), and write it to .claude/telemetry-profile for adaptive orchestration in /g-execute and /g-review. Read-only on history; never modifies retros, forecasts, or git state.