Turn rough bug reports or requests into Linear issues with clear symptoms, reproduction steps, evidence, and routing details. Check for duplicates, distinguish observations from guesses, and present the proposed issue for approval before creating it.
Turn a rough report into a Linear issue someone can pick up — reproduce the claim, check for duplicates, and fill in team, priority, and labels. Use when the user says to file, open, or create an issue, hands over a bug report or error, or asks to get something into Linear.
Review the instructions the agent will receive before you install.
An issue is a handoff to someone who was not in this conversation. The test is whether they can start without asking you a question.
Search for the error text and for the feature name separately — people describe the same bug in words that share no vocabulary. Check closed issues too, but do not read "closed" as "regression": most closed duplicates were closed during triage, not fixed. Call it a regression only when the issue shows a fix that shipped, or it was reopened — then it is a more urgent and differently-shaped report than a new bug.
Found a duplicate? Comment the new evidence on it instead of opening a second issue. Show the user the duplicate you matched and the comment you intend to leave, and post it only once they say to. A wrong match buries a real bug under an unrelated issue, and nobody goes looking for what they think is already tracked.
The report you were handed is a symptom filtered through someone's theory of the cause. Separate the two. Write down what was observed, and mark anything you inferred as inferred.
Where you can check the claim, check it. An issue that says "search is broken" and an issue that says "search returns no results for queries with an apostrophe, verified on staging" have very different lifespans.
Put the diagnosis last if you have one, marked as a guess. A confident wrong cause at the top of an issue sends the assignee down it before they read the steps.
Resolve the team from the area the bug lives in, not from who reported it. If you cannot tell, ask rather than guessing — a misrouted issue sits until someone triages it by hand.
Priority is about consequence, not annoyance: data loss and broken auth are urgent, a misaligned button is not, however visible. Set an estimate only if you understand the fix well enough to defend it; a wrong estimate is worse than none.
Print the title, body, team, priority, and labels, and ask the user to confirm. Filing is a write to a shared backlog that other people triage and get notified about; a misrouted or duplicate issue costs someone else's attention to undo. Reporting the result afterwards is not confirmation — by then the write has happened.
Once they confirm, create it and report the identifier and URL along with what you set, so a routing mistake gets corrected immediately rather than after it goes unread for a week.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.
Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.
Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.
Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.
Verify desktop UI changes through the Chrome DevTools Protocol, a connection for controlling the running app. Reproduce the user’s actual steps and compare screenshots, measured state, and console errors to establish evidence before and after a fix.
Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.