b60638f0a3
Community Skills (32): - jat: jat-start, jat-verify, jat-complete - pi-mono: codex-cli, codex-5.3-prompting, interactive-shell - picoclaw: github, weather, tmux, summarize, skill-creator - dyad: 18 skills (swarm-to-plan, multi-pr-review, fix-issue, lint, etc.) - dexter: dcf valuation skill Agents (23): - pi-mono subagents: scout, planner, reviewer, worker - toad: 19 agent configs (Claude, Codex, Gemini, Copilot, OpenCode, etc.) System Prompts (91): - Anthropic: 15 Claude prompts (opus-4.6, code, cowork, etc.) - OpenAI: 49 GPT prompts (gpt-5 series, o3, o4-mini, tools) - Google: 13 Gemini prompts (2.5-pro, 3-pro, workspace, cli) - xAI: 5 Grok prompts - Other: 9 misc prompts (Notion, Raycast, Warp, Kagi, etc.) Hooks (9): - JAT hooks for session management, signal tracking, activity logging Prompts (6): - pi-mono templates for PR review, issue analysis, changelog audit Sources analyzed: jat, ralph-desktop, toad, pi-mono, cmux, pi-interactive-shell, craft-agents-oss, dexter, picoclaw, dyad, system_prompts_leaks, Prometheus, zed, clawdbot, OS-Copilot, and more
89 lines
3.7 KiB
Markdown
89 lines
3.7 KiB
Markdown
---
|
|
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.
|