CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/sqs-tests

Tests AWS SQS queue interactions - Standard (at-least-once delivery, near-unlimited throughput) vs FIFO (exactly-once processing, ordered) queue semantics; visibility-timeout interaction model; dead-letter queue (DLQ) for poison-message isolation; message retention period (default 4 days, configurable 60s - 1209600s); test patterns via LocalStack or `aws-sdk-client-mock` (TypeScript) / `moto` (Python). Use when the user works with AWS SQS producers/consumers and needs unit/integration tests for queue interactions.

76

Quality

95%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

87%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A lean, highly actionable skill body with executable code in both languages and well-structured progressive disclosure via a verified reference file; the only gap is the absence of explicit validation checkpoints/feedback loops in the workflow.

Suggestions

Add an explicit validation checkpoint after Step 4 (LocalStack setup), e.g. 'curl http://localhost:4566/_localstack/health' to confirm the emulator is ready before running tests.

Insert a fix-retry feedback loop around the visibility-timeout / DLQ recipes (e.g. 'if msg2 returns a message, the visibility window was not applied - recheck VisibilityTimeout and re-run').

Make Step 1's decision explicit as a checklist ('choose mock for pure logic, LocalStack for semantics, real SQS for smoke') so the parallel Steps 2-7 are clearly alternatives rather than an implied sequence.

DimensionReasoningScore

Conciseness

The body is lean - mostly tables, executable code, and terse step descriptions with no tutorial padding about what SQS is; the few concept restatements (visibility-timeout, retention) are single contextual sentences rather than verbose explanation, so it earns its tokens.

3 / 3

Actionability

Provides multiple complete, executable examples (TypeScript aws-sdk-client-mock, Python moto, LocalStack docker-compose, visibility-timeout test, CI yaml) plus real copy-paste-ready recipes in the referenced file, matching the 'fully executable' anchor.

3 / 3

Workflow Clarity

Steps 1-9 are numbered with a useful Step-1 decision framework, but there are no explicit validation checkpoints or fix-retry feedback loops, and Steps 2-7 read as parallel recipes rather than a strictly validated pipeline, matching the 'sequence present, checkpoints missing/implicit' anchor instead of the level-3 example with validate->fix->retry.

2 / 3

Progressive Disclosure

The main file keeps core recipes inline and offloads the longer DLQ and FIFO recipes to a real, clearly signaled, one-level-deep references/localstack-recipes.md (verified to exist and contain the recipes), matching the 'clear overview with well-signaled one-level-deep references' anchor.

3 / 3

Total

11

/

12

Passed

Description

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.

A strong, comprehensive description: it states concrete capabilities across SQS Standard/FIFO semantics, names specific testing tools, and provides an explicit third-person 'Use when' trigger, so it scores at the top of the scale on every dimension.

DimensionReasoningScore

Specificity

Lists multiple concrete actions - testing SQS queue interactions, visibility-timeout model, DLQ for poison-message isolation, message retention, and specific test tooling (LocalStack, aws-sdk-client-mock, moto) - matching the 'lists multiple specific concrete actions' anchor rather than the partial level 2.

3 / 3

Completeness

Clearly answers both what (tests SQS semantics, visibility-timeout, DLQ, retention via named tools) and when, with an explicit 'Use when the user works with AWS SQS producers/consumers and needs unit/integration tests' clause in third-person voice, so the level-2 cap for missing triggers does not apply.

3 / 3

Trigger Term Quality

Natural terms a user would say are well covered - 'AWS SQS', 'queue interactions', 'unit/integration tests', 'producers/consumers', plus tool names (LocalStack, moto, aws-sdk-client-mock) that practitioners actually mention, matching the good-coverage anchor.

3 / 3

Distinctiveness Conflict Risk

It occupies a clear AWS SQS-specific niche with distinct triggers (SQS queues, visibility-timeout, DLQ, LocalStack/moto) that make it unlikely to fire for unrelated skills.

3 / 3

Total

12

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents