address-issues
Skill0 starsChanged 8 months agoMITView on GitHub
Iterate all open GitHub issues: triage, reproduce, fix with tests, create PR, review. Fully automated issue resolution.
- Commits and pushes
1 other project uses a version of this.
Adopted by
Most recently taken up by
- EdoMon93/claude-skillstheir own version, first seen Oct 17, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- EdoMon93/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository4 other files it gives its agents.
- create-prSkill
- release-versionSkill
- release-workflowSkill
- review-prSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. About 0 are common, 20 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈20
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Read the issue title, body, and labels.
- Distinctive: line 45
Read the issue thoroughly.
- Distinctive: line 49
Related code: read the relevant source files to understand current behavior
- Distinctive: line 50
Linked issues/PRs: check for related context
- Distinctive: line 56
Read all affected source files to understand the code before making changes.
- Distinctive: line 60
Verify the issue is real before attempting a fix.
- Distinctive: line 63
Follow the repro steps from the issue
- Distinctive: line 64
Run existing tests that cover the affected code
- Distinctive: line 65
Write a minimal failing test if no repro steps are provided
- Distinctive: line 73
Verify the current state (missing feature, outdated docs, etc.)
- Distinctive: line 91
Create a branch based on the triage category:
- Distinctive: line 102
Docs: update the relevant documentation files
- Distinctive: line 107
Every fix MUST include tests:
- Distinctive: line 109
Bug fix: add a test that fails without the fix and passes with it
- Distinctive: line 110
Feature: add tests covering the new functionality and edge cases
- Distinctive: line 111
Docs: verify any code examples in docs are accurate
- Distinctive: line 112
Chore: update existing tests if behavior changed
- Distinctive: line 114
Verify all tests pass:
- Distinctive: line 166
After processing all issues, output a summary table:
- Distinctive: line 181
Always return to main between issues to avoid cross-contamination
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Address Issues
Iterate all open GitHub issues on the current repo. For each issue: triage, gather context, reproduce, implement a fix with tests, create a PR via /create-pr, and review via /review-pr.
Step 0: Fetch All Open Issues
gh issue list --state open --json number,title,body,labels --limit 100Process each issue sequentially through Steps 1–7. Return to main branch before starting each issue.
git checkout main && git pullStep 1: Triage
Read the issue title, body, and labels. Classify into one of:
| Category | Description | Branch prefix |
| bug | Something is broken or behaving incorrectly | fix/ |
| feature | New functionality or enhancement | feat/ |
| docs | Documentation improvement or correction | docs/ |
| chore | Maintenance, deps, config, refactoring | chore/ |
| skip | Too large, ambiguous, needs human decision, or requires external access | — |
If skip:
Post a comment explaining why, then move to the next issue:
gh issue comment <NUMBER> --body "This issue requires human attention — <reason>. Skipping automated resolution."Step 2: Gather Context
Read the issue thoroughly. Identify:
- Affected files: which source files, tests, or docs are relevant
- Repro steps: how to trigger the issue (from the issue body or inferred)
- Related code: read the relevant source files to understand current behavior
- Linked issues/PRs: check for related context
gh issue view <NUMBER> --json title,body,labels,commentsRead all affected source files to understand the code before making changes.
Step 3: Reproduce
Verify the issue is real before attempting a fix.
For bugs:
- Follow the repro steps from the issue
- Run existing tests that cover the affected code
- Write a minimal failing test if no repro steps are provided
# Run relevant tests
uv run pytest tests/ -k "<relevant_test_pattern>" -vFor features/docs/chore:
- Verify the current state (missing feature, outdated docs, etc.)
- Establish a baseline of current behavior
If reproduction fails:
Post a comment and move to the next issue:
gh issue comment <NUMBER> --body "Attempted to reproduce this issue but was unable to.
**What was tried:**
- <list steps attempted>
Please provide additional reproduction steps if possible."Step 4: Create Branch and Implement Fix
Create a branch based on the triage category:
git checkout -b <prefix>/issue-<NUMBER>
# Examples: fix/issue-42, feat/issue-15, docs/issue-7Implementation guidelines:
- Bug fixes: fix the root cause, not just the symptom
- Features: implement the minimum viable version described in the issue
- Docs: update the relevant documentation files
- Chore: make the maintenance change described
Tests:
Every fix MUST include tests:
- Bug fix: add a test that fails without the fix and passes with it
- Feature: add tests covering the new functionality and edge cases
- Docs: verify any code examples in docs are accurate
- Chore: update existing tests if behavior changed
Verify all tests pass:
uv run pytest tests/ -v
uv run ruff check src/ tests/Step 5: Commit and Push
git add <changed-files>
git commit -m "<prefix>: <concise description> (closes #<NUMBER>)"
git push -u origin HEADThe commit message prefix should match the branch prefix (fix:, feat:, docs:, chore:).
Step 6: Create PR
Invoke the /create-pr skill. Ensure the PR body includes Closes #<NUMBER> to auto-close the issue on merge.
Step 7: Review PR
Invoke the /review-pr skill on the newly created PR.
Review retry loop:
- Approved or warnings-only → done. Move to the next issue.
- Critical findings → read the review comments, fix the issues on the same branch:
# Fix the issues identified in review
# ... make changes ...
git add <files>
git commit -m "fix: address review feedback for #<NUMBER>"
git pushThen re-invoke /review-pr. Maximum 2 retry attempts. After that, leave the PR as-is for human review.
Step 8: Next Issue
Return to main and proceed to the next issue:
git checkout main && git pullRepeat from Step 1 for the next issue.
Summary Output
After processing all issues, output a summary table:
| Issue | Title | Action | Result |
|-------|-------|--------|--------|
| #42 | Broken sync | fix | PR #51 created, approved |
| #15 | Add search | skip | Too large for automated fix |
| #7 | Typo in docs | docs | PR #52 created, approved |
| #3 | Crash on empty | fix | PR #53 created, review pending |Notes
- This skill requires
ghCLI authenticated with repo access - Each issue gets its own branch and PR — no combining issues
- Always return to main between issues to avoid cross-contamination
- The skill invokes
/create-prand/review-pr— those skills handle the details of PR formatting and review process
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

