This document provides guidelines for AI agents working with the SuperPlane documentation repository.
This repository contains the documentation for SuperPlane, an open source DevOps control plane. The documentation site is built with Starlight, a documentation framework built on Astro.
src/content/docs/- All documentation content (.mdand.mdxfiles)- Each file becomes a route based on its file name
- Organized by topic (e.g.,
installation/,reference/)
src/assets/- Images and other assets referenced in documentationpublic/- Static assets like faviconsastro.config.mjs- Starlight configuration (sidebar, title, etc.)
Documentation files follow a hierarchical structure:
get-started/- Getting started guidesinstallation/- Installation instructionslocal.md- Local installationsingle-host/- Single host deploymentskubernetes/- Kubernetes deployments
reference/- Reference documentation
All documentation files should include frontmatter with:
title- Page titledescription- Page description (optional but recommended)
Example:
---
title: Page Title
description: Brief description of the page content
---Aim for the “classic devtool docs” voice: clear, direct, and pragmatic, with a little personality — but not inside-baseball.
- Prefer plain language over clever phrasing. Avoid idioms that require shared context (e.g., “do the thing”).
- Write like Stripe-style docs / good OSS docs: short sentences, specific claims, strong structure.
- Keep marketing minimal. When describing value, anchor it in what the user can do and what problem it solves.
- Use examples to spark imagination: focus on outcomes and cross-tool workflows.
- Avoid overly specific “demo numbers” or sequences unless the doc is a step-by-step tutorial.
- Write clear, concise documentation
- Limit markdown files to 120 characters width
- Use code blocks with appropriate language tags
- Include prerequisites when relevant
- Link to related documentation when helpful
- Use relative paths for internal links
- Use the same core terms consistently: canvas, node, component, run, run item, payload, channel, subscription, expression.
- When introducing a term for the first time on a page, consider linking to the glossary.
- Use appropriate syntax highlighting
- Include complete, runnable examples when possible
- Add comments to explain complex steps
- Specify version numbers or tags when relevant (e.g., Docker image tags)
- Place images in
src/assets/ - Reference them with relative paths in Markdown
- Use descriptive filenames
- Include alt text for accessibility
- Prefer Starlight autogenerated sections (
autogenerate) for directories that will grow (e.g.reference/,components/). - If you add a manual sidebar entry, ensure the slug exists and the site builds. A bad slug fails the build.
- Avoid leaving unused “template” pages around; they can create confusing routes or warnings.
- Create a new
.mdor.mdxfile in the appropriate directory undersrc/content/docs/ - Add frontmatter with
titleanddescription - Write the content following existing patterns
- Update
astro.config.mjsif you need to modify the sidebar structure
- Locate the file in
src/content/docs/ - Maintain the existing structure and style
- Update frontmatter if the title or description changes
- Ensure links remain valid
- Save the image to
src/assets/ - Reference it in Markdown:
 - Adjust the relative path based on the documentation file's location
npm install- Install dependenciesnpm run dev- Start local dev server atlocalhost:4321npm run generate:llms- Generatepublic/llms.txtandpublic/llms-full.txtnpm run build- Build production sitenpm run preview- Preview production build locally
When making content or navigation changes, run npm run build to catch:
- invalid slugs
- missing/invalid frontmatter
- broken asset paths
@astrojs/starlight- Starlight documentation frameworkastro- Astro frameworksharp- Image processing
- Consistency: Follow existing documentation patterns and structure
- Clarity: Write for users who may be new to SuperPlane
- Completeness: Include all necessary steps and prerequisites
- Accuracy: Ensure code examples and commands are correct and tested
- Organization: Place content in the appropriate directory based on topic
- Links: Use relative paths for internal documentation links
- Versioning: When mentioning versions or tags, be specific (e.g.,
v0.4,stable,beta)
- Always read existing documentation files to understand the style and structure before making changes
- When adding new content, check similar existing files for patterns to follow
- Maintain the hierarchical organization of documentation
- Update the sidebar source in
src/config/sidebar.mjsif adding new top-level sections - Test that relative paths for images and links are correct based on file location
- Preserve frontmatter structure when editing files
- When in doubt, follow the patterns established in existing documentation
- Treat
public/llms.txtandpublic/llms-full.txtas generated artifacts (do not edit manually)