菜单
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"
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/plvo/create-faster --skill extracting-blueprints命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 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 creating a new blueprint for create-faster from scratch - covers META entry design, application template creation, and testing for complete starter projects
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
基于 SOC 职业分类
正在显示 SKILL.md
| name | extracting-blueprints |
| description | 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" |
Extract a real-world project and convert it into a generic, functional create-faster blueprint. The external project is a reference for understanding the architecture and patterns, not a source to copy-paste from.
Core principle: Understand the project's architecture, identify the generic patterns, strip the business logic, verify everything against current library docs, then build a clean blueprint. The project shows you WHAT to build — the docs tell you HOW to build it correctly.
Use this skill when:
Do NOT use for:
adding-blueprints skill directly)extracting-templates skill)fixing-templates skill)A blueprint is a complete starter project that combines:
META.blueprintstemplates/blueprints/{name}/How it works at generation time:
templates/blueprints/{name}/packageJson is merged into app packagesenvs are collected alongside library/project envsKey distinction from library extraction: Extracting a library (extracting-templates) is surgical — one concern, one setup. Extracting a blueprint is architectural — you're extracting an entire application's structure, patterns, and flows while stripping domain-specific business logic.
MetaBlueprint in types/meta.ts)interface MetaBlueprint {
label: string;
hint: string;
category: string;
context: {
apps: { appName: string; stackName: StackName; libraries: string[] }[];
project: { database?: string; orm?: string };
};
packageJson?: PackageJsonConfig;
envs?: EnvVar[];
}
digraph extracting_blueprint {
node [fontsize=11];
edge [fontsize=9];
"Start" [shape=doublecircle];
"Scan project" [shape=box];
"Map architecture" [shape=box];
"Classify every file" [shape=box];
"Identify composition" [shape=box];
"Research library docs\n(context7)" [shape=box];
"Confident in understanding?" [shape=diamond];
"Design META entry" [shape=box];
"Genericize templates" [shape=box];
"Hand off to\nadding-blueprints" [shape=box];
"Done" [shape=doublecircle];
"Start" -> "Scan project";
"Scan project" -> "Map architecture";
"Map architecture" -> "Classify every file";
"Classify every file" -> "Identify composition";
"Identify composition" -> "Research library docs\n(context7)";
"Research library docs\n(context7)" -> "Confident in understanding?";
"Confident in understanding?" -> "Design META entry" [label="yes"];
"Confident in understanding?" -> "Research library docs\n(context7)" [label="no — re-read docs"];
"Design META entry" -> "Genericize templates";
"Genericize templates" -> "Hand off to\nadding-blueprints";
"Hand off to\nadding-blueprints" -> "Done";
}
User tells you: project path + what kind of blueprint to extract.
package.json — map all dependencies and their versionsOutput: A complete file map with initial purpose annotations.
Example for a CRM project:
src/app/page.tsx → Landing/redirect
src/app/(dashboard)/layout.tsx → Dashboard shell (sidebar + header)
src/app/(dashboard)/page.tsx → Dashboard overview
src/app/(dashboard)/clients/page.tsx → Client list (BUSINESS LOGIC)
src/app/(dashboard)/clients/[id]/page.tsx → Client detail (BUSINESS LOGIC)
src/app/(dashboard)/settings/page.tsx → Settings page
src/components/sidebar.tsx → Navigation sidebar
src/components/header.tsx → App header
src/components/client-table.tsx → Data table (BUSINESS LOGIC)
src/components/stats-cards.tsx → Generic stat cards
src/lib/auth.ts → Auth setup (covered by better-auth)
src/lib/db.ts → DB setup (covered by drizzle)
Understand the project's architectural patterns:
Focus on the GENERIC patterns, not the domain-specific implementations.
The CRM's client list page uses a data table with server-side pagination — that's a generic pattern worth keeping. The specific columns (client name, email, contract value) are business logic to strip.
For each file in the project, classify it:
| Classification | Action | Example |
|---|---|---|
| Already covered by create-faster | Skip — stacks/libraries/addons handle this | tailwind.config.ts, next.config.ts, auth setup, DB schema |
| Generic application pattern | Keep — this becomes a blueprint template | Dashboard layout, sidebar, header, stats cards, settings page |
| Business logic | Strip — domain-specific, not reusable | Client table columns, specific API routes, custom schemas |
| Config/boilerplate | Skip or genericize | .env values, API keys, hardcoded URLs |
| Extra dependency usage | Keep + add to blueprint packageJson | recharts charts, framer-motion animations |
Critical question for each file: "Would this file be useful in ANY project of this type, or only in THIS specific project?"
From the project's dependencies and code, map what goes where:
Existing create-faster building blocks:
Stack: nextjs
Libraries: shadcn, better-auth, tanstack-query
Project: postgres, drizzle, biome
Blueprint-specific extras (NOT in create-faster):
Dependencies: recharts, framer-motion
Env vars: ADMIN_EMAIL
Verify each library exists in META.libraries. If a library the project uses doesn't exist in create-faster yet, it must be added FIRST via the adding-templates skill before the blueprint can reference it.
Validate the composition: Check META dependency rules (orm requires database, better-auth requires orm, etc.).
THIS IS A BLOCKING PREREQUISITE. You CANNOT proceed to Phase 6 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 because "the project already works," not because "I can just copy the project's pattern."
Baseline testing showed agents skip this 100% of the time when not enforced. The result: code copied directly from the project with patterns described as "identical to CRM" — no verification that the APIs are current, that the patterns are recommended, or that the versions are stable.
The project is ONE implementation, possibly months or years old. The docs are the source of truth.
For EVERY library in the composition AND every extra dependency:
'use client' requirements, server component compatibilityWhat to verify against docs:
Output requirement: Document specific findings for each library. Don't just say "verified."
Example:
Finding: recharts v2.15 has a new `ResponsiveContainer` that auto-sizes without
explicit width/height props when using CSS container queries.
Differs: Project uses explicit width="100%" height={350} pattern.
Impact: Blueprint templates should use the current pattern but keep explicit
sizing as it's more predictable across browsers.
Finding: framer-motion was renamed to just "motion" in v12. Import is now
`import { motion } from "motion/react"`.
Differs: Project uses `import { motion } from "framer-motion"` (v11 API).
Impact: Check latest stable version — if v11 is still widely used, keep it.
If v12 is stable, use the new import.
If you catch yourself thinking any of these, STOP:
Before genericizing anything, read what create-faster already generates.
templates/stack/{stackName}/ — what files does the stack produce?templates/libraries/{lib}/ — for each library in the compositiontemplates/blueprints/Why this matters: Baseline testing showed agents assume files exist (e.g., "this overrides the structural proxy.ts") without checking. This produces overrides that target nonexistent files, or duplicate files that are already generated by the structural templates.
For each file classified as "Already covered by create-faster" in Phase 3, VERIFY by reading the actual template. Don't assume — read.
Before designing, read apps/cli/src/types/meta.ts to verify the MetaBlueprint interface.
Based on Phase 4 (composition) and Phase 5 (research):
'blueprint-name': {
label: 'Display Name',
hint: 'One-line description',
category: 'Category Name',
context: {
apps: [
{
appName: 'web',
stackName: 'nextjs',
libraries: ['shadcn', 'better-auth', 'tanstack-query'],
},
],
project: {
database: 'postgres',
orm: 'drizzle',
},
},
packageJson: {
dependencies: {
recharts: '^2.15.0', // Blueprint-specific only
},
},
envs: [
{
value: 'ADMIN_EMAIL=admin@example.com',
monoScope: ['app'],
},
],
},
Rules:
packageJson contains ONLY extras not covered by compositionenvs contains ONLY extras not covered by compositioncontext.apps[].libraries must exist in META.librariesTransform the project's files into blueprint templates. This is the core of the extraction work.
For each file classified as "Generic application pattern" in Phase 3:
Strip business logic — remove domain-specific content
Replace hardcoded values with Handlebars variables
{{projectName}}{{#if (isMono)}}@repo/...{{else}}@/...{{/if}}Add Handlebars conditionals for optional parts
{{#if (hasLibrary "better-auth")}}Use current library APIs — from Phase 5 research, NOT from the project
Keep it functional but minimal
Example transformation:
Project file (CRM sidebar):
const navigation = [
{ name: 'Dashboard', href: '/dashboard', icon: LayoutDashboard },
{ name: 'Clients', href: '/dashboard/clients', icon: Users },
{ name: 'Contracts', href: '/dashboard/contracts', icon: FileText },
{ name: 'Invoices', href: '/dashboard/invoices', icon: Receipt },
{ name: 'Settings', href: '/dashboard/settings', icon: Settings },
];
Blueprint template (generic sidebar):
const navigation = [
{ name: 'Dashboard', href: '/dashboard' },
{ name: 'Settings', href: '/dashboard/settings' },
];
Removed: domain-specific pages (Clients, Contracts, Invoices), icons (user can add their own).
adding-blueprintsWith the research complete and templates genericized, hand off to the adding-blueprints skill for:
__meta__.tstemplates/blueprints/{name}/Provide the adding-blueprints skill with:
package.json for all dependenciesMETA.libraries (flagged missing ones for creation)types/meta.ts to verify MetaBlueprint fieldsadding-blueprints for implementation and testing| Excuse | Reality |
|---|---|
| "The project code works, just templatize it" | Project code may be outdated, use deprecated APIs, or have workarounds for fixed bugs. Check docs. |
| "I know this library" | Docs evolve. Check context7 for current API and best practices. |
| "This business logic is generic enough" | If it references domain concepts (clients, invoices, contracts), it's business logic. Strip it. |
| "Skip context7, I'll use the project as reference" | The project is ONE implementation, possibly outdated. Docs are the source of truth. |
| "I'll keep all the pages" | Only keep pages that make sense in ANY project of this type. A CRM's client page is not generic. |
| "The project's dependency versions are fine" | Check latest stable versions. The project may be months or years behind. |
| "I verified against docs" | Saying "verified" without specific findings is the same as not checking. Document what you found. |
| "This component is too complex to strip" | If you can't strip it to a generic version, it's probably business logic. Remove it. |
| "The project uses library X, so require it" | Check if the library is in META. If not, it needs adding-templates first, or it's a blueprint extra. |
| "I'll figure out what's generic later" | Classify EVERY file in Phase 3. Don't start writing templates without a complete classification. |
| "Identical to the project" | If your template is "identical" to the project, you didn't do the work. Verify against docs, update APIs, strip specifics. |
| "I'll use the project's versions" | The project may be months old. Check npm/docs for current stable versions. |
| "This overrides the structural proxy.ts" | Did you READ the structural templates to verify proxy.ts exists? Check first. |
STOP immediately if you:
blueprint.packageJson (they belong in library/addon META)context.apps[].libraries that doesn't exist in META.librariesadding-blueprintsThese shortcuts produce blueprints that work for ONE project's setup but break for others.