repro-description

name	repro-description
description	Create a self-contained bug reproduction from a description. Asks which Sentry SDK is affected and suggests a descriptive branch name.
argument-hint	<bug-description>

Description-Based Reproduction Skill

This skill creates a self-contained bug reproduction from a description (without requiring a GitHub issue URL).

Input

The user provides a bug description, which can include:

• The unexpected behavior
• The expected behavior
• SDK version
• Framework being used
• Code snippets or configuration
• Environment details

Workflow

Step 1: Gather Information

Use the AskUserQuestion tool to collect:

1. Which Sentry SDK is affected?

   • Options: sentry-ruby, sentry-python, sentry-javascript, sentry-rust, sentry-java, sentry-dotnet, sentry-php, etc.

2. Suggest a descriptive branch name based on the bug description

   • Format: repro/{sdk}-{descriptive-name}
   • Example: repro/sentry-ruby-error-page-status-mismatch
   • Ask user to confirm or provide alternative

Step 2: Analyze the Description

Read through the description to understand:

• What is the bug/unexpected behavior?
• What is the expected behavior?
• What environment/setup is needed (language version, framework, dependencies)?
• What SDK version is mentioned (if any)?
• Are there code snippets or configuration examples provided?

Step 3: Create the Reproduction Directory

Create the directory structure:

{sdk}/{descriptive-name}/
├── README.md          # Instructions to run the reproduction
├── [package manager files]  # Dependencies (package.json, Gemfile, requirements.txt, etc.)
├── [reproduction files]

Directory naming:

• Extract SDK name from the full SDK identifier (e.g., sentry-ruby → ruby)
• Use the descriptive name provided/confirmed by the user
• Example: sentry-ruby/error-page-status-mismatch/

Step 4: Build the Reproduction

Create a minimal, self-contained reproduction that:

1. Demonstrates the reported bug clearly
2. Uses the minimal dependencies necessary
3. Can be run with simple commands (e.g., npm install && npm start or uv run or bundle exec)
4. Includes clear console output or error messages showing the bug

Guidelines for reproductions:

• Keep it minimal - only include what's needed to show the bug
• Install the Sentry SDK version mentioned in the description
  • Fall back to a recent/stable version if no specific version is provided
• Keep the DSN for Sentry empty and remind users to export SENTRY_DSN= in the instructions
• Use standard tooling where possible (npm, uv, bundle, pip, cargo, etc.)
• If the description mentions a specific framework (Django, Rails, Express, Flask, etc.), set up that framework minimally
• Include any necessary configuration files
• Add comments in the code explaining what should happen vs what actually happens
• Consider using Spotlight (https://spotlightjs.com/) for local Sentry event inspection where applicable

Step 5: Test the Reproduction

Before committing, verify the reproduction actually works:

1. Run the install commands
2. Run the reproduction
3. Confirm the bug manifests as described
4. If you get stuck, continue with Step 6 but mention it clearly in the README and still create the PR

Step 6: Write the README.md

The README.md in the reproduction directory should include:

# Reproduction for {sdk} {descriptive-name}

**SDK:** {sdk-name} v{version}

## Description

[Brief description of the bug being reproduced]

## Steps to Reproduce

1. Install dependencies:
   ```bash
   [install command]
   ```

2. (Optional) Start Spotlight for event inspection:
   ```bash
   npx @spotlightjs/spotlight
   ```

3. Run the reproduction:
   ```bash
   [command to run]
   ```

## Expected Behavior

[What should happen]

## Actual Behavior

[What actually happens - the bug]

## Reproduction Evidence

[If applicable, show console output, logs, or screenshots demonstrating the bug]

## Environment

- [Language]: [version if relevant]
- {sdk-name}: [version]
- [Framework]: [version if relevant]
- OS: [if relevant]

## Notes

[Any additional context or observations]

Step 7: Commit and Create PR

1. Create a new branch (if not already created):

   git checkout -b repro/{sdk}-{descriptive-name}
   

2. Stage and commit the files:

   git add {sdk}/{descriptive-name}/
   git commit -m "Add reproduction for {sdk} {descriptive-name}"
   

3. Push and create PR:

   git push -u origin repro/{sdk}-{descriptive-name}
   gh pr create --title "Reproduction for {sdk} {descriptive-name}" --body "..."
   

   The PR body should include:

   • Summary of the bug
   • Evidence from the reproduction (console output, logs, etc.)
   • Instructions to run it
   • Note that this is a description-based reproduction (no associated GitHub issue)

Step 8: No Backlink (Skip for Description-Based)

Since there's no GitHub issue, skip the backlink step. The reproduction stands alone as a demonstration of the bug.

Error Handling

• If the description is too vague, ask the user for more details about:
  • Expected vs actual behavior
  • SDK version
  • Framework being used
  • Any error messages or symptoms
• If the SDK is not specified, ask the user which SDK is affected

Example

For a description about "Rails 404 errors reported as 500 in Sentry trace data":

1. SDK: sentry-ruby
2. Descriptive name: error-page-status-mismatch
3. Directory: sentry-ruby/error-page-status-mismatch/
4. Branch: repro/sentry-ruby-error-page-status-mismatch
5. PR title: "Reproduction for sentry-ruby error-page-status-mismatch"

When to Use This Skill

Use this skill when:

• The user provides a bug description without a GitHub issue URL
• You want to create a standalone reproduction for testing or demonstration
• The bug hasn't been filed as an issue yet
• You're exploring a potential bug that needs a concrete example

Use the regular repro skill when:

• The user provides a GitHub issue URL
• You want to link the reproduction back to an existing issue