Expand toolkit to 135 agents, 120 plugins, 796 total files
- Add 60 new agents across all 10 categories (75 -> 135) - Add 95 new plugins with command files (25 -> 120) - Update all agents to use model: opus - Update README with complete plugin/agent tables - Update marketplace.json with all 120 plugins
This commit is contained in:
6
plugins/github-issue-manager/.claude-plugin/plugin.json
Normal file
6
plugins/github-issue-manager/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"name": "github-issue-manager",
|
||||
"version": "1.0.0",
|
||||
"description": "GitHub issue triage, creation, and management",
|
||||
"commands": ["commands/triage-issues.md", "commands/create-issue.md"]
|
||||
}
|
||||
28
plugins/github-issue-manager/commands/create-issue.md
Normal file
28
plugins/github-issue-manager/commands/create-issue.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# /create-issue - Create GitHub Issue
|
||||
|
||||
Create a well-structured GitHub issue with proper metadata.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Ask the user for the issue type: bug report, feature request, or task
|
||||
2. For bugs: gather steps to reproduce, expected vs actual behavior, environment details
|
||||
3. For features: gather the use case, proposed solution, and alternatives considered
|
||||
4. For tasks: gather the description, acceptance criteria, and dependencies
|
||||
5. Select the appropriate issue template if the repository has them configured
|
||||
6. Add relevant labels: bug/feature/task, priority, component area
|
||||
7. Set the milestone if applicable to the current release cycle
|
||||
8. Add the issue to a project board if one is configured
|
||||
9. Link related issues using GitHub keywords (relates to, depends on, blocks)
|
||||
10. Assign to the appropriate team member if known
|
||||
11. Create the issue using the GitHub API with all metadata
|
||||
12. Report: issue number, URL, labels, assignee, project board
|
||||
|
||||
## Rules
|
||||
|
||||
- Use the repository's issue template when available
|
||||
- Include reproducible steps for every bug report
|
||||
- Add code snippets or screenshots when they clarify the issue
|
||||
- Do not create duplicate issues; search existing issues first
|
||||
- Keep the title concise and descriptive (under 80 characters)
|
||||
- Use task lists (checkboxes) for issues with multiple deliverables
|
||||
- Include acceptance criteria for features and tasks
|
||||
28
plugins/github-issue-manager/commands/triage-issues.md
Normal file
28
plugins/github-issue-manager/commands/triage-issues.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# /triage-issues - Triage GitHub Issues
|
||||
|
||||
Analyze and triage open GitHub issues for prioritization.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Fetch all open issues from the repository using the GitHub API
|
||||
2. Filter issues by: unlabeled, unassigned, or stale (no activity in 30 days)
|
||||
3. Analyze each issue for: completeness, reproducibility, severity, and impact
|
||||
4. Suggest labels based on issue content: bug, feature, enhancement, documentation, question
|
||||
5. Assess priority based on: user impact, frequency of reports, component affected
|
||||
6. Identify duplicate issues by comparing titles and descriptions with existing issues
|
||||
7. Flag issues that need more information from the reporter
|
||||
8. Group related issues that could be addressed together
|
||||
9. Suggest assignees based on the component or area affected
|
||||
10. Create a triage summary: total open, by priority, by label, stale issues
|
||||
11. Recommend which issues to close (duplicates, won't fix, cannot reproduce)
|
||||
12. Generate a prioritized backlog view for the next sprint
|
||||
|
||||
## Rules
|
||||
|
||||
- Do not close issues without user confirmation
|
||||
- Respect existing labels and assignments; suggest changes, do not override
|
||||
- Mark issues as stale only if truly inactive (no comments, no linked PRs)
|
||||
- Prioritize bugs over features, security issues over all others
|
||||
- Consider the number of thumbs-up reactions as a popularity signal
|
||||
- Do not auto-assign issues; suggest assignees for human decision
|
||||
- Keep triage notes factual and neutral in tone
|
||||
Reference in New Issue
Block a user