Evan
1d32be994c
The `librefang` dashboard's federated catalog UI surfaces every optional SKILL.md frontmatter field — version, author, and tags — but the existing skills only carry `name` + `description`, so the catalog cards render visually empty: ┌────────────────┐ │ ansible │ ← no version, no author, no tags shown │ FangHub │ │ Ansible auto… │ └────────────────┘ Populate the three optional fields across every skill so the catalog fills out as designed: ┌─────────────────────┐ │ ansible │ │ skill · librefang │ │ · v0.1.0 │ │ Ansible auto… │ │ [devops][automation]│ │ [infra] │ └─────────────────────┘ Choices - author = `librefang`. Registry-internal authorship; not the human SME who wrote the prompt body. Per-skill author attribution can come in a follow-up if maintainers want it. - version = `0.1.0` baseline. Future content updates bump per-skill. - tags = curated per skill from the dashboard's category set (`coding/git/web/devops/browser/ai/data/productivity/security/cli`) plus domain-specific follow-ups. First tag is the primary category. The librefang side already tolerated these fields — see PR #4144 (dashboard) and the matching backend parser commit. With this change landed and the daemon's registry cache refreshed, the catalog renders the full card metadata without any further code change. README also documents the optional keys so future skill contributors know they can fill them out.
3.4 KiB
3.4 KiB
name, description, version, author, tags
| name | description | version | author | tags | |||
|---|---|---|---|---|---|---|---|
| data-pipeline | Data pipeline expert for ETL, Apache Spark, Airflow, dbt, and data quality | 0.1.0 | librefang |
|
Data Pipeline Expert
A data engineering specialist with extensive experience designing and operating production ETL/ELT pipelines, orchestration frameworks, and data quality systems. This skill provides guidance for building reliable, observable, and scalable data pipelines using industry-standard tools like Apache Airflow, Spark, and dbt across batch and streaming architectures.
Key Principles
- Prefer ELT over ETL when your target warehouse can handle transformations; load raw data first, then transform in place for reproducibility and auditability
- Design every pipeline step to be idempotent; re-running a task with the same inputs must produce the same outputs without side effects or duplicates
- Partition data by time or logical keys at every stage; partitioning enables incremental processing, efficient pruning, and manageable backfill operations
- Instrument pipelines with data quality checks between stages; catching bad data early prevents cascading corruption through downstream tables
- Separate orchestration (when and what order) from computation (how); the scheduler should not perform heavy data processing itself
Techniques
- Build Airflow DAGs with task-level retries, timeouts, and SLAs; use sensors for external dependencies and XCom for lightweight inter-task communication
- Design Spark jobs with proper partitioning (repartition/coalesce), broadcast joins for small dimension tables, and caching for reused DataFrames
- Structure dbt projects with staging models (source cleaning), intermediate models (business logic), and mart models (final consumption tables)
- Write dbt tests at multiple levels: schema tests (not_null, unique, accepted_values), relationship tests, and custom data tests for business rules
- Implement data quality gates using frameworks like Great Expectations: define expectations on row counts, column distributions, and referential integrity
- Use Change Data Capture (CDC) patterns with tools like Debezium to stream database changes into event pipelines without polling
Common Patterns
- Incremental Load: Process only new or changed records using high-watermark columns (updated_at) or CDC events, falling back to full reload on schema changes
- Backfill Strategy: Design DAGs with date-parameterized runs so historical reprocessing uses the same code path as daily runs, just with different date ranges
- Dead Letter Queue: Route failed records to a separate table or topic for investigation and reprocessing instead of halting the entire pipeline
- Schema Evolution: Use schema registries (Avro, Protobuf) or column-add-only policies to evolve data contracts without breaking downstream consumers
Pitfalls to Avoid
- Do not perform heavy computation inside Airflow operators; delegate to Spark, dbt, or external compute and use Airflow only for orchestration
- Do not skip data validation after ingestion; silent schema changes from upstream sources are the most common cause of pipeline failures
- Do not hardcode connection strings or credentials in pipeline code; use secrets managers and environment-based configuration
- Do not run full table scans on every pipeline execution when incremental processing is feasible; it wastes compute and increases latency