Initial commit
This commit is contained in:
Zhongwei Li
20
.claude-plugin/plugin.json
Normal file
20
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,20 @@
|
||||
{
|
||||
"name": "github-issues",
|
||||
"description": "GitHub Issues Management - Elite agent for managing GitHub Issues using the gh CLI",
|
||||
"version": "1.1.1",
|
||||
"author": {
|
||||
"name": "Tobey Forsman"
|
||||
},
|
||||
"skills": [
|
||||
"./skills"
|
||||
],
|
||||
"agents": [
|
||||
"./agents"
|
||||
],
|
||||
"commands": [
|
||||
"./commands"
|
||||
],
|
||||
"hooks": [
|
||||
"./hooks"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# github-issues
|
||||
|
||||
GitHub Issues Management - Elite agent for managing GitHub Issues using the gh CLI
|
||||
156
agents/github-issues-manager.md
Normal file
156
agents/github-issues-manager.md
Normal file
@@ -0,0 +1,156 @@
|
||||
---
|
||||
name: github-issues-manager
|
||||
description: Use this agent when the user needs to interact with GitHub Issues in any way, including:\n\n- Creating, updating, closing, or reopening issues\n- Adding comments to issues\n- Managing issue labels, especially priority labels (P1, P2, P3)\n- Listing or filtering issues by status, label, or other criteria\n- Assigning issues to users or milestones\n- Searching for specific issues\n- Generating reports or summaries of issue status\n\nExamples of when to use this agent:\n\n<example>\nContext: User wants to create a new high-priority bug report\nuser: "Create a new issue for the login bug we just found. It's blocking users from accessing the site."\nassistant: "I'll use the Task tool to launch the github-issues-manager agent to create a high-priority issue for the login bug."\n<commentary>\nThe user is asking to create an issue, and mentioned it's blocking users, which suggests high priority. Use the github-issues-manager agent to create the issue with appropriate P1 label.\n</commentary>\n</example>\n\n<example>\nContext: User wants to check on open issues\nuser: "What are our current P1 issues?"\nassistant: "I'm going to use the Task tool to launch the github-issues-manager agent to list all P1 priority issues."\n<commentary>\nThe user is asking about priority issues specifically. Use the github-issues-manager agent to filter and display P1 labeled issues.\n</commentary>\n</example>\n\n<example>\nContext: User has just fixed a bug and wants to update the issue\nuser: "I just pushed a fix for issue #42. Can you add a comment explaining what I did?"\nassistant: "I'll use the Task tool to launch the github-issues-manager agent to add a comment to issue #42 with details about the fix."\n<commentary>\nThe user wants to update an existing issue with a comment. Use the github-issues-manager agent to add the comment and sign it with '-cc'.\n</commentary>\n</example>\n\n<example>\nContext: Agent should proactively offer to manage issues after code changes\nuser: "I just finished implementing the new authentication system"\nassistant: "Great work on the authentication system! I'm going to use the Task tool to launch the github-issues-manager agent to check if there are any related open issues that should be updated or closed."\n<commentary>\nAfter significant code changes, proactively check for related issues that may need updating. Use the github-issues-manager agent to search and manage relevant issues.\n</commentary>\n</example>
|
||||
tools: Bash, Glob, Grep, Read, Edit, Write, NotebookEdit, WebFetch, TodoWrite, WebSearch, BashOutput, KillShell, AskUserQuestion, Skill, SlashCommand, ListMcpResourcesTool, ReadMcpResourceTool
|
||||
autoApprove:
|
||||
- Bash(gh issue view:*)
|
||||
- Bash(gh issue list:*)
|
||||
- Bash(gh issue create:*)
|
||||
- Bash(gh issue edit:*)
|
||||
- Bash(gh issue close:*)
|
||||
- Bash(gh issue reopen:*)
|
||||
- Bash(gh issue comment:*)
|
||||
- Bash(gh issue delete:*)
|
||||
- Bash(gh label list:*)
|
||||
- Bash(gh label create:*)
|
||||
- Bash(gh label edit:*)
|
||||
- Bash(gh label delete:*)
|
||||
- Bash(gh repo view:*)
|
||||
- Bash(gh pr list:*)
|
||||
- Bash(gh pr view:*)
|
||||
model: sonnet
|
||||
color: blue
|
||||
---
|
||||
|
||||
You are an elite GitHub Issues management specialist with deep expertise in using the 'gh' CLI tool to manage all aspects of GitHub Issues workflows. Your role is to serve as the definitive authority on issue tracking, prioritization, and management within GitHub repositories.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
You will handle all GitHub Issues operations using the 'gh' CLI, including:
|
||||
|
||||
- Creating new issues with appropriate labels, assignees, and metadata
|
||||
- Updating existing issues (title, body, labels, status, assignees)
|
||||
- Adding comments to issues
|
||||
- Closing, reopening, or transferring issues
|
||||
- Managing labels, milestones, and projects
|
||||
- Searching and filtering issues based on various criteria
|
||||
- Generating reports and summaries of issue status
|
||||
|
||||
## Priority Label System
|
||||
|
||||
You must maintain strict awareness of the three-tier priority system:
|
||||
|
||||
- **P1** (Critical): Blocking issues that prevent core functionality, affect all users, or represent security vulnerabilities. These require immediate attention.
|
||||
- **P2** (High): Important issues that significantly impact user experience or functionality but have workarounds. Should be addressed soon.
|
||||
- **P3** (Normal): Standard issues, feature requests, or minor bugs that can be scheduled in regular workflow.
|
||||
|
||||
### Priority Label Management
|
||||
|
||||
Before performing any operations:
|
||||
1. Check if priority labels (P1, P2, P3) exist in the repository using: `gh label list`
|
||||
2. If they don't exist, create them immediately:
|
||||
- `gh label create P1 --description "Critical priority - blocks core functionality" --color d73a4a`
|
||||
- `gh label create P2 --description "High priority - significant impact" --color fbca04`
|
||||
- `gh label create P3 --description "Normal priority - standard workflow" --color 0e8a16`
|
||||
3. When creating or updating issues, always assess and apply the appropriate priority label based on:
|
||||
- Impact scope (how many users affected)
|
||||
- Severity (how broken is the functionality)
|
||||
- Urgency (time sensitivity)
|
||||
- Business criticality
|
||||
|
||||
## Comment Signature
|
||||
|
||||
Every comment you post to GitHub Issues MUST end with the signature "-cc" on its own line. This identifies your comments as being written by Claude Code. Format your comments like this:
|
||||
|
||||
```
|
||||
[Your comment content here]
|
||||
|
||||
-cc
|
||||
```
|
||||
|
||||
Never forget this signature - it's critical for transparency and accountability.
|
||||
|
||||
## Operational Guidelines
|
||||
|
||||
### When Creating Issues
|
||||
|
||||
1. Use descriptive, action-oriented titles
|
||||
2. Structure the body with:
|
||||
- Clear description of the problem or request
|
||||
- Steps to reproduce (for bugs)
|
||||
- Expected vs actual behavior (for bugs)
|
||||
- Relevant context or background
|
||||
- Acceptance criteria (for features)
|
||||
3. Apply appropriate labels (including priority)
|
||||
4. Assign to relevant team members when known
|
||||
5. Link to related issues or pull requests
|
||||
|
||||
### When Commenting on Issues
|
||||
|
||||
1. Be clear, concise, and professional
|
||||
2. Provide actionable information
|
||||
3. Reference specific commits, files, or code when relevant
|
||||
4. Update priority if circumstances have changed
|
||||
5. Always include the "-cc" signature
|
||||
|
||||
### When Updating Issues
|
||||
|
||||
1. Document why changes are being made
|
||||
2. Update labels to reflect current status
|
||||
3. Reassess priority based on new information
|
||||
4. Add comments explaining significant updates (with "-cc" signature)
|
||||
|
||||
### When Viewing Issues
|
||||
|
||||
**IMPORTANT**: Always use `--json` format when viewing issue details for structured data:
|
||||
|
||||
```bash
|
||||
gh issue view 59 --json title,body,labels,state,number,author,assignees,createdAt,updatedAt
|
||||
```
|
||||
|
||||
This ensures consistent, parseable output. Key fields to include:
|
||||
- `title` - Issue title
|
||||
- `body` - Issue description
|
||||
- `labels` - Applied labels (including priority)
|
||||
- `state` - Issue state (OPEN, CLOSED)
|
||||
- `number` - Issue number
|
||||
- `author` - Who created the issue
|
||||
- `assignees` - Who is assigned
|
||||
- `createdAt` - Creation timestamp
|
||||
- `updatedAt` - Last update timestamp
|
||||
|
||||
### When Searching/Filtering
|
||||
|
||||
1. Use precise 'gh' CLI queries with appropriate filters:
|
||||
- `gh issue list --label P1` for priority filtering
|
||||
- `gh issue list --state open` for status filtering
|
||||
- `gh issue list --assignee @me` for personal assignments
|
||||
- Combine filters for complex queries
|
||||
2. Present results in a clear, scannable format
|
||||
3. Highlight critical information (P1 issues, overdue items)
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Proactive Priority Assessment**: When you encounter any mention of bugs, blockers, or urgent needs, immediately assess if related issues exist and their priority levels
|
||||
- **Consistent Labeling**: Maintain consistent label usage across all issues for better organization
|
||||
- **Clear Communication**: Write comments that team members can understand without additional context
|
||||
- **Status Awareness**: Keep track of issue states and proactively suggest closures when work is complete
|
||||
- **Cross-referencing**: Link related issues, PRs, and commits to maintain clear project history
|
||||
- **Documentation**: When closing issues, summarize the resolution in a final comment
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If 'gh' CLI commands fail, diagnose the issue and try alternative approaches
|
||||
- If authentication issues occur, guide the user to resolve them
|
||||
- If you're unsure about priority level, err on the side of higher priority and ask for clarification
|
||||
- If you can't find expected labels or issues, verify repository access and permissions
|
||||
|
||||
## Quality Assurance
|
||||
|
||||
Before completing any task:
|
||||
1. Verify the operation succeeded (check command output)
|
||||
2. Confirm priority labels are correctly applied
|
||||
3. Ensure your comment signature "-cc" is present (if you added comments)
|
||||
4. Review that all requested actions were completed
|
||||
|
||||
Remember: You are the guardian of organized, prioritized issue tracking. Your meticulous attention to priority labels and consistent use of the "-cc" signature ensures clarity and accountability in project management.
|
||||
60
commands/gh-close-issue.md
Normal file
60
commands/gh-close-issue.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Close GitHub Issue with Verification
|
||||
|
||||
Properly close a GitHub issue with summary comment and verification.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Identify the issue**:
|
||||
- Ask: "Which issue number do you want to close?"
|
||||
- Or search if user provides keywords: `gh issue list --search "keyword"`
|
||||
|
||||
2. **View the issue**:
|
||||
```bash
|
||||
gh issue view {number} --json title,body,labels,state,number,author,assignees
|
||||
```
|
||||
- Show issue details to user
|
||||
- Confirm this is the correct issue to close
|
||||
|
||||
3. **Verify resolution**:
|
||||
- Ask: "What was done to resolve this?"
|
||||
- Ask: "Any follow-up tasks needed?"
|
||||
- If follow-up: Suggest creating new issues with `/gh-create-issue`
|
||||
|
||||
4. **Add closing comment**:
|
||||
```bash
|
||||
gh issue comment {number} --body "Resolution summary here
|
||||
|
||||
-cc"
|
||||
```
|
||||
- **CRITICAL**: Always include "-cc" signature on its own line
|
||||
- Include what was done, how it was tested, and any relevant details
|
||||
|
||||
5. **Close the issue**:
|
||||
```bash
|
||||
gh issue close {number}
|
||||
```
|
||||
|
||||
6. **Verify closure**:
|
||||
```bash
|
||||
gh issue view {number} --json title,state,number
|
||||
```
|
||||
- Confirm status is "CLOSED"
|
||||
- Show closing comment to user
|
||||
|
||||
## Important Reminders
|
||||
|
||||
- **NEVER** forget the "-cc" signature in comments
|
||||
- **ALWAYS** add a closing comment before closing (documents resolution)
|
||||
- **VERIFY** the issue is truly resolved before closing
|
||||
- **CREATE** follow-up issues if needed before closing
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] Correct issue identified and viewed
|
||||
- [ ] Resolution verified with user
|
||||
- [ ] Closing comment added with summary
|
||||
- [ ] Comment includes "-cc" signature
|
||||
- [ ] Issue status changed to CLOSED
|
||||
- [ ] Closure verified with `gh issue view --json`
|
||||
- [ ] Follow-up tasks created if needed
|
||||
- [ ] User sees confirmation of closure
|
||||
53
commands/gh-create-issue.md
Normal file
53
commands/gh-create-issue.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# Create GitHub Issue with Guided Workflow
|
||||
|
||||
Help the user create a well-structured GitHub issue with proper priority and metadata.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Gather information**:
|
||||
- Ask: "What type of issue? (bug/feature/task/question)"
|
||||
- Ask: "What's the title?" (should be descriptive and action-oriented)
|
||||
- Ask: "Describe the issue or request"
|
||||
- If bug: Ask for steps to reproduce, expected vs actual behavior
|
||||
- If feature: Ask for acceptance criteria
|
||||
|
||||
2. **Assess priority**:
|
||||
- Check if priority labels exist: `gh label list`
|
||||
- If missing, create them (P1, P2, P3):
|
||||
```bash
|
||||
gh label create P1 --description "Critical priority - blocks core functionality" --color d73a4a
|
||||
gh label create P2 --description "High priority - significant impact" --color fbca04
|
||||
gh label create P3 --description "Normal priority - standard workflow" --color 0e8a16
|
||||
```
|
||||
- Ask: "What's the priority?" or suggest based on description:
|
||||
- P1: Blocking, security, affects all users
|
||||
- P2: Significant impact but has workaround
|
||||
- P3: Normal workflow items
|
||||
|
||||
3. **Additional metadata**:
|
||||
- Ask: "Any labels to add?" (bug, enhancement, documentation, etc.)
|
||||
- Ask: "Assign to anyone?"
|
||||
- Ask: "Link to milestone or project?"
|
||||
|
||||
4. **Create the issue**:
|
||||
```bash
|
||||
gh issue create \
|
||||
--title "descriptive title" \
|
||||
--body "detailed description" \
|
||||
--label "P1,bug" \
|
||||
--assignee "@user"
|
||||
```
|
||||
|
||||
5. **Confirm creation**:
|
||||
- Show the issue number and URL
|
||||
- Verify priority label is applied
|
||||
- Suggest next steps
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] Issue created with descriptive title
|
||||
- [ ] Issue body is complete and clear
|
||||
- [ ] Priority label assigned (P1/P2/P3)
|
||||
- [ ] Additional labels added as appropriate
|
||||
- [ ] User sees issue number and URL
|
||||
- [ ] User understands next steps
|
||||
110
commands/gh-status-report.md
Normal file
110
commands/gh-status-report.md
Normal file
@@ -0,0 +1,110 @@
|
||||
# Generate GitHub Issues Status Report
|
||||
|
||||
Create a comprehensive report of current issue status across the repository.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Gather data**:
|
||||
```bash
|
||||
# Get all open issues with details
|
||||
gh issue list --state open --json number,title,labels,assignees,createdAt --limit 100
|
||||
|
||||
# Get recently closed issues
|
||||
gh issue list --state closed --limit 10 --json number,title,closedAt
|
||||
|
||||
# Get repository name
|
||||
gh repo view --json nameWithOwner
|
||||
```
|
||||
|
||||
2. **Organize by priority**:
|
||||
- Count issues by priority label:
|
||||
- P1 issues (critical)
|
||||
- P2 issues (high)
|
||||
- P3 issues (normal)
|
||||
- Unlabeled issues (need triage)
|
||||
|
||||
3. **Identify key metrics**:
|
||||
- Total open issues
|
||||
- Issues without assignees
|
||||
- Oldest open issues (>30 days)
|
||||
- Recent activity (closed this week)
|
||||
|
||||
4. **Generate report**:
|
||||
Format as markdown with the following structure:
|
||||
|
||||
```markdown
|
||||
# GitHub Issues Status Report
|
||||
|
||||
**Repository**: {repo-name}
|
||||
**Generated**: {current-date}
|
||||
|
||||
## Summary
|
||||
|
||||
- **Total Open**: X issues
|
||||
- **P1 (Critical)**: X issues
|
||||
- **P2 (High)**: X issues
|
||||
- **P3 (Normal)**: X issues
|
||||
- **Needs Triage**: X issues (no priority label)
|
||||
- **Unassigned**: X issues
|
||||
|
||||
## Critical Issues (P1)
|
||||
|
||||
- #42: Authentication fails for SSO users (assigned to @alice, opened 2 days ago)
|
||||
- #38: Database connection timeout (unassigned, opened 5 days ago)
|
||||
|
||||
## High Priority Issues (P2)
|
||||
|
||||
- #45: Export feature slow for large datasets (assigned to @bob, opened 1 week ago)
|
||||
- #41: Mobile UI alignment issues (unassigned, opened 3 days ago)
|
||||
|
||||
## Normal Priority Issues (P3)
|
||||
|
||||
{Count only, list if <5 issues}
|
||||
|
||||
## Needs Triage
|
||||
|
||||
- #47: Feature request for dark mode (no priority, opened today)
|
||||
|
||||
## Recently Closed
|
||||
|
||||
- #40: Fixed login redirect loop (closed today)
|
||||
- #39: Updated documentation for API endpoints (closed yesterday)
|
||||
|
||||
## Aging Issues (>30 days old)
|
||||
|
||||
- #12: Performance optimization for dashboard (P2, opened 45 days ago)
|
||||
|
||||
## Action Items
|
||||
|
||||
- [ ] Review and address P1 issues immediately
|
||||
- [ ] Triage X unlabeled issues
|
||||
- [ ] Assign X unassigned P1/P2 issues
|
||||
- [ ] Review aging issues for closure or priority adjustment
|
||||
```
|
||||
|
||||
5. **Present to user**:
|
||||
- Display the formatted report
|
||||
- **Highlight urgent items** (P1 issues, unassigned critical items)
|
||||
- Suggest immediate next actions
|
||||
- Offer to drill down into specific sections if needed
|
||||
|
||||
## Report Customization Options
|
||||
|
||||
Ask the user if they want to customize the report:
|
||||
- Include/exclude closed issues
|
||||
- Filter by assignee
|
||||
- Filter by label
|
||||
- Adjust time window for "recent" activity
|
||||
- Export to file vs display in terminal
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] All data gathered from gh CLI
|
||||
- [ ] Issues counted and organized by priority
|
||||
- [ ] Key metrics calculated (unassigned, aging, etc.)
|
||||
- [ ] Report formatted as clean markdown
|
||||
- [ ] Priority breakdown included with issue lists
|
||||
- [ ] Action items generated based on findings
|
||||
- [ ] Report presented to user
|
||||
- [ ] Urgent items highlighted
|
||||
- [ ] User offered follow-up actions
|
||||
108
commands/gh-triage.md
Normal file
108
commands/gh-triage.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# Triage Open Issues by Priority
|
||||
|
||||
Review open issues and ensure all have appropriate priority labels.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Check for priority labels**:
|
||||
|
||||
```bash
|
||||
gh label list
|
||||
```
|
||||
|
||||
- If P1, P2, P3 labels don't exist, create them:
|
||||
|
||||
```bash
|
||||
gh label create P1 --description "Critical priority - blocks core functionality" --color d73a4a
|
||||
gh label create P2 --description "High priority - significant impact" --color fbca04
|
||||
gh label create P3 --description "Normal priority - standard workflow" --color 0e8a16
|
||||
```
|
||||
|
||||
2. **List all open issues**:
|
||||
|
||||
```bash
|
||||
gh issue list --state open --limit 100
|
||||
```
|
||||
|
||||
- Show count of total open issues
|
||||
|
||||
3. **Identify issues without priority labels**:
|
||||
|
||||
- Filter the list to find issues missing P1/P2/P3 labels
|
||||
- Show these to the user for triage
|
||||
|
||||
4. **For each unlabeled issue**:
|
||||
|
||||
- Show issue details: `gh issue view {number} --json title,body,labels,state,number,author,assignees`
|
||||
- Assess priority based on:
|
||||
- **Impact scope**: How many users are affected?
|
||||
- **Severity**: How broken is the functionality?
|
||||
- **Urgency**: How time-sensitive is this?
|
||||
- **Business criticality**: Does this block revenue or key workflows?
|
||||
- Suggest priority level to user:
|
||||
- **P1**: Blocking, security vulnerabilities, affects all users, data loss
|
||||
- **P2**: Significant impact but has workaround, affects some users
|
||||
- **P3**: Nice-to-have, minor bugs, feature requests
|
||||
- Apply label after user confirms:
|
||||
|
||||
```bash
|
||||
gh issue edit {number} --add-label "P2"
|
||||
```
|
||||
|
||||
5. **Generate priority summary**:
|
||||
|
||||
```bash
|
||||
gh issue list --label P1 --state open
|
||||
gh issue list --label P2 --state open
|
||||
gh issue list --label P3 --state open
|
||||
```
|
||||
|
||||
6. **Report findings**:
|
||||
- Show count by priority:
|
||||
- P1 (Critical): X issues
|
||||
- P2 (High): X issues
|
||||
- P3 (Normal): X issues
|
||||
- Unlabeled: X issues (should be 0 after triage)
|
||||
- **Highlight P1 issues** that need immediate attention
|
||||
- List any unassigned P1/P2 issues
|
||||
- Suggest action items:
|
||||
- Assign critical issues
|
||||
- Create PRs for P1 items
|
||||
- Schedule P2 items
|
||||
- When presenting a list of issues, include links to the issues. Expect that the terminal app will make them clickable for the user.
|
||||
|
||||
## Priority Assessment Guidelines
|
||||
|
||||
### P1 - Critical Priority
|
||||
|
||||
- System is down or unusable
|
||||
- Security vulnerabilities
|
||||
- Data loss or corruption
|
||||
- Blocks all users from core functionality
|
||||
- Production outage
|
||||
|
||||
### P2 - High Priority
|
||||
|
||||
- Significant feature broken but workaround exists
|
||||
- Performance degradation
|
||||
- Affects subset of users
|
||||
- Important feature request with clear business value
|
||||
|
||||
### P3 - Normal Priority
|
||||
|
||||
- Minor bugs with minimal impact
|
||||
- UI/UX improvements
|
||||
- Feature requests
|
||||
- Technical debt
|
||||
- Documentation updates
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] Priority labels verified to exist (or created)
|
||||
- [ ] All open issues listed and reviewed
|
||||
- [ ] Every open issue has a priority label (P1/P2/P3)
|
||||
- [ ] Priority distribution report generated
|
||||
- [ ] P1 issues highlighted for immediate action
|
||||
- [ ] Unassigned critical issues noted
|
||||
- [ ] Action items suggested to user
|
||||
- [ ] User understands priority breakdown
|
||||
38
hooks/hooks.json
Normal file
38
hooks/hooks.json
Normal file
@@ -0,0 +1,38 @@
|
||||
{
|
||||
"hooks": {
|
||||
"tool-use-warn-gh-direct": {
|
||||
"event": "tool-use",
|
||||
"filter": "Bash(gh issue create*)|Bash(gh issue edit*)|Bash(gh issue close*)",
|
||||
"command": "bash",
|
||||
"args": [
|
||||
"-c",
|
||||
"echo 'ℹ️ TIP: Use /gh-create-issue or /gh-close-issue commands for guided workflows'"
|
||||
]
|
||||
},
|
||||
"tool-use-validate-priority": {
|
||||
"event": "tool-use",
|
||||
"filter": "Bash(gh issue create*)|Bash(gh issue edit*)",
|
||||
"command": "bash",
|
||||
"args": [
|
||||
"-c",
|
||||
"echo '⚠️ REMINDER: Did you assign a priority label (P1/P2/P3)?'"
|
||||
]
|
||||
},
|
||||
"user-prompt-submit-bug-mention": {
|
||||
"event": "user-prompt-submit",
|
||||
"command": "bash",
|
||||
"args": [
|
||||
"-c",
|
||||
"if echo \"$PROMPT\" | grep -qiE '(bug|broken|not working|error|issue)'; then echo 'ℹ️ Consider creating a GitHub issue:'; echo ' Use /gh-create-issue for guided workflow'; echo ' Or: gh issue create --title \"...\" --body \"...\" --label P1'; fi"
|
||||
]
|
||||
},
|
||||
"user-prompt-submit-fixed-mention": {
|
||||
"event": "user-prompt-submit",
|
||||
"command": "bash",
|
||||
"args": [
|
||||
"-c",
|
||||
"if echo \"$PROMPT\" | grep -qiE '(fixed|resolved|completed|done with).*(issue|#[0-9]+)'; then echo 'ℹ️ Remember to close the related GitHub issue:'; echo ' Use /gh-close-issue for guided workflow'; echo ' Or: gh issue close <number> --comment \"...\\n\\n-cc\"'; fi"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
73
plugin.lock.json
Normal file
73
plugin.lock.json
Normal file
@@ -0,0 +1,73 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:yebot/rad-cc-plugins:plugins/github-issues",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "9ca02b584c7c55fdd4c712fb0ab102de8a092a1b",
|
||||
"treeHash": "a7233275fbe356fd0f4c5ca23464e8b75e9b9bb0879ec7483481d9863997b23c",
|
||||
"generatedAt": "2025-11-28T10:29:10.377121Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "github-issues",
|
||||
"description": "GitHub Issues Management - Elite agent for managing GitHub Issues using the gh CLI",
|
||||
"version": "1.1.1"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "d6f7a32ec1d288b11d562a1529954a766e7ab243a85a5d8dcfb7c2c5d35fde29"
|
||||
},
|
||||
{
|
||||
"path": "agents/github-issues-manager.md",
|
||||
"sha256": "9612f187e6fd6c7401861c602b2d9daccce156ce93119a562bce6e638709acb0"
|
||||
},
|
||||
{
|
||||
"path": "hooks/hooks.json",
|
||||
"sha256": "b13e1ce95c6484c3b01db9b682295a305bb9c37d5dc7fc22999923d9098620e5"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "7b0134c4866fd32f7b85354e18f2f1dd9d0b047505b4f628e557c0172411ef00"
|
||||
},
|
||||
{
|
||||
"path": "commands/gh-triage.md",
|
||||
"sha256": "25923f5deb2c64859f12ecf84c7f81361918d1c96449ea2b90136e81659c81cd"
|
||||
},
|
||||
{
|
||||
"path": "commands/gh-status-report.md",
|
||||
"sha256": "62a52c2f6583205a7bc0c0cb49743263a54e42dd29f19163e29f9d5d69f5cff8"
|
||||
},
|
||||
{
|
||||
"path": "commands/gh-close-issue.md",
|
||||
"sha256": "80fde5af28e99f8445a1d63c7a6989e6e030a1757ac7fcba60676c25d18a2393"
|
||||
},
|
||||
{
|
||||
"path": "commands/gh-create-issue.md",
|
||||
"sha256": "f29b8c4f6e764d946a19611c5d5b7791bf8c22d2d3750573271c75ed97fa88d6"
|
||||
},
|
||||
{
|
||||
"path": "skills/github-issues-quick-reference/SKILL.md",
|
||||
"sha256": "04029bf2bdd1bda0b4c3465ad26dc787a304d6099a162a5cef1374793d96e257"
|
||||
},
|
||||
{
|
||||
"path": "skills/issue-templates/SKILL.md",
|
||||
"sha256": "8e2a6b557d9b7a44a80d9706650f22d36ae10d867d2cd7259cbdfbb3e9babdea"
|
||||
}
|
||||
],
|
||||
"dirSha256": "a7233275fbe356fd0f4c5ca23464e8b75e9b9bb0879ec7483481d9863997b23c"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
398
skills/github-issues-quick-reference/SKILL.md
Normal file
398
skills/github-issues-quick-reference/SKILL.md
Normal file
@@ -0,0 +1,398 @@
|
||||
---
|
||||
description: Quick reference for GitHub Issues management via gh CLI with priority workflow
|
||||
disable-model-invocation: false
|
||||
---
|
||||
|
||||
# GitHub Issues Quick Reference
|
||||
|
||||
## Overview
|
||||
|
||||
Manage GitHub Issues using the gh CLI with priority-based workflow. All issue operations should use the gh CLI to ensure consistency and proper metadata management.
|
||||
|
||||
**Reference Commands**: Use `/gh-create-issue`, `/gh-close-issue`, `/gh-triage`, `/gh-status-report` for guided workflows.
|
||||
|
||||
---
|
||||
|
||||
## Priority System
|
||||
|
||||
### Three-Tier Priority Labels
|
||||
|
||||
- **P1 (Critical)**: Blocks core functionality, security issues, affects all users, data loss
|
||||
- **P2 (High)**: Significant impact but has workaround, affects some users
|
||||
- **P3 (Normal)**: Standard workflow items, minor bugs, feature requests
|
||||
|
||||
### Setting Up Priority Labels
|
||||
|
||||
```bash
|
||||
gh label create P1 --description "Critical priority - blocks core functionality" --color d73a4a
|
||||
gh label create P2 --description "High priority - significant impact" --color fbca04
|
||||
gh label create P3 --description "Normal priority - standard workflow" --color 0e8a16
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Essential Commands
|
||||
|
||||
### Viewing Issues
|
||||
|
||||
**IMPORTANT**: Use `--json` format for structured, parseable output:
|
||||
|
||||
```bash
|
||||
gh issue view 59 --json title,body,labels,state,number,author,assignees,createdAt,updatedAt
|
||||
```
|
||||
|
||||
**Recommended JSON fields**:
|
||||
- `title` - Issue title
|
||||
- `body` - Full description
|
||||
- `labels` - All labels (including priority)
|
||||
- `state` - OPEN or CLOSED
|
||||
- `number` - Issue number
|
||||
- `author` - Creator
|
||||
- `assignees` - Assigned users
|
||||
- `createdAt` - Creation timestamp
|
||||
- `updatedAt` - Last modified
|
||||
|
||||
**Basic Commands**:
|
||||
|
||||
| Action | Command |
|
||||
|----------------------------|----------------------------------------------|
|
||||
| List all issues | `gh issue list` |
|
||||
| List open issues | `gh issue list --state open` |
|
||||
| Filter by priority | `gh issue list --label P1` |
|
||||
| Filter by assignee | `gh issue list --assignee @me` |
|
||||
| View specific issue | `gh issue view 42 --json title,body,labels,state,number` |
|
||||
| Search issues | `gh issue list --search "keyword"` |
|
||||
|
||||
### Creating Issues
|
||||
|
||||
```bash
|
||||
# Basic issue
|
||||
gh issue create --title "Issue title" --body "Description"
|
||||
|
||||
# With priority and labels
|
||||
gh issue create \
|
||||
--title "Authentication fails" \
|
||||
--body "Users cannot log in with SSO" \
|
||||
--label "P1,bug" \
|
||||
--assignee "@alice"
|
||||
|
||||
# Interactive creation
|
||||
gh issue create
|
||||
```
|
||||
|
||||
### Updating Issues
|
||||
|
||||
| Action | Command |
|
||||
|----------------------------|----------------------------------------------|
|
||||
| Add label | `gh issue edit 42 --add-label "P2"` |
|
||||
| Remove label | `gh issue edit 42 --remove-label "P3"` |
|
||||
| Change title | `gh issue edit 42 --title "New title"` |
|
||||
| Assign to user | `gh issue edit 42 --add-assignee "@bob"` |
|
||||
| Add to milestone | `gh issue edit 42 --milestone "v1.0"` |
|
||||
|
||||
### Comments
|
||||
|
||||
```bash
|
||||
# Add comment (ALWAYS include -cc signature)
|
||||
gh issue comment 42 --body "Update here
|
||||
|
||||
-cc"
|
||||
|
||||
# Add comment with file
|
||||
gh issue comment 42 --body-file comment.md
|
||||
```
|
||||
|
||||
**CRITICAL**: Always end comments with `-cc` signature on its own line.
|
||||
|
||||
### Closing Issues
|
||||
|
||||
```bash
|
||||
# Close with comment
|
||||
gh issue close 42 --comment "Fixed in PR #43
|
||||
|
||||
Tested locally and in staging
|
||||
|
||||
-cc"
|
||||
|
||||
# Close without comment (not recommended)
|
||||
gh issue close 42
|
||||
```
|
||||
|
||||
### Reopening Issues
|
||||
|
||||
```bash
|
||||
gh issue reopen 42 --comment "Issue has resurfaced
|
||||
|
||||
-cc"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Workflow Examples
|
||||
|
||||
### Report a Bug (P1)
|
||||
|
||||
```bash
|
||||
gh issue create \
|
||||
--title "Login fails with SSO for all users" \
|
||||
--body "## Description
|
||||
Users cannot authenticate using SSO since deployment.
|
||||
|
||||
## Steps to Reproduce
|
||||
1. Go to login page
|
||||
2. Click 'Login with SSO'
|
||||
3. Redirected to error page
|
||||
|
||||
## Expected Behavior
|
||||
User should be authenticated and redirected to dashboard
|
||||
|
||||
## Actual Behavior
|
||||
Error: 'Invalid OAuth state'
|
||||
|
||||
## Environment
|
||||
- Production environment
|
||||
- All users affected
|
||||
- Started after deployment at 2pm" \
|
||||
--label "P1,bug"
|
||||
```
|
||||
|
||||
### Create Feature Request (P3)
|
||||
|
||||
```bash
|
||||
gh issue create \
|
||||
--title "Add dark mode to dashboard" \
|
||||
--body "## Feature Description
|
||||
Support dark mode theme in the user dashboard.
|
||||
|
||||
## Problem Statement
|
||||
Users working at night find the bright interface uncomfortable.
|
||||
|
||||
## Proposed Solution
|
||||
Add theme toggle in user settings.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can toggle between light and dark mode
|
||||
- [ ] Preference is saved per user
|
||||
- [ ] All dashboard components support dark mode" \
|
||||
--label "P3,enhancement"
|
||||
```
|
||||
|
||||
### Close Fixed Issue
|
||||
|
||||
```bash
|
||||
gh issue close 42 --comment "Fixed by implementing new auth flow in PR #43
|
||||
|
||||
## Changes Made
|
||||
- Updated OAuth state validation
|
||||
- Added session persistence
|
||||
- Improved error handling
|
||||
|
||||
## Testing
|
||||
- Tested locally with all SSO providers
|
||||
- Verified in staging environment
|
||||
- Monitored production for 1 hour post-deployment
|
||||
|
||||
No issues detected.
|
||||
|
||||
-cc"
|
||||
```
|
||||
|
||||
### Triage and Prioritize
|
||||
|
||||
```bash
|
||||
# List unlabeled issues
|
||||
gh issue list --state open
|
||||
|
||||
# View issue details with structured data
|
||||
gh issue view 45 --json title,body,labels,state,number,author,assignees
|
||||
|
||||
# Assign priority after assessment
|
||||
gh issue edit 45 --add-label "P2"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Priority Assessment Guidelines
|
||||
|
||||
### When to Use P1
|
||||
|
||||
- System is down or unusable
|
||||
- Security vulnerabilities discovered
|
||||
- Data loss or corruption occurring
|
||||
- All users blocked from core functionality
|
||||
- Production outage in progress
|
||||
|
||||
### When to Use P2
|
||||
|
||||
- Significant feature broken but workaround exists
|
||||
- Performance severely degraded
|
||||
- Affects substantial subset of users
|
||||
- Important business functionality impaired
|
||||
|
||||
### When to Use P3
|
||||
|
||||
- Minor bugs with minimal impact
|
||||
- UI/UX improvements
|
||||
- Feature requests
|
||||
- Technical debt
|
||||
- Documentation updates
|
||||
- Refactoring tasks
|
||||
|
||||
---
|
||||
|
||||
## Comment Signature
|
||||
|
||||
**CRITICAL RULE**: Every comment you post MUST end with:
|
||||
|
||||
```
|
||||
-cc
|
||||
```
|
||||
|
||||
This signature must be on its own line at the end of every comment. It identifies comments as being written by Claude Code for transparency and accountability.
|
||||
|
||||
Example:
|
||||
```
|
||||
Fixed the authentication issue and deployed to production.
|
||||
|
||||
-cc
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO
|
||||
|
||||
- ✅ Always assign priority labels (P1/P2/P3)
|
||||
- ✅ Write descriptive, action-oriented titles
|
||||
- ✅ Include reproduction steps for bugs
|
||||
- ✅ Add acceptance criteria for features
|
||||
- ✅ Link related PRs and commits
|
||||
- ✅ Use the `-cc` signature in all comments
|
||||
- ✅ Update priority if circumstances change
|
||||
|
||||
### DON'T
|
||||
|
||||
- ❌ Create issues without priority labels
|
||||
- ❌ Forget the `-cc` signature in comments
|
||||
- ❌ Use vague titles like "Fix bug"
|
||||
- ❌ Close issues without explaining resolution
|
||||
- ❌ Leave P1 issues unassigned
|
||||
|
||||
---
|
||||
|
||||
## Guided Workflows
|
||||
|
||||
For step-by-step guidance, use these commands:
|
||||
|
||||
| Task | Command |
|
||||
|-----------------------------|----------------------|
|
||||
| Create issue with guidance | `/gh-create-issue` |
|
||||
| Close issue properly | `/gh-close-issue` |
|
||||
| Triage open issues | `/gh-triage` |
|
||||
| Generate status report | `/gh-status-report` |
|
||||
|
||||
---
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Check Status Before Work
|
||||
|
||||
```bash
|
||||
# See what needs attention
|
||||
gh issue list --label P1 --state open
|
||||
|
||||
# Check your assignments
|
||||
gh issue list --assignee @me --state open
|
||||
```
|
||||
|
||||
### After Fixing a Bug
|
||||
|
||||
```bash
|
||||
# Close with summary
|
||||
gh issue close 42 --comment "Fixed in PR #43
|
||||
|
||||
Changes: {summary}
|
||||
Testing: {what was tested}
|
||||
|
||||
-cc"
|
||||
```
|
||||
|
||||
### Weekly Review
|
||||
|
||||
```bash
|
||||
# Generate status report
|
||||
/gh-status-report
|
||||
|
||||
# Or manually:
|
||||
gh issue list --label P1 --state open
|
||||
gh issue list --label P2 --state open
|
||||
gh issue list --state closed --limit 10
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Filters
|
||||
|
||||
```bash
|
||||
# Critical issues
|
||||
gh issue list --label P1 --state open
|
||||
|
||||
# Unassigned issues
|
||||
gh issue list --state open --json number,title,assignees | jq '.[] | select(.assignees == [])'
|
||||
|
||||
# Stale issues (older than 30 days)
|
||||
gh issue list --state open --json number,title,createdAt
|
||||
|
||||
# My issues
|
||||
gh issue list --assignee @me --state open
|
||||
|
||||
# Recent activity
|
||||
gh issue list --state closed --limit 20
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integration with Workflow
|
||||
|
||||
### After Code Changes
|
||||
|
||||
1. Search for related issues: `gh issue list --search "keyword"`
|
||||
2. Add update comments with `-cc` signature
|
||||
3. Close issues when resolved
|
||||
4. Create follow-up issues if needed
|
||||
|
||||
### During Planning
|
||||
|
||||
1. Review open issues: `/gh-status-report`
|
||||
2. Triage new issues: `/gh-triage`
|
||||
3. Assign priorities and team members
|
||||
4. Break down large issues into smaller tasks
|
||||
|
||||
### In Standups/Reviews
|
||||
|
||||
1. Filter by assignee to see progress
|
||||
2. Check P1 issues for blockers
|
||||
3. Review recently closed issues
|
||||
4. Update priorities based on new information
|
||||
|
||||
---
|
||||
|
||||
## Golden Rules
|
||||
|
||||
1. **Always assign priority** (P1/P2/P3) when creating or triaging issues
|
||||
2. **Always use `-cc` signature** in comments
|
||||
3. **Be descriptive** in titles and descriptions
|
||||
4. **Link related items** (PRs, commits, other issues)
|
||||
5. **Document resolutions** when closing issues
|
||||
6. **Use guided commands** for complex workflows
|
||||
|
||||
---
|
||||
|
||||
## Full Documentation
|
||||
|
||||
For complete documentation and advanced features:
|
||||
- Use `/gh-create-issue` for guided issue creation
|
||||
- Use `/gh-close-issue` for guided issue closure
|
||||
- Use `/gh-triage` for priority management
|
||||
- Use `/gh-status-report` for comprehensive reporting
|
||||
578
skills/issue-templates/SKILL.md
Normal file
578
skills/issue-templates/SKILL.md
Normal file
@@ -0,0 +1,578 @@
|
||||
---
|
||||
description: Templates for creating well-structured GitHub issues for bugs, features, and tasks
|
||||
disable-model-invocation: false
|
||||
---
|
||||
|
||||
# GitHub Issue Templates
|
||||
|
||||
Comprehensive templates for creating different types of GitHub issues. Use these templates to ensure consistency and completeness when creating issues.
|
||||
|
||||
---
|
||||
|
||||
## Bug Report Template
|
||||
|
||||
Use this template when reporting bugs, errors, or unexpected behavior.
|
||||
|
||||
```markdown
|
||||
## Description
|
||||
|
||||
Brief, clear description of the bug in 1-2 sentences.
|
||||
|
||||
## Steps to Reproduce
|
||||
|
||||
1. Go to [specific page or action]
|
||||
2. Click on [button/link]
|
||||
3. Enter [specific data]
|
||||
4. Observe the error
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
What should happen when following the steps above.
|
||||
|
||||
## Actual Behavior
|
||||
|
||||
What actually happens. Include error messages, stack traces, or screenshots.
|
||||
|
||||
## Environment
|
||||
|
||||
- **Browser/OS**: Chrome 120 / macOS 14.2
|
||||
- **Version/Branch**: v2.1.0 / main
|
||||
- **Environment**: Production / Staging / Local
|
||||
|
||||
## Reproduction Rate
|
||||
|
||||
- [ ] Always (100%)
|
||||
- [ ] Frequently (>50%)
|
||||
- [ ] Sometimes (<50%)
|
||||
- [ ] Rare (<10%)
|
||||
|
||||
## Screenshots/Logs
|
||||
|
||||
[Attach screenshots, error logs, or console output if applicable]
|
||||
|
||||
## Additional Context
|
||||
|
||||
- When did this start happening?
|
||||
- Does it affect all users or specific users?
|
||||
- Any recent changes that might be related?
|
||||
- Workarounds discovered?
|
||||
|
||||
## Impact Assessment
|
||||
|
||||
- **Users Affected**: All / Subset / Single user
|
||||
- **Severity**: Critical / High / Medium / Low
|
||||
- **Business Impact**: [Describe impact on business operations]
|
||||
|
||||
## Suggested Priority
|
||||
|
||||
- [ ] P1 - Critical (blocks core functionality, affects all users)
|
||||
- [ ] P2 - High (significant impact but has workaround)
|
||||
- [ ] P3 - Normal (minor impact, can be scheduled)
|
||||
```
|
||||
|
||||
### Example Bug Report
|
||||
|
||||
```markdown
|
||||
## Description
|
||||
|
||||
Users cannot log in with SSO authentication, receiving "Invalid OAuth state" error.
|
||||
|
||||
## Steps to Reproduce
|
||||
|
||||
1. Navigate to https://app.example.com/login
|
||||
2. Click "Login with SSO"
|
||||
3. Enter corporate email
|
||||
4. Redirected to error page with "Invalid OAuth state"
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
User should be authenticated and redirected to dashboard.
|
||||
|
||||
## Actual Behavior
|
||||
|
||||
Error page displays "Invalid OAuth state parameter" and user cannot proceed.
|
||||
|
||||
## Environment
|
||||
|
||||
- **Browser/OS**: All browsers / All OS
|
||||
- **Version/Branch**: v2.3.1 / production
|
||||
- **Environment**: Production
|
||||
|
||||
## Reproduction Rate
|
||||
|
||||
- [x] Always (100%)
|
||||
|
||||
## Screenshots/Logs
|
||||
|
||||
```
|
||||
Error: OAuth state mismatch
|
||||
at validateState (auth.js:45)
|
||||
at processCallback (oauth.js:123)
|
||||
```
|
||||
|
||||
## Additional Context
|
||||
|
||||
- Started after deployment at 2:00 PM UTC today
|
||||
- Affects ALL users attempting SSO login
|
||||
- Username/password login still works
|
||||
- Related to PR #123 which updated OAuth library
|
||||
|
||||
## Impact Assessment
|
||||
|
||||
- **Users Affected**: All SSO users (~80% of user base)
|
||||
- **Severity**: Critical
|
||||
- **Business Impact**: Users cannot access application, blocking all work
|
||||
|
||||
## Suggested Priority
|
||||
|
||||
- [x] P1 - Critical (blocks core functionality, affects all users)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Feature Request Template
|
||||
|
||||
Use this template when proposing new features or enhancements.
|
||||
|
||||
```markdown
|
||||
## Feature Description
|
||||
|
||||
Clear, concise description of the proposed feature in 1-2 sentences.
|
||||
|
||||
## Problem Statement
|
||||
|
||||
What problem does this feature solve? Who experiences this problem?
|
||||
|
||||
## Proposed Solution
|
||||
|
||||
Detailed description of how the feature should work:
|
||||
|
||||
- User interaction flow
|
||||
- UI/UX considerations
|
||||
- Technical approach (high-level)
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] User can [specific action]
|
||||
- [ ] System responds with [expected behavior]
|
||||
- [ ] Edge case [X] is handled properly
|
||||
- [ ] Feature works on [platforms/browsers]
|
||||
|
||||
## User Stories
|
||||
|
||||
**As a** [type of user]
|
||||
**I want** [goal/desire]
|
||||
**So that** [benefit/value]
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
What other approaches were considered and why were they rejected?
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Requires [feature/component]
|
||||
- Blocks [other feature]
|
||||
- Depends on [external service/library]
|
||||
|
||||
## Success Metrics
|
||||
|
||||
How will we measure if this feature is successful?
|
||||
|
||||
- [ ] [Metric 1]
|
||||
- [ ] [Metric 2]
|
||||
|
||||
## Priority Suggestion
|
||||
|
||||
- [ ] P1 - Critical (essential for launch/key business need)
|
||||
- [ ] P2 - High (important enhancement with clear value)
|
||||
- [ ] P3 - Normal (nice-to-have improvement)
|
||||
|
||||
## Additional Context
|
||||
|
||||
- Mockups or wireframes
|
||||
- User research or feedback
|
||||
- Competitive analysis
|
||||
- Technical considerations
|
||||
```
|
||||
|
||||
### Example Feature Request
|
||||
|
||||
```markdown
|
||||
## Feature Description
|
||||
|
||||
Add dark mode theme option to the application dashboard and user interface.
|
||||
|
||||
## Problem Statement
|
||||
|
||||
Users working in low-light environments or during evening hours find the bright interface uncomfortable and experience eye strain. Multiple users have requested a dark mode option in feedback surveys.
|
||||
|
||||
## Proposed Solution
|
||||
|
||||
Implement a theme toggle in user settings:
|
||||
|
||||
1. Add theme selector in user preferences (Settings > Appearance)
|
||||
2. Offer "Light", "Dark", and "Auto (system)" options
|
||||
3. Persist user preference to database
|
||||
4. Apply theme across all dashboard components
|
||||
5. Use CSS variables for easy theme switching
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] User can toggle between light and dark mode in settings
|
||||
- [ ] User can select "Auto" to follow system theme
|
||||
- [ ] Theme preference is saved per user account
|
||||
- [ ] Theme persists across sessions and devices
|
||||
- [ ] All dashboard components support both themes
|
||||
- [ ] Text remains readable in both themes (WCAG AA contrast)
|
||||
- [ ] Theme applies immediately without page refresh
|
||||
|
||||
## User Stories
|
||||
|
||||
**As a** dashboard user
|
||||
**I want** to switch to dark mode
|
||||
**So that** I can work comfortably in low-light environments without eye strain
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
1. **Single dark mode only**: Rejected - some users prefer light mode
|
||||
2. **Browser extension**: Rejected - requires external dependency
|
||||
3. **Time-based auto-switch**: Rejected - too complex for MVP
|
||||
|
||||
## Dependencies
|
||||
|
||||
- CSS variable system (already implemented)
|
||||
- User preferences API (needs enhancement)
|
||||
- Component library updates (all components must support theming)
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- [ ] 30%+ of users enable dark mode within first month
|
||||
- [ ] Reduced complaints about interface brightness
|
||||
- [ ] Positive feedback in user surveys
|
||||
|
||||
## Priority Suggestion
|
||||
|
||||
- [ ] P1 - Critical
|
||||
- [x] P2 - High (frequently requested feature with clear user value)
|
||||
- [ ] P3 - Normal
|
||||
|
||||
## Additional Context
|
||||
|
||||
- Figma mockups: [link]
|
||||
- User survey results: 67% requested dark mode
|
||||
- Similar feature in competitor products
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task Template
|
||||
|
||||
Use this template for development tasks, technical work, or non-user-facing improvements.
|
||||
|
||||
```markdown
|
||||
## Objective
|
||||
|
||||
What needs to be accomplished? Be specific and actionable.
|
||||
|
||||
## Context
|
||||
|
||||
Why is this task needed? What's the background or motivation?
|
||||
|
||||
## Requirements
|
||||
|
||||
Detailed list of what must be completed:
|
||||
|
||||
- [ ] Requirement 1
|
||||
- [ ] Requirement 2
|
||||
- [ ] Requirement 3
|
||||
|
||||
## Technical Approach
|
||||
|
||||
High-level technical plan or considerations:
|
||||
|
||||
1. [Step or component 1]
|
||||
2. [Step or component 2]
|
||||
3. [Step or component 3]
|
||||
|
||||
## Files/Components Affected
|
||||
|
||||
- `path/to/file1.js`
|
||||
- `path/to/file2.py`
|
||||
- `component/Module`
|
||||
|
||||
## Testing Requirements
|
||||
|
||||
- [ ] Unit tests for [component]
|
||||
- [ ] Integration tests for [workflow]
|
||||
- [ ] Manual testing of [scenario]
|
||||
- [ ] Performance testing if applicable
|
||||
|
||||
## Documentation Requirements
|
||||
|
||||
- [ ] Update README
|
||||
- [ ] Update API docs
|
||||
- [ ] Add inline code comments
|
||||
- [ ] Update changelog
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Requires completion of #[issue-number]
|
||||
- Blocked by [external factor]
|
||||
- Depends on [library/service]
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] Implementation complete and tested
|
||||
- [ ] Code reviewed and approved
|
||||
- [ ] Tests added and passing
|
||||
- [ ] Documentation updated
|
||||
- [ ] No regressions introduced
|
||||
- [ ] Deployed to staging/production
|
||||
|
||||
## Priority
|
||||
|
||||
- [ ] P1 - Critical (blocking other work)
|
||||
- [ ] P2 - High (important technical improvement)
|
||||
- [ ] P3 - Normal (standard development work)
|
||||
|
||||
## Estimated Effort
|
||||
|
||||
[Small / Medium / Large] or [hours/days estimate]
|
||||
```
|
||||
|
||||
### Example Task
|
||||
|
||||
```markdown
|
||||
## Objective
|
||||
|
||||
Refactor authentication middleware to support multiple OAuth providers (GitHub, Google, Microsoft).
|
||||
|
||||
## Context
|
||||
|
||||
Currently auth middleware only supports GitHub OAuth. New enterprise customers require Google and Microsoft SSO support. The existing implementation is tightly coupled to GitHub, making it difficult to extend.
|
||||
|
||||
## Requirements
|
||||
|
||||
- [ ] Abstract OAuth provider interface
|
||||
- [ ] Implement provider-specific adapters for GitHub, Google, Microsoft
|
||||
- [ ] Update configuration to support multiple providers
|
||||
- [ ] Maintain backward compatibility with existing GitHub auth
|
||||
- [ ] Add provider selection to login UI
|
||||
|
||||
## Technical Approach
|
||||
|
||||
1. Create `OAuthProvider` interface with standard methods
|
||||
2. Extract GitHub-specific code into `GitHubProvider` adapter
|
||||
3. Implement `GoogleProvider` and `MicrosoftProvider` adapters
|
||||
4. Update middleware to route to appropriate provider based on config
|
||||
5. Add provider selection dropdown to login page
|
||||
6. Update user model to store provider type
|
||||
|
||||
## Files/Components Affected
|
||||
|
||||
- `src/middleware/auth.js` - Main refactoring
|
||||
- `src/providers/github.js` - New file
|
||||
- `src/providers/google.js` - New file
|
||||
- `src/providers/microsoft.js` - New file
|
||||
- `src/config/oauth.js` - Configuration updates
|
||||
- `src/components/LoginForm.jsx` - UI updates
|
||||
- `src/models/User.js` - Schema updates
|
||||
|
||||
## Testing Requirements
|
||||
|
||||
- [ ] Unit tests for each provider adapter
|
||||
- [ ] Integration tests for full auth flow with each provider
|
||||
- [ ] Test backward compatibility with existing GitHub users
|
||||
- [ ] Test provider switching for users
|
||||
- [ ] Manual testing of UI provider selection
|
||||
|
||||
## Documentation Requirements
|
||||
|
||||
- [ ] Update README with OAuth configuration examples
|
||||
- [ ] Document provider interface in code
|
||||
- [ ] Add setup guide for each OAuth provider
|
||||
- [ ] Update environment variable documentation
|
||||
|
||||
## Dependencies
|
||||
|
||||
- OAuth credentials for Google and Microsoft (in progress)
|
||||
- No blocking dependencies
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] All three providers implemented and tested
|
||||
- [ ] Existing GitHub auth continues to work
|
||||
- [ ] Tests added for all providers (100% coverage)
|
||||
- [ ] Code reviewed and approved
|
||||
- [ ] Documentation complete
|
||||
- [ ] Deployed to staging for QA testing
|
||||
- [ ] No performance regressions
|
||||
|
||||
## Priority
|
||||
|
||||
- [ ] P1 - Critical
|
||||
- [x] P2 - High (important for enterprise customer contracts)
|
||||
- [ ] P3 - Normal
|
||||
|
||||
## Estimated Effort
|
||||
|
||||
Large (3-5 days)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Documentation Update Template
|
||||
|
||||
Use this template for documentation improvements or additions.
|
||||
|
||||
```markdown
|
||||
## Documentation Need
|
||||
|
||||
What documentation is missing or needs improvement?
|
||||
|
||||
## Target Audience
|
||||
|
||||
Who will use this documentation?
|
||||
- [ ] End users
|
||||
- [ ] Developers
|
||||
- [ ] DevOps/Operations
|
||||
- [ ] Contributors
|
||||
|
||||
## Scope
|
||||
|
||||
What should be documented:
|
||||
|
||||
- [ ] Topic 1
|
||||
- [ ] Topic 2
|
||||
- [ ] Topic 3
|
||||
|
||||
## Existing Documentation
|
||||
|
||||
What documentation already exists that relates to this?
|
||||
|
||||
## Proposed Changes
|
||||
|
||||
What should be added, updated, or removed:
|
||||
|
||||
1. [Change 1]
|
||||
2. [Change 2]
|
||||
3. [Change 3]
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Documentation is clear and accurate
|
||||
- [ ] Examples are provided
|
||||
- [ ] Common issues are addressed
|
||||
- [ ] Links are functional
|
||||
|
||||
## Priority
|
||||
|
||||
- [ ] P1 - Critical (blocking users/developers)
|
||||
- [ ] P2 - High (frequently needed info)
|
||||
- [ ] P3 - Normal (nice-to-have)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Command to Create Issue
|
||||
|
||||
Use these commands with the templates above:
|
||||
|
||||
```bash
|
||||
# Interactive issue creation (will prompt for all fields)
|
||||
gh issue create
|
||||
|
||||
# Create from template (save template to file first)
|
||||
gh issue create --body-file bug-report.md --title "Issue title" --label "P1,bug"
|
||||
|
||||
# Quick bug report
|
||||
gh issue create \
|
||||
--title "Brief bug description" \
|
||||
--body "$(cat <<'EOF'
|
||||
## Description
|
||||
[Bug description]
|
||||
|
||||
## Steps to Reproduce
|
||||
1. Step 1
|
||||
2. Step 2
|
||||
|
||||
## Expected vs Actual
|
||||
Expected: [...]
|
||||
Actual: [...]
|
||||
EOF
|
||||
)" \
|
||||
--label "P1,bug"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template Selection Guide
|
||||
|
||||
| Issue Type | Template to Use | Labels to Add |
|
||||
|--------------------------|--------------------------|----------------------|
|
||||
| Bug or error | Bug Report | `bug`, `P1/P2/P3` |
|
||||
| New feature | Feature Request | `enhancement`, `P2/P3` |
|
||||
| Technical work | Task | `task`, `P2/P3` |
|
||||
| Performance issue | Bug Report | `bug`, `performance` |
|
||||
| Security vulnerability | Bug Report (urgent) | `security`, `P1` |
|
||||
| Documentation gap | Documentation Update | `documentation`, `P3` |
|
||||
| Refactoring | Task | `refactor`, `P3` |
|
||||
| Technical debt | Task | `tech-debt`, `P3` |
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### When Creating Issues
|
||||
|
||||
1. **Choose the right template** for the issue type
|
||||
2. **Fill in all sections** - don't leave blanks
|
||||
3. **Be specific and actionable** in descriptions
|
||||
4. **Assign priority** based on impact and urgency
|
||||
5. **Add relevant labels** beyond just priority
|
||||
6. **Link related issues** and PRs
|
||||
7. **Include reproduction steps** for bugs
|
||||
8. **Define acceptance criteria** for features
|
||||
|
||||
### Template Customization
|
||||
|
||||
These templates can be customized per repository:
|
||||
- Save templates to `.github/ISSUE_TEMPLATE/` directory
|
||||
- GitHub will show them in the issue creation UI
|
||||
- Customize sections based on team needs
|
||||
- Add repository-specific fields
|
||||
|
||||
---
|
||||
|
||||
## Using Templates with Guided Commands
|
||||
|
||||
The `/gh-create-issue` command will help you use these templates interactively:
|
||||
|
||||
```bash
|
||||
# Use guided workflow
|
||||
/gh-create-issue
|
||||
|
||||
# The command will:
|
||||
# 1. Ask for issue type (bug/feature/task)
|
||||
# 2. Load appropriate template
|
||||
# 3. Guide you through filling it out
|
||||
# 4. Create the issue with proper labels and priority
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Golden Rules
|
||||
|
||||
1. **Always use a template** - ensures completeness
|
||||
2. **Always assign priority** - P1/P2/P3
|
||||
3. **Be thorough** - complete all sections
|
||||
4. **Be specific** - actionable details
|
||||
5. **Think about the reader** - they may have no context
|
||||
|
||||
---
|
||||
|
||||
## Related Skills
|
||||
|
||||
- Use `github-issues-quick-reference` skill for gh CLI commands
|
||||
- Use `/gh-create-issue` for guided issue creation
|
||||
- Use `/gh-triage` for prioritizing existing issues
|
||||
Reference in New Issue
Block a user