Files
paperclip-docs/docs/reference/api/teams-catalog.md
Aron PrinsandClaude Opus 5 325c9eb819 seo: hand-write titles and descriptions for all 192 pages (#115)
## Why

The build derived `<title>` from the **sidebar label** and the
description from the **first paragraph clipped to 220 characters**. Both
are the wrong source. A sidebar label is written for a 240px-wide nav
that supplies its own context; a search result has none.

On production that produced:

- **7 pages titled "Overview"**, and 32 pages sharing a title with
another page
- **109 of 193 descriptions cut off mid-word**, and 174 over 160
characters (where Google truncates)

```
/guides/welcome/key-concepts/
  BEFORE (220):  ...and if you misunderstand them early, the product wi
```

Near-identical titles are the weak-differentiation signal behind
"crawled — currently not indexed", which is the exact symptom on this
property.

## What changed

`seo_title` and `seo_description` frontmatter on **every one of the 192
pages**, written by hand against each page's real content and optimised
for the click — lead with what the reader can do, name the concrete
things covered, no keyword stuffing, no repeating the title.

| | Before | After |
|---|---|---|
| Duplicate titles | 32 pages | **0** |
| Duplicate descriptions | — | **0** |
| Descriptions cut mid-word | 109 | **0** |
| Descriptions over 160 chars | 174 | **0** |
| Title length (incl. suffix) | up to "Overview" | **26–60** |
| Description length | 31–240 | **122–158** |

**No prose was rewritten.** I measured content overlap between the
colliding pairs first — only 17–23%, so these were always distinct pages
wearing the same label, not duplicate content. The `docs/` diff is **564
insertions, zero deletions**.

### Examples

```
BEFORE — all seven identical:  "Overview | Paperclip Docs"
AFTER:  "Adapters Overview"      "API Overview"        "CLI Overview"
        "Deployment Overview"    "Bundled Skills"      "Optional Skills"
        "Experimental Features"

BEFORE — both identical:  "Issues | Paperclip Docs"
AFTER:  "Issues: Creating and Tracking Work"   /guides/day-to-day/issues/
        "Issues API"                           /reference/api/issues/
```

```
/guides/getting-started/five-minute-path/
BEFORE (220):  The shortest route from a running Paperclip instance to an agent that has
               just completed work for you. After Paperclip is installed, the path takes
               about 5 minutes: create a company, hire a CEO agent, approve its first s
AFTER  (131):  Install Paperclip, create a company, hire a CEO agent, and approve its
               first strategy — a working AI company in about five minutes.
```

## Plumbing

- **`site/build-release.mjs`** prefers the authored fields; the derived
path stays only as a fallback the CI gate prevents ever reaching.
`<title>`, `<meta name="description">`, and the `TechArticle` JSON-LD
all read from the same source.
- **`site/app.js`** uses the same fields, so a client-side transition
cannot leave a different title on screen than the crawler was served.
Verified in-browser: navigating `/guides/day-to-day/issues/` →
`/reference/api/issues/` swaps to exactly the server-rendered values, no
JS errors.
- **`scripts/verify-seo-metadata.mjs`** (new) enforces presence,
uniqueness, length, complete-sentence endings, and the
frontmatter-safety rules. Wired into `docs:test` and CI as its own step.

I negative-tested the gate rather than assuming it works — it correctly
fails on a duplicate title, a mid-word description, and a missing field,
and passes again once restored.

## Automating it going forward

`skills/sync-docs/SKILL.md` now:

- gains an **"Authored SEO metadata"** section: why the fields exist,
the enforced rules as a table, and how to actually write them (title
names the subject not the nav position; description writes for the
click; never generate mechanically from the first paragraph — *that is
the fallback the gate exists to prevent*).
- requires both fields in the **page-authoring instruction** given to
every subagent, with guidance on when to update an existing description
versus leave it.
- runs `docs:test:seo-metadata` and `docs:test:crawlable-links` as
**fail-loud gates in Phase 7** before commit.
- documents all six build gates in the files/gates section.

So once this lands, a new page cannot ship without hand-written
metadata, and a title collision cannot reach production.

## Verified

All six verifiers pass:

```
Static route verification passed
Asset fingerprint verification passed
Hierarchical Skills nav verification passed
Skill source block verification passed (11 skill pages, 1 control page)
Crawlable-link contract passed: 40886 internal links across 194 pages resolve in one hop
Authored-SEO contract passed: 192 pages carry a unique, hand-written seo_title and seo_description
```

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
2026-08-25 22:51:42 +02:00

9.4 KiB

paperclip_version, seo_title, seo_description
paperclip_version seo_title seo_description
v2026.609.0 Teams Catalog API The surface behind catalog teams — ready-made starter groups bundling agents, projects, routines, and skills that install into a company in one step.

Teams Catalog API

The teams catalog API is the control-plane surface behind catalog teams — the ready-made starter groups Paperclip ships with the app. A catalog team bundles a small set of agents, projects, tasks, and the skills they need, so you can drop a whole working unit into a company in one step. These endpoints let you browse the catalog, inspect a single team and its files, see what is already installed in a company, preview an import, and install a team.

For the user-facing concept and CLI workflow, see Teams Commands and the Team Catalog guide. This page documents the raw HTTP endpoints that those tools call.

All routes here are mounted under /api. The browsing routes need only an authenticated caller and no company context; the installed, preview, and install routes are company-scoped and check company access.

There are two kinds of catalog teams. Bundled teams ship inside the app and are the everyday starting points. Optional teams are extras, some of which pull in skills from external sources. The kind filter switches between the two.


Browse the catalog

GET /api/teams/catalog

Returns the catalog teams the caller can see. Browsing reads the catalog without writing anything and requires no company context.

Query parameters

Parameter Values Description
kind bundled, optional Filter by catalog kind.
category string Filter by catalog category slug.
q string Free-text search over the catalog.

Each catalog team in the response carries id, key, kind, category, slug, name, description, path, entrypoint, schema, defaultInstall, recommendedForCompanyTypes, tags, a counts object (agents, projects, tasks, routines, localSkills, catalogSkills, externalSkillSources), rootAgentSlugs, agentSlugs, projectSlugs, requiredSkills, envInputs, sourceRefs, files, trustLevel, compatibility, and contentHash. Optional teams sourced from a package also include packageName and packageVersion.


Inspect one catalog team

GET /api/teams/catalog/{catalogId}

Returns the full record for a single catalog team — the same shape as a list entry, including its agents, projects, tasks, required skills, and file manifest. Inspecting a team before you install it is the clearest way to see exactly what will land in the company.

The path segment {catalogId} is a catalog reference: a catalog team ID, key, or unique slug. You can also pass the reference explicitly with the ref query parameter, which takes precedence over the path segment.

Query parameters

Parameter Description
ref Catalog reference (ID, key, or slug). Overrides the {catalogId} path segment when present.

Read a catalog team file

GET /api/teams/catalog/{catalogId}/files

Returns one file out of the catalog team package — for example TEAM.md. Use this to read a team's manifest or any referenced file without installing it.

Query parameters

Parameter Description
ref Catalog reference (ID, key, or slug). Overrides the {catalogId} path segment when present.
path Relative path of the file to read inside the team package. Defaults to TEAM.md.

The response carries catalogTeamId, path, kind, content, language, and markdown.


List installed catalog teams

GET /api/companies/{companyId}/teams/catalog/installed

Returns the catalog teams already installed in the given company. This is the company-lensed view: it tells you which teams are present and lets a client flag teams that have drifted out of date from the current catalog version. Company access is checked before the listing runs.


Preview an install

POST /api/companies/{companyId}/teams/catalog/{catalogId}/preview

Runs the import on the server and returns the plan without writing anything to the company. The preview reports what would be created, which skills the team needs and how they would be prepared, and any warnings or errors. Company access is checked before the preview runs.

All body fields are optional:

Field Type Description
targetManagerAgentId string or null Existing agent ID that the catalog's root agents should report to.
targetManagerSlug string or null Portable manager slug that the catalog's root agents should report to.
include object Portability include block selecting which entity kinds to import.
agents "all" or array of slugs Restrict the import to selected agent slugs.
collisionStrategy rename, skip, replace How to handle entities that already exist.
nameOverrides object (slug → name) Override imported entity names.
selectedFiles array of strings Restrict the import to selected portable files.
sourcePolicy object Gate external skill sources. Accepts allowExternalSources, allowUnpinnedOptionalSources, and allowLocalPathSources booleans.

The {catalogId} path segment is a catalog reference, and the ref query parameter overrides it when present, exactly as on the browse routes.

curl -X POST "http://localhost:3100/api/companies/company-1/teams/catalog/core-exec-team/preview" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "targetManagerSlug": "cto",
    "collisionStrategy": "rename"
  }'
