agentleFS
Sign inStart free
rade-nugrohorade-nugroho/Agentic-Enteprises-Skill/data-architect/SKILL.md

data-architect

Skill9 starsChanged 6 months agoMITView on GitHub

Design data architecture at enterprise and solution levels. Cover data mesh, lakehouse, governance, domain-driven design, conceptual/logical/physical data modeling, platform selection, and compliance frameworks. Produce ADRs, data model diagrams, platform comparison matrices, and governance policy templates. Triggers on "design data platform", "choose data warehouse", "data mesh", "lakehouse architecture", "data governance", "data modeling", "platform selection", "data architecture decision", "compliance framework", or "data strategy". For applied AI solution architecture (RAG data plane, embeddings, vector stores in commercial or enterprise products), use applied-ai-architect-commercial-enterprise. For dbt analytics layers and mart delivery, use analytics-data-engineer—not data-architect.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow the corresponding workflow below

    line 53
  2. Distinctive:

    Start with the business question, not the technology

    line 111
  3. Distinctive:

    Use surrogate keys in physical model.

    line 112

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “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

Data Architect

Overview

Design data architecture at enterprise and solution levels. This skill covers data mesh, lakehouse, governance, domain-driven design, conceptual/logical/physical data modeling, platform selection, and compliance frameworks. Produce ADRs, data model diagrams, platform comparison matrices, and governance policy templates.

When to Use

  • Choosing among warehouse, lake, lakehouse, mesh, or streaming-first patterns
  • Creating conceptual, logical, or physical data models and ADRs
  • Defining data governance, catalog, quality, and compliance frameworks
  • Evaluating data platforms and long-term TCO or vendor trade-offs

When NOT to Use

  • Day-to-day pipeline on-call, SLA breaches, or shift handoffs → use data-system-ops-lead
  • Single-platform SQL tuning or star-schema implementation detail → use data-warehouse-engineer
  • dbt project implementation, mart tests, and analytics CI → use analytics-data-engineer
  • Team roadmaps, sprint cadence, or governance operations execution → use data-manager
  • OWL/RDF ontologies or knowledge-graph construction → use ontology-engineer
  • Application integration patterns and non-data system ADRs → use senior-system-architecture
  • LLM/RAG/copilot solution architecture and AI ADRs → use applied-ai-architect-commercial-enterprise

Features

  • Architecture decision framework with weighted criteria evaluation
  • Progressive data modeling workflow (conceptual → logical → physical)
  • Platform selection decision tree for warehouse/lake/lakehouse/mesh/streaming
  • Governance pillar planning with tool recommendations
  • ADR template generation and stakeholder review processes

Usage

  1. Identify the user's data architecture need (platform choice, modeling, governance, or decision framework)
  2. Follow the corresponding workflow below
  3. Produce structured outputs: ADRs, data model diagrams, platform comparison matrices, or governance policies

Examples

  • User: "Should we use a data lake or data warehouse for our analytics?" Agent: Runs Platform & Technology Selection workflow (Workflow 3), evaluates structured vs raw data needs, recommends warehouse/lake/lakehouse with trade-offs
  • User: "We need to model our customer domain" Agent: Runs Data Modeling Workflow (Workflow 2), starts with conceptual model (entities, relationships), progresses to logical ER diagram, then physical DDL
  • User: "How do we set up data governance for GDPR compliance?" Agent: Runs Governance & Compliance Planning (Workflow 4), maps GDPR requirements to governance pillars, recommends tools and controls

Core Workflows

1. Architecture Decision Framework

Use this 5-step process for any major data architecture decision:

  1. Define the decision context
    • Business drivers (scale, latency, cost, compliance)
    • Constraints (budget, timeline, existing tech, team skills)
    • Stakeholders (data engineers, analysts, product, legal)
  2. Identify alternatives
    • At least 3 options (do nothing, minimal change, transformative)
    • Include cloud-native, hybrid, and open-source alternatives
  3. Evaluate against criteria
    CriterionWeightScore 1-5 each option
    ScalabilityHigh
    Cost (TCO 3yr)High
    Time to valueMedium
    Operational complexityMedium
    Team fitMedium
    Vendor lock-in riskLow
  4. Assess risks & mitigation
    • Migration risk, talent risk, operational risk
    • POC plan for the top 2 options
  5. Document the decision
    • ADR (Architecture Decision Record) with context, decision, consequences
    • Share with stakeholders; revisit quarterly

2. Data Modeling Workflow

Progressive refinement from business to implementation:

StageOutputAudienceKey Activities
ConceptualEntity list, relationships, business glossaryBusiness stakeholdersWorkshops, domain events
LogicalNormalized ER diagram, attributes, keysData analysts, architectsIdentify entities, resolve many-to-many
PhysicalDB-specific DDL, partitions, indexesEngineersPlatform optimization, denormalization

Key principles:

  • Start with the business question, not the technology
  • Use surrogate keys in physical model; natural keys in logical
  • Denormalize only when you have a performance requirement

3. Platform & Technology Selection

Decision tree:

  • Need structured analytics + BI at scale? → Data Warehouse (Snowflake, BigQuery, Redshift)
  • Need raw data + ML + flexible schemas? → Data Lake (S3 + Athena/Spark)
  • Need both with ACID guarantees? → Lakehouse (Databricks, Iceberg, Hudi)
  • Need domain ownership + federated governance? → Data Mesh (multiple warehouses/lakes per domain)
  • Need real-time + low latency? → Streaming-first (Kafka + Flink + materialized views)

4. Governance & Compliance Planning

Governance pillars:

PillarActivitiesTools
Data QualityProfiling, validation rules, anomaly detectiondbt tests, Great Expectations, Monte Carlo
Data CatalogMetadata, lineage, discoveryDataHub, Collibra, Alation
Access ControlRBAC, ABAC, masking, encryptionPlatform-native + Immuta/Okera
Master Data ManagementGolden records, deduplicationInformatica, Reltio, custom MDM
ComplianceGDPR, CCPA, HIPAA, SOC 2Legal review + technical controls

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