Use when documenting blueprints in create-faster MDX docs - covers pre-composed starter projects with composition, architecture, application code, CLI usage, and extra dependencies
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use when documenting blueprints in create-faster MDX docs - covers pre-composed starter projects with composition, architecture, application code, CLI usage, and extra dependencies
Documenting Blueprint
Overview
Document what create-faster generates for each blueprint. Focus on the composition, architecture, and application code โ not on teaching each library.
Core principle: Document the COMPOSITION and what APPLICATION CODE is included. For individual libraries in the composition, link to their standalone module/stack pages.
When to Use
Use when:
Adding a new blueprint documentation page
Updating existing blueprint docs after template changes
context.apps[] โ what stacks and libraries are pre-selected
context.project โ what project addons are pre-selected (database, orm, deployment)
packageJson โ extra dependencies ONLY for the blueprint (not from composition)
envs โ extra env vars ONLY for the blueprint (not from composition)
Blueprint templates override structural templates with the same destination path
Package.json is programmatic. Composition dependencies come from META stacks/libraries/addons. Blueprint packageJson only declares EXTRA dependencies.
Env vars are programmatic. Composition envs come from META libraries/addons. Blueprint envs only declares EXTRA env vars.
Structure Template
---
title: Blueprint Name
description: One-line description of the starter project (from META.blueprints[name].hint)
---## Presentation
Brief description of the complete starter project (2-3 sentences). What does the user get?
## Composition**Apps:**-`appName` โ Stack ([โ docs](/docs/stacks/stackname)) + modules ([โ module](/docs/modules/category/name), ...)
**Project addons:**- Database: [โ PostgreSQL](/docs/database/postgresql)
- ORM: [โ Drizzle](/docs/orm/drizzle)
- Deployment: [โ SST](/docs/deployment/sst) (if applicable)
## Architecture
File tree of the blueprint-specific application code (only what the blueprint ADDS beyond structural templates):
\`\`\`
src/
โโโ app/
โ โโโ page.tsx # Description
โ โโโ (section)/
โ โโโ layout.tsx # Description
โ โโโ page.tsx # Description
โโโ components/
โ โโโ component.tsx # Description
โโโ lib/
โโโ util.ts # Description
\`\`\`
For multi-app blueprints (turborepo), show per-app structure.
## What's included
Describe the key application features the blueprint provides. Keep it factual โ what pages exist, what functionality they have. Use subsections if the blueprint has multiple significant features.
Code examples ONLY for blueprint-specific patterns (e.g., custom auth integration, special middleware). Do NOT show code for standard library setup โ link to module docs instead.
## Extra dependencies
Only if `META.blueprints[name].packageJson` exists:
\`\`\`
package version purpose
recharts ^2.15.0 Dashboard charts
\`\`\`
## Environment variables
Only if `META.blueprints[name].envs` exists:
-`VAR_NAME` - Purpose (scope: app/root/pkg)
## CLI usage
\`\`\`bash
bunx create-faster myproject --blueprint {name} --linter biome --git --pm bun
\`\`\`
Documentation Workflow
Step 1: Analyze META for Blueprint Metadata
CRITICAL: META is the source of truth for composition, dependencies, and env vars.
# Check blueprint metadata in META
grep -A 40 "'{blueprintname}'" apps/cli/src/__meta__.ts
# Check composition: apps, stacks, libraries
grep -A 20 "context:" apps/cli/src/__meta__.ts | grep -A 15 "'{blueprintname}'"# Check extra dependencies
grep -A 10 "packageJson:" apps/cli/src/__meta__.ts | grep -A 8 "'{blueprintname}'"# Check extra env vars
grep -A 10 "envs:" apps/cli/src/__meta__.ts | grep -A 8 "'{blueprintname}'"
Step 2: Analyze Blueprint Template Files
# List all blueprint template files
find apps/cli/templates/blueprints/{blueprintname}/ -name "*.hbs" | sort# Check for frontmatter (path/scope overrides)
grep -l '^---' apps/cli/templates/blueprints/{blueprintname}/**/*.hbs
# Check for stack-specific templatesls apps/cli/templates/blueprints/{blueprintname}/**/*.*.hbs
# Check for mono/single filtering
grep 'only:' apps/cli/templates/blueprints/{blueprintname}/**/*.hbs
Document EXACTLY what files the blueprint adds. Cross-reference every claim with actual template files.
Step 3: Identify Overrides vs Additions
For each blueprint template file, determine:
Override โ replaces a structural template (same destination path as a stack/library template)
Addition โ new file not present in structural templates
Only document the blueprint-specific files. Don't document structural templates that pass through unchanged.
Step 4: Structure Document
Frontmatter (YAML):
title: Blueprint display name (from META.blueprints[name].label)
description: From META.blueprints[name].hint
CRITICAL - Don't add # Title:
Title in frontmatter already renders as H1. Adding # Title creates duplicate.
Document structure:
## Presentation โ what the user gets (complete starter project description)
## Composition โ stacks, libraries, project addons with links to their doc pages
## Architecture โ file tree of blueprint-specific files
## What's included โ application features and key code patterns
## Extra dependencies โ only blueprint-specific extras from META
## Environment variables โ only blueprint-specific extras from META
## CLI usage โ example command
Step 5: Focus on Blueprint-Specific Content
DO document:
The complete starter project description (what you get)
Full composition with links to individual stack/module/addon pages
Blueprint template files (verified in apps/cli/templates/blueprints/{name}/)
Application features (pages, layouts, components, routes)
Key code patterns unique to the blueprint (custom auth flows, special middleware)
Extra dependencies from META.blueprints[name].packageJson
Extra env vars from META.blueprints[name].envs
Multi-app architecture (for turborepo blueprints)
CI/CD workflows (if included in blueprint templates)
DON'T document:
How individual libraries work (link to module docs)
How the stack works (link to stack docs)
How the ORM/database works (link to their docs)
Standard library setup code (shadcn components, tRPC init, etc.)
Dependencies that come from the composition (they're in the library/stack META)
Env vars that come from the composition (they're in the library/addon META)
Structural template files that pass through unchanged
Step 6: Verify Every Claim
MANDATORY verification before publishing:
# Verify composition matches META
grep -A 30 "'{blueprintname}'" apps/cli/src/__meta__.ts
# Verify template files exist
find apps/cli/templates/blueprints/{blueprintname}/ -name "*.hbs" | sort# Verify extra dependencies are in blueprint META (not composition META)
grep -A 10 "packageJson:" apps/cli/src/__meta__.ts | grep -A 8 "'{blueprintname}'"# Verify extra envs are in blueprint META (not composition META)
grep -A 10 "envs:" apps/cli/src/__meta__.ts | grep -A 8 "'{blueprintname}'"# Verify apps in composition
grep -A 15 "context:" apps/cli/src/__meta__.ts | grep -A 10 "'{blueprintname}'"
Every composition element, file reference, dependency, and env var MUST be verified against the codebase.
Fumadocs Page Placement
Blueprint pages live under apps/www/content/docs/blueprints/{category}/: