Agent skill · product strategy · jeremylongshore

pave-catalog

Build a service catalog — schema, starter entries, and governance model. Produces what information to capture per service, how it's maintained, and where it lives. Use when asked to "service catalog", "what services do we have", "catalog our services", "service inventory", or "who owns what".

Why this skill is useful

Provides a governance model and schema for maintaining a service catalog, which the AI wouldn't reliably generate on its own.

What it needs

About 5k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.

What this skill does

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): Extended schema (add only when pain exists): Do not add fields speculatively. Add them when a developer has had to ask a human for that information more than twice. Step 2: Inventory All Services Discover what exists. Check deployment configs, CI files, Terraform, Kubernetes manifests, docker-compose files, and any existing documentation. For each service, produce one catalog entry using schema from Step 1. Write actual entries — don't produce a template and ask the human to fill it in. …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills jeremylongshore/pave-catalog

View the source on GitHub

Browse the @skills marketplace