qa-to-issues

Convert conversational bug reports into thin, domain-worded issues in a local ISSUES.md file.

1|Updated Jul 13, 2026
One-click install
npx skills add https://github.com/dineshrevunuru/SuperSkills --skill qa-to-issues-dineshrevunuru
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: qa-to-issues
Source: https://github.com/dineshrevunuru/SuperSkills/tree/main/qa-to-issues
Command: npx skills add https://github.com/dineshrevunuru/SuperSkills --skill qa-to-issues-dineshrevunuru

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Rambling bug reports like "it feels broken" either get filed as one unactionable mega-issue or discarded entirely. This Skill decomposes vague QA feedback into discrete, durable, independently-fixable issues worded in domain language, without over-interviewing the reporter or asserting unverified claims. ## Core Features & Use Cases - Conversational intake: Listens to plain-language bug descriptions, asks at most 2-3 clarifying questions, and files one thin issue at a time. - Mode-switchable filing: Defaults to a local ISSUES.md punch list for solo work, escalating to gh issue create with dependency ordering and AI-provenance notes only for shared GitHub repos. - Vibe decomposition: Breaks "everything feels broken" anchors into separate behavioral issues with What happened / Expected / Steps to reproduce / Context structure, leaving unverified doubts as open questions for triage. - Use Case: A beta tester texts that a salon booking app "feels broken and cheap" on mobile. The Skill files three thin issues (overlapping slot-picker chips, a hanging Confirm spinner, an unbranded confirmation email) and flags email delivery as an open question rather than an asserted bug. ## Quick Start Run a QA session on my app: I'll describe what's wrong in plain language, and you file each problem as a thin issue in ISSUES.md.

Frequently Asked Questions about qa-to-issues

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I turn a vague bug report into actionable issues?

Decompose the vague report into discrete failure modes and file each as its own thin issue with What happened, Expected, Steps to reproduce, and Context sections. Ask at most 2-3 clarifying questions, and file only what the reporter can actually stand behind.

How do I file bugs from a QA session without a tracker?

Append thin entries to a local ISSUES.md punch list at the repo root, one issue per concern. This is the default for solo work; escalate to gh issue create only when working on a shared GitHub repository.

Should a bug report include file paths and line numbers?

No. File paths and line numbers go stale after refactors. Describe the behavior at the seam in domain terms, such as "the slot picker chips overlap on mobile," so the issue stays durable across code changes.

When should I not use conversational bug intake?

Do not use it to verify reproduction, diagnose root causes, or fix bugs; those belong to triage and diagnosis steps. Also avoid it when a vague report is really an unstated feature request, which needs a problem statement instead.

Why file many thin issues instead of one detailed bug report?

Thin issues are independently fixable and verifiable, so multiple people or agents can work them in parallel. One thick issue mixing layout, logic, and content problems cannot be cleanly assigned, tracked, or verified.