agentleFS
crux-clicrux-cli/crux/.claude/skills/address-issues/SKILL.md

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

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    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.

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
  1. Distinctive:

    Read the issue title, body, and labels.

    line 25
  2. Distinctive:

    Read the issue thoroughly.

    line 45
  3. Distinctive:

    Related code: read the relevant source files to understand current behavior

    line 49
  4. Distinctive:

    Linked issues/PRs: check for related context

    line 50
  5. Distinctive:

    Read all affected source files to understand the code before making changes.

    line 56
  6. Distinctive:

    Verify the issue is real before attempting a fix.

    line 60
  7. Distinctive:

    Follow the repro steps from the issue

    line 63
  8. Distinctive:

    Run existing tests that cover the affected code

    line 64
  9. Distinctive:

    Write a minimal failing test if no repro steps are provided

    line 65
  10. Distinctive:

    Verify the current state (missing feature, outdated docs, etc.)

    line 73
  11. Distinctive:

    Create a branch based on the triage category:

    line 91
  12. Distinctive:

    Docs: update the relevant documentation files

    line 102
  13. Distinctive:

    Every fix MUST include tests:

    line 107
  14. Distinctive:

    Bug fix: add a test that fails without the fix and passes with it

    line 109
  15. Distinctive:

    Feature: add tests covering the new functionality and edge cases

    line 110
  16. Distinctive:

    Docs: verify any code examples in docs are accurate

    line 111
  17. Distinctive:

    Chore: update existing tests if behavior changed

    line 112
  18. Distinctive:

    Verify all tests pass:

    line 114
  19. Distinctive:

    After processing all issues, output a summary table:

    line 166
  20. Distinctive:

    Always return to main between issues to avoid cross-contamination

    line 181

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 100

Process each issue sequentially through Steps 1–7. Return to main branch before starting each issue.

git checkout main && git pull

Step 1: Triage

Read the issue title, body, and labels. Classify into one of:

CategoryDescriptionBranch prefix
bugSomething is broken or behaving incorrectlyfix/
featureNew functionality or enhancementfeat/
docsDocumentation improvement or correctiondocs/
choreMaintenance, deps, config, refactoringchore/
skipToo 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,comments

Read 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>" -v

For 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-7

Implementation 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 HEAD

The 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:

  1. Approved or warnings-only → done. Move to the next issue.
  2. 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 push

Then 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 pull

Repeat 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 gh CLI 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-pr and /review-pr — those skills handle the details of PR formatting and review process

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.