agentleFS
Sign inStart free
SentryKnown publishergetsentry/junior/.agents/skills/vercel-queues/SKILL.md

vercel-queues

Skill394 starsChanged 7 months agoApache-2.0View on GitHub

Build and operate Vercel Queues with @vercel/queue across push and poll consumers. Use when users ask about "vercel queues", "@vercel/queue", "queue/v2beta", "handleCallback", "PollingQueueClient", "receive", queue retries, visibility timeouts, idempotency keys, or queue region routing.

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 4 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the task spans multiple categories, read only the relevant files above.

    line 21
  2. Very specific:

    Use bounded retry strategy for poison messages (acknowledge: true after threshold).

    line 28
  3. Very specific:

    Keep topic and consumer names within ^[A-Za-z0-9_-]+$.

    line 29
  4. Very specific:

    Prefer top-level send and handleCallback for standard Vercel push mode.

    line 33
  5. Very specific:

    Use QueueClient only when you need custom options (transport, token, headers, deploymentId).

    line 34
  6. Very specific:

    Use PollingQueueClient for poll mode (receive) and handle { ok: false, reason: "empty" } explicitly.

    line 35
  7. Very specific:

    Keep vercel.json trigger mapping explicit and scoped to the consumer route.

    line 36
  8. Very specific:

    Verify producer returns messageId and treat nullable messageId as acceptable deferred acceptance.

    line 40
  9. Distinctive:

    Verify consumer behavior across success, retry, and poison-message paths.

    line 41
  10. Distinctive:

    Verify visibility timeout assumptions match workload duration.

    line 42
  11. Distinctive:

    Verify region assumptions in poll mode.

    line 43

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Implement queue producers and consumers using Vercel Queues docs and SDK contracts.

Step 1: Classify the request

Choose one path before writing code:

Request typePrimary reference
First-time setup, minimal producer + consumerreferences/quickstart.md
SDK usage, options, retries, transport behaviorreferences/sdk.md
API-level integration (custom clients, non-SDK consumers)references/api.md
Delivery semantics and architecture decisionsreferences/concepts.md
Polling workers and mixed push/poll designreferences/poll-mode.md
Local setup and debuggingreferences/local-dev.md

If the task spans multiple categories, read only the relevant files above.

Step 2: Apply core guardrails

  1. Design consumers as idempotent because delivery is at-least-once.
  2. Pick push mode by default on Vercel unless the task explicitly needs scheduled/batched/client-driven polling.
  3. For poll mode, pin an explicit region and use the same region for send and receive.
  4. Use bounded retry strategy for poison messages (acknowledge: true after threshold).
  5. Keep topic and consumer names within ^[A-Za-z0-9_-]+$.

Step 3: Implement with minimal surface

  1. Prefer top-level send and handleCallback for standard Vercel push mode.
  2. Use QueueClient only when you need custom options (transport, token, headers, deploymentId).
  3. Use PollingQueueClient for poll mode (receive) and handle { ok: false, reason: "empty" } explicitly.
  4. Keep vercel.json trigger mapping explicit and scoped to the consumer route.

Step 4: Validate behavior

  1. Verify producer returns messageId and treat nullable messageId as acceptable deferred acceptance.
  2. Verify consumer behavior across success, retry, and poison-message paths.
  3. Verify visibility timeout assumptions match workload duration.
  4. Verify region assumptions in poll mode.

Step 5: Troubleshoot from first principles

  1. Authentication issues: check OIDC/token source and env loading.
  2. Missing deliveries: verify topic name, trigger registration, and region alignment.
  3. Duplicate processing: verify idempotency key strategy and consumer idempotency.
  4. Backlog growth: inspect consumer throughput, retry policy, and visibility timeout.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free