ideogram-rate-limits
Implement Ideogram rate limiting, backoff, and request queuing patterns. Use when handling rate limit errors, implementing retry logic, or optimizing API request throughput for Ideogram. Trigger with phrases like "ideogram rate limit", "ideogram throttling", "ideogram 429", "ideogram retry", "ideogram backoff", "ideogram queue".
84
82%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%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 that clearly defines its scope (Ideogram rate limiting and request management), provides explicit 'Use when' guidance, and includes a comprehensive list of natural trigger terms. It uses proper third-person voice and is concise without being vague. It serves as a strong example of how to write a skill description for a narrowly-scoped, API-specific task.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: rate limiting, backoff, and request queuing patterns. Also mentions retry logic and optimizing API request throughput. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement rate limiting, backoff, and request queuing for Ideogram) and 'when' (explicit 'Use when' clause covering rate limit errors, retry logic, and throughput optimization, plus explicit trigger phrases). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms including 'ideogram rate limit', 'ideogram throttling', 'ideogram 429', 'ideogram retry', 'ideogram backoff', 'ideogram queue' — these are terms users would naturally use when encountering these issues. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — scoped specifically to Ideogram API rate limiting patterns. The combination of 'Ideogram' + rate limiting/backoff/queuing creates a very clear niche unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 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, actionable skill with executable TypeScript examples covering multiple rate-limiting patterns for Ideogram's API. Its main weaknesses are verbosity (four full implementations inline when some could be referenced) and missing validation checkpoints for what are inherently batch/destructive operations. The error handling table and rate limit model table are well-structured additions.
Suggestions
Add an explicit validation checkpoint before batch operations (e.g., 'Test with a single request first to verify API key and connectivity before running batch')
Consider moving the Token Bucket implementation (Step 3) to a separate referenced file since it's an alternative to the queue approach, not a required step in the workflow
Remove the 'Prerequisites' bullet about 'Understanding of async patterns' — Claude already knows this
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some unnecessary elements like the 'Prerequisites' section (Claude knows what async patterns are), the 'Output' section restating what was already shown, and the token bucket implementation which adds significant length for a pattern that overlaps with the queue approach. The rate limit table is useful and concise though. | 2 / 3 |
Actionability | All code examples are fully executable TypeScript with concrete API endpoints, headers, error handling, and real configuration values. The examples are copy-paste ready with specific Ideogram API details like the endpoint URL, header format, and request body structure. | 3 / 3 |
Workflow Clarity | Steps are clearly numbered and sequenced, and the error handling table provides good guidance. However, there are no explicit validation checkpoints — for batch operations that could generate many API calls and costs, there should be verification steps (e.g., validate API key first, test with single request before batch, verify results). The batch operation in Step 4 lacks a feedback loop for partial failure recovery. | 2 / 3 |
Progressive Disclosure | The content is structured with clear sections and a reference to external resources and a related skill. However, the four implementation patterns (backoff, queue, token bucket, batch) are all inline when the token bucket and batch processing could reasonably be split into separate referenced files, making the main skill leaner. | 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 | |
- Commit
c8a915c
- Reviewed
Table of Contents
Is this your skill?
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.