iii-dead-letter-queues
Inspects and redrives jobs that exhausted all retries. Use when handling failed queue jobs, debugging processing errors, or implementing retry strategies.
60
70%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/iii-dead-letter-queues/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 solid description that clearly communicates both what the skill does and when to use it, with an explicit 'Use when' clause and good trigger terms. The main weakness is that the 'what' portion could be more specific by listing additional concrete actions beyond 'inspects and redrives'. Overall it performs well for skill selection purposes.
Suggestions
Expand the capability list with more concrete actions, e.g., 'Inspects failed job payloads, views error stack traces, redrives jobs that exhausted all retries, and configures retry policies.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (queue jobs) and some actions ('inspects and redrives jobs that exhausted all retries'), but doesn't list multiple concrete actions comprehensively—e.g., it could mention viewing error logs, filtering by error type, or configuring retry policies. | 2 / 3 |
Completeness | Clearly answers both 'what' (inspects and redrives jobs that exhausted all retries) and 'when' (Use when handling failed queue jobs, debugging processing errors, or implementing retry strategies) with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'failed queue jobs', 'retry', 'processing errors', 'redrive', 'debugging'. These cover common variations of how a user would describe this need. | 3 / 3 |
Distinctiveness Conflict Risk | The description targets a clear niche—failed queue jobs and retry/redrive logic—which is distinct and unlikely to conflict with other skills like general debugging or queue management. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides useful domain-specific knowledge about DLQ operations in the iii engine with concrete SDK/CLI commands and clear cross-references to related skills. However, it suffers from some redundancy between sections (primitives table vs common patterns), lacks an explicit step-by-step workflow with validation checkpoints for the inspect-fix-redrive cycle, and includes boilerplate meta-sections that consume tokens without adding value.
Suggestions
Replace the narrative Architecture section and scattered best-practice bullets with a single numbered workflow: 1. Check status → 2. Inspect failures → 3. Deploy fix → 4. Redrive → 5. Verify DLQ depth is zero, with explicit validation at steps 1 and 5.
Consolidate the 'iii Primitives Used' table and 'Common Patterns' section to eliminate redundancy — the same redrive commands appear in both.
Remove or merge the 'When to Use' and 'Boundaries' boilerplate sections, as these are meta-instructions that don't add actionable guidance for the task at hand.
Include at least one inline executable code snippet (e.g., a complete inspect-then-redrive flow) rather than deferring all working code to reference files.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some unnecessary sections like 'When to Use' and 'Boundaries' that are boilerplate/meta rather than instructive. The 'Architecture' section narrates what Claude already understands from the Key Concepts. Some redundancy between the primitives table and Common Patterns section. | 2 / 3 |
Actionability | Provides concrete SDK calls and CLI commands with specific examples (e.g., redrive payload, expected return shape), but lacks inline executable code blocks — the full working examples are deferred to reference files. The Common Patterns section gives copy-paste-ready snippets but they're presented as bullet points rather than structured executable examples with context. | 2 / 3 |
Workflow Clarity | The Architecture section describes the workflow narratively (fail → retry → DLQ → inspect → fix → redrive) and 'best practice: investigate failures, deploy fix, then redrive' is mentioned, but there's no explicit numbered sequence with validation checkpoints. Missing a clear step like 'check DLQ status before and after redrive to confirm all jobs were replayed' as an explicit validation gate. | 2 / 3 |
Progressive Disclosure | References to external files (JS, Python, Rust implementations, iii-config.yaml) are well-signaled and one level deep, which is good. However, no bundle files were provided to verify these references exist, and the Pattern Boundaries section effectively cross-references other skills. The inline content could be better organized — the primitives table, common patterns, and adapting sections have overlapping information that could be consolidated. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- iii-hq/iii
- Commit
a7ebbbb
- 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.