feat(workflow): Add workflow plugin v1.0.0
Git workflow, code quality, context management and testing commands: - commit, push, pr, issue - git operations - simplify, refactor, verify, check - code quality - catchup, onboard, save, cleanup - context management - test, format, sync - development utilities Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
68
plugins/workflow/commands/issue.md
Normal file
68
plugins/workflow/commands/issue.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
description: Analyze and fix a GitHub issue automatically
|
||||
argument-hint: <issue-number> - Required issue number to fix
|
||||
---
|
||||
|
||||
# Fix GitHub Issue
|
||||
|
||||
## Pre-computed Context
|
||||
|
||||
**Issue Details:**
|
||||
!`gh issue view $ARGUMENTS --json number,title,body,labels,assignees 2>/dev/null || echo "Error: Could not fetch issue $ARGUMENTS. Make sure gh is authenticated and issue exists."`
|
||||
|
||||
**Repository Info:**
|
||||
!`gh repo view --json nameWithOwner,defaultBranchRef -q '"\(.nameWithOwner) (default: \(.defaultBranchRef.name))"' 2>/dev/null || echo "Not a GitHub repository"`
|
||||
|
||||
**Current Branch:**
|
||||
!`git branch --show-current`
|
||||
|
||||
**Working Tree Status:**
|
||||
!`git status --porcelain | head -5`
|
||||
|
||||
---
|
||||
|
||||
## Instructions
|
||||
|
||||
You are fixing GitHub issue #$ARGUMENTS. Follow this workflow:
|
||||
|
||||
### 1. Parse Issue
|
||||
- Extract the problem description from the issue body
|
||||
- Note any specific files, error messages, or reproduction steps mentioned
|
||||
- Check labels for context (bug, feature, enhancement, etc.)
|
||||
|
||||
### 2. Search Codebase
|
||||
- Use Grep/Glob to find relevant files mentioned in the issue
|
||||
- Look for error messages, function names, or keywords from the issue
|
||||
- Read the most relevant files to understand the context
|
||||
|
||||
### 3. Implement Fix
|
||||
- Make minimal, focused changes to fix the issue
|
||||
- Follow existing code patterns and style
|
||||
- Add comments only if the logic isn't self-evident
|
||||
|
||||
### 4. Verify
|
||||
- Run relevant tests if they exist
|
||||
- Check for type errors: `npx tsc --noEmit` or equivalent
|
||||
- Ensure the fix addresses all points in the issue
|
||||
|
||||
### 5. Create Commit
|
||||
Create a commit with a message that references the issue:
|
||||
|
||||
```
|
||||
<type>: <description> (closes #$ARGUMENTS)
|
||||
|
||||
<optional body explaining the fix>
|
||||
|
||||
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
Where `<type>` is one of: fix, feat, refactor, docs, test, chore
|
||||
|
||||
---
|
||||
|
||||
## Important Notes
|
||||
|
||||
- If the issue is unclear or needs more information, explain what's missing
|
||||
- If the issue requires changes outside your scope (infrastructure, external services), explain the limitation
|
||||
- Always verify your fix works before committing
|
||||
- Create a focused branch if working on main: `git checkout -b fix/issue-$ARGUMENTS`
|
||||
Reference in New Issue
Block a user