ReadMe

View saved version →

---
name: edit-page-content
description: Create or edit documentation pages in ReadMe, including guides, API reference prose, changelogs, discussions, recipes, and custom pages.
---

# Edit ReadMe page content

## Workflow

1. **Target + Method.** Unless the user has specified directly to you, use the `managing-readme-docs` skill to understand whether you are using MCP or BiDi Sync to make changes, ensure you are working on the right project and targeting the right branch. Identify the page type and whether this is a new page or an edit; use the page-type table below for paths and scope.
   **Done:** The project, write surface, section, page identity, and applicable branch are explicit.
2. **Locate and read.** For updates, read relevant files by searching and finding.
   For MCP use the `/v2/search` endpoint via `execute-request` and if search is insufficient, retrieve categories for the section (`v2/branches/{branch}/categories/{section}`) then pages within categories (`/v2/branches/{branch}/categories/{section}/{title}/pages`)
   **Done:** The exact page and full current body/metadata are available, or the new page's category and slug are agreed.
3. **Draft** Ensure that you have a strong idea of what the user wants, and what you can use in the page. Refer to the [ReadMe docs mdx page](https://docs.readme.com/main/docs/mdx.md) to understand how to write valid MDX. A good page uses components wherever they make the content easier to read: look for places each one fits, but never force one onto content that doesn't suit it. Follow [COMPONENTS.md](COMPONENTS.md) for when to use each built-in component and how to format it, and use reusable content where it fits (see below). Apply the page-type concerns below.
4. **Write**:
   - Use available tools to update content
   - For MCP when creating MDX you MUST apply your changes in full
   **Done:** changes successfully applied
5. **Verify.** Fetch content if using MCP, or check git status for local documentation
   **Done:** The saved result match your applied changes.

## Components and reusable content

| Type | What it is | Docs |
| --- | --- | --- |
| Built-in components | Available in every project: Tabs, Accordion, Cards, and Columns, plus callouts, tabbed code blocks, images, and embeds | [Built-in components](https://docs.readme.com/main/docs/built-in-components.md); best practices in [COMPONENTS.md](COMPONENTS.md) |
| Custom components | JSX components a project defines under **Settings → Custom Components**, or adds from the component marketplace. Used in pages by tag name, like built-ins. Pro and Enterprise plans only | [Custom components](https://docs.readme.com/main/docs/building-custom-mdx-components.md) |
| Reusable content | Named Markdown blocks managed under **Editor → Reusable Content**. Editing a block updates every page that uses it. Pro and Enterprise plans only | [Reusable content](https://docs.readme.com/main/docs/reusable-content.md) |

- Prefer an existing component or reusable block over raw HTML or content copied between pages.
- There is no way for you as an agent to make custom components/reusable components yet - the user must make them on their ReadMe docs site.
- Never invent custom component or reusable block names. Only use ones already present in the project's pages, or ones the user names. If unsure, ask.
- Editing a page that contains a reusable block does not change the block. Changes to the block itself happen in the Reusable Content editor in the user's docs site.
- If the user wants a new custom component or reusable block, give them instructions for how to do this and direct them to their ReadMe docs site.

## Page Types and linking

Unless the site already uses an alternative linking style for intra-project links (same subdomain), prefer root-relative `/section/{slug}` links with descriptive text: `[Authentication](/docs/authentication)`. Use full URLs for external sites or canonical page URLs.

| Page type | Authoring concern | Preferred 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: manage-navigation
description: Organize docs side navigation in ReadMe including category management, page management, changing page titles and urls and more.
---

# Manage ReadMe navigation

## Workflow

1. **Target + Method.** Unless the user has specified directly to you, use the `managing-readme-docs` skill to understand whether you are using MCP or BiDi Sync to make changes, ensure you are working on the right project and targeting the right branch. Identify the page type and whether this is a new page or an edit; use the page-type table below for paths and scope.
   **Done:** The project, write surface, section, page identity, and applicable branch are explicit.
2. **Understand How to Manage ReadMe Navigation.** Read through the #readme-navigation-hierarchy section to understand mechanically how ReadMe's site navigation works. To understand best practices around site structure and navigation refer to Readme's [Structuring your docs](https://docs.readme.com/main/docs/structuring-your-docs.md) page.
   **Done:** The affected navigation and its project/branch are known.
3. **Plan.** Show the proposed before/after structure, including page identities, destination categories, order, title versus slug changes, and removals. This should be in a simple to read structure for the user - you don't need to get bogged down in ReadMe's technical concepts. Tree-esque views work well. Check inbound links when URLs change. Explain destructive effects and obtain explicit approval for deletion.
   **Done:** The desired structure and any destructive/URL-changing actions are approved.
4. **Apply.** Depending on the method (local via BiDi Sync or via MCP), make edits.
   **Done:** Every approved structural change has a result, with any partially completed sequence recorded.
5. **Verify.** Re-read over changes and verify against the plan that the user agreed to.
   **Done:** The resulting structure matches the plan or every discrepancy is reported.

## ReadMe Navigation Hierarchy

ReadMe's navigation style is section-dependent. In BiDi synced repositories sections are the folders at root level - ie `docs/` and `reference/`. Refer to the [documentation structure page](https://docs.readme.com/main/docs/documentation-structure) to understand how to structure BiDi git repositories.

### Categories

Categories are not pages - but are the top-level containers that exist in the UI for certain sections. In BiDi synced repositories these correspond to the folders that exist within section folders.

Categories only exist in the guides and API reference sections - and only have a name, no description.

#### Key MCP Operations

- Get all categories in a section - GET https://api.readme.com/v2/branches/{branch}/categories/{section}
- Get all pages in a category - GET https://api.readme.com/v2/branches/{branch}/categories/{section}/{title}/pages

### Guides & API Reference

In the guides (under /docs/{slug}) and API reference (under /reference/{slug}) section all pages must exist under a category. Existing under a category does not mean that it is at the root-level of the category, because pages within these sections can have parent pages.

Parent pages (#empty-vs-non-empty-parent-pages) are normal pages within that category, and to assign a page as the parent of a page set the `parent` on the page as the slug of that page (note that parents must be from the same section) via the create/update endpoint of that section type.

Pages with no `parent` are at the root of the category.

To order pages under a parent page/category:

- For MCP: set the `position` of the page. This is 0-based, and setting to an index that already has a page will push that page, and all pages with a greater index lower.
- For BiDi sync: each folder in `docs/` and `reference/` contains an `order.yml` file that dictates the order. Each .mdx page in the folder must be present in the `order.yml` file without its file extension, in the order you want to show it in:
   ```yml
   

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: managing-readme-docs
description: Shared reference for working on a ReadMe project, covering MCP routing, project sections, Git-backed docs (BiDi Sync), and confirming the active project and branch. Use before reading or changing documentation hosted on ReadMe.
---

# Working on a ReadMe project

Shared reference for project operations. Read the sections needed by the current workflow.

## MCP routing

Use [ReadMe's MCP server](https://docs.readme.com/main/docs/readmes-mcp-server) and its `execute-request` tool to read and maintain documentation hosted on ReadMe.

Use the MCP-server exposed `list-specs`, `list-endpoints`, `get-endpoint` and `search-endpoints` tools to search and understand the operations that can be performed on your documentation via the MCP server. These discovery tools describe ReadMe's APIs, not your endpoints/API reference hosted at ReadMe.

The `fetch` and `search` tools can be used to read through ReadMe's own documentation, hosted ad https://www.docs.readme.com.

Route project analytics separately: page views, search terms, and page quality belong to the `Developer Metrics API` spec, not the `ReadMe API` spec. Discover the available operation and inspect schema before calling endpoints.

## ReadMe Sections

A ReadMe project is organised into sections, and a page belongs to exactly one of them.

- **Guides** — prose documentation: concepts, how-tos, tutorials, onboarding. The main body of most projects, and where content belongs when no other section fits.
- **API Reference** — largely consisting of endpoint ("API") pages (documenting one HTTP method on one endpoint) backed by an OpenAPI definition. The section also holds prose ("API Reference") and webhook pages, which do not include any API schema. API Endpoint pages are commonly created from an uploaded OpenAPI Specification (OAS spec)
- **Changelog** — dated entries announcing releases and changes.
- **Custom pages** — standalone pages outside of other doc sections that generally aren't related to documentation, such as landing or marketing pages.
- **Recipes** — step-by-step code walkthroughs. A recipe is a code sample broken into ordered steps with per-step annotations and line highlighting, not prose with snippets in it. Structured content, edited through its own tooling rather than as markdown.
- **Discussions** — reader-generated community threads and questions.

Do not describe a page as belonging to a section other than the one it is actually in: a guide about a recipe is still a guide.

## Git backed documentation

ReadMe documentation is git-backed, meaning that ReadMe supports:

- Branches and versioning of documentation:
  - Each project has a single "Stable" branch (commonly v1.0, v2.0, ...)
  - By default operations will be applied to the stable branch **unless otherwise specified in a request**
  - Always be cautious when writing to a stable branch - any changes will be immediately visible to users.
  - It is recommended to make changes in branches, then merge branches into stable versions after getting approval for these (ReadMe UI offers an approval process)
- Bi-Directional Synchronization (aka "BiDi Sync") 
  - Users can setup BiDi Sync on a docs repository so that they can make changes to a repository and push those changes, rather than making changes through ReadMe's UI/API/MCP server
  - Configuring BiDi Sync is not supported via MCP and must be done via the UI
  - Github and Gitlab are supported, with BitBucket in beta (contact support)
  - **If you have been instructed to make documentation changes in a docs repository (contains `docs/`, `reference/` etc.) or the user has specified that this is a bi-di synced repository, then make changes via git operations rather than via the MCP server.

## Confirming the active Project

Use the `execute-request` tool to execute a request against the `/v2/projects/me` to get information on the current project. If this project conflicts with what the user is asking for, or if there 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: mcp-auth
description: Configure authentication with ReadMe to manage documentation hosted on ReadMe. Use during first time setup, or when a project operation is rejected for missing, invalid, expired, or unresolved authentication.
---

# Recover ReadMe MCP authentication

## Workflow

1. **Classify.** Capture the failing operation and non-secret error response. Check whether the response actually indicates missing/rejected credentials rather than validation, insufficient permissions, plan restrictions, or a service outage.
   **Done:** There is an authentication failure to repair, or the error is handed back to its owning workflow.
2. **Identify the environment.** Establish the client that you are running in (for example Claude Code versus Claude Desktop Chat). Commonly you will have information available about the client and surface that you are running in; ask if unclear. Read only the matching [client connection reference](CLIENTS.md).
   **Done:** You understand what client you are running in, and have rea the client connection reference for that client.
3. **Setup.** If you have the API key already in the chat for the project the user is attempting to modify, and the client is one that you can update settings for without user's intervention then setup the connection yourself. Otherwise Direct the user to the intended ReadMe project's **Settings → API Keys** to get their API key (if you have the link to their documentation page, this is accessed by adding "#/settings/api-keys" to any url in that domain). If the client is one where you can configure the MCP configuration yourself, offer to setup the environment if they give you the API key, and tell them that they can setup the configuration themselves and give them the steps to do so.
   **Done:** The user confirms the credential is configured, or you have setup yourself.
4. **Verify and resume.** Use the `https://api.readme.com/v2/projects/me` endpoint via the MCP's `execute-request` to determine whether the correct project has been authenticated. After this, resume with the original operations that the user was attempting to do.
   **Done:** The intended project is reachable and the original workflow resumes, or the unresolved error is reported without repeated guesses.

## First time account setup

New accounts and projects are created through the `setup-project` skill - follow it rather than creating an account from here. If the user has an existing account, they must create their project via the UI and provide the API Key.

## Authentication scope

ReadMe API keys are scoped to a single project only. To edit multiple projects, it is recommended that you set up multiple MCP clients under different names - ie "docs-projectNameA", "docs-projectNameB" and set these up with their individual, project-based API keys.

ReadMe does not currently offer OAuth via MCP.

Referenced files: 6 — file references are metadata, not package contents.

View saved version →

---
name: mcp-server
description: Route ReadMe MCP calls to the right project and the right spec. Use before any request touching the user's own content - "our docs", "my hub", "create a page", "update the changelog", "what endpoints do we have", "search our guides", "how many page views", "top search terms", "send our API logs to ReadMe" - and before calling execute-request for the first time in a session.
---

# Which project does this call land in?

This plugin connects to `https://docs.readme.com/mcp`, which serves **ReadMe's own documentation**.
`search` and `fetch` answer questions about how ReadMe works. The user's project is reached only
through `execute-request` with their API key. Reads and writes land in different places.

Questions about ReadMe itself need nothing else: use `search` and `fetch` and answer.

## Tools on this server

| Tool | Answers for | Use it when |
| --- | --- | --- |
| `search`, `fetch` | ReadMe's own product documentation | The question is about how ReadMe works |
| `list-specs`, `list-endpoints`, `get-endpoint`, `search-endpoints` | ReadMe's API definitions, as documents | Looking up a route before calling it |
| `execute-request` | **The user's project**, with their key | Reading or changing anything of theirs |
| `update-docs`, `draft-changelog` | Nothing. They return instructions for you to carry out | You want the recommended procedure |

Tool availability is per-project configuration, not a fixed list. Call `tools/list` rather than
assuming a tool named here is present, and never assume one that is not.

## The three specs

`execute-request` reaches only servers declared in these definitions. There are three, and
`search-endpoints` searches all of them at once:

| Spec title | Server | Auth |
| --- | --- | --- |
| `ReadMe API` | `https://api.readme.com/v2` | Bearer `rdme_...` |
| `Developer Metrics API` | `https://metrics.readme.io` | HTTP basic, the key as username and an empty password |
| `Legacy API` | `https://dash.readme.com/api/v1` | HTTP basic |

**Use `ReadMe API` for all work on the user's content.** `Legacy API` is v1: it takes basic auth
rather than a bearer token, and it is unavailable to projects on ReadMe Refactored. `search-endpoints`
will surface its routes alongside the others — ignore them. Never fall back to v1 when a v2 call
fails.

## Finding a route

Do not guess paths or work from memory. `list-endpoints` returns every path and summary in a spec in
one cheap call; `get-endpoint` adds the full request and response schema for one of them, including
which routes exist only on ReadMe Refactored. Read them rather than reproducing them here.

Two things the definitions do not tell you:

- Paginated responses carry `paging.next`, `paging.previous`, `paging.first` and `paging.last`.
  Query with `page` and `per_page`, max 100 and max 50 on search.
- Enterprise child projects need the child's own key. Only the API-key routes take a `{subdomain}`,
  and `me` works there.

## Calling execute-request

```json
{
  "title": "ReadMe API",
  "harRequest": {
    "method": "get",
    "url": "https://api.readme.com/v2/projects/me"
  }
}
```

- `title` names the spec and is required whenever the server carries more than one, as this one does.
  Omitting it fails validation before the request is made.
- `url` must be absolute. `get-endpoint` and `search-endpoints` report paths relative to the server
  (`/projects/me`), so prepend `https://api.readme.com/v2` rather than pasting the path through.
- The key decides which project the call lands in, and the user cannot override it per-request.
  Name the project before you change anything; asking them which one to write to is misleading.

Setting up, verifying, or repairing that key is the `mcp-auth` skill.

## When the user asks about their own docs

"Search our docs", "what does our guide say", "find the page about X in my project" cannot be
answered by `search` or `fetch` here. Those read ReadMe's documentation and would return confiden

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: onboarding
description: Get a new customer from zero to a live ReadMe developer hub. Use when someone is new to ReadMe, asks what ReadMe is, wants to sign up, create a project, publish their first API reference or guide, or needs an API key for this plugin. Explains the product and walks the web-UI setup flow.
---

# ReadMe onboarding

> Onboarding endpoints are coming soon. Until then this skill only covers the web-UI flow and ReadMe basics.

## Tools

- `search`
- `fetch`
- `execute-request`

## What ReadMe is

ReadMe hosts a developer hub for your API at `{subdomain}.readme.io` or a custom domain. One hub contains:

| Section | Content |
| --- | --- |
| Guides | Markdown pages in categories, with a sidebar |
| API Reference | Interactive docs generated from an OpenAPI or Swagger definition, with a Try It console |
| Recipes | Step-by-step code walkthroughs |
| Changelog | Release notes, shared across versions |
| Custom Pages | Free-form Markdown or HTML pages |

Guides, reference, recipes and custom pages live on a **branch** (a version such as `1.0` or `stable`). The changelog does not. Ask AI and the project's MCP server answer questions from the hub content. Metrics track page views, search, page quality, and, with SDK setup, API calls.

Plans: Starter (free), Pro, Enterprise. Enterprise supports child projects and Developer Metrics API reads.

## Quick Start

1. Sign up at `https://dash.readme.com/signup`.
2. Click **Create New Project**. Set a name, upload a logo (ReadMe picks brand colors from it), and choose the subdomain.
3. Add the API definition under **API Reference**: upload an OpenAPI file, import a URL, build one from scratch, or run `npx rdme openapi upload <file>` from a terminal. ReadMe validates the file and renders every endpoint.
4. Write the first guide under **Guides**. Use the AI Agent for a draft or the editor for a blank page. A "Getting Started" page is the usual first one.
5. Generate an API key at **Configuration → API Keys**, URL `https://dash.readme.com/project/{subdomain}/v{version}/api-key`.
6. Attach the key. The plugin's own `readme` server is anonymous and cannot read the key. The user registers a server under the same name, which replaces the plugin's one. The command differs per client: use the registration table in the `mcp-auth` skill, which also covers repairing a key that is already set.
7. Verify: `execute-request` with spec title `ReadMe API`, `GET https://api.readme.com/v2/projects/me`. A 200 with the project name means the plugin is wired to the right project. `Missing Security Schemes` means the registration is sending no key; a 401 titled `The API key couldn't be located.` means the key is wrong; a 500 titled `An unknown error has occurred.` means it resolved to an empty string. In every case, go back to step 5.

After step 7, the `mcp-server` skill covers which spec and which project everything else lands in.

## Driving the browser yourself

Steps 1 to 5 are all browser work. If you can drive a browser, offer to do them in the user's own browser instead of only listing the steps: open the signup page, create the project, upload the API definition, and open the API Keys page. Let the user type credentials and payment details themselves. Steps 6 and 7 stay in the terminal.

Find the row for the client you are running in. If you cannot tell which one that is, ask rather than guess.

| Client | Drive the browser with |
| --- | --- |
| Claude Code | `mcp__claude-in-chrome__*`, when the Claude in Chrome extension is connected |
| ChatGPT desktop app or ChatGPT web | `@Browser`. It has its own profile, so the user signs in to ReadMe there, and it asks before submitting forms. It cannot upload files, so for step 3 import the API definition by URL or run `npx rdme openapi upload <file>` from a terminal |
| Codex CLI, Codex IDE extension, Cursor | No browser of their own. List the steps for the user |

## When you cannot install anything yourself

On a chat surface you have 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: setup-project
description: Create a new ReadMe Docs project, including new account creation for those without an existing account.
---

# Set up a ReadMe project

This skill walks through the steps to setup a new ReadMe project, including the available options and required MCP configuration.

## Requirements

- This skill assumes that the ReadMe MCP server has been configured. If you do not have the ReadMe MCP available, you must first follow the steps in the `mcp-auth` skill for the specific client and setup the ReadMe MCP server before you can setup a new ReadMe project. Note that you don't need to connect up to an actual project if the user is creating a new account.
- Currently new project setup is only allowed if the user does not have an existing ReadMe account. If the user has an existing account, they must create their new project in the ReadMe UI, and follow the instructions in `mcp-auth` to get their project API key loaded into configuration.

**Done**
- You are connected to the ReadMe MCP server
- You have confirmed that the user is creating this project with a new account, OR if they have an existing account they've manually created it in the UI and have set you up with the API Key:
  - You should have used `execute-request` on the `/v2/projects/me` endpoint and have confirmed that the configuration is correct

## Workflow

### 1. Gather Required Information

Before creating the account and project for the user, you should verify that you have all of the required information to seed their project with some initial content for them to view. Having a project with some details already configured is a much better experience than putting them into an empty, generic project setup.

You should clarify the following with the user:

#### Information Source

What information will you be provided to create the docs for this user? Options include but are not limited to:

- An existing documentation repository that they want to connect via BiDi Sync (see #bidi-sync)
- An existing documentation site that they want to copy verbatim (see #docs-site-import)
- A non docs-website that has relevant information (ie their marketing site)
- Local files that they want to use as information to create a new docs site
- A summary that they will type out for what they want to configure
- An existing code repository that you will read to create docs from
- An existing OAS spec (see #oas-upload)

Note that the user may have one or more of these, and it is not an exhaustive list.

**Done**
You have the information that will be used to create at least the first few pages in the project, and you have verified that you can read these. If you cannot access, tell the user that you cannot and ask if they can provide or whether they would prefer to continue without this information.

#### Branding/Styling

Does the user have an existing color system/style guide? May include but not be limited to:

- Logo(s) and favicon
- Color systems - there are colors available for:
  - Brand (primary) color
  - Links color (if not given use the brand color they give)
  - Backgrount (if not given don't specify)
  - Sidebar Border (if not given don't specify)
  - Borders color (if not given don't specify)
  - BreadCrumts (use brand color if not specified)
  - Tint (accent color)
  - Ask AI (if not given don't specify)
  However, to keep it simple it is usually good to just get the primary/accent colors.

Note that its fine if the user doesn't have anything for this, since its styling that they can configure later via UI.

**Done**
When the user has either:

- Provided styling content; or
- Has said that they don't have any content to give you

#### Gather Account + Project Information (Optional)

IF the user is creating a new account + project, then you also need:

- The user's name
- The user's email
- The project's name

Instruct the user its VERY important that they have access to this email:

- This email owns the project and is the one used for account 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: update-project-settings
description: View and update ReadMe project settings, including appearance, branding, AI features, MCP server settings, agent discovery, llms.txt, SEO, access and domains, API reference, localization, and integrations. Use when a user wants to configure any settings on their ReadMe docs site.
---

# Update ReadMe project settings

Note - these settings are only configurable via the ReadMe MCP Server - BiDi sync users must use the server or configure on their ReadMe site.

## Workflow

1. **Target.** Retrieve the current project via `execute-request` with `GET https://api.readme.com/v2/projects/me` and confirm it is the project the user means. Note `parent` (enterprise) and `plan.type`.
   **Done:** The intended project is confirmed and its current settings are in hand.
2. **Locate.** Match the request to a category and read its corresponding category file. When the user asks broadly (e.g. "what can I change about my styling?"), offer that category's common operations. Inspect the `updateProject` schema with `get-endpoint` for the exact fields.
   **Done:** Every requested change maps to a schema field or to a named dashboard-only action.
3. **Plan.** Show the current and proposed value for every field. Flag each change that is noted as being plan-gated, needs an extra purchase, may be overridden by an enterprise parent, or is write-only (see [How project settings behave](#how-project-settings-behave)). Get explicit approval: changes go live as soon as they are saved and make sure the user is aware of this.
   **Done:** The user has approved every field change, with the before values recorded for rollback.
4. **Apply.** Complete any upload step the category file names first. Send `PATCH https://api.readme.com/v2/projects/me` containing only the approved fields.
   **Done:** The request returned 200, or the error is reported with the field it names.
5. **Verify.** Retrieve the project again and compare every changed field with the plan. A field that kept its old value usually means a plan gate. Confirm write-only fields in the dashboard unless the category file says otherwise, and hand visual checks to the user.
   **Done:** Every approved field matches the plan, or each mismatch is reported with its likely cause.

## How project settings behave

- **Live immediately.** Settings are project-wide, apply to every branch and version, and are visible to readers as soon as they are saved. There is no draft or preview, so the recorded before values are the rollback.
- **Partial updates.** Send only the fields being changed; nested objects merge with the stored values.
- **Arrays are replaced in full.** Any array you send becomes the complete new value. Read the current array, edit it, and send the whole array back; sending one item deletes the rest. Category files name the exceptions. Keyed maps vary, so read the field's schema description before writing one.
- **Read-only fields.** Fields whose schema description says "Read-only" are ignored on write.
- **Write-only fields.** Fields marked write-only, such as site and MCP passwords and OAuth client secrets, can be set but are never returned. Other secrets, such as the JWT secret and integration keys, are returned to admins.
- **Plan-gated settings.** Some settings need a higher plan, such as Pro or Enterprise. Writes to a gated setting are silently ignored: the request still returns 200 and the old value stays. Category files mark each operation's tier. Check `plan.type` before writing, and don't write a setting below its tier. If the user wants to upgrade their plan, send the user to their plan page, reached by adding `#/settings/manage-plans` to any URL on their documentation domain.
- **Extra purchases.** Some features need an add-on beyond any plan, such as AI-enabled translations. Direct the user to sales@readme.io.
- **Enterprise parent projects.** A non-null `parent` means the project is a child in an enterprise group. Depending on the setting

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.