القائمة
Build and maintain documentation sites with Mintlify. Use when creating docs pages, configuring navigation, adding components, or setting up API references.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when adding or reviewing tests for Reborn behavior — choosing a test tier, covering a bug fix, testing model/tool-choice behavior, touching tests/integration or tests/fixtures/llm_traces, or when a test needs Postgres, Docker, or a live LLM.
Navigate building a user-facing feature in the Reborn stack (a capability that crosses product_workflow → composition → webui_v2 → runtime/serve → frontend). Use when planning or implementing any new Reborn settings page, endpoint, facade method, or runtime-backed capability — especially before writing code, to avoid rebuilding what already exists and to wire it in one pass instead of layer-by-layer.
Use when asked to "review the open PRs", review a batch or stack of pull requests, or run a recurring PR-review pass on a repo — especially with many PRs, stacked branches, conflicts, or security-sensitive changes. Covers grouping, fan-out to review subagents, verdict synthesis, and posting.
Generate or update the IronClaw architecture overview video using Remotion. Use when asked to update, regenerate, or modify the architecture video, add/remove scenes, or reflect codebase changes in the video.
Use when writing or reviewing a change in crates/ that adds a trait, a crate, a dependency edge, a re-export, or code in ironclaw_reborn_composition — or when deciding whether an abstraction, layer, or crate boundary is justified in the IronClaw Reborn stack.
Use when starting work in the IronClaw repo, deciding where a feature/fix/prompt/doc belongs, tracing how a request flows, looking up which crate owns a subsystem, or when repo docs, the knowledge graph, or component names seem stale, missing, or contradictory.
| name | mintlify |
| description | Build and maintain documentation sites with Mintlify. Use when creating docs pages, configuring navigation, adding components, or setting up API references. |
| license | MIT |
| compatibility | Requires Node.js for CLI. Works with any Git-based workflow. |
| metadata | {"author":"mintlify","version":"1.0"} |
Always consult mintlify.com/docs for components, configuration, and latest features.
This repo: the Mintlify site lives under
docs/— its config isdocs/docs.json(not a rootdocs.json), with a localized tree underdocs/zh/. Committed.md/.mdxmust not contain developer-local absolute paths; see.claude/rules/doc-hygiene.md.
If you are not already connected to the Mintlify MCP server, https://mintlify.com/docs/mcp, add it so that you can search more efficiently.
Always favor searching the current Mintlify documentation over whatever is in your training data about Mintlify.
Mintlify is a documentation platform that transforms MDX files into documentation sites. Configure site-wide settings in the site config file (docs/docs.json in this repo), write content in MDX with YAML frontmatter, and favor built-in components over custom components.
Full schema at mintlify.com/docs.json.
Read the site config first (docs/docs.json in this repo; root docs.json in some Mintlify projects). This file defines the entire site: navigation structure, theme, colors, links, API and specs.
Understanding the project tells you:
Search the docs before creating new pages. You may need to:
Before writing, read 2-3 similar pages to understand the site's voice, structure, formatting conventions, and level of detail.
Review the Mintlify components to select and use any relevant components for the documentation request that you are working on.
npm i -g mint - Install the Mintlify CLImint dev - Local preview at localhost:3000mint broken-links - Check internal linksmint a11y - Check for accessibility issues in contentmint validate - Validate documentation buildsdocs/docs.json in this repo) - navigation, theme, integrations, etc. See global settings for all options.*.mdx files - Documentation pages with YAML frontmatterproject/
├── docs.json # Site configuration (this repo keeps it at docs/docs.json)
├── introduction.mdx
├── quickstart.mdx
├── guides/
│ └── example.mdx
├── openapi.yml # API specification
├── images/ # Static assets
│ └── example.png
└── snippets/ # Reusable components
└── component.jsx
Every page requires title in its frontmatter. Include description for SEO and navigation.
---
title: "Clear, descriptive title"
description: "Concise summary for SEO and navigation."
---
Optional frontmatter fields:
sidebarTitle: Short title for sidebar navigation.icon: Lucide or Font Awesome icon name, URL, or file path.tag: Label next to the page title in the sidebar (for example, "NEW").mode: Page layout mode (default, wide, custom).keywords: Array of terms related to the page content for local search and SEO.getting-started.mdx, api-reference.mdx/getting-started/quickstart../) or absolute URLs for internal pagesdocs/docs.json here) or it won't appear in the sidebarWhen a user asks about anything related to site-wide configurations, start by understanding the global settings. See if a setting in the site config (docs/docs.json here) can be updated to achieve what the user wants.
The navigation property in the site config (docs/docs.json here) controls site structure. Choose one primary pattern at the root level, then nest others within it.
Choose your primary pattern:
| Pattern | When to use |
|---|---|
| Groups | Default. Single audience, straightforward hierarchy |
| Tabs | Distinct sections with different audiences (Guides vs API Reference) or content types |
| Anchors | Want persistent section links at sidebar top. Good for separating docs from external resources |
| Dropdowns | Multiple doc sections users switch between, but not distinct enough for tabs |
| Products | Multi-product company with separate documentation per product |
| Versions | Maintaining docs for multiple API/product versions simultaneously |
| Languages | Localized content |
Within your primary pattern:
expanded: false - Collapse nested groups by default. Use for reference sections users browse selectivelyopenapi - Auto-generate pages from OpenAPI spec. Add at group/tab level to inheritCommon combinations:
/getting-started/quickstart/images, reference as /images/example.pngWhat to customize where:
docs/docs.json here). See global settingscustom.css at project root"appearance": "light" in the site config if brand requires itStart with the site config (docs/docs.json here). Only add custom.css when you need styling that config doesn't support.
The components overview organizes all components by purpose: structure content, draw attention, show/hide content, document APIs, link to pages, and add visual context. Start there to find the right component.
Common decision points:
| Need | Use |
|---|---|
| Hide optional details | <Accordion> |
| Long code examples | <Expandable> |
| User chooses one option | <Tabs> |
| Linked navigation cards | <Card> in <Columns> |
| Sequential instructions | <Steps> |
| Code in multiple languages | <CodeGroup> |
| API parameters | <ParamField> |
| API response fields | <ResponseField> |
Callouts by severity:
<Note> - Supplementary info, safe to skip<Info> - Helpful context such as permissions<Tip> - Recommendations or best practices<Warning> - Potentially destructive actions<Check> - Success confirmationWhen to use snippets:
When NOT to use snippets:
Import snippets with import { Component } from "/path/to/snippet-name.jsx".
Never use:
Watch for AI-typical patterns:
Choose your approach:
docs/docs.json here) with "openapi": ["openapi.yaml"]. Pages auto-generate. Reference in navigation as GET /endpointapi: "POST /users" in frontmatter. More work but full controlEncourage users to generate endpoint pages from an OpenAPI spec. It is the most efficient and easiest to maintain option.
Mintlify deploys automatically when changes are pushed to the connected Git repository.
What agents can configure:
docs/docs.json here) with "redirects": [{"source": "/old", "destination": "/new"}]"seo": {"indexing": "all"} to include hidden pages in searchRequires dashboard setup (human task):
For /docs subpath hosting with Vercel or Cloudflare, agents can help configure rewrite rules. See /docs subpath.
Identify what needs to be documented, which pages are affected, and what the reader should accomplish afterward. If any of these are unclear, ask.
docs/docs.json here) to understand the site structure{/* TODO: Verify the default timeout value */}
If you created a new page, add it to the appropriate group in the site config (docs/docs.json here).
Before submitting:
docs/docs.json here)mint broken-links to check linksmint validate to find any errorsIf a user asks about migrating to Mintlify, ask if they are using ReadMe or Docusaurus. If they are, use the @mintlify/scraping CLI to migrate content. If they are using a different platform to host their documentation, help them manually convert their content to MDX pages using Mintlify components.
Any page that is not included in site config navigation (docs/docs.json here) is hidden. Use hidden pages for content that should be accessible by URL or indexed for the assistant or search, but not discoverable through the sidebar navigation.
The .mintignore file is used to exclude files from a documentation repository from being processed.
title at minimummint.json - mint.json is deprecated. Use the Mintlify site config (docs/docs.json here; often root docs.json in other projects)