Generate a Chorenzo recipe for: {{ recipe_name }}

Summary: {{ summary }}
Category: {{ category }}
Recipe ID: {{ recipe_id }}
Recipe Path: {{ recipe_path }}
{{ additional_instructions }}

Follow these guidelines for creating the recipe:
{{ recipe_guidelines }}

**ECOSYSTEM REQUIREMENTS:**

- Use ONLY `javascript` or `python` as ecosystem IDs
- An ecosystem refers to the language runtime environment, NOT specific technologies
- ✅ `javascript` includes: TypeScript, Node.js, React, Vue, Angular, etc.
- ✅ `python` includes: Django, Flask, FastAPI, etc.

**VARIANT CREATION RULES:**

- CRITICAL: When you detect multiple tools/approaches in your fix instructions, you MUST create separate variants
- Each distinct tool or approach gets its own variant with its own fix file
- Good variants: Different tools that accomplish the same goal through different approaches
- Bad variants: Minor configuration differences within the same tool, different versions of the same tool, cosmetic naming differences
- If only one approach exists, use single 'default' variant
- If you find yourself writing "For Tool A do X, for Tool B do Y" in a single fix file, create separate variants instead

**PROVIDES/REQUIRES GUIDELINES:**

**CRITICAL: Provides variables should be SCARCE. Default to empty `provides: []` in most cases.**

- **DEFAULT BEHAVIOR**: Use empty `provides: []` - Most recipes should have no provides variables
- **ONLY add provides when absolutely certain** other recipes would depend on this state
- **When in doubt, don't add** - It's better to require manual addition than create clutter
- **Focus on infrastructure/tooling state** that other recipes genuinely need to know about

**When to add provides variables:**
- Only when the recipe sets up fundamental infrastructure that other recipes genuinely need
- Only when there's a clear, obvious case that other recipes would depend on this state
- Never for internal recipe state, completion status, or generic file operations

- Only reference existing recipe outputs in requires field
- Available outputs: {{ available_outputs }}

**INSTRUCTION WRITING RULES:**

- Keep instructions generic and ecosystem-agnostic in prompt.md
- Use specific tools as examples only: "e.g., Prettier for JavaScript, Black for Python"
- Focus on concepts and investigation steps, not tool-specific implementation
- Avoid tool-specific checks unless recipe specifically targets that tool
- Write investigation steps that work across different implementations

**CODE SNIPPET RULES:**

- Avoid basic code examples (imports, simple function calls)
- Only include complex configuration examples when absolutely necessary
- Focus on configuration files and setup commands
- Let developers implement the actual code
- Prefer describing what to configure rather than showing trivial code

**LEVEL SELECTION GUIDELINES:**

Choose the appropriate recipe level based on the recipe's scope and intended usage:

- **`workspace-only`**: Use for tools that MUST be global across the entire workspace
  - Examples: Git hooks, workspace-wide package manager setup, global linting rules
  - Never applies to individual projects, even in mixed-ecosystem scenarios
  
- **`project-only`**: Use for tools that MUST be per-project and never global
  - Examples: Framework setup, project-specific build configurations, test setup
  - Never applies at workspace level, always targets individual projects
  
- **`workspace-preferred`**: Use for tools that work best globally but can handle mixed ecosystems
  - Examples: Code formatting that prefers workspace-wide rules but adapts to project differences
  - Intelligently applies at workspace or project level based on ecosystem compatibility
  
**CRITICAL: Analyze your recipe's purpose and choose the most appropriate level. Default to `workspace-preferred` only if the tool genuinely benefits from workspace-level application but can handle project-level scenarios.**

**FILE STRUCTURE:**

1. Create {{ recipe_path }}/metadata.yaml with:
   - **IMPORTANT: Choose appropriate `level` field based on guidelines above**
   - **IMPORTANT: Default to empty `provides: []` unless absolutely necessary**
   - Conservative requires lists referencing only essential dependencies
   - Separate variants for each tool/approach you identified
2. Create {{ recipe_path }}/prompt.md with:
   - **WHAT and WHY only**: Goal statement and investigation steps to discover current state
   - **NO implementation details**: Do not include HOW to fix, install, or configure
   - Generic discovery/detection steps that identify what needs to be done
   - **CRITICAL**: Include Expected Output descriptions for EVERY field you list in the "provides" section of metadata.yaml
   - **CRITICAL**: Each provides field description should explain what the fact represents and how it's determined (through investigation or as result of application)
   - Ecosystem-agnostic investigation logic
3. Create {{ recipe_path }}/fix.md with:
   - **HOW only**: Implementation instructions for achieving the desired state
   - **NO investigation logic**: Do not include discovery or detection steps
   - Base instructions that work for all ecosystems
   - Common setup and configuration steps that apply to all variants
4. Create {{ recipe_path }}/variants/[ecosystem]\_[variant].md or {{ recipe_path }}/variants/[variant].md with:
   - **ADDITIVE content only**: Additional steps that extend fix.md
   - **NO duplication**: Do not repeat content from fix.md
   - ONE tool/approach per variant file
   - Variant-specific implementation details only
   - Minimal, essential code examples only
   - If multiple tools exist, create multiple variant files

Use the Write tool to create each file following these principles.

**FINAL VALIDATION STEPS** (Required before completion):

After creating all recipe files:

1. Run `chorenzo recipes validate {{ recipe_path }} --debug`
2. Run `chorenzo recipes review {{ recipe_id }} --debug`
3. If issues found, fix them and run both commands again (once)
4. If issues still persist after fixing, include them in your final report
5. Report completion with any remaining validation warnings