Skip to main content

AI Agent Guide: Creating New Documentation

When to create: Feature gaps, user confusion, missing tutorials, new functionality.

When to Create New Documentation

Documentation Gaps to Fill

Gap TypeExamplePriority
Feature exists but no docsNew playlist feature undocumentedHigh
User confusion reportedSupport tickets about same processHigh
Complex workflowMulti-step producer onboardingMedium
Reference neededAPI endpoint undocumentedMedium
Best practicesOptimizing track uploadsLow

Before Creating: Check if Doc Already Exists

# Search existing documentation
grep -r "featureName" Documentation/help/ --include="*.mdx"

# Check if topic is covered in related docs
grep -r "topicKeyword" Documentation/help/[section]/ --include="*.mdx"

# Look for index pages that might cover it
cat Documentation/help/[section]/index.mdx | grep -i "topic"
Don’t duplicate: If topic exists, update existing doc rather than creating new one.

The New Documentation Process

Step 1: Research and Discovery

A. Understand the Feature

Questions to answer:
  1. What does this feature do?
  2. Who is it for? (audience)
  3. How do users access it? (navigation)
  4. What are the prerequisites?
  5. What are the common use cases?
  6. What are the limitations or edge cases?
Research sources:
# UI components
grep -r "FeatureName" resources/client/ --include="*.tsx"

# Backend logic
grep -r "FeatureName" app/ --include="*.php"

# Routes
grep -r "feature-route" routes/ --include="*.php"

# Database
grep -r "feature_table" database/migrations/ --include="*.php"

B. Verify Navigation Paths

Critical: Document the actual user journey, not assumed paths.
# Check menu items
php artisan tinker --execute="$menus = json_decode(\DB::table('settings')->where('name', 'menus')->first()->value, true); foreach($menus as $menu) { if (in_array('auth-dropdown', $menu['positions'] ?? [])) { foreach($menu['items'] as $item) { echo $item['label'] . ' → ' . $item['action'] . PHP_EOL; } } }"

# Check specific UI components
cat resources/client/web-player/[feature]/[component].tsx | grep -E "(button|label|title)"
Trace the full path:
  1. Starting point (e.g., profile menu)
  2. Intermediate steps (if any)
  3. Final destination
  4. Available actions on that page
Find connections:
# What docs might link to this?
grep -r "relatedTopic" Documentation/help/ --include="*.mdx" -l

# What will this doc link to?
grep -r "prerequisiteFeature" Documentation/help/ --include="*.mdx" -l
Plan cross-links:
  • Parent/child relationships
  • Before/after dependencies
  • Related features
  • Prerequisite knowledge

Step 2: Determine Documentation Type

TypePurposeStructure
OverviewIntroduce feature areaWhat, why, who, where
How-toStep-by-step guidePrerequisites, steps, outcomes
ReferenceTechnical detailsTables, specifications, lists
TutorialLearn by doingContext, steps, verification
FAQCommon questionsQ&A format
ConceptExplain ideasExplanations, analogies

Step 3: Choose Location and Filename

Folder Structure

Documentation/help/
├── [section]/                    # e.g., billing, account-settings
│   ├── index.mdx                # Section overview
│   └── [specific-topic].mdx     # Individual pages

Naming Conventions

TypePatternExample
Overviewindex.mdxbilling/index.mdx
How-toaction-topic.mdxcancelling-subscription.mdx
Referencetopic-reference.mdxmetrics-glossary.mdx
Subtopicparent/child.mdxpassword/changing-password.mdx
Rules:
  • Use lowercase with hyphens
  • Be descriptive but concise
  • Match URL structure to content hierarchy
  • Group related topics in subfolders

Step 4: Create Frontmatter

Required fields:
---
audience: help
title: "Descriptive Page Title"
sidebarTitle: "Short Title"          # If different from title
description: "One-line summary for SEO and previews."
---
Audience values:
  • help — General user documentation
  • developers — API/technical docs
  • admins — Admin panel documentation
