Service Catalog EntryCAUTION

1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in Anthropic's plugin directory. Plus a typed decision layer: which skill, is it safe, ship or slip. Free in-browser or npx pm-

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: service-catalog-entry
description: "Write a service catalog entry for a microservice or internal platform service — covering service identity, purpose, architecture context, SLAs, API contract summary, data classification, dependencies, operational runbooks, and known limitations. Use when asked to document a service for an internal developer portal, write a service README for a platform catalog, create a service overview page, or onboard a new service to a service registry. Produces a complete service catalog entry suitable for an internal developer portal or wiki."
---

# Service Catalog Entry Skill

Produce a complete service catalog entry for a microservice or internal platform service — giving any engineer at the company the context they need to understand what the service does, how to depend on it, what its reliability characteristics are, and where to go when something goes wrong. A well-written catalog entry eliminates "who owns this?" and "is this safe to use?" questions that slow down teams depending on shared services.

## Required Inputs

Ask for these if not already provided:
- **Service name** — the canonical identifier used in code, monitoring, and deployments
- **Team and owner** — team name, tech lead name, and on-call contact
- **Architecture overview** — what the service does, what calls it, and what it calls
- **SLA requirements** — availability target, latency SLO, support tier, and maintenance window
- **Key APIs** — the most important endpoints other teams use (method, path, brief description)
- **Data handled** — what data the service stores or processes, sensitivity classification, retention

## Output Format

---

# Service Catalog: [Service Name]

> **[One sentence — what this service does for consumers, in plain language]**
>
> *e.g. "The Payments Service processes charge, refund, and subscription billing events for all Acme products."*

---

## Identity

| Field | Value |
|---|---|
| **Service name** | `[service-name]` |
| **Canonical repository** | [https://github.com/[org]/[repo]] |
| **Owner team** | [Team name] |
| **Tech lead** | [Name] ([Slack: @handle]) |
| **On-call rotation** | [PagerDuty service link] |
| **Slack channel** | `#[team-channel]` |
| **Support tier** | [Tier 1 — 24/7 / Tier 2 — business hours / Tier 3 — best effort] |
| **Status** | [Active / Deprecated / Sunset date: YYYY-MM-DD] |
| **Language / runtime** | [e.g. Go 1.22 / Python 3.12 / Node 20] |
| **Deployment platform** | [Kubernetes / ECS / Lambda / etc.] |
| **Environments** | [Production: URL] | [Staging: URL] | [Dev: URL] |

---

## What It Does

[Two to three paragraphs in plain language — no jargon or acronyms without explanation.]

[Paragraph 1: The business problem this service solves. What would break or be missing if this service did not exist?]

[Paragraph 2: How it works at a high level — the main processing model (e.g. request/response API, event-driven consumer, batch processor), what triggers it, and what it produces.]

[Paragraph 3: What this service is NOT responsible for — the explicit boundaries. This prevents other teams from building incorrect assumptions about scope.]

---

## Architecture Context

### System Diagram

```
[Upstream callers]          [This Service]             [Downstream dependencies]
                                                        
  [Web App]  ──────────→                          ──→  [Primary Database — PostgreSQL]
  [Mobile API]  ────────→  [Service Name]         ──→  [Cache — Redis]
  [Partner API] ────────→  (Port 8080/gRPC)       ──→  [Message Queue — Kafka/SQS]
                                                   ──→  [External Service / API]
                           ↓ emits events to
                        [Event Bus / SNS]
                           ↓ consumed by
                  [Downstream Service A]
                  [Downstream Service B]
```

### Who Depends on This Service

| Caller | How they use it | Contact |
|---|---|---|
| [Service / Team A] | [e.g. "Calls POST /charges to initiate payments"] | [Slack: #team-a] |
| [Service / Team B] | [e.g. "Subscribes to payment.completed events via Kafka topic"] | [Slack: #team-b] |
| [Service / Team C] | [e.g. "Calls GET /subscriptions for billing status"] | [Slack: #team-c] |

### What This Service Depends On

| Dependency | Type | Criticality | Their on-call |
|---|---|---|---|
| [PostgreSQL instance] | Database | Critical — all writes fail without it | [DBA team: #db-oncall] |
| [Redis cluster] | Cache | High — latency degrades without it | [Infra team: #infra-oncall] |
| [Kafka cluster] | Message queue | High — async events queue | [Infra team: #infra-oncall] |
| [Stripe API] | External API | Critical — payment processing fails | [vendor status: status.stripe.com] |
| [Auth Service] | Internal service | Critical — all auth fails | [Auth team: #auth-oncall] |

---

## Service Level Agreement

### Availability and Latency

| SLO | Target | Measurement window | Error budget |
|---|---|---|---|
| Availability | [99.9%] | Rolling 30 days | [43 min/month] |
| p50 latency (key endpoints) | < [50] ms | Rolling 24 hours | — |
| p99 latency (key endpoints) | < [500] ms | Rolling 24 hours | — |
| p99.9 latency (key endpoints) | < [2000] ms | Rolling 24 hours | — |
| Error rate | < [0.1]% | Rolling 1 hour | — |

**SLO dashboard:** [Link to monitoring dashboard]
**Current error budget remaining:** [Link to SLO dashboard or inline value]

### Support Tiers

| Tier | Scope | Response time | Resolution time |
|---|---|---|---|
| P1 — Service down | All authenticated requests failing | 15 minutes | 1 hour |
| P2 — Significant degradation | Error rate >1% or p99 >2× SLO | 30 minutes | 4 hours |
| P3 — Minor issues | Non-critical endpoints degraded | Next business day | 3 business days |
| Feature requests / bugs | Via standard ticket process | [Ticket SLA] | Per roadmap |

**To raise an incident:** Page via [PagerDuty service link] or post in `#incidents`.
**To raise a feature req

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

templates/pm-discovery-agent/skills/assumption-mapper/SKILL.md

templates/pm-discovery-agent/skills/discovery-interview-guide/SKILL.md

templates/pm-discovery-agent/skills/job-story-mapper/SKILL.md

templates/pm-discovery-agent/skills/user-interview-synthesis/SKILL.md

templates/pm-launch-agent/skills/content-calendar/SKILL.md

Gates applied: no_behavioural_pass.