const res = await fetch(
  "http://localhost:3100/api/companies/company-1/teams/catalog/core-exec-team/preview",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${token}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      targetManagerSlug: "cto",
      collisionStrategy: "rename",
    }),
  },
);
const plan = await res.json();
import requests

res = requests.post(
    "http://localhost:3100/api/companies/company-1/teams/catalog/core-exec-team/preview",
    headers={"Authorization": f"Bearer {token}"},
    json={
        "targetManagerSlug": "cto",
        "collisionStrategy": "rename",
    },
)
plan = res.json()

Install a team

POST /api/companies/{companyId}/teams/catalog/{catalogId}/install

Does what preview shows: imports the team into the company, creating its agents, projects, and tasks, and preparing its required skills. On success the route responds with 201. Because installing a team creates agents, the caller must be able to create agents in the company — board callers need the agents:create permission (local implicit and instance-admin board callers are exempt), and agent callers need an agents:create grant or the equivalent agent permission.

The install body accepts everything preview accepts, plus:

Field Type Description
adapterOverrides object (slug → override) Pin an imported agent to an adapter. Each override is an object with adapterType (string) and an optional adapterConfig object.
secretValues object (key → value) Provide values for the secret env inputs the team declares.

As with preview, {catalogId} is a catalog reference and the ref query parameter overrides it when present.

curl -X POST "http://localhost:3100/api/companies/company-1/teams/catalog/product-engineering/install" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "targetManagerSlug": "cto",
    "adapterOverrides": {
      "senior-coder": { "adapterType": "claude_local" }
    }
  }'
const res = await fetch(
  "http://localhost:3100/api/companies/company-1/teams/catalog/product-engineering/install",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${token}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      targetManagerSlug: "cto",
      adapterOverrides: {
        "senior-coder": { adapterType: "claude_local" },
      },
    }),
  },
);
const result = await res.json();
import requests

res = requests.post(
    "http://localhost:3100/api/companies/company-1/teams/catalog/product-engineering/install",
    headers={"Authorization": f"Bearer {token}"},
    json={
        "targetManagerSlug": "cto",
        "adapterOverrides": {
            "senior-coder": {"adapterType": "claude_local"},
        },
    },
)
result = res.json()

Practical notes

  • Catalog teams ship without a fixed adapter per agent on purpose. Use adapterOverrides to pin a specific agent to a runtime such as claude_local or codex_local; agents you do not override are resolved at import time.
  • Browse, inspect, and file reads require only an authenticated caller. The installed, preview, and install routes check company access first.
  • Preview writes nothing. Run it before install to confirm what will be created and how the team's skills will be prepared.
  • The install route enforces the agents:create permission. If you lack it, the install is rejected before anything is created.