Title guidelines:
  • 40-60 characters ideal
  • Include key feature name
  • Action-oriented for how-tos
  • Descriptive for reference
Description guidelines:
  • 120-160 characters ideal
  • Include key search terms
  • Explain what user will learn
  • Active voice

Step 4.5: Check for Applicable Snippets

Before writing any content, check if reusable snippets already exist for common patterns:
# List all available snippets
ls Documentation/snippets/callouts/ Documentation/snippets/warnings/ Documentation/snippets/sections/
Check the snippet for each pattern:
If your page needs…Use this snippet
Platform fee explanationimport PlatformFee from "/snippets/callouts/platform-fee.mdx";
”Need Help?” footer sectionimport NeedHelp from "/snippets/sections/need-help.mdx";
”Still Need Help?” with stepsimport StillNeedHelp from "/snippets/sections/still-need-help.mdx";
Inline support contact lineimport SupportContact from "/snippets/sections/support-contact.mdx";
Paid plan required noticeimport SubscriptionRequired from "/snippets/callouts/subscription-required.mdx";
Stripe Connect required noticeimport StripeConnectRequired from "/snippets/callouts/stripe-connect-required.mdx";
Producer-only feature noticeimport ProducerOnly from "/snippets/warnings/producer-only.mdx";
API invite-only warningimport ApiInviteOnly from "/snippets/warnings/api-invite-only.mdx";
Plan comparison tableimport PlanComparisonTable from "/snippets/data/plan-comparison-table.mdx";
Rule: Never write inline content that duplicates an existing snippet. Always import the snippet instead. See Mintlify Reference — Reusable Snippets for the full list and usage details.

Step 5: Structure Content

Standard Page Structure

---
audience: help
title: "Page Title"
description: "Brief description for SEO."
---

import NeedHelp from "/snippets/sections/need-help.mdx";
import PlatformFee from "/snippets/callouts/platform-fee.mdx";

# Page Title

Brief introduction (1-2 sentences explaining what this covers).

## Prerequisites (if any)

- Required plan/permission
- Previous setup needed
- Knowledge requirements

## Main Content Sections

### Section 1: Getting There

Navigation instructions with exact UI labels.

### Section 2: Using the Feature

Step-by-step instructions.

<PlatformFee />   {/* Use snippets for common callouts */}

### Section 3: Understanding Results

What to expect, how to verify success.

## Common Issues (optional)

<AccordionGroup>
  <Accordion title="Issue 1">
    Solution...
  </Accordion>
</AccordionGroup>

<NeedHelp />   {/* Use snippet for standardized support footer */}

## Related

- [Related topic](/help/path)
- [Next step](/help/path)

Content Section Guidelines

SectionPurposeLength
IntroductionContext and preview2-3 sentences
PrerequisitesWhat you need firstBullet list
StepsHow to do itNumbered, 3-7 items
ExplanationWhy it works1-2 short paragraphs
ExamplesSee it in action1-2 concrete examples
TroubleshootingFix problemsAccordion format
RelatedWhere to go next3-5 links

Step 6: Write Content

Use Verified Information Only

For every claim:
  1. State what you found in codebase
  2. Use exact UI labels
  3. Provide specific numbers
  4. Link to related verified docs
Example:
To manage your subscription, click your **profile avatar** in the top navigation bar, then select **Billing**. 

The **Current plan** section shows your active subscription. Click **Change plan** to switch plans.
NOT:
Go to Settings → Subscription to manage your plan.
Click the Change Plan button.
Link when:
  • Mentioning a related feature
  • Referencing a prerequisite
  • Suggesting next steps
  • Providing alternatives
Format:
Before continuing, ensure you've [set up your producer profile](/help/producer-program/after-approval).

See also: [Managing your tracks](/help/producer-dashboard/tracks)
Always root-relative: /help/path not ../path

Step 7: Add Mintlify Components

Approved Components for Documentation

Use for:
  • Cards — Related documentation, feature highlights
  • CardGroup — Multiple related links
  • Steps — Numbered instructions
  • Accordion/AccordionGroup — FAQs, troubleshooting
  • Callouts (Info, Warning, Tip, Note) — Important notices
  • Tables — Reference data, comparisons
  • Badges — Status indicators
  • Tooltips — Inline definitions of jargon or technical terms (first occurrence per page only)
Don’t use:
  • Complex code blocks (unless developer docs)
  • Videos
  • External embeds
  • Custom components

Component Examples

<CardGroup cols={2}>
  <Card title="Setting Up" icon="gear" href="/help/producer-program/after-approval">
    Complete your producer profile setup
  </Card>
  <Card title="Uploading Tracks" icon="cloud-arrow-up" href="/help/producer-dashboard/tracks">
    Learn the track upload process
  </Card>
</CardGroup>

<Steps>
  <Step title="Navigate to Billing">
    Click your **profile avatar**, then select **Billing**.
  </Step>
  <Step title="Select New Plan">
    Click **Change plan**, then choose your new plan.
  </Step>
</Steps>

<Warning>
  Cancelling your plan will remove access to premium features at the end of your billing period.
</Warning>

<Tooltip tip="Credits that control how many beat requests you can create each month. Your plan determines your allowance." cta="Learn more" href="/help/beat-requests/understanding-tokens">Tokens</Tooltip> are used to create requests.

New Documentation Checklist

Pre-Writing

  • Feature existence verified in codebase
  • Navigation paths verified
  • UI labels confirmed
  • Database values queried (if applicable)
  • Related documentation identified
  • Doc type determined
  • Location and filename chosen

Writing

  • Frontmatter complete and accurate
  • Introduction explains what doc covers
  • Prerequisites listed (if any)
  • Steps use exact UI labels (bold)
  • Navigation instructions verified
  • No technical jargon users don’t see
  • Specific numbers and names used
  • Mintlify components used appropriately
  • Tooltips added for domain jargon and technical terms (first occurrence per page)
  • Snippets used for all applicable patterns (platform fee, need help, warnings)
  • No inline duplication of content that exists as a snippet

Post-Writing

  • All claims verifiable
  • Links use root-relative paths
  • Related docs cross-linked
  • Tone appropriate for audience
  • Length appropriate (not too long)
  • Self-review completed
  • Mental walkthrough of steps done
  • Snippet imports use absolute paths (/snippets/...)

Common New Documentation Mistakes

❌ Don’t Do This

  1. Documenting non-existent features
    • Verify feature exists before writing
    • Search codebase thoroughly
    • Query database if needed
  2. Assumed navigation
    • Never write navigation without verifying
    • Check actual menu items
    • Test the path mentally
  3. Wrong location
    • Don’t create orphan pages
    • Place in logical section
    • Link from parent index
  4. Missing frontmatter
    • Every doc needs frontmatter
    • Include all required fields
    • Use correct audience value
  5. No cross-links
    • Link to related docs
    • Link from related docs (update them)
    • Create content web, not islands
  6. Too long
    • Break into multiple pages if needed
    • Write user-focused content that explains actions and outcomes—not implementation details.
Content Guidelines:
Write ThisNot This
”Click Upload to add your track""The upload controller handles file processing"
"Your payment is processed securely""The Stripe webhook processes payment_intent events"
"You’ll receive a confirmation email""The notification service queues the email job"
"Your profile is updated instantly""The database transaction commits the changes”
Release Notes Must Be:
  • Benefits-focused (what users gain)
  • Action-oriented (what users can do)
  • Free of technical implementation details
  • Easy to scan and understand
Example Release Note:
✅ Correct:
## Instant Playlist Collaboration

