1.9 KiB
1.9 KiB
| trigger |
|---|
| always_on |
GitHub Issue Triage
When given a GitHub issue or discussion URL, follow this process:
1. Check Git History FIRST (before reading issue details)
# Search for commits referencing the issue number or related keywords
git log --all --since="30 days ago" --format="%h %ai %s" | grep -i "keywords|from|issue"
git log --all --oneline | grep -i "#123\|relevant-keywords" | head -20
- Look for commits that reference the issue number
- Check if the issue was already addressed
- Understand recent development context
2. Read ALL Comments
gh issue view 123 --repo owner/repo --json comments --jq '.comments[] | "\(.author.login) (\(.createdAt)): \(.body)"'
- NEVER respond based on partial context
- Later comments often contain critical context
- Check if users confirmed fixes or provided updates
3. Establish Timeline
- When was the issue created?
- What commits happened after?
- Did users comment after commits to confirm/deny fixes?
4. Challenge the Premise
- Does this request make sense architecturally?
- What are the security implications?
- Is this solving the right problem?
- Does similar functionality already exist?
- Is there a configuration or documentation solution instead?
5. Commit Message Rules
- Reference issues: "Related to #123" or "Addresses #123"
- NEVER use auto-close keywords: "Fixes #123", "Closes #123", "Resolves #123"
- Users must verify fixes before issues are closed
6. Comment Style (when writing responses)
- Direct but user-friendly, write for typical users not developers
- No "we", "us", "our"
- No exclamation marks or enthusiasm
- No bullets/dashes for lists
- No pleasantries ("hope this helps", "let me know")
- Use hedging when uncertain: "might", "could", "possibly"
- For fixes: just say "This will be in the next release"
- NEVER say "build from source" or "pull latest"
- Match the user's effort level in your response