Starlight Base Setup
Set up a new Astro Starlight documentation site from scratch. Use when creating a new Starlight project, adding Starlight to an existing Astro project, or configuring core options like sidebar, logo, social links, and page layout.
npx skills add github:pantheon-org/tekhne --skill documentation--astro-starlight--skills--starlight-baseStarlight is a full-featured documentation theme built on Astro. It ships with routing, search, dark mode, i18n, and accessibility — configure features rather than build them.
When to Use
- Creating a new documentation site with Astro and Starlight
- Adding Starlight to an existing Astro project
- Configuring core options (logo, sidebar, social links, etc.)
- Setting up content pages and navigation
When Not to Use
- Custom theming with CSS variables or Tailwind — use
starlight-themeinstead - Overriding built-in Starlight components — use
starlight-custom-componentinstead
Philosophy
Starlight = Astro integration + file-based routing + content collections.
- One integration, one config object. All options live inside
starlight({})inastro.config.mjs. No separate config file. - Files are pages. Every
.md/.mdxundersrc/content/docs/becomes a URL. File path = URL route. - Sidebar and routing are independent. You can have a page with no sidebar entry, or a sidebar entry for any slug. They are not coupled unless you use
autogenerate. - Configure, do not build. Prefer Starlight’s built-in features over hand-rolled replacements.
Quick Start
npm create astro@latest -- --template starlight
npm run dev
To add Starlight to an existing Astro project:
npx astro add starlight
Core Configuration
All options live inside starlight({}). See configuration-reference.md for the full option table.
import { defineConfig } from 'astro/config';
import starlight from '@astrojs/starlight';
export default defineConfig({
site: 'https://mydocs.example.com', // Required for sitemap
integrations: [
starlight({
title: 'My Docs',
logo: { src: './src/assets/logo.svg' },
social: [
{ icon: 'github', label: 'GitHub', href: 'https://github.com/my-org/repo' },
],
sidebar: [
{
label: 'Guides',
items: [
{ label: 'Getting Started', slug: 'guides/getting-started' },
],
},
{ label: 'Reference', autogenerate: { directory: 'reference' } },
],
editLink: { baseUrl: 'https://github.com/my-org/repo/edit/main/docs/' },
customCss: ['./src/styles/custom.css'],
}),
],
});
Content Pages
Create .md or .mdx files under src/content/docs/:
---
title: My Page Title
description: A short description for SEO.
---
Content goes here.
Use template: splash for landing pages, draft: true to exclude from builds:
---
title: Home
template: splash
hero:
tagline: Welcome to my docs
---
Anti-Patterns
NEVER add content outside src/content/docs/
WHY: Starlight’s routing only picks up files inside src/content/docs/. Consequence: Pages silently won’t appear.
BAD: Create .md in src/pages/.
GOOD: Create .md in src/content/docs/.
NEVER use src inside logo alongside light/dark
WHY: Mutually exclusive. src is for a single logo; light/dark are for variants. Consequence: Config error.
BAD: logo: { src: './logo.svg', light: './light.svg' }
GOOD:
logo: { light: './src/assets/light-logo.svg', dark: './src/assets/dark-logo.svg' }
NEVER hard-code sidebar slugs with leading slashes or file extensions
WHY: Slugs map to paths under src/content/docs/ with no leading slash and no .md extension. Consequence: Sidebar links 404.
BAD: slug: '/guides/setup.md'
GOOD: slug: 'guides/setup'
NEVER set site inside starlight({}) for sitemap
WHY: Sitemap generation requires site at the defineConfig level. Consequence: Sitemap not generated.
BAD: starlight({ site: 'https://...' })
GOOD: defineConfig({ site: 'https://...' })
NEVER mix autogenerate with items in the same sidebar group
WHY: A group uses either items or autogenerate, not both. Consequence: Build error.
BAD: { label: 'Guides', items: [...], autogenerate: { directory: 'guides' } }
GOOD: Choose one approach per group.
NEVER put Starlight options in a separate config file
WHY: All options live inside starlight({}) in astro.config.mjs. Consequence: Options in another file are never read.
BAD: Create starlight.config.mjs with title and sidebar.
GOOD: Put title and sidebar inside starlight({}).
NEVER assume a page appears in the sidebar just because the file exists
WHY: Sidebar and routing are independent unless you use autogenerate. Consequence: Reachable pages missing from navigation.
BAD: Add guides/setup.md and expect a sidebar entry.
GOOD: Add a slug: 'guides/setup' entry, or use autogenerate for the directory.
NEVER hand-roll the integration when astro add starlight exists
WHY: For an existing Astro project, npx astro add starlight installs the package and updates astro.config.mjs for you. Consequence: Manual edits risk a half-wired integration.
BAD: npm install @astrojs/starlight followed by manual config edits.
GOOD: npx astro add starlight
NEVER publish a work-in-progress page without draft: true
WHY: draft: true excludes the page from production builds. Consequence: Unfinished pages go live.
BAD: Commit an unfinished page with only title in frontmatter.
GOOD: Add draft: true to its frontmatter until it is ready.
NEVER use this skill for theming or component overrides
WHY: Those are separate concerns with their own skills. Consequence: Mixed guidance and wrong patterns.
BAD: Override Header here.
GOOD: Use starlight-theme for CSS variables and Tailwind and starlight-custom-component for component overrides.
References
| Topic | Reference | When to Use |
|---|---|---|
| Configuration options | Configuration Reference | Looking up the full option table |
| Getting started | Starlight Getting Started | Scaffolding a project |
| Configuration | Configuration Options | Checking option semantics |
| Frontmatter | Frontmatter Reference | Setting page fields such as template and draft |
| Sidebar | Sidebar Navigation Guide | Building navigation |
| Pages | Pages Guide | Adding content pages |
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
No eval scenarios available.
Starlight Configuration Reference
Quick-reference for the most commonly used starlight({}) options in astro.config.mjs.
Top-Level Options
| Option | Type | Description |
|---|---|---|
title |
string |
Required. Site title shown in header and page titles. |
description |
string |
Default meta description for all pages. |
logo |
LogoConfig |
Header logo. See Logo section below. |
social |
SocialLink[] |
Social media links in the header. |
sidebar |
SidebarItem[] |
Sidebar navigation configuration. |
editLink |
EditLinkConfig |
“Edit page” link configuration. |
customCss |
string[] |
CSS files to inject. Paths relative to project root. |
components |
ComponentsConfig |
Override built-in UI components. |
head |
HeadConfig[] |
Additional HTML elements to inject into <head>. |
favicon |
string |
Path to favicon (relative to public/). |
tableOfContents |
TableOfContentsConfig | false |
Global TOC configuration. |
lastUpdated |
boolean |
Show last-updated date on pages. |
pagination |
boolean |
Show previous/next page links. |
defaultLocale |
string |
Default locale for i18n. |
Logo Options
type LogoConfig =
| { src: string; replacesTitle?: boolean; alt?: string }
| { light: string; dark: string; replacesTitle?: boolean; alt?: string }
src and light/dark are mutually exclusive.
Sidebar Item Types
type SidebarItem =
| { label: string; slug: string } // Single link
| { label: string; items: SidebarItem[]; collapsed?: boolean } // Group with explicit items
| { label: string; autogenerate: { directory: string }; collapsed?: boolean } // Auto group
A group cannot have both items and autogenerate.
Social Link Icons
Full list from Starlight Icons Reference:
github, gitlab, discord, twitter, mastodon, linkedin, youtube, rss, email, external, seti, x.com
defineConfig Options (not in starlight({}))
| Option | Description |
|---|---|
site |
Canonical URL — required for sitemap generation |
base |
Base path for deployment to a subdirectory |
Project Structure
my-docs/
├── astro.config.mjs # Starlight integration config
├── src/
│ ├── assets/ # Images, logos
│ ├── content/docs/ # All documentation pages (.md / .mdx)
│ │ ├── index.md # Homepage (route: /)
│ │ └── guides/example.md # Route: /guides/example/
│ └── styles/ # Optional custom CSS
└── public/ # Static assets served as-is
Upgrading
npx @astrojs/upgrade