Add Internal Recipes To Recipes Cookbook (#3179)

documentation/src/pages/recipes/data/recipes/analyze-pr.yaml

@@ -0,0 +1,57 @@
+id: analyze-pr
+version: 1.0.0
+title: Analyse PR
+author:
+  contact: douwe
+description: Analyse a pr
+instructions: Your job is to analyse and explain a PR
+activities:
+  - Query authentication logs
+  - Investigate Sentry reports
+  - Correlate device usage with auth events
+  - Query Snowflake user identity tables
+  - Review repo code for auth issues
+parameters:
+  - key: pr
+    input_type: string
+    requirement: required
+    description: name of the pull request
+  - key: repo
+    input_type: string
+    requirement: optional
+    description: name of the repo. uses the current one if not selected
+    default: ""
+extensions:
+    - type: builtin
+      name: developer
+      display_name: Developer
+      timeout: 300
+      bundled: true
+    - type: builtin
+      name: memory
+      display_name: Memory
+      timeout: 300
+      bundled: true
+      description: "For storing and retrieving formating preferences that might be present"
+prompt: |
+  Analyze the pr with the name {{ pr }}. Find out what has changed, try to figure out why these
+  changes were made and tell the user in detail what you found out.
+  {% if repo %}
+  We are working with the {{ repo }} repository, so make sure to add that to all commands.
+  {% endif %}
+
+  Steps:
+  1. Find the actual pull request. {{ pr }} is the name or part of it. You can just run
+     `gh pr list`
+     and see which prs are open. Note which one the user is talking about
+  2. Look at what is changed. You can run:
+     `gh pr view <pr-number> --comments --commits --files`
+     to get an overview.
+  3. Optionally: if this looks complicated you could check out the relevant commit and have
+     a look at the files involved to get more context. If you do this, mark which branch you
+     were on. If there are pending changes, do a git stash
+  4. Gather your thoughts and tell the user what changed, which changes look like they might
+     be worth an extra look and give them an idea of maybe why these changes were needed
+  5. Clean up after yourself. If you cloned a repository or checked out a commit, make sure
+     you return the state to what it was before. So if in step 3 you changed branch, change
+     it back. If you had git stashed something, stash pop it again.

documentation/src/pages/recipes/data/recipes/change-log.yaml

@@ -0,0 +1,74 @@
+version: 1.0.0
+title: Generate Change Logs from Git Commits
+description: Generate Change Logs from Git Commits
+instructions: Follow the prompts to generate change logs from the provided git commits
+activities:
+  - Retrieve and analyze commits
+  - Categorize changes
+  - Format changelog entries
+  - Update CHANGELOG.md
+prompt: |
+  Task: Add change logs from Git Commits
+  1. Please retrieve all commits between SHA {{start_sha}} and SHA {{end_sha}} (inclusive) from the repository.
+
+  2. For each commit:
+    - Extract the commit message
+    - Extract the commit date
+    - Extract any referenced issue/ticket numbers (patterns like #123, JIRA-456)
+
+  3. Organize the commits into the following categories:
+    - Features: New functionality added (commits that mention "feat", "feature", "add", etc.)
+    - Bug Fixes: Issues that were resolved (commits with "fix", "bug", "resolve", etc.)
+    - Performance Improvements: Optimizations (commits with "perf", "optimize", "performance", etc.)
+    - Documentation: Documentation changes (commits with "doc", "readme", etc.)
+    - Refactoring: Code restructuring (commits with "refactor", "clean", etc.)
+    - Other: Anything that doesn't fit above categories
+
+  4. Format the release notes as follows:
+    
+    # [Version/Date]
+    
+    ## Features
+    - [Feature description] - [PR #number](PR link)
+    
+    
+    ## Bug Fixes
+    - [Bug fix description] - [PR #number](PR link)
+    
+    [Continue with other categories...]
+    
+    Example:
+    - Implement summary and describe-commands for better sq integration - [PR #369](https://github.com/squareup/dx-ai-toolbox/pull/369)
+    
+  5. Ensure all the commit items has a PR link. If you cannot find it, try again. If you still cannot find it, use the commit sha link instead. For example: [commit sha](commit url)
+
+  6. If commit messages follow conventional commit format (type(scope): message), use the type to categorize and include the scope in the notes.
+
+  7. Ignore merge commits and automated commits (like those from CI systems) unless they contain significant information.
+
+  8. For each category, sort entries by date (newest first).
+
+  9. formatted change logs as a markdown document
+
+  10. Create an empty CHANGELOG.md file if it does not exist
+
+  11. Read CHANGELOG.md and understand its format.
+
+  11. Insert the formatted change logs at the beginning of the CHANGELOG.md, and adjust its format to match the existing CHANGELOG.md format. Do not change any existing CHANGELOG.md content.
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+parameters:
+- key: start_sha
+  input_type: string
+  requirement: user_prompt
+  description: the start sha of the git commits
+- key: end_sha
+  input_type: string
+  requirement: user_prompt
+  description: the end sha of the git commits
+author:
+  contact: lifeizhou-ap

documentation/src/pages/recipes/data/recipes/create-kafka-topic.yaml

@@ -0,0 +1,54 @@
+version: 1.0.0
+title: Create Kafka Topic
+author:
+  contact: danielst-block
+description: Create a new Kafka topic with specified parameters.
+activities:
+  - Check for existing topic name conflicts
+  - Validate publisher and subscriber names
+  - Calculate optimal partition count
+  - Generate Kafka topic configuration
+  - Create topic directory and config files
+parameters:
+  - key: topic_name
+    input_type: string
+    requirement: required
+    description: The name of the Kafka topic to create
+  - key: owner
+    input_type: string
+    requirement: required
+    description: The name/identifier of owner.
+  - key: publisher
+    input_type: string
+    requirement: required
+    description: The name/identifier of the publisher service or application
+  - key: subscribers
+    input_type: string
+    requirement: required
+    description: Comma-separated list of subscriber services or applications that will consume from this topic (e.g., "service1,service2,service3")
+  - key: throughput
+    input_type: string
+    requirement: optional
+    description: Expected throughput. Used to calculate optimal number of partitions for the topic
+    default: unknown
+extensions:
+  - type: builtin
+    name: developer
+    display_name: Developer
+    timeout: 300
+    bundled: true
+instructions: |
+  You are a Kafka topic creation assistant. Your job is to help create a new Kafka topic HCL 
+  definitions with the specified configuration including topic name, publisher, owner, 
+  subscribers, and optional throughput. Follow the existing folder structure and conventions.
+prompt: |
+  1. Create a {{ topic_name }} directory for a Kafka topic based on the following parameters:
+    - Topic name: {{ topic_name }}
+    - Owner: {{ owner }}
+    - Publisher: {{ publisher }}
+    - Subscribers: {{ subscribers }}
+    - Throughput: {{ throughput }} messages/second (if provided)
+  2. Ensure the directory name does not conflict with any existing topics (notify the user and abort if it does).
+  3. Check that the publisher and subscribers have been seen in other topics before to avoid typos.
+  4. If throughput is provided - calculate the optimal number of partitions. Otherwise, default to 4 partitions.
+  5. Include the calculated partition count in the topic configuration and explain the reasoning.

documentation/src/pages/recipes/data/recipes/dev-guide-migration.yaml

@@ -0,0 +1,45 @@
+version: 1.0.0
+title: dev guide migration from a specific file or files in a directory
+description: dev guide migration from a specific file or files in a directory
+instructions: Follow the prompts to migrate the doc page from source file(s) to target folder.  
+activities:
+  - Create target directory structure
+  - Migrate source docs to new location
+  - Format using example doc as reference
+  - Add new page to sidebar
+prompt: |
+    Migrate the doc page from source file(s) at {{source_file}} to {{target_folder}}.  Please follow the instructions below:  
+    1. Create the parent directory if the parent directory of the target file does not exist
+    2. use {{example_file}} as a reference for the doc format
+    3. retain all the information of the source file(s) in the target file 
+    4. If the page is not in the sidebar, add it in {{sidebar_file}}
+    5. Ensure the target files 
+          - has preserved the original content
+          - has correct formatting
+          - has clear and well-organized file structure
+
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+parameters:
+- key: source_file
+  input_type: file
+  requirement: user_prompt
+  description: the source file(s) or the folder to migrate
+- key: target_folder
+  input_type: file
+  requirement: user_prompt
+  description: the target folder to migrate
+- key: example_file
+  input_type: file
+  requirement: user_prompt
+  description: the example file to follow the doc format
+- key: sidebar_file
+  input_type: file
+  requirement: user_prompt
+  description: the sidebar file to add the new doc page
+author:
+  contact: lifeizhou-ap

documentation/src/pages/recipes/data/recipes/migrate-cypress-test-to-playwright.yaml

@@ -0,0 +1,65 @@
+version: 1.0.0
+title: Migrate Cypress tests to Playwright
+author:
+  contact: joahg
+description: Migrate Cypress tests to Playwright
+instructions: Your job is to migrate cypress tests to playwright tests.
+activities:
+  - Analyze Cypress test file
+  - Convert Cypress syntax to Playwright
+  - Migrate custom commands and helpers
+  - Update imports and async handling
+  - Save Playwright test in target directory
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+prompt: |
+    You are tasked with migrating a Cypress test to Playwright. 
+    
+    Cypress test file: {{ cypress_test_file }}
+    Target directory: {{ target_directory }}
+    
+    Please follow these steps:
+    
+    1. **Analyze the Cypress test file**: Examine the Cypress test file at {{ cypress_test_file }}, including its structure, commands, and any custom helper functions used.
+    
+    2. **Migrate the test structure**: Convert Cypress test syntax to Playwright:
+       - Replace `describe()` and `it()` with Playwright's `test.describe()` and `test()`
+       - Convert `cy.visit()` to `page.goto()`
+       - Convert `cy.get()` to appropriate Playwright locators
+       - Convert assertions from Cypress format to Playwright's `expect()` assertions
+       - Handle async/await patterns properly in Playwright
+    
+    3. **Migrate Cypress commands**: Convert common Cypress commands to Playwright equivalents:
+       - `cy.click()` → `locator.click()`
+       - `cy.type()` → `locator.fill()` or `locator.type()`
+       - `cy.should()` → `expect(locator).to**()`
+       - `cy.wait()` → `page.waitForTimeout()` or better, specific wait conditions
+       - `cy.intercept()` → `page.route()`
+    
+    4. **Migrate helper functions**: If the Cypress test uses custom commands or helper functions:
+       - Convert Cypress custom commands to Playwright helper functions
+       - Ensure helper functions are properly imported and available in the target directory
+       - Update function signatures to work with Playwright's page object
+    
+    5. **Update imports and setup**: 
+       - Add proper Playwright imports (`import { test, expect } from '@playwright/test'`)
+       - Remove Cypress-specific imports
+       - Ensure proper test configuration and setup
+    
+    6. **Handle test data and fixtures**: Convert any Cypress fixtures or test data to work with Playwright
+    
+    Create the migrated Playwright test in the target directory, maintaining the same test coverage and functionality as the original Cypress test. Use the same base filename but with appropriate Playwright test naming conventions (e.g., .spec.ts or .test.ts).
+
+parameters:
+  - key: cypress_test_file
+    input_type: file
+    requirement: user_prompt
+    description: The specific Cypress test file to migrate (e.g., cypress/e2e/login.cy.js)
+  - key: target_directory
+    input_type: file
+    requirement: user_prompt
+    description: The target directory where the Playwright test should be created

documentation/src/pages/recipes/data/recipes/migrate-from-poetry-to-uv.yaml

@@ -0,0 +1,28 @@
+version: 1.0.0
+title: migrate from poetry to uv
+description: migrate from poetry to uv
+instructions: Follow the instructions to move the project from using `poetry` to `uv`
+author:
+  contact: jamadeo
+activities:
+  - Check if project already uses uv
+  - Run migration using uvx
+  - Remove poetry-related files and virtualenv
+  - Run uv sync
+prompt: |
+  The current project uses `poetry` for Python environment and dependency management. We want to use `uv` instead.
+
+  First, verify that the above is true. If the project is actually already using `uv`, you can stop.
+
+  Start by running `uvx migrate-to-uv`. If you don't have `uv` installed, use `hermit install uv` to add it. If hermit isn't set up, use `hermit init` to do so.
+
+  Once `migrate-to-uv` has run, delete any local virtualenvs (often located at ./.venv) and run `uv sync`.
+
+  Grep for other uses of `poetry` in the project. If you can switch these commands to `uv`, do so. If not, just make a note of it.
+
+extensions:
+  - type: builtin
+    name: developer
+    display_name: Developer
+    timeout: 300
+    bundled: true

documentation/src/pages/recipes/data/recipes/pr-demo-planner.yaml

@@ -0,0 +1,64 @@
+version: 1.0.0
+title: PR Demo Planner
+author:
+  contact: lifei
+description: Transforms technical Pull Requests into effective demonstrations that showcase functionality and value
+activities:
+  - Analyze PR changes for demonstrable improvements
+  - Create demo script and narrative flow
+  - Build visual storyboard with before/after comparisons
+  - Suggest environments and test data for effective demo
+  - Translate technical changes into business value
+instructions: |
+  You are a PR Demo Planner, an assistant specialized in transforming technical Pull Requests into engaging demonstrations.
+  
+  Your capabilities include:
+  1. Analyzing PR changes to identify demonstrable features and improvements
+  2. Creating structured demo scripts based on code changes
+  3. Generating visual storyboards for demonstrations
+  4. Helping prepare before/after comparisons that highlight improvements
+  5. Crafting narratives that connect technical changes to business value
+  6. Suggesting demo environments and test data
+  
+  When helping developers convert PRs to demos:
+  
+  - First understand the PR's purpose, scope, and technical changes
+  - Identify the most visually demonstrable aspects of the changes
+  - Create a narrative flow that showcases the improvements
+  - Focus on before/after comparisons when applicable
+  - Prepare for both technical and non-technical audiences
+  - Include setup instructions to ensure smooth demonstrations
+  - Suggest ways to highlight performance improvements or bug fixes
+  
+  You have access to reference materials:
+  - {{ recipe_dir }}/demo-formats.md for different demonstration approaches
+  - {{ recipe_dir }}/demo-script-templates.md for structured presentation formats
+  - {{ recipe_dir }}/technical-to-visual-guide.md for translating code changes to visual demonstrations
+  
+  Always aim to create demonstrations that clearly show the value of the changes made in the PR.
+
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+
+prompt: |
+  I need help converting my Pull Request into an effective demonstration. Please help me showcase the changes and improvements in a way that's clear and engaging.
+  
+  You can assist me with:
+  - Analyzing my PR to identify demonstrable features
+  - Creating a structured demo script
+  - Generating a visual storyboard
+  - Preparing before/after comparisons
+  - Crafting a narrative that explains the value
+  - Setting up an effective demo environment
+  
+  This is my PR: {{ pr_url }}
+
+parameters:
+  - key: pr_url
+    input_type: string
+    requirement: required
+    description: The URL of the PR to convert into a demo.

documentation/src/pages/recipes/data/recipes/readme-bot.yaml

@@ -0,0 +1,35 @@
+version: 1.0.0
+title: Readme Bot
+author:
+  contact: DOsinga
+description: Generates or updates a readme
+instructions: You are a documentation expert
+activities:
+  - Scan project directory for documentation context
+  - Generate a new README draft
+  - Compare new draft with existing README.md
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+prompt: |
+  Here's what to do step by step:
+    1. The current folder is a software project. Scan it and learn as
+       much as possible.
+    2. Based on what you find, write a read me file that contains a
+       general description of the project, how to get started and how
+       to run the tests. Only mention future plans if you find explicit
+       todo's. Do not write about future plans or licenses or anything
+       that you can't find explicit support for.
+    3. Write this out as README.tmp.md.
+    4. Look at the existing README.md. If it exists and the version you
+       wrote out is not really better, just tell the user that what
+       exists is really good enough and you can exit.
+    5. If your version is better or no README.md exists, make your version
+       the current one
+    6. If you are on main or master, create a new branch
+    7. If the only chance at this point is the modification to the the
+       README.md, create a new commit 
+    8. Clean up after yourself, delete the README.tmp.md after use.

documentation/src/pages/recipes/data/recipes/recipe-generator.yaml

@@ -0,0 +1,49 @@
+version: 1.0.0
+title: Recipe Generator
+author:
+  contact: iYung
+description: Creates other recipes
+parameters:
+  - key: prompt
+    input_type: string
+    requirement: required
+    description: Description of what I want the recipe to do. Could be a file path
+prompt: |
+ Recipes are a set of instructions.
+ 
+ Here is what a recipe should look like:
+ ```yaml
+ version: 1.0.0
+ title: Title of my recipe
+ description: Recipe Template
+ prompt: Write your prompt in here
+ extensions:
+   - type: builtin
+     name: developer
+     display_name: Developer
+     timeout: 300
+     bundled: true
+ #only required if recipe description asks for user input
+ #parameters are used in within prompt like \{\{ key }} and must be present
+ parameters:
+   - key: example_parameter
+     input_type: string or number
+     requirement: required or optional
+     description: Description of the paramater.
+ ```
+ 
+ Important notes:
+ - title is the name of the recipe
+ - description is a short summary of what the recipe does
+ - parameters are used within prompt like \{\{ key }} and must be present if mentioned in the recipe description
+ 
+ Under prompt can you write instructions that achieve
+ {{ prompt }}
+ 
+ If the above is a file path, read the file to determine the goal.
+extensions:
+  - type: builtin
+    name: developer
+    display_name: Developer
+    timeout: 300
+    bundled: true

documentation/src/pages/recipes/data/recipes/remove-ai-artifacts-from-python-code.yaml

@@ -0,0 +1,37 @@
+version: 1.0.0
+title: Python un-AI
+author:
+  contact: douwe
+description: Remove typical AI artifacts from Python code
+instructions: Your job is to write a remove AI artifacts from Python code
+activities:
+  - Remove redundant comments  
+  - Fix exception handling  
+  - Modernize typing  
+  - Inline trivial functions  
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+prompt: |
+    Look at the file: {{ file_name }}
+    Apply the following fixes:
+    1. Remove any comment that replicates the name of a function or describes the next statement
+       but does not add anything. Like if it says # call the server and it is followed by a
+       statement call_server(), that's pointless
+    2. Any try.. except block where we catch bare Exception, remove that or if you can find a
+       specific exception to catch and it makes sense since we can actually do something better
+       catch that. But in general consider whether we need an exception like that, we don't want
+       to ignore errors and quite often the caller is in a better state to do the right thing
+       or even if it is a genuine error, the user can just take action
+    3. Modernize the typing used (if any). Don't use List with a capital, just use list. Same for
+       Dict vs dict etc. Also remove Optional and replace with |None. Use | anywhere else where
+       it fits too.
+    4. Inline trivial functions that are only called once, like reading text from a file.
+parameters:
+  - key: file_name
+    input_type: file
+    requirement: user_prompt
+    description: the full path to the python file you want to sanitize

documentation/src/pages/recipes/index.tsx

@@ -17,7 +17,7 @@ export default function RecipePage() {
   const [isLoading, setIsLoading] = useState(true);
   const [error, setError] = useState<string | null>(null);
   const [currentPage, setCurrentPage] = useState(1);
-  const recipesPerPage = 20;
+  const recipesPerPage = 10;
 
   const uniqueExtensions = Array.from(
     new Set(