You can now invite other producers to collaborate on your playlists 
in real-time. Perfect for joint projects, compilations, or curated 
collections.

**What's New:**
- **Invite collaborators** — Add producers to your playlists
- **Real-time sync** — Changes appear instantly for all collaborators  
- **Permission controls** — Set who can edit or view

❌ Wrong:
## Playlist Collaboration API

We've implemented the playlist collaboration feature using WebSocket 
connections and role-based access control through the `playlist_collaborator` 
table.

**Technical Details:**
- WebSocket server handles real-time updates
- RBAC system manages permissions  
- New database schema for storing collaborators
  1. Wrong tone
    • Match existing docs in section
    • User-focused, not technical
    • Active voice
  2. Incomplete information
    • Cover the full user journey
    • Include edge cases if relevant
    • Add troubleshooting if common issues exist
  3. Not using snippets
    • Wrong: Writing a custom “Need Help?” section or platform fee callout inline
    • Fix: Import the existing snippet (<NeedHelp />, <PlatformFee />, etc.)
    • Check /snippets/ directory before writing common patterns
  4. Hardcoding values that may change
    • Wrong: Writing contact@beatpass.ca or 12% + $3 directly in content
    • Fix: Use the appropriate snippet so changes propagate from one source

Template: New How-To Document

---
audience: help
title: "How to [Do Something]"
description: "Step-by-step guide to [achieve result] on BeatPass."
---

import NeedHelp from "/snippets/sections/need-help.mdx";
{/* Import other applicable snippets: PlatformFee, SubscriptionRequired, etc. */}

# How to [Do Something]

[Brief introduction: what this accomplishes and who it's for.]

## Prerequisites

- [Requirement 1]
- [Requirement 2]

## Instructions

### Step 1: [Navigate to Location]

[Exact navigation with bold UI labels]

### Step 2: [Take Action]

[What to click/do with exact labels]

### Step 3: [Verify Result]

[What success looks like]

## Troubleshooting

<AccordionGroup>
  <Accordion title="[Common Issue 1]">
    [Solution]
  </Accordion>
  <Accordion title="[Common Issue 2]">
    [Solution]
  </Accordion>
</AccordionGroup>

<NeedHelp />

## Related

- [Related topic](/help/path)
- [Next step](/help/path)

Template: New Overview Document

---
audience: help
title: "[Feature Area] Overview"
description: "Learn about [feature area] and how it helps you [benefit]."
---

import NeedHelp from "/snippets/sections/need-help.mdx";
{/* Import other applicable snippets based on content needs */}

# [Feature Area] Overview

[What this feature area does and why it matters.]

## What You Can Do

<CardGroup cols={2}>
  <Card title="[Action 1]" icon="[icon]" href="/help/path">
    [Brief description]
  </Card>
  <Card title="[Action 2]" icon="[icon]" href="/help/path">
    [Brief description]
  </Card>
</CardGroup>

## Key Concepts

- **[Concept 1]**: [Explanation]
- **[Concept 2]**: [Explanation]

## Getting Started

[Link to first how-to or tutorial]

<NeedHelp />

## Learn More

- [Subtopic 1](/help/path)
- [Subtopic 2](/help/path)

Quick Reference: File Placement

If documenting…Place in…Example filename
Account settings featureaccount-settings/two-factor-authentication.mdx
Billing functionalitybilling/managing-subscription/upgrading-plan.mdx
Producer toolsproducer-dashboard/tracks.mdx
Release informationrelease-notes/v3.0/3.0.8-26.mdx (individual page)
Changelog entryrelease-notes/Add Update to changelog.mdx
Help overviewhelp/ rootindex.mdx
Release notes require two files: an individual page in release-notes/v3.0/{version}.mdx AND an Update component entry at the top of release-notes/changelog.mdx. See template.mdx for the complete workflow.

Remember: Good documentation fills a gap users actually have. Research first, write second, verify always.

Last modified on February 7, 2026