agentsclimarketplace

Streaming and messaging systems

Skill vaquarkhan/data-engineering-agent-skills/skills/streaming-and-messaging-systems

Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.

Install
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill streaming-and-messaging-systems

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Guides agents through event streaming and real-time data pipeline design. Use when working with Kafka, Kinesis, Flink, stream processing, windowing, stateful consumers, or near-real-time publish flows.

SKILL.md

3.0 KB, as published. Nobody here has run it

Streaming And Messaging Systems

Overview

Use this skill for continuous data movement and real-time processing. It helps agents design safe event pipelines around brokers and stream processors such as Kafka, Kinesis, and Flink, with attention to ordering, state, replay, schema evolution, and delivery guarantees.

When to Use

  • designing or modifying Kafka topics, consumers, or stream processors
  • using Kinesis for event ingestion or streaming delivery
  • implementing Flink jobs or stateful stream transformations
  • defining near-real-time pipelines, windows, watermarks, and replay behavior
  • handling schemas and contracts for event-driven systems

Do not use this when the workload is purely batch and does not require streaming semantics.

Workflow

  1. Define the event contract. Include:

    • event key
    • schema and versioning
    • ordering expectations
    • delivery guarantees
    • retention and replay policy

  2. Choose the right platform role.

    • Kafka: durable event backbone and broad ecosystem
    • Kinesis: AWS-native streaming ingestion and transport
    • Flink: stateful stream processing and event-time logic

  3. Design for state and late data. Account for:

    • watermarks
    • windows
    • deduplication
    • exactly-once or at-least-once semantics
    • checkpointing and recovery

  4. Make consumer behavior observable. Lag, failed checkpoints, poison messages, schema drift, and dead-letter handling should be planned, not discovered in production. For production Kafka hardening, load kafka-resilience-and-schema-evolution. For live lag or broker metadata before changes, load mcp-data-observability-integration.

  5. Treat replay as a first-class operation. Reprocessing events should not depend on manual guesswork.

Common Rationalizations

RationalizationReality
"Streaming just means faster batch."Streaming introduces ordering, state, replay, and time semantics that batch systems do not have.
"We can ignore schema evolution because events are small."Event size does not reduce contract risk; schema drift can break many downstream consumers.
"Exactly-once is automatic."Delivery semantics depend on end-to-end design, state handling, sinks, and replay behavior.

Red Flags

  • no explicit event contract or key strategy
  • replay and retention are undefined
  • time semantics are assumed instead of specified
  • consumer lag and dead-letter strategy are missing
  • stateful processing has no checkpoint or recovery plan

Verification

  • Event schema, keys, retention, and replay rules are defined
  • Platform responsibilities are clear across broker and processor layers
  • Time semantics, state, and recovery design are explicit
  • Operational visibility exists for lag, failures, and bad records

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.