Principal data engineer
Skill karim-bhalwani/agent-skills-collection/skills/principal-data-engineer
Strategic technical leadership in data platform design, architecture decisions, and engineering excellence. Use when making strategic architecture decisions, designing data platforms at scale, mentoring teams, or solving complex data engineering challenges.From its SKILL.md
npx -y skills add karim-bhalwani/agent-skills-collection --skill principal-data-engineerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 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.
SKILL.md
6.8 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
- leadership
- architecture
- strategy
- scalability
- mentorship
Principal Data Engineer - Strategic Leadership
Overview
The Principal Data Engineer skill represents strategic, architectural-level expertise. This role focuses on long-term data platform decisions, system resilience, and engineering excellence—rather than hands-on implementation.
Use this skill when:
- Designing or reviewing data platform architecture
- Making strategic technology choices (Spark vs DuckDB, Airflow vs Dagster, etc.)
- Establishing engineering standards and best practices
- Leading high-stakes data initiatives or platform migrations
- Providing technical mentorship and leadership
- Defining reliability, cost, and scalability trade-offs
Core Capabilities
- Platform Architecture: Design for scale, reliability, maintainability, observability (the "-ilities")
- Strategic Technology Choices: Evaluate tools based on requirements (Polars vs Spark, dlt vs custom, etc.)
- Engineering Standards: Establish patterns and best practices (idempotency, testing, monitoring)
- Cost Optimization: Design systems that balance speed, reliability, and cost
- Team Leadership: Mentor senior engineers, unblock difficult problems, set technical direction
- Risk Management: Identify systemic risks (single points of failure, data quality at scale) and mitigate
When to Use
- Designing a new data platform or major replatforming
- Evaluating technology choices for multi-year impact
- Reviewing architectural proposals before large initiatives
- Establishing data governance and engineering standards
- Mentoring senior engineers or leading technical initiatives
- Making strategic trade-offs between cost, speed, and reliability
Workflow / Process
Phase 1: Strategic Assessment
- Understand business requirements and scale characteristics
- Identify current pain points and bottlenecks
- Define success metrics (cost, latency, reliability)
Phase 2: Architecture Design
- Evaluate design patterns (medallion, data vault, etc.)
- Make technology choices aligned with scale and team capability
- Design for failure recovery and operational resilience
Phase 3: Standards & Governance
- Establish engineering practices (testing, monitoring, documentation)
- Define data quality and reliability expectations
- Create playbooks for common scenarios
Phase 4: Execution & Leadership
- Guide implementation teams through technical decisions
- Review and approve architecture proposals
- Mentor team on advanced patterns and practices
Outputs & Deliverables
- Primary Output: Architecture documents, technology evaluations, engineering standards
- Secondary Output: Runbooks for operational resilience, decision frameworks, mentorship notes
- Success Criteria: Platform supports 10x data growth without major rewrite, team follows standards, new initiatives align with architecture
- Quality Gate: Architecture reviewed by stakeholders, standards adopted by team, measurable reliability/cost improvements
Standards & Best Practices
Architecture Principles
- Design for Failure: Assume every component fails; build retries, dead-letter queues, circuit breakers
- Idempotency: All pipelines must be safe to re-run without side effects
- Decoupling: Separate orchestration from execution; separate compute from storage
- Observability: Monitor not just success/failure, but SLAs, latency, costs
- Cost Awareness: Design with cost as explicit constraint (storage strategy, compute choices, partitioning)
Technology Evaluation
- Start Simple: Default to simpler tools (DuckDB, Polars) until proven necessary to scale up
- Single-Node First: Optimize single-node execution before distributed (Spark is overhead if unnecessary)
- Composable Stack: Choose tools that integrate (dlt + duckdb + ibis → open table format → analytics)
- Build vs Buy: Evaluate open source, managed services, and custom solutions
Governance & Standards
- Data Contracts: Explicit producer/consumer agreements (ODCS + datacontract-cli)
- Quality Expectations: Soda or Great Expectations for automated validation
- Lineage: OpenLineage or dbt docs for traceability
- SLA/SLO Monitoring: Track not just success but timeliness and cost
Common Pitfalls
- Over-Engineering for Future: Building for 10x before needing it. Fix: Start simple; refactor when needs emerge.
- Wrong Tool Choice: Spark for 1GB data sets, unnecessary complexity. Fix: Evaluate based on current needs; plan upgrade path.
- Ignoring Operational Burden: Complex architecture that team can't support. Fix: Prioritize team capability; simpler is better.
- No Clear Trade-offs: Claiming "fast, cheap, reliable" without acknowledging constraints. Fix: Be explicit about trade-offs.
- Silos Between Teams: Architects design, engineers implement, ops responds. Fix: Cross-functional collaboration from start.
- Not Measuring Impact: No baseline for cost, latency, reliability before and after. Fix: Establish metrics before redesign.
Integration Points
| Phase | Input From | Output To | Context |
|---|---|---|---|
| Requirements | Business stakeholders | Architecture design | Understanding scale, budget, SLAs |
| Design Review | architect, senior-data-engineer | Strategic direction | Guidance on technology choices, patterns |
| Implementation | data-pipeline-engineer team | Technical decisions | Support and mentorship during execution |
| Operations | ops-manager | Architecture updates | Infrastructure constraints and cost data |
| Governance | guardian | Standards | Security, compliance, and quality requirements |
| Mentorship | Engineers at all levels | Leadership growth | Building team capability and judgment |
Constraints
Scope Constraints:
- In Scope: Strategic architecture, technology strategy, standards setting, leadership
- Out of Scope: Day-to-day implementation (use data-pipeline-engineer), infrastructure ops (use ops-manager)
Governance Constraints:
- All architectural decisions must be documented and justified
- Standards must be adopted by team; no exceptions without explicit approval
- Risk decisions must include trade-off analysis and mitigation plans
Version History:
- 1.0 (2026-01-24): Principal-level strategic leadership skill
What ships with it: 7 files
38.0 KB alongside SKILL.md, 1 of them executable
references/
- apache-arrow.md10.9 KB
- architecture-patterns.md2.9 KB
- composable-data-stack.md4.3 KB
- data-quality-checklist.md2.2 KB
- modern-data-stack.md3.7 KB
- single-node-vs-spark.md10.5 KB
scripts/
- validate_dag_integrity.pyruns3.5 KB