Auto-reproduce new GitHub bug reports in a sandbox

Build me an agent workflow that auto-attempts to reproduce new GitHub bug reports in a Daytona sandbox before an engineer ever looks at them.

Trigger: GitHub webhook for new issues created. Filter to issues that carry a configurable label (default: bug). Also skip the issue entirely if the body has no code block and no numbered steps, so vague reports don't waste sandbox time. Make the label and that skip rule configurable.

When an issue passes the filter, the agent should:

1. Use GitHub's Get an Issue to pull the full issue body, then extract the affected repository (default to the repo the issue was opened in) and the reporter's "steps to reproduce" section. If the report references env, OS, or version info, capture that too.

2. Use Daytona's Create Sandbox to spin up a fresh, short-lived sandbox with sensible auto-stop (e.g. 15 minutes idle) and auto-delete (e.g. a few hours) so it cleans itself up. Then call Git Clone Repository to clone the repo at the default branch into the sandbox.

3. Use Execute Command in Sandbox to run the project's setup (install dependencies, run any documented bootstrap script, populate a .env from a template if one exists). Detect the toolchain from lockfiles (package.json, pyproject.toml, go.mod, Gemfile, etc.) rather than hard-coding one stack.

4. Walk the reproduction steps one at a time using Execute Command in Sandbox for shell steps, Run Code in Sandbox for inline scripts, or curl/CLI calls for HTTP repros. Capture stdout, stderr, exit code, and any minimal stack trace for each step. Stop early as soon as the bug clearly reproduces or clearly does not.

5. If the bug is a server/HTTP one (the steps started a web process), use Get Sandbox Preview URL on the exposed port so a human can hit the running instance before the sandbox auto-stops.

6. Use Create an Issue Comment on the original GitHub issue summarizing: whether the bug reproduced (yes / no / inconclusive), the exact command sequence the agent ran, the relevant log excerpt (truncated, in a fenced code block), the preview URL if applicable, and a one-line guess at the likely subsystem (e.g. "auth middleware", "db migration", "frontend router") so a human can triage faster. Make it clear the comment is from an automated triage agent.

7. If reproduction succeeded, also use Slack Bot's Send a Message to post into a configurable #bug-triage channel with a link to the issue, the repo, the one-line subsystem guess, and a tag for the on-call user/group. Skip the Slack ping for non-reproducing or inconclusive runs (those just get the GitHub comment).

8. Use Stop Sandbox at the end of the run so cost stops accruing immediately; rely on Daytona's auto-delete to clean up the disk. If any step in the pipeline errored out (sandbox couldn't start, clone failed, setup failed), still post a GitHub comment explaining what blocked the repro attempt so the human triager isn't left wondering.

Keep the sandbox lifecycle tight: create, attempt repro, comment, stop. Never leave a sandbox running across runs. One issue = one sandbox.

Configurable inputs the user should be able to set when installing the workflow: the label to watch (default bug), the Slack channel for confirmed-bug alerts, the on-call user or user-group to tag, optional project setup commands to run after clone (overrides the auto-detected ones), and optional environment variables to inject into the sandbox.