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.
Run score Not tested
See how to installThis skill turns rough bug reports or requests into Linear issues that someone can act on. It searches for existing issues using the error text and feature name, and checks the reported behavior where possible. The proposed issue separates observed facts from guesses and organizes the symptom, numbered reproduction steps, expected and actual results, impact, and evidence. It also prepares the team, priority, and labels.
Use it when you need to hand off a vague report such as “search is broken,” or when you have an error log to file in Linear. Checking for duplicates can help avoid tracking the same problem in separate issues.
The skill uses Linear integration tools. Before creating an issue, it presents the title, body, team, priority, and labels for the user to confirm. If it finds a duplicate, it shows the matching issue and proposed evidence comment for confirmation before posting. It asks when the team is unclear and leaves the estimate unset when the fix is not understood well enough to estimate.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.
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 a UI change or reproduce a bug in the running desktop app using the Chrome DevTools Protocol (CDP), a browser debugging interface. Follow the real user journey and compare screenshots with measurements such as route, scroll position, and persisted state.
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.