Analyze a project or subsystem and extract its structure, patterns, and integration glue into a reusable recipe skill. Use when the user asks to "create a recipe", "extract a recipe from this project", "turn this into a reusable pattern", "make a recipe skill", "capture this as a recipe", or wants to package a working implementation as a repeatable blueprint for other projects.
From recipesnpx claudepluginhub ichabodcole/project-docs-scaffold-template --plugin recipesThis skill uses the workspace's default tool permissions.
references/recipe-skill-template.mdProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Calculates TAM/SAM/SOM using top-down, bottom-up, and value theory methodologies for market sizing, revenue estimation, and startup validation.
Analyze a project (or a specific subsystem within a project) and produce a recipe skill that captures its architecture, patterns, and implementation details in a form that can be executed in a different project to reproduce the same system.
A recipe is a markdown file with YAML frontmatter that follows the Claude Code
skill convention. It lives in the plugins/recipes/skills/ directory. When
invoked, it gives Claude the instructions and context needed to implement the
same patterns in a new codebase.
Important: The user will typically invoke this skill from a different project than where the recipes plugin lives. The workflow is:
The recipes repo is always cloned fresh from the canonical URL — this ensures the skill works regardless of how the plugin was installed (local path, remote URL, etc.).
A recipe captures the parts that aren't obvious from reading each library's docs individually:
A recipe does NOT capture:
Before anything else, clone the recipes repo so you can reference existing recipes and eventually write the new one.
Clone the project-docs repo into a temp directory:
RECIPE_WORKSPACE="/tmp/recipe-workspace-$(date +%s)"
git clone git@github.com:ichabodcole/project-docs-scaffold-template.git "$RECIPE_WORKSPACE"
Create a branch for the new recipe:
cd "$RECIPE_WORKSPACE" && git checkout -b recipe/<recipe-name>
Use kebab-case for the recipe name (e.g., recipe/document-versioning,
recipe/elysia-betterauth-api).
Read existing recipe skills from the clone at
plugins/recipes/skills/*/SKILL.md to understand the output format and
quality bar. Skim at least 2 existing recipes if available.
After this phase, you have:
Before exploring code, clarify what the recipe should cover.
Ask the user:
Use AskUserQuestion to determine:
What to capture - Is this a full project recipe (entire app structure) or a subsystem recipe (e.g., "document versioning", "auth system", "real-time sync")? The user's initial request usually makes this clear, but confirm if ambiguous.
Technology specificity - Should the recipe be tied to specific technologies (e.g., "Elysia + BetterAuth + Drizzle") or technology-agnostic (e.g., "document versioning that works with any DB/framework")? Rule of thumb: if the value is in the integration glue between specific libs, make it technology-specific. If the value is in the architecture/pattern, make it agnostic.
What to include - For full project recipes, ask about optional systems (see "Categorizing Findings" below). For subsystem recipes, ask if there are related systems to include (e.g., "Should the recipe include the AI auto-versioning integration, or just the core versioning system?").
Thoroughly explore the codebase to understand the system being captured.
For full project recipes:
package.json (or equivalent) for dependencies and scriptsFor subsystem recipes:
docs/architecture/) that describe the systemUse exploration agents for complex systems. Launch parallel Explore agents for different aspects (data model, service layer, UI integration, sync/API) to gather context efficiently.
Organize discoveries into categories to decide what goes in the recipe:
A. Core Pattern (Always Include):
B. Supporting Infrastructure (Usually Include):
C. Optional Extensions (Ask User):
D. Application-Specific (Exclude):
Use AskUserQuestion for category C items (up to 4 questions, combine related items).
Write the skill file into the cloned recipe workspace from Phase 0:
$RECIPE_WORKSPACE/plugins/recipes/skills/<recipe-name>/SKILL.md
The <recipe-name> directory should already match the branch name you created
in Phase 0 (e.g., if the branch is recipe/document-versioning, the directory
is document-versioning).
Consult references/recipe-skill-template.md for the full template structure, writing principles, and examples of good vs bad recipe content.
If the recipe includes an admin UI, dashboard, or any visual interface described
in prose, create HTML mockup prototypes as visual references. These live in a
references/ directory alongside the SKILL.md and give implementing agents a
clickable target instead of interpreting prose descriptions.
When to create prototypes:
When to skip:
How to create them:
Use the html-mockup-prototyping skill — copy
plugins/project-docs/skills/html-mockup-prototyping/templates/state-flow.html
as the starting point
Build the prototype using the recipe's data model for realistic sample data
Cover the key states: default view, selected/detail, search/filter, empty state, any confirmation dialogs
Save to $RECIPE_WORKSPACE/plugins/recipes/skills/<recipe-name>/references/
Add a UI Reference section near the top of the recipe SKILL.md pointing to the prototype:
## UI Reference
See `references/<feature>-mockup.html` for an interactive prototype of the
admin UI. Open in a browser to click through states.
Add a prototype callout in the relevant implementation phase (usually the UI phase):
> **Prototype available:** See `references/<feature>-mockup.html` for a
> clickable reference of the admin UI described below.
Show the prototype to the user before proceeding — open it in a browser and let them click through the states. Iterate on feedback before committing.
Lessons from building prototypes:
Alpine.data() registration, never inline x-data with complex stateQuality checks - verify the recipe before publishing:
references/?Publish the recipe via git:
Stage and commit in the recipe workspace:
cd "$RECIPE_WORKSPACE"
git add plugins/recipes/skills/<recipe-name>/
git commit -m "recipe: add <recipe-name> recipe skill"
Push the branch:
git push -u origin recipe/<recipe-name>
Create a pull request so the user can review:
gh pr create \
--title "Recipe: <Human-Readable Recipe Name>" \
--body "## New Recipe Skill
**Recipe:** <recipe-name>
**Type:** <technology-specific | technology-agnostic>
**Source project:** <name of the project analyzed>
## What this recipe captures
<2-3 bullet summary>
## Review checklist
- [ ] Architecture and concepts are accurate
- [ ] Implementation phases are in the right order
- [ ] Gotchas and trade-offs are documented
- [ ] Trigger phrases in description are natural"
Clean up the temp workspace:
rm -rf "$RECIPE_WORKSPACE"
Tell the user: