From ops-suite
Move failed messages from dead letter queues back to their main queue for reprocessing. Creates a shovel or uses the Management API to move messages. Always recommends triaging first.
npx claudepluginhub weorbitant/workbench-dev --plugin ops-suiteThis skill is limited to using the following tools:
Check if `/tmp/ops-suite-session/config.json` exists:
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Check if /tmp/ops-suite-session/config.json exists:
config.yaml, parse it, and write to /tmp/ops-suite-session/config.json for other skills to reuse.
If neither exists, tell the user to copy config.example.yaml to config.yaml and fill in their values. Stop here.Extract:
message_broker — determines which adapter to loadorchestrator — for connecting to the brokerenvironments — connection detailsRead the adapter file at adapters/{message_broker}.md (in this skill's directory).
If the adapter does not exist, tell the user that the message broker {message_broker} is not yet supported and stop.
If $ARGUMENTS contains an environment name, use it. Otherwise ask the user.
Store the selected environment config as env.
Check /tmp/ops-suite-session/last-triage.json:
If it exists and is less than 10 minutes old for the same DLQ:
If it does not exist or is stale:
→ Run /ops-suite:queue-triage {dlq_name} {env_name} first.If $ARGUMENTS contains a queue name, use it.
Otherwise, list DLQs with messages and let the user pick:
DLQs with messages:
| DLQ Name | Messages | Target Queue |
|--------------------------|----------|----------------------|
| {dlq_name} | {count} | {target_queue} |
Determine the target (main) queue by:
x-first-death-queue header from a sample message.dlq, .dead-letter, .error)Use the adapter to check:
If the target queue has 0 consumers, warn the user that messages will just pile up.
ALWAYS ask for explicit confirmation before moving messages.
Display:
Ready to reprocess:
Source DLQ: {dlq_name}
Target queue: {target_queue}
Messages: {count}
Method: {shovel/move/republish}
This will move {count} messages back to {target_queue}. Proceed? (yes/no)
Use the adapter's preferred method (in order of preference):
After starting the move:
Once the DLQ is empty (or the expected count has been moved):
If messages are not reprocessable (e.g., malformed payloads, already processed):
ALWAYS ask for explicit confirmation before purging.
Purge {count} messages from {dlq_name}? This is irreversible. (yes/no)
Reprocessing Summary:
DLQ: {dlq_name}
Target: {target_queue}
Environment: {env_name}
Messages moved: {count}
Method: {method}
Status: {success/partial/failed}
Post-move check:
DLQ remaining: {count}
Target queue: {count} messages, {consumers} consumers
New DLQ entries: {count} (messages that failed again)
Cleanup:
- Shovel removed: {yes/no/n/a}
- Port-forward killed: {yes/no/n/a}