一键导入
documenting-stack
Use when documenting stacks, databases, or ORMs in create-faster MDX docs - focuses on technical changes and what we add beyond official setup
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when documenting stacks, databases, or ORMs in create-faster MDX docs - focuses on technical changes and what we add beyond official setup
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when documenting blueprints in create-faster MDX docs - covers pre-composed starter projects with composition, architecture, application code, CLI usage, and extra dependencies
Use when creating a new blueprint for create-faster from scratch - covers META entry design, application template creation, and testing for complete starter projects
Use when extracting a working project into a create-faster blueprint - triggers on phrases like "turn my project into a blueprint", "extract blueprint from my CRM", "make this project a create-faster template"
Use when updating library or project addon versions in create-faster __meta__.ts, especially when the update may involve breaking changes, new packages, renamed APIs, or cross-integration impacts
Use when documenting modules (libraries/addons) in create-faster MDX docs - covers standalone module pages with supported stacks, dependencies, env vars, and file structures
Use when adding new stacks, libraries, or project addons to create-faster CLI tool - covers META entries, template creation, and testing for all addon types
基于 SOC 职业分类
| name | documenting-stack |
| description | Use when documenting stacks, databases, or ORMs in create-faster MDX docs - focuses on technical changes and what we add beyond official setup |
Document what create-faster adds beyond official framework setup. Focus on technical changes, not framework features.
Core principle: Document OUR additions, link to THEIR docs.
Use when:
Do NOT use for:
Where things live:
templates/stack/{framework}/templates/libraries/{library}/templates/project/{category}/{name}/META.stacks[name].packageJson in __meta__.ts (NOT in templates)META.libraries[name].envs and META.project.*.options.*.envs (NOT in templates)META.libraries[name].support.stacksapps/www/content/docs/Package.json is programmatic. Scripts and dependencies are declared in META, not in template files. To verify what a stack provides, check META.stacks[name].packageJson in __meta__.ts.
Env vars are programmatic. Check envs fields in META addons, not template files.
---
title: Stack Name
description: Keep original style - framework presentation (don't change)
---
## Presentation
Brief explicit description of what you get as result (Full-stack X framework...).
[→ Official Documentation](https://...)
## What create-faster adds
Beyond the official setup, we include:
**Project Structure:**
- Pre-configured error pages
- Custom utilities directory
- Optimized layouts
**Development Scripts:**
- Custom scripts with purpose (build:analyze - Bundle analysis)
- Debug helpers (start:inspect - Node inspector)
**DO NOT include:**
- Framework-agnostic options (Biome, git, etc.)
- Default framework features (TypeScript, build tools)
- Optional features as if they're default
## Compatible Modules
List modules available for this stack with links to their standalone pages.
→ [shadcn/ui](/docs/modules/ui/shadcn) · [Next Themes](/docs/modules/ui/next-themes) · ...
Module documentation lives in `modules/{category}/`. Do NOT document modules inline.
CRITICAL: META is the source of truth for dependencies and scripts, not template files.
# Check META for stack's packageJson
grep -A 30 "'stackname'" apps/cli/src/__meta__.ts
# Check what libraries support this stack
grep -B 2 -A 5 "stacks:.*'stackname'" apps/cli/src/__meta__.ts
# Also check for stacks: 'all' (available to every stack)
grep -A 2 "stacks: 'all'" apps/cli/src/__meta__.ts
# Find all template files for stack
ls -la apps/cli/templates/stack/{stackname}/
# Check library templates
ls -la apps/cli/templates/libraries/
# Verify specific files mentioned in docs
find apps/cli/templates -name "filename.hbs"
# Check for frontmatter (only/mono filters)
grep -l '^---' apps/cli/templates/stack/{stackname}/*.hbs
head -5 apps/cli/templates/stack/{stackname}/*.hbs
Document EXACTLY what files we create/modify. Cross-reference every claim with actual template files AND META.
Frontmatter (YAML):
title: Stack namedescription: Keep original style - framework presentation (DON'T change)Document structure:
→ syntax)CRITICAL - Don't add # Title:
Title in frontmatter already renders as H1. Adding # Title creates duplicate.
For compatible modules:
Link to standalone module pages in modules/{category}/. Do NOT document modules inline on stack pages. Use documenting-module skill for module documentation.
DO document:
apps/cli/templates/)packageJson.scripts (with their purpose)packageJson.dependenciesonly: mono filters)envs fields (with scope resolution)DON'T document:
MANDATORY verification before publishing:
# Verify scripts exist in META
grep "scripts:" -A 10 apps/cli/src/__meta__.ts | grep stackname
# Verify dependencies exist in META
grep "dependencies:" -A 10 apps/cli/src/__meta__.ts | grep stackname
# Verify template files exist
ls apps/cli/templates/stack/{stackname}/
# Verify library compatibility
grep "'stackname'" apps/cli/src/__meta__.ts
Every script, dependency, and file reference MUST be verified against the codebase. Existing docs have had factual errors (wrong script commands, nonexistent dependencies).
STOP if you write:
# Stack Name title (title in frontmatter already renders as H1)@hono/zod-validator when it's not in META)build script when only dev and start exist)These mean: Refocus on what create-faster adds, not what the framework does. And VERIFY against code.
| Mistake | Fix |
|---|---|
| Documenting modules inline | Link to standalone module pages in modules/{category}/ |
| Explaining framework features | Link to official docs, focus on our additions |
| No file structure | Show tree with files created |
| Missing "What we add" | Required section at top |
| Verbose descriptions | Technical changes only |
| No official doc link | MANDATORY at top |
| Unverified dependencies | Check META.stacks[name].packageJson |
| Unverified scripts | Check META.stacks[name].packageJson.scripts |
| Checking package.json.hbs | Package.json is programmatic, check META instead |
| Excuse | Reality |
|---|---|
| "Need H1 title for clarity" | Frontmatter title renders as H1. Don't duplicate. |
| "Better description style" | Keep original framework presentation style. |
| "Should document modules here too" | Modules have their own pages. Link, don't duplicate. |
| "Need context about framework" | Official docs exist. Link to them. |
| "More detail is better" | Technical changes only. Avoid bloat. |
| "Should explain benefits" | Features = official docs. Our additions = us. |
| "Biome/git are part of stack" | Framework-agnostic options. Not stack-specific. |
| "I saw it in the old docs" | Old docs had errors. Verify against META and templates. |
| "The package.json template has it" | There IS no package.json template. It's programmatic from META. |
Frontmatter:
title: in YAML (don't add # Title after)description: keeps original framework presentation styleDocument:
## Presentation section added after frontmattermodules/{category}/)Verification (MANDATORY):
META.stacks[name].packageJson.scriptsMETA.stacks[name].packageJson.dependenciesapps/cli/templates/META.libraries[name].supportenvs fields (if documented)only: mono means turborepo-only)