$npx -y skills add getnao/sylph --skill create-issueStandard process for creating well-structured GitHub issues. Use for bugs, feature requests, and tasks.
| 1 | # Create GitHub Issue |
| 2 | |
| 3 | Standard process for creating well-structured GitHub issues. Use for bugs, feature requests, and tasks. |
| 4 | |
| 5 | ## MCP connectors |
| 6 | |
| 7 | | Connector | Purpose | |
| 8 | |-----------|---------| |
| 9 | | GitHub | Create and label issues | |
| 10 | |
| 11 | ## Bug report template |
| 12 | |
| 13 | ```markdown |
| 14 | ## Problem |
| 15 | |
| 16 | [Clear description of what's broken. Include steps to reproduce.] |
| 17 | |
| 18 | 1. Step one |
| 19 | 2. Step two |
| 20 | 3. Observe: [what happens] |
| 21 | |
| 22 | ## Expected behavior |
| 23 | |
| 24 | [What should happen instead] |
| 25 | |
| 26 | **Environment**: [browser, OS, version, relevant config] |
| 27 | ``` |
| 28 | |
| 29 | ## Feature request template |
| 30 | |
| 31 | ```markdown |
| 32 | ## Problem |
| 33 | |
| 34 | [What user problem does this solve? Who is affected?] |
| 35 | |
| 36 | ## Expected behavior |
| 37 | |
| 38 | [What the feature should do, from the user's perspective] |
| 39 | |
| 40 | ## Notes |
| 41 | |
| 42 | [Optional: technical considerations, related issues, mockups] |
| 43 | ``` |
| 44 | |
| 45 | ## Labels |
| 46 | |
| 47 | | Label | When to use | |
| 48 | |-------|------------| |
| 49 | | `bug` | Something is broken | |
| 50 | | `feature` | New functionality request | |
| 51 | | `enhancement` | Improvement to existing feature | |
| 52 | | `docs` | Documentation change needed | |
| 53 | | `good first issue` | Simple, well-scoped, good for new contributors | |
| 54 | | `priority:high` | Blocks users or causes data issues | |
| 55 | | `priority:low` | Nice to have, no urgency | |
| 56 | | `needs-triage` | Needs review before prioritization | |
| 57 | | `customer-reported` | Came from customer feedback | |
| 58 | |
| 59 | ## Process |
| 60 | |
| 61 | 1. **Check for duplicates** - search existing issues before creating |
| 62 | 2. **Use the right template** - bug report or feature request |
| 63 | 3. **Add labels** - at least one type label and one priority label |
| 64 | 4. **Link related issues** - reference with `#issue-number` if related |
| 65 | 5. **Assign** - only if the assignee is clear; otherwise leave unassigned |
| 66 | |
| 67 | ## Title format |
| 68 | |
| 69 | - Bug: `[component] Short description of what's broken` |
| 70 | - Feature: `[component] Short description of desired behavior` |
| 71 | - Docs: `docs: Short description of what needs updating` |
| 72 | |
| 73 | Examples: |
| 74 | - `[API] Query timeout on large datasets` |
| 75 | - `[Dashboard] Add date range filter to usage chart` |
| 76 | - `docs: Update authentication setup guide` |
| 77 | |
| 78 | ## Guardrails |
| 79 | |
| 80 | - **No PII** - scrub customer names, emails, and company names from all issue content |
| 81 | - **One issue per problem** - no omnibus issues covering multiple bugs |
| 82 | - **No Impact section** - keep body to Problem + Expected behavior only |
| 83 | - **No confidential data** - no API keys, credentials, or internal URLs in issues |
| 84 | - **Don't close issues** - only the CAO or the assignee closes issues |
| 85 | |
| 86 | ## Self-improvement |
| 87 | |
| 88 | After the CAO reviews created issues: |
| 89 | |
| 90 | 1. If the CAO edits an issue title, body, or labels before posting, note the pattern |
| 91 | 2. If her edits reveal a preference for how problems are framed, bug reports are structured, or priorities are assigned, update the Templates or Labels sections |
| 92 | 3. Update `product/_insights.md` with patterns: which issue formats get the fastest triage, which label conventions the team actually uses |
| 93 | 4. If an issue template works particularly well, save it to `product/_examples/` as a reference |