playbooks

home / skills / dyad-sh / dyad / feedback-to-issues

feedback-to-issues skill

/.claude/skills/feedback-to-issues

This skill converts customer feedback into actionable GitHub issues, detects duplicates, and drafts follow-up reply emails to streamline issue triage.

npx playbooks add skill dyad-sh/dyad --skill feedback-to-issues

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.7 KB
---
name: dyad:feedback-to-issues
description: Turn customer feedback (usually an email) into discrete GitHub issues. Checks for duplicates, proposes new issues for approval, creates them, and drafts a reply email.
---

# Feedback to Issues

Turn customer feedback (usually an email) into discrete GitHub issues. Checks for duplicates, proposes new issues for approval, creates them, and drafts a reply email.

## Arguments

- `$ARGUMENTS`: The customer feedback text (email body, support ticket, etc.). Can also be a file path to a text file containing the feedback.

## Instructions

1. **Parse the feedback:**

   Read `$ARGUMENTS` carefully. If it looks like a file path, read the file contents.

   Break the feedback down into discrete, actionable issues. For each issue, identify:
   - A concise title (imperative form, e.g., "Add dark mode support")
   - The type: `bug`, `feature`, `improvement`, or `question`
   - A clear description of what the customer is reporting or requesting
   - Severity/priority estimate: `high`, `medium`, or `low`
   - Any relevant quotes from the original feedback

   Ignore pleasantries, greetings, and non-actionable commentary. Focus on extracting concrete problems, requests, and suggestions.

2. **Search for existing issues:**

   For each discrete issue identified, search GitHub for existing issues that may already cover it:

   ```bash
   gh issue list --repo "$(gh repo view --json nameWithOwner -q '.nameWithOwner')" --state all --search "<relevant keywords>" --limit 10 --json number,title,state,url
   ```

   Try multiple keyword variations for each issue to avoid missing duplicates. Search both open and closed issues.

3. **Present the report to the user:**

   Format the report in three sections:

   ### Already Filed Issues

   For each issue that already has a matching GitHub issue, show:
   - The extracted issue title
   - The matching GitHub issue(s) with number, title, state (open/closed), and URL
   - Brief explanation of why it matches

   ### Proposed New Issues

   For each issue that does NOT have an existing match, show:
   - **Title**: The proposed issue title
   - **Type**: bug / feature / improvement / question
   - **Priority**: high / medium / low
   - **Body preview**: The proposed issue body (include the relevant customer quote and a clear description of what needs to happen)
   - **Labels**: Suggest appropriate labels based on the issue type

   ### Summary
   - Total issues extracted from feedback: N
   - Already filed: N
   - New issues to create: N

   **Then ask the user to review and approve the proposal before proceeding.** Do NOT create any issues yet. Wait for explicit approval. The user may want to edit titles, descriptions, priorities, or skip certain issues.

4. **Create approved issues:**

   After the user approves (they may request modifications first — apply those), create each approved issue:

   ```bash
   gh issue create --title "<title>" --body "<body>" --label "<labels>"
   ```

   Report back each created issue with its number and URL.

5. **Draft a reply email:**

   After all issues are created, draft a brief, professional reply email for the customer. The email should:
   - Thank them for their feedback
   - Briefly acknowledge each item they raised
   - For items that already had existing issues: mention it's already being tracked
   - For newly created issues: mention it's been filed and will be looked into
   - Keep it concise — no more than a few short paragraphs
   - Use a friendly but professional tone
   - Include a link to the GitHub issue URL for each item so the customer can follow progress
   - End with an invitation to share more feedback anytime

   Present the draft email to the user for review before they send it.

Overview

This skill turns customer feedback (email, ticket, or text file) into discrete GitHub issues, detects duplicates, proposes new issues for review, creates approved issues, and drafts a customer reply. It streamlines triage by extracting actionable items, searching the repository for matching issues, and preparing clear issue bodies and labels for maintainers.

How this skill works

The skill parses the feedback into separate, actionable items with an imperative title, type (bug/feature/improvement/question), a short description, priority, and relevant quotes. It searches GitHub for potential duplicates using multiple keyword variations, then presents a three-part report: already filed matches, proposed new issues with bodies and labels, and a summary. After user approval and any edits, it creates the issues and drafts a concise reply email linking to each issue.

When to use it

  • Processing customer support emails or helpdesk tickets into actionable engineering work.
  • Triage after product launch to capture early user reports and feature requests.
  • Regularly converting qualitative feedback from sales or success teams into tracked issues.
  • When you need a fast, consistent way to check for duplicate issues before filing new ones.

Best practices

  • Feed the raw message body or a plain text file to preserve original quotes for context.
  • Review and edit proposed titles, priorities, and bodies before approval to match team conventions.
  • Use multiple, focused keyword searches during duplicate detection to reduce false negatives.
  • Label new issues with product/component names in addition to type and priority for easier routing.
  • Keep reply emails short and link to issues so customers can follow progress themselves.

Example use cases

  • A support agent forwards a bug report email to produce a high-priority GitHub issue and reply to the customer.
  • Product managers batch-process feature requests gathered from interviews into proposed issues for roadmap review.
  • Customer success compiles UX complaints into discrete improvement issues and removes duplicates first.
  • Open-source maintainers convert community questions and reproducible bugs into tracked issues with links for reporters.

FAQ

Does the skill create issues automatically?

Not until you explicitly approve the proposed issues. It first presents matches and proposals for review, then creates only approved items.

How does duplicate detection work?

It runs multiple GitHub issue searches using varied keywords from each extracted item and reports matching open or closed issues with reasoning so you can confirm duplicates.