メニュー
Use when creating a new blueprint for create-faster from scratch - covers META entry design, application template creation, and testing for complete starter projects
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/plvo/create-faster --skill adding-blueprintsコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
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 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
SKILL.md を表示中
SOC 職業分類に基づく
| name | adding-blueprints |
| description | Use when creating a new blueprint for create-faster from scratch - covers META entry design, application template creation, and testing for complete starter projects |
Create a new blueprint — a pre-composed, functional starter project. Blueprints combine existing building blocks (stacks, libraries, project addons) AND add opinionated application code (pages, layouts, components) to give users a working app out of the box.
Core principle: A blueprint is a functional application, not just a preset of libraries. Every blueprint must produce a working app that a user can run immediately after generation.
Use this skill when:
Do NOT use for:
extracting-blueprints skill first, then come here)adding-templates skill)fixing-templates skill)A blueprint is a complete starter project that combines:
META.blueprintstemplates/blueprints/{name}/recharts for a dashboard)How it works at generation time:
templates/blueprints/{name}/packageJson is merged into app packagesenvs are collected alongside library/project envsWhat blueprints do NOT do:
MetaBlueprint in types/meta.ts)interface MetaBlueprint {
label: string; // Display name in CLI
hint: string; // Description shown during selection
category: string; // Grouping category (e.g. 'Web3', 'Business')
context: {
apps: { appName: string; stackName: StackName; libraries: string[] }[];
project: { database?: string; orm?: string };
};
packageJson?: PackageJsonConfig; // Extra deps for the blueprint
envs?: EnvVar[]; // Extra env vars
}
Blueprint templates at templates/blueprints/{name}/src/app/page.tsx.hbs override the stack's templates/stack/nextjs/src/app/page.tsx.hbs because they resolve to the same destination path. The blueprint version wins.
This means:
templates/blueprints/{blueprintName}/file.tsx.nextjs.hbs (filtered to matching stacks)only: mono|single filteringapp (blueprints target the first app in turborepo)mono.scope: root available for root-level filesdigraph adding_blueprint {
node [fontsize=11];
edge [fontsize=9];
"Start" [shape=doublecircle];
"Clarify composition" [shape=box];
"Research library docs\n(context7)" [shape=box];
"Confident in understanding?" [shape=diamond];
"Read types/meta.ts" [shape=box];
"Design META entry" [shape=box];
"Design template file tree" [shape=box];
"Write templates" [shape=box];
"Add META entry" [shape=box];
"Test all modes" [shape=box];
"Done" [shape=doublecircle];
"Start" -> "Clarify composition";
"Clarify composition" -> "Research library docs\n(context7)";
"Research library docs\n(context7)" -> "Confident in understanding?";
"Confident in understanding?" -> "Read types/meta.ts" [label="yes"];
"Confident in understanding?" -> "Research library docs\n(context7)" [label="no — re-read docs"];
"Read types/meta.ts" -> "Design META entry";
"Design META entry" -> "Design template file tree";
"Design template file tree" -> "Write templates";
"Write templates" -> "Add META entry";
"Add META entry" -> "Test all modes";
"Test all modes" -> "Done";
}
If the user has a vague idea ("landing page with analytics"):
adding-templatesIf the user already knows the composition:
Output: A clear composition spec:
Blueprint: landing-page
Apps: web (nextjs) + shadcn, tanstack-query
Project: biome
Extra deps: framer-motion, @vercel/analytics
Extra envs: ANALYTICS_ID
THIS IS A BLOCKING PREREQUISITE. You CANNOT proceed to Phase 3 without completing this.
You MUST use context7 (or web search) to read documentation for EVERY library in the composition AND every extra dependency. No exceptions — not for libraries you "know well," not for "simple" setups, not because "the user is waiting."
Baseline testing showed agents skip this 100% of the time when not enforced. The result: invented API signatures, wrong package names, outdated patterns, guessed version numbers. All of which produce broken blueprints.
For every library in the composition AND every extra dependency:
'use client', which can be server componentsFor extra blueprint dependencies specifically:
Output requirement: Document specific findings per library. Don't just say "verified."
Example:
Finding: framer-motion v11 uses `motion` import directly, not `motion.div`.
`import { motion } from 'framer-motion'` is the current API.
Differs: Many tutorials still show the old `motion.div` pattern.
Impact: Blueprint templates must use the current `motion` component API.
If you catch yourself thinking any of these, STOP:
Read apps/cli/src/types/meta.ts to verify the MetaBlueprint interface and related types. Don't guess what fields are available.
Read the existing structural templates that the blueprint will interact with. Before designing any override, you MUST know what you're overriding:
templates/stack/{stackName}/ — what files does the stack already generate?templates/libraries/{lib}/ — for each library in the composition, what files exist?templates/blueprints/ for referenceWhy this matters: Baseline testing showed agents assume files exist (e.g., "I'll override proxy.ts") without checking if the structural template actually generates that file. This produces overrides that don't match any destination path and just become orphan files.
'blueprint-name': {
label: 'Display Name',
hint: 'One-line description of what this blueprint creates',
category: 'Category Name',
context: {
apps: [
{
appName: 'web', // Default app name
stackName: 'nextjs',
libraries: ['shadcn', 'tanstack-query'],
},
],
project: {
database: 'postgres', // Optional
orm: 'drizzle', // Optional
},
},
packageJson: { // Only blueprint-specific extras
dependencies: {
'framer-motion': '^11.0.0',
},
},
envs: [ // Only blueprint-specific extras
{
value: 'ANALYTICS_ID=your-analytics-id',
monoScope: ['app'],
},
],
},
Key rules:
context.apps[].libraries must only reference libraries that exist in META.librariescontext.project must only reference addons that exist in META.project.{category}.optionspackageJson should ONLY include extra dependencies not already declared by the composition's stacks/libraries/addonsenvs should ONLY include extra env vars not already declared by the composition's libraries/addonsbetter-auth is in libraries, orm + database must be in projectMap out every file the blueprint will add or override:
templates/blueprints/{name}/
src/
app/
page.tsx.hbs # Override: replaces stack's default page
(dashboard)/
layout.tsx.hbs # New: dashboard layout with sidebar
page.tsx.hbs # New: dashboard home page
settings/
page.tsx.hbs # New: settings page
components/
sidebar.tsx.hbs # New: navigation sidebar
header.tsx.hbs # New: header component
For each file, decide:
.nextjs.hbs) because it's framework-specific?Default behavior (no frontmatter needed):
src/... within the app directoryapps/{appName}/src/...src/...When you DO need frontmatter:
mono: { scope: root }path: custom/path/file.tsonly: mono or only: singleFor each template file:
{{projectName}} for app name display{{#if (hasLibrary "x")}} for optional library integration{{#if (isMono)}} for import path differencesHandlebars escape gotcha: When a template contains JSX with literal double curly braces (e.g., style={{ color: 'red' }}), Handlebars will try to interpret them. Use \{{ to escape, or wrap blocks in {{{{raw}}}}...{{{{/raw}}}}. Test your templates — this is a common source of rendering errors.
Template quality checklist per file:
'use client' directive where needed{{projectName}} etc.)META.blueprints in __meta__.tstemplates/blueprints/{name}/Single repo mode:
bunx create-faster test-single --blueprint {name} --git --pm bun
Turborepo mode (add a second app to force turborepo): The blueprint defines one app, but adding a second via the CLI should also work. Test that blueprint templates resolve correctly in turborepo.
Verify:
package.json has correct dependencies (composition + blueprint extras).env.example has correct variables (composition + blueprint extras)bun install succeedsbun run dev starts without errors--blueprint {name} flag workstypes/meta.ts to verify MetaBlueprint fields--blueprint {name} flag workspackage.json correct (composition + extras merged).env.example correct (composition + extras merged)bun install && bun run dev works| Excuse | Reality |
|---|---|
| "I know this library, skip docs" | Libraries change. Check context7 for current API. |
| "Placeholder code is fine for now" | Blueprints must be functional. Users expect a working app. |
| "I'll add the extra deps to the library META" | Blueprint extras go in blueprint.packageJson, not library META. |
| "Skip testing, it's just templates" | Untested templates produce broken projects. Test both modes. |
| "The composition is obviously valid" | Check META dependency rules. better-auth needs orm needs database. |
| "I don't need frontmatter" | Default behavior is usually fine, but verify path resolution. |
| "I'll use the old API pattern" | Research first. Use current stable APIs from context7. |
| "Verified against docs" | Saying "verified" without specific findings is the same as not checking. |
| "I'll override proxy.ts" | Did you READ the existing stack templates to verify proxy.ts exists? Check first. |
| "The version is ^3.8.1" | Did you check npm/docs, or did you guess? Guessed versions break installs. |
| "I know the cookie name is privy-token" | Did you read the docs, or did you assume? Library internals change. |
| "Context7 is too slow for this" | Broken blueprints from wrong APIs are slower to debug. Use it. |
STOP immediately if you:
blueprint.packageJson (they belong in library/addon META)| What | Where | How |
|---|---|---|
| Blueprint definition | META.blueprints in __meta__.ts | label, hint, category, context, packageJson?, envs? |
| Blueprint type | MetaBlueprint in types/meta.ts | Verify fields before designing |
| Blueprint templates | templates/blueprints/{name}/ | .hbs files, override semantics |
| Override behavior | template-resolver.ts L288-293 | Blueprint destinations replace structural |
| Template authoring | See adding-templates skill | Frontmatter, helpers, stack suffixes |
| Package.json merge | package-json-generator.ts | Blueprint packageJson merged into app |
| Env generation | env-generator.ts | Blueprint envs collected with library/project envs |
| CLI flag | --blueprint {name} | Can combine with --linter/--tooling; exclusive with --app/--database/--orm |
| Interactive mode | cli.ts blueprintCli() | Prompts: project name, linter, tooling, git, pm |