Automates the grouping of package reverse dependency errors into a structured issue file.
Install
mkdir -p .claude/skills/categorize-revdep-issues && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/6208" && unzip -o skill.zip -d .claude/skills/categorize-revdep-issues && rm skill.zipInstalls to .claude/skills/categorize-revdep-issues
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Write revdep/issue.md to group packages by common error categoriesKey capabilities
- →Parse revdep check results
- →Group packages by error category
- →Generate issue tracking documentation
- →Prioritize fixes based on error patterns
How it works
It analyzes failure logs to categorize packages by the root cause of their check failures, producing a structured issue tracking document.
Inputs & outputs
When to use categorize-revdep-issues
- →Triaging package check failures
- →Creating revdep issue summary
- →Analyzing breaking change impacts
About this skill
Categorize Reverse Dependency Issues
Write revdep/issue.md to group packages by common error categories based on the error output in revdep/problems.md and revdep/failures.md.
What This Skill Does
This skill analyzes reverse dependency check results and writes out an issue tracking file to group packages by their error types, making it easier to:
- Identify common problems across packages
- Understand which issues are dplyr-related vs external dependencies
- Prioritize fixes based on error patterns
- Provide clear guidance to package maintainers
Files Involved
Input files:
revdep/README.md- TheNew problemssection lists the packages to grouprevdep/problems.md- Detailed error output for packages with test/check issuesrevdep/failures.md- Installation failures and error messages
Output file:
revdep/issue.md- File to write packages grouped by error category to, may need to be created
Process
Step 1: Read All Input Files
Read all input files in parallel to understand the complete error landscape.
Step 2: Analyze and Categorize Errors
Group packages by their primary error cause. Common categories include:
Issues related to changes in our package:
- Missing exports
- Defunct functions
- Defunct function arguments
- Missing Rd cross-references to removed functions
Issues unrelated to changes we have made:
- Missing exports from other packages (e.g.,
purrr::at_depth) - Dependency issues
- Compilation failures (C++, Rust)
- Other packages that passed or have unclear status
Step 3: Create Category Structure
For each category:
- Create an H2 header with a descriptive category name
- Write a brief description explaining:
- What the issue is
- Why it's happening
- Suggested solution or migration path
- List all affected packages in checkbox format
Step 4: Write the New File
Format requirements:
## Category Name
Brief description of the issue and solution approach.
* [ ] [package1](url1)
* [ ] [package2](url2)
...
If you must include package specific comments, do so like:
## Category Name
Brief description of the issue and solution approach.
* [ ] [package1](url1)
* Comments about package1.
* [ ] [package2](url2)
...
Do not include package specific comments in the Brief description section.
Critical constraints:
- MUST preserve ALL packages from the
README.md'sNew problemssection - Each package appears in exactly ONE category
- Maintain checkbox format:
* [ ] [package](url) - Order categories by relevance (common issues first)
- Use "Other issues requiring investigation" for unclear cases
Quality Checks
After completing the rewrite, verify:
- Total package count in new file matches the
README.md'sNew problemssection - Each package from original appears exactly once in new file
- Each category has a clear H2 header and description
- Packages are in checkbox format with correct URLs
- Categories are logically ordered
- Common patterns are grouped together
Example Category
## Missing export: `dplyr::id`
Packages using `dplyr::id` which is not exported. These packages get "no visible binding for global variable 'id'" errors.
* [ ] [packageA](https://github.com/userA/packageA)
* [ ] [packageB](https://github.com/userB/packageB)
When not to use it
- →When revdep check results are missing
Prerequisites
Limitations
- →Requires all input files to be present for accurate categorization
How it compares
It automates the triage of reverse dependency failures, allowing developers to group issues by category rather than manually reviewing individual package logs.
Compared to similar skills
categorize-revdep-issues side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| categorize-revdep-issues (this skill) | 1 | 7mo | No flags | Intermediate |
| code-review-checklist | 3 | 27d | No flags | Beginner |
| openspec-verify-change | 3 | 6mo | Review | Advanced |
| superpowers-finish | 1 | 6mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by r-lib
View all by r-lib →You might also like
code-review-checklist
vudovn
Code review guidelines covering code quality, security, and best practices.
openspec-verify-change
studyzy
验证实现是否与变更产出物匹配。当用户想要在归档前验证实现是否完整、正确且一致时使用。
superpowers-finish
anthonylee991
Finalizes work: runs verification, summarizes changes, notes follow-ups, and ensures repo hygiene. Use at the end of an implementation or debugging session.
positron-qa-verify
posit-dev
Generates clear, actionable verification guides for QA testing of Positron bug fixes and features
pr-review
microsoft
Multi-dimensional review of a PR or feature branch in the microsoft/winappcli repo. Activate when a contributor asks to "review my PR", "review my changes", "vet my branch before pushing", "do a full review", "PR review", "review this feature", or similar. Fans out parallel sub-agents covering secur
atdd
kevinMgreer
Spec-Driven ATDD workflow skill. Use for running the full ATDD cycle, writing Gherkin feature files, creating technical specs, generating acceptance tests, or reviewing spec compliance. Trigger phrases: ATDD, BDD, Gherkin, spec-first, acceptance test, feature file, Given When Then, red-green-refacto