Add Internal Recipes To Recipes Cookbook

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