Understand and handle CodeRabbit and GitHub API rate limits for review automation. Use when hitting rate limits on @coderabbitai commands, automating review queries, or building scripts that interact with CodeRabbit via the GitHub API. Trigger with phrases like "coderabbit rate limit", "coderabbit throttling", "coderabbit too many requests", "github api rate limit coderabbit".
80
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/coderabbit-pack/skills/coderabbit-rate-limits/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-crafted skill description with strong trigger terms, explicit 'Use when' and 'Trigger with' clauses, and a clearly distinct niche. Its main weakness is that the capability description could be more specific about what concrete actions the skill teaches (e.g., retry strategies, quota checking, header parsing) rather than the somewhat vague 'understand and handle'.
Suggestions
Replace 'Understand and handle' with more specific concrete actions like 'Detect, diagnose, and work around CodeRabbit and GitHub API rate limits' or list specific techniques such as 'implement retry backoff, check rate limit headers, batch requests'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (CodeRabbit/GitHub API rate limits) and mentions some actions like 'handle rate limits', 'automating review queries', and 'building scripts', but doesn't list multiple concrete specific actions (e.g., it doesn't say 'retry with backoff', 'check remaining quota', 'parse rate limit headers'). | 2 / 3 |
Completeness | Clearly answers both 'what' (understand and handle CodeRabbit and GitHub API rate limits for review automation) and 'when' (explicit 'Use when' clause with specific scenarios plus a 'Trigger with phrases' section listing exact trigger terms). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms including 'coderabbit rate limit', 'coderabbit throttling', 'coderabbit too many requests', 'github api rate limit coderabbit', '@coderabbitai commands', and 'review automation'. These are terms users would naturally use when encountering this problem. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche combining CodeRabbit + rate limits + GitHub API. This is unlikely to conflict with general GitHub skills, general rate limiting skills, or general CodeRabbit usage skills due to the narrow intersection of these domains. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, highly actionable skill with real executable scripts and useful rate limit tables. Its main weaknesses are length (several complete scripts inline that could be offloaded to bundle files) and the lack of explicit validation checkpoints tying the steps together as a cohesive workflow. The content would benefit from being trimmed to essential patterns with detailed scripts moved to referenced files.
Suggestions
Move the longer scripts (rate-safe-query.sh, cache-coderabbit-metrics.sh) into bundle files and reference them from SKILL.md to improve progressive disclosure and conciseness.
Add explicit validation steps after running automation scripts (e.g., 'Verify output contains expected PR count' or 'Confirm cache file was written correctly') to strengthen workflow clarity.
Trim Step 3's markdown comment block into a concise bullet list—the symptoms and best practices can be stated more efficiently.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary framing (e.g., the Overview section explains what rate limits are at two levels, which Claude already understands). The tables and code are mostly efficient, but the markdown comment block in Step 3 is verbose and could be tightened. The caching script in Step 5 is useful but lengthy for what could be a shorter pattern. | 2 / 3 |
Actionability | All scripts are fully executable bash with proper error handling (set -euo pipefail), real gh CLI commands, and concrete GraphQL queries. The code is copy-paste ready with parameterized inputs and practical patterns like pagination, rate limit checking, and caching. | 3 / 3 |
Workflow Clarity | Steps are numbered and sequenced, but they read more like independent recipes than a cohesive workflow. The rate limit check in Step 2 has a good validation pattern (check remaining before proceeding), but there's no explicit validation checkpoint after running the bulk scripts or caching—e.g., no step to verify cached data integrity or confirm the automation completed successfully. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and tables, but it's quite long (~180 lines of substantive content) with no bundle files to offload detail. The full caching script and bulk query script could be separate referenced files, keeping SKILL.md as a concise overview. References to external docs and next steps are good but the inline content is heavy. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
3a2d27d